wood burning stoves 2.0*
The moose likes Beginning Java and the fly likes Problems with class variables and abstract classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Problems with class variables and abstract classes" Watch "Problems with class variables and abstract classes" New topic
Author

Problems with class variables and abstract classes

Chris Copeland
Greenhorn

Joined: Oct 20, 2003
Posts: 10
Hey All,
Our Java instuctor is having us modify one of our existing programs we did for class to use an abstract superclass. The project was a simple ATM. The classes where savings and checking and an ATMinterface. The change was to take the generic classes out of checking and savings about put them in an abstract class BankAccount. Then we would implement the non-generic methods abstract.
Then we do something like the following:
BankAccount ba = null;
Checking checking = new Checking();
Savings savings = new Savings();
<get input from user on checking or savings>
if (choice = CHECKING)
{
ba = checking;
}
else
{
ba = savings;
}
<then we use ba.withdraw or ba.deposit to access the methods of whatever class was chosen>
My problem is this... I am using class variables in my existing savings and checking classes... My understanding was that no BankAccount object would be created and it would ONLY be used as a framework for the Checking and Savings objects when they were instantiated. However, this isn't working for me. For some reason everytime I call Savings savings = new Savings(); it is not only instantiating a savings object... it is ALSO instantiating a BankAccount object. I saw this because I added a constructor to the BankAccount object with a print statement.
I thought that this shouldn't happen. I thought I would have to issue super() from the subclass constructor to call the superclas constructor? Anyway the problem is with balance. I am maintaining two separate balances. When I access the methods that were non-generic and were defined in the checking/savings classes... then the balance in those classes are updated, but when I access the generic classes that were defined in the abstract class... the balance in the abstract class is updated!
I am only defining this abstract class to be a framework...I don't want it to maintain any memory and I certainly don't want it's functionality being used.
What problem am I having? I could REALLY use some help!
Thanks,
Chris Copeland
skywalkr2@netzero.net
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

Hi Chris,
Welcome to JavaRanch!
If you construct an object of a subclass, that object contains, as a part of itself, a superclass object. It's not a separate object, it's really part of the one object.
That superclass part always gets constructed. If you use super() explicitly, then you get to pick the superclass constructor. If you don't, then the no-argument one gets called by default.
Anyhow, what you're doing is conceptually wrong. Since BankAccount won't ever be separately instantiated, why does it need its own separate balance? Or to ask the same question a slightly different way, if a CheckingAccount is a kind of BankAccount, why does it need its own separate balance -- why can't it just inherit the one from BankAccount?
Now, if you really mean "class variable," as in a static variable, then boy, you've got a problem here. Each BankAccount has a different balance, so each object should have its own balance variable, yes? If your balance is not static, then good. If it is static, make it unstatic, now!
So here's what you do (this is only one possibility, and not even necessarily the very best one, but it's an easy one
  • Delete the balance variable in CheckingAccount.
  • Mark the balance variable in BankAccount "protected."
  • Define the BankAccount methods that have obvious generic implementations. Those that don't, leave them marked "abstract."
  • Implement the abstract methods in CheckingAccount, and also, optionally, override some of the non-abstract methods, as needed.
  • All the methods should operate on the one single balance variable.


  • Now, you've got something that starts to resemble the Right Way to Do It.
    Make sense yet?
    [ October 20, 2003: Message edited by: Ernest Friedman-Hill ]

    [Jess in Action][AskingGoodQuestions]
    Chris Copeland
    Greenhorn

    Joined: Oct 20, 2003
    Posts: 10
    It makes PERFECT sense. I was too caught up in the methods and completely forgot the class variables themselves would be inherited!
    Thanks!
    chris
     
    wood burning stoves
     
    subject: Problems with class variables and abstract classes