• Post Reply Bookmark Topic Watch Topic
  • New Topic

Too many methods  RSS feed

 
Benjamin Power
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I am trying to make a small general ledger program which will consist of the following classes:
- Main_Program - displays a text based menu for recording different transactions
- Ledger - class that holds a List/HashMap of Account objects
- Account - class that holds the String AccountName and int AccounNo along with a List/HashMap that holds AccountEntry objects
- AccountEntry - Object that stores the date particulars and amount of the transaction along with an int AccountEntryID.

The problem is that if I want to display an amount from an AccountEntry I have to use the following method calls:

1. Main_Program - Call method in Ledger called getAccountEntryAmount(AccountEntryID)
2. Ledger - Call method in Account called getAccountEntryAmount(AccountEntryID)
3. Account - Call method in AccountEntry called getAccountEntryAmount(AccountEntryID)

All these methods to get one AccountEntryAmount value. If I were to have many Ledger type lists such as customer lists etc the Main_Program will have methods corresponding to all the lowest level class' methods.

Is there a shortcut to access a variable (eg AccountEntryAmount) that is so deeply nested i.e main_Program-->Ledger-->Account-->AccountEntry-->Amount, so as to avoid so many identical methods calls?
 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One solution that comes to mind is putting most of this logic in Main_Program. You can do this by creating just a Ledger.getAccount() method that returns an Account object. Then main() (or some other method in Main_Program can call methods on that Account directly (such as an Account.getEntry() method, rather than using the indirect scheme you showed above.

However, I don't think this will completely solve your problem with multiple types of ledgers. If you suddenly want a Ledger that holds Employee objects instead, you have to add other methods to retrieve them. This situation seems to beg for a class hierarchy. For example, you can make Ledger a base class and create two subclasses: AccountLedger and EmployeeLedger.

If you are unfamiliar with inheritence and polymorphism, you will need to research these topics before going much further. you should also research design patterns because they describe general solutions to types of problems. In fact, there might be a design pattern that addresses the issues you are encountering with this project.

I hope this helps. Let us know if you need more help.

Regards,

Layne
 
Benjamin Power
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Layne, one question though, should I pass a complete copy of the object or just its reference?

Cheers
Benjamin Power
 
Joel McNary
Bartender
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In Java, you can only pass the reference to the object. (And through the wonders of lexical gymnastics which only a few have mastered, this is still considered pass-by-value....)

By the way,

Welcome to JavaRanch, blp blp. We hope that you enjoy it here. One small detail, though: please read our Naming Policyand Change Your Display Name to comply. (We are looking for real-sounding names; "Benjamin Power" would be acceptable)
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't want to overwhelm you in the beginner forum but the question shows interest in the subtleties of design, so here's something to think about. It's tempting to write something like:

This means that your main program intimately knows the structure of all the objects in the system. In larger and more complex systems this gets to be a real problem, so it's good to look for alternatives. Think about how you'd implement this:

Now instead of asking for data we're telling ledger what to do, a command instead of a query. For more on these ideas, see
Demeter's Rather Good Idea and the tongue in cheek Knight's Principles, particularly "Never do any work that you can get someone else to do for you"

If all that is interesting, join us down the page at the OO, UML etc forum for more of this cool theoretical stuff. Cheers!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!