3 Replies Latest reply on May 29, 2018 8:06 PM by NickR2600-Oracle Branched from an earlier discussion.

    Re: Abstract Class

    NickR2600-Oracle

      Great question!  You're absolutely correct.  Abstract classes may contain methods with implementations.  These are called concrete methods.  Abstract classes may also contain methods without implementations.  These are called abstract methods.  To make a method abstract, you'd replace everything within the curly braces with a semi-colon.  So for example, an abstract printDetails() method would look like this:

      public void printDetails();
      

       

      Concrete classes, like SavingsAccount and CheckingAccount, can't contain abstract methods.  That means at some point in the inheritance structure, you'll need write a version of these methods with an implementation.  Otherwise, you won't be able to create instances of those classes.  In the case of SavingsAccount, this would be:

      public void printDetails(){
           System.out.println(accountType +" #" +accountNum);
           System.out.println("Account Owner: " +accountOwner);
           System.out.println("Balance: $" +balance);
           System.out.println("Interest Rate: " +interestRate);
           System.out.println("");
      }
      

       

      And in CheckingAccount this would be:

      public void printDetails(){
           System.out.println(accountType +" #" +accountNum);
           System.out.println("Account Owner: " +accountOwner);
           System.out.println("Balance: $" +balance);
           System.out.println("");
      }
      


      You'll notice both methods print the account owner and balance.  Generally, we want to reduce duplication like this.  It makes the code more maintainable if this functionality were written in a single place rather than duplicated.  This is because if we realize we've made a mistake or need to have additional functionality, we'd only need to make edits in one place.  This makes the printDetails() method of the Account super class the perfect place write this functionality once.  But doing so means the method can no longer be abstract.

        • 1. Re: Abstract Class
          NickR2600-Oracle

          So when would it be beneficial to have an abstract method in a super class?  One answer would be because the sub classes have no shared functionality.  Or in other words, because the functionality is so different between subclasses.  Or because the functionality can't be defined yet.

           

          In Java Puzzle Ball, I have an abstract class called GameObject. It's inherited by a lot of different concrete classes: bumpers, assignable behaviors, level geometry...  And one if its responsibilities is to define what happens when a collision occurs.  But I have to leave the collision effect method abstract.  The geometry of all these objects are so dramatically different, there isn't any shared functionality I can write to define how the physics of all these different angles and shapes should work.  The best I can do is write an abstract method as a promise to implement the functionality somewhere later down the inheritance structure.

           

          1 person found this helpful
          • 2. Re: Abstract Class
            AjayKumarGuttikonda

            Thank you so much for taking time out and answering the question in very elaborated manner. I understand, the conclusion is Account class need not be abstract as all methods are implemented and also there is no problem Account class being abstract as the abstract class by definition can have all methods implemented. Can you please also explain why in this case it is beneficial to have Account class as abstract since we have implemented all methods.

            • 3. Re: Abstract Class
              NickR2600-Oracle

              You got it.  I'm glad you're enjoying the course

               

              It's more of a design choice in this example.  Even though Account could technically exist as a concrete class, I only meant for it to be a container for all the fields and methods shared by savings and checking accounts.  So to reinforce that decision and prevent instances of Accounts from getting created, the class is left abstract.

               

              One other thing to consider is that Accounts don't have an accountType field, but savings and checking account classes do.  Looking back, maybe I should have written an abstract method into the Account class to somehow enforce the need for this field.