abstract method in lab 4?

Hi Carol,

These are such amazing questions!  I was hoping someone would pick up on this.  You've come so far since the beginning of the course!  Both questions share the same answer.

Yes, getAccountType() in the Account class is an abstract method.  Abstract methods may only exist in abstract classes.  They have no implementation and must be implemented later by any non-abstract (known as "concrete") sub classes.  I thought I should write this method in the Account class because of how the ArrayList stream works.  accountList contains only accounts.  If you create a stream and use the dot operator on an account instance, you can only access the public fields and methods written in the Account class.  That is, unless you resort to casting like in button6Pressed().  I thought it would be unfair and messy to make people cast, because we didn't really cover that technique.  So to avoid casting, I wrote getAccountType() in the Account class.  The implementation which gets used depends on whether the account is a Savings or a Checking account.  It's a sneaky way of taking advantage of polymorphism.

Nick

I would LOVE to create more game-based learning courses like this!  The tricky part is convincing Oracle it's worthwhile.  Although games can be a tremendously powerful way to learn, they take a while to develop and are unfamiliar territory for the corporate world.  Ha ha, so you're welcome to help me lobby.  How would you feel about sending your thoughts about the course to the mailing list ([email protected])?  That list goes to me and a couple higher-ups who I'd like to convince that game-based learning should be a priority.

1) We'll keep the forum active after June 1.  But it will be a lot harder for me to answer questions as frequently as before.

2) Have you had an OTN account since 2013?  I believe the logins between the OLL and OTN are shared.  If not, you might have found a bug,

3) I highly recommend Oracle Academy Java Foundations.  I wrote that course to be just as playful and explorative as the Java Puzzle Ball MOOC.  Membership with Oracle Academy is free, as long as you're associated with some sort of educational institution.  There's also a free JDK 8 Lambda MOOC created by Simon Ritter available on the Oracle Learning Library.  That course is more advanced and dives a lot deeper into Lambda and Streams.  One last option is convincing your employer to pay for training through Oracle University Java SE 8 Fundamentals.  Oracle University targets corporate customers.

Nick

Thanks!  Yes, your experience and growth with the course is a remarkable story.

1) Good luck!

2) OTN stands for Oracle Technical Network.  The forum is a part of OTN.

3) Oh, interesting to hear about the email.  I was wondering how Oracle ended up promoting the course.  You wouldn't necessarily need to be a student to get an Oracle Academy membership.  I believe it's also possible to join as an instructor or if you're on a school's advisory committee.  I wonder if alumni qualifies?  I'll try to think of other options.  I think the first lesson of Simon's lambda course might be doable.  But the next two get harder.

4) Correct, the Bumper and Account classes are both abstract and super classes.  In fact, I think an abstract class would have be a super class in order to be useful.  Since instances of an abstract class can't be created, an abstract class would need to be extended by a subclass at some point.

Nick

Yes.  It is possible to write the program so that the abstract getAccountType() method is omitted from the Account class.  It just means doing a little casting whenever you want to call that method on an Account ArrayList object.  Abstract methods are a design option programmers have available to them. People often use the analogy of a "contract" to describe abstract methods.  Abstract methods mandate that all potential sub classes promise to provide their own implementation for the method.  By writing getAcountType() as an abstract method in the Account class, it forces all potential sub classes to provide their own implementation.  I didn't think I could provide an implementation in the Account class because it would rely on retrieving a static field variable which didn't yet exist.

You're right.  In fact, NetBeans won't even allow sub classes to call super.getAccountType(), since the abstract method getAccountType() doesn't have an implementation.  Sometimes it's useful to call a super class's version of a method so you can pass values to it.  Other times, you do it to reuse the same logic found in the super class's version of the method.  For example, calling super.printDetails() in the printDetails() method of the CheckingAccount class is a way to reuse the same printout logic.

I saw.  Thank you, thank you!  That was a such a nicely written letter.

Nick