Win a copy of High Performance Python for Data Analytics this week in the Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Jj Roberts
  • Carey Brown
Bartenders:
  • salvin francis
  • Frits Walraven
  • Piet Souris

inheritance problem

 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guys, hope you can help me with this OOP design.
I have a class BankAccount, and few more classes the extends the BankAccount. Each of these subclasses have diferent methods to deal with the BankAccount attribute currency.
The problem is that in runtime i have to check what type of subclass im receiving from a List<BankAccount>. And depending on the type to call the methods specific.

Im using instance of to check the type of the class, but... is this a bad design?
Because if more classes and added and extend the BankAccount i have to change the code to check what type of the subclass im dealing...

Hope is clear...
 
Marshal
Posts: 71752
312
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

b os wrote:I guys, hope you can help me with this OOP design.

Yes, we can help, and welcome to the Ranch

. . . Each of these subclasses have diferent methods . . . in runtime i have to check what type of subclass . . . And depending on the type to call the methods specific.

Im using instance of . . .

Afraid instanceof is a bad sign, except in equals():-There are different kinds of inheritance, including type extension and functional extension. Don't look them up; I didn't find anything good to read about either. Basically you can create subclasses with additional methods, or you create subclasses without additional methods. So you might have this sort of class:-Can you see a problem there? The euro account class hasn't got the convert pounds/dollars methods, and the other subtypes don't need them all, only some of them. Why not make the bank account class abstract? Then you can do this sort of thing:-Look, no hands! Look, no feet! Look, no teeth polymorphism! Use @Override on all methods you think you are overriding. You will need super(xxx); calls in your constructors. It would be even more object‑oriented to have Currency objects and pass them as arguments to the convert methodBut that will get you out of needing inheritance at all.
 
B Ortet
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank for the response.
I was using the BankAccount as an abstract class and those methods as abstract as well. But I made a mistake in my the code, when passing arguments and the methods werent behaving properly. And that led me to a big confusion, and i removed the abstract methods from the parent class. And implementing them in the child class.
Wich led me to try to call the child method from the Parent reference... As your example its solved now.

I have been using this forum to clarify some doubts, only now i signed.
Starting my programming journey with java...
 
Sheriff
Posts: 16049
266
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another thing you might want to consider is whether the responsibility of doing currency conversion is even appropriately assigned to a BankAccount class. I don't think it is. Why would I introduce inheritance into the design just so that I can do specific currency conversions? That seems like a responsibility that needs to be assigned to a different class, perhaps Currency or CurrencyConverter. A BankAccount could certainly delegate the responsibility over to that class but I don't think it's appropriate to introduce inheritance to the design of BankAccount just for this responsibility.
 
B Ortet
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are probably right. I belive that serves as an example. As in my problem was:


 
Campbell Ritchie
Marshal
Posts: 71752
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I did say it would be more object‑oriented to have a currency object, and I had to guess what sort of methods might have gone walkies. There was obviously enough information that I could get somewhere near the real problem, anyway.
 
Junilu Lacar
Sheriff
Posts: 16049
266
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Don't use floating point type for fields that represent money.
 
Campbell Ritchie
Marshal
Posts: 71752
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:Don't use floating point type for fields that represent money

And I would say, don't use the float datatype for anything because of its poor precision.

Actually, there are a few methods and constructors which require a float where a double would have been easier to use.

Search my (No 109202) posts for

BigDecimal divide

in this forum and Java in General and you will find what you should use for money. It is also possible to denominate money in cents/pence and use integer arithmetic.
 
B Ortet
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok. I didnt know. I will look it up.
 
B Ortet
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guys I have another doubt, regarding de OOP design. As for example the class in the previous post. Its a bad design to have, the list of CertificateDeposit inside the CheckingAccount?
In the relational database, the CertificateDeposit table, have as a foreign key the "AccountNumber" of the CheckingAccount.


Could you recomend me a good book, or any resource about de Object Oriented design, with exercises?
 
Campbell Ritchie
Marshal
Posts: 71752
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What do certificate deposits have to do with a cheque account? I think you will answer your own question when you explain that.
 
B Ortet
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Its associated to he checking account. A user can only have a certificate deposits if he as a Checking account.

I have same doubt when aplied to a Session of a UserAccount.
Everytime a user login, results of a Session, so i belive the UserAccount should store all the Session inside the class in a List.
Please correct me if im thinking the wrong way...

 
Campbell Ritchie
Marshal
Posts: 71752
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One problem at a time, please; that will make things easier

Does the account or the user have certificate deposits?

Actually, I find it easier to envisage that an account will have sessions; a deposit to or a payment from an account would constitute a session or part of a session.
 
B Ortet
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
:-)
The CheckingAccount that have the CertificateDeposits. He could have or not... Depending on the cliente.
The CheckingAccount, can have various types of baking accounts associated to it.

For example, a user has a UserAccount. and he can do some operations with that userAccount. Each time he log in, there will be created a Session, with the date and time of the login.
Its correct to have those Sessions Stored in the UserAccount class?

 
Campbell Ritchie
Marshal
Posts: 71752
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Don't know. Every time you psot, you seem to introduce a new datatype. It would be necessary to know what all the datatypes are. In the end, it will ahve to be your decision. We can suggest and advise you but not instruct your.
 
B Ortet
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Im sorry, i probably expressed in the wrong way.
What im trying to understand is if makes sense to store the list of bankAccounts types that are associated with the checkingAccount, inside the CheckingAccount class.
In the relational database, the way i know the the various types of bankAccount is related with the checkingAccount is by creating a foreign Key of the checkingAccount inside those tables...

It is the same as the example i put in the previous post, no new datatype.

 
Saloon Keeper
Posts: 7622
68
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A simple is-a/has-a test:

A CheckingAccount is-a BankAccount
TRUE therefore probably inheritance

A CheckingAccount has-zero-or-more BankAccount(s)
FALSE therefore not aggregation

A Customer has-zero-or-more BankAccount(s)
TRUE therefore probably aggregation
 
B Ortet
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


A CheckingAccount has-zero-or-more BankAccount(s)
FALSE therefore not aggregation


Its actually true. But a CheckingAccount doesnt have one or more CheckingAccount.
But it has the SavingAccount the CertificateDepositAccount, and the other types of account the extends the BankAccount except the CheckingAccount.
 
Carey Brown
Saloon Keeper
Posts: 7622
68
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

B Ortet wrote:

A CheckingAccount has-zero-or-more BankAccount(s)
FALSE therefore not aggregation

Its actually true. But a CheckingAccount doesnt have one or more CheckingAccount.
But it has the SavingAccount the CertificateDepositAccount, and the other types of account the extends the BankAccount except the CheckingAccount.

I would say the CUSTOMER has various accounts, such as CheckingAccount and SavingsAccount, but nowhere should one account OWN another account. A Customer may start with a CheckingAccount and a CheckingAccount may be the Customer's primary account, but what does it mean for a CheckingAccount to OWN a SavingsAccount? What kind of a relationship would that be? Can a Customer have a  SavingsAccount without a CheckingAccount?
 
B Ortet
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A customer cant have any type of account unless he has a checking account. He can have multiple checkingAccount.
But all those other types of accounts will depend on the CheckingAccount. So a customer can not have a SavingAccount without a CheckingAccount.
In the case of the relationship that a Customer has various accounts... how could it be structured?
Lets say a Customer class its like this, and perhaps it has more information detail about the customer


public class Customer{
 private int customerID;
 private String customerFirstName;
 private String customerLastName;
 private CustomerAccount customerAccount;
}



Is this a bad pratice?
 
Carey Brown
Saloon Keeper
Posts: 7622
68
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The fact that the Customer must have a CheckingAccount before it can have any other type  of account may be a rule of this particular bank but it does not mean that CheckingAccount has-a SavingsAccount. It is the Customer who OWNs the various BankAccounts, perhaps even more than one SavingsAccount. So, I tweaked what you had slightly. No need to put the prefix "customer" in front of each field name. As the fields are accessed it will be obvious that you are dealing with the Customer.firstName, for instance. And then the Customer will have a List of BankAccount objects. This is a good start.

 
Campbell Ritchie
Marshal
Posts: 71752
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It shouldn't be too difficult to ensure that a cheque account has to be included in the accounts list, possibly by passing it to the customer's constructor, and enforcing a rule that whenever the last cheque account is closed, all the other accounts must be closed, too. This is where OO programming can make it easier if you restrict closing an account to via a method in the customer object.
 
B Ortet
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, i can see it. It makes sense...
But in a case of a customer that as multiple CheckingAccount, and multiple SavingAccount. What kind of relationship the accounts would have? Because the SavingAccount doesnt exist without a CheckingAccount...
Example:
Customer A has a CheckingAccount = {2, 3}
And the SavingAccount id = 21, its associated with the CheckingAccount = 2
And the SavingAccount id = 31 its associated with the CheckingAccount = 3;

Could it be:


Where the checking account its a reference of the CheckingAccount in the list of the BankAccount in the Customer class??
 
Carey Brown
Saloon Keeper
Posts: 7622
68
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If a Customer has two CheckingAccounts (not likely, but ok), and two SavingsAccounts (very likely), I would think that BOTH SavingsAccounts would be associated with the Customer's PRIMARY CheckingAccount, NOT a different CheckingAccount for the other SavingAccount. You could write your Customer class in such a way as to enforce that the primary CheckingAccount is always at index zero of the List<BankAccount>.

The various individual accounts would not need a reference to the primary account because they are not responsible for maintaining that relationship, but it is quite likely that the individual BankAccounts would have a reference back to the owner (Customer) and could call owner.getPrimaryAccount() or some such.
 
my overalls have superpowers - they repel people who think fashion is important. Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic