Forum Stats

  • 3,824,994 Users
  • 2,260,452 Discussions
  • 7,896,378 Comments

Discussions

Implementation question from Lab 3

TIM PETCHEL
TIM PETCHEL Member Posts: 13
edited Nov 21, 2017 1:27PM in Java Puzzle Ball

All,

I understand the concepts but am struggling with the implementation. I understand that account type is a local method to each subclass. But, can't the super class have an account type method that has no implementation but is overridden by the sub classes with the account type? Thanks for your help in advance.

mNemOTG-467455
«1

Answers

  • OTG-467455
    OTG-467455 Member Posts: 506 Bronze Badge
    edited Nov 19, 2017 4:48AM

    Hi Tim,

    I don't want to provide the answer directly, so I am going to try give clues as to how to implement the solution.

    The super class is  the template for creating all the other sub classes and would contain only the properties, constructors and methods that would be common to all sub classes.  The sub classes being referred to are the Savings and Checking Accounts.

    The Savings Account and Checking Account classes would inherit all the account class properties, constructors and methods from the Account class (Super Class)

    Considering that Savings and Checking Account classes operate differently in terms of interest.   Interest earned is only applicable to the Savings Account. 

    The Savings Account should have a method which is unique to it for this purpose.  That is to calculate the interest that savings accounts earn.   Remember this does not occur in the Account super class nor in the checking account.   The checking account does not earn interest.

    In both the Savings Account and the Checking Account one would override the printDetails method with code which is relevant to the account that is being processed.

    Another tip;  Take a look at the output produced by the course coordinator.   You will need to decide which System.out.println statements need re-positioning in t the code and some statements could even be removed entirely.

    Use a step wise approach to solve the problem.

    Comment out the lines of code you think don't need to be in the Savings Account class

    Try run compile and run the main method.

    Once you find the output is similar to the example in the lab then remove the code you commented out.

    Look at the main method and do the same.

    Hope this helps.

    mNemTIM PETCHEL
  • TIM PETCHEL
    TIM PETCHEL Member Posts: 13
    edited Nov 20, 2017 1:49PM

    Nice explanation. Thanks

  • TIM PETCHEL
    TIM PETCHEL Member Posts: 13
    edited Nov 20, 2017 3:23PM

    Yes it helps, thanks. I was just thinking of the accountType. I know it is unique to each account type but couldn’t it also be an unimplemented method of the account class. When the subclasses inherit it they supply their unique implementation, i.e.: accountType.

  • OTG-467455
    OTG-467455 Member Posts: 506 Bronze Badge
    edited Nov 20, 2017 3:37PM

    Hi Tim.   That is an interesting one.  Why don't we both try it out.  I can see why it would be implemented in each sub class only.  The difficulty is trying to implement it in the super class without causing other problems.  When one places a property or a method into the super class it becomes a global or should I say static  entity.  But maybe if we research it could be possible or not.

  • OTG-467455
    OTG-467455 Member Posts: 506 Bronze Badge
    edited Nov 20, 2017 4:06PM

    Hi Tim,  You could implement the account type into the abstract super class, but then you will have to change the way the constructor is called and provide it with the account type.

    Change the constructor method to allow it to receive the account type parameter value "Savings Account" or "Checking Account".

    Then change the call to the constructor to include the value when creating the account type.   new SavingsAccount("Savings Account:,"Duke", 100);

    TIM PETCHELmNem
  • TIM PETCHEL
    TIM PETCHEL Member Posts: 13
    edited Nov 20, 2017 5:18PM

    ok I will Try it out and let you know. I worked on the formatting of the output. manged some ofit Still playing with it.

    TIM PETCHEL
  • mNem
    mNem Member Posts: 1,380 Gold Trophy
    edited Nov 21, 2017 12:51AM

    Like your idea.

    new SavingsAccount("Savings Account:" ,"Duke", 100);

    May be a tiny modification in the child and parent constructors like, 

    public class SavingsAccount1 extends Account1 {   private static String accountType = "Savings Account";   //Constructor   public SavingsAccount1(String o, double b) {      super(o, b, accountType);   }...}

    and then the super constructor is like ...

      public Account1(String o, double b, String acType) {      accountType = acType;       ...   }

    Now, by just implementing a method getAccountType() at the super class, you can avoid implementing them in each child.

    OTG-467455
  • TIM PETCHEL
    TIM PETCHEL Member Posts: 13
    edited Nov 21, 2017 8:54AM

    Actually, I like that. You don’t have to call separate methods for savings and checking accounts

  • TIM PETCHEL
    TIM PETCHEL Member Posts: 13
    edited Nov 21, 2017 9:08AM

    We could create new account types without hardcoding

  • OTG-467455
    OTG-467455 Member Posts: 506 Bronze Badge
    edited Nov 21, 2017 10:01AM

    Hi Tim,  The code demonstrated by mNem is what I was referring to.  It is as demonstrated in the earlier labs, just that you now fully implement inheritance and overriding.

    TIM PETCHEL