views:

71

answers:

5

Hi,

I have this class model where, Bank is a class which is now going for computerized Banking network. This must have ATM(Automatic Teller Machine) and also Human Cashier.

I used Generalization and have taken a class called AccountHandlers which inherits Bank class. This AccountHandlers further have ATM and HumanCashier aggregated to it.

Now the thing is, my friend was arguing that i have taken the whole thing wrong. According to him AccountHandlers must be aggregated to Bank and that ATM and HumanCashier must inherit to AccountHandlers.

I am a bit confused over it. How can i model it!! or is that both method correct?

+1  A: 

If it works it's correct. Don't get caught up on the waste-of-time that is UML modelling. Write a prototype and any design flaws will soon become apparent.

James
Seriously??!! Design flaws don't always become apparent immediately when you write a prototype, sometimes they can take weeks or months to become apparent, and they can cost a lot of time to fix. UML modelling is not for everybody, but better the design flaw become apparent in a diagram than months later in your code - UML modelling helps make sure you get it as right as possible the first time.
slugster
Absolutely. This is clearly homework and there's confusion already. If I was this guy I'd try coding it out first, figure out why things are the way they are, and draw up the UML from that. It'd help him get his future UML right first time (if that ever happens)
James
@James i understand what u want to tell, but the bottom line is now i even should have a clear idea of how and what i choose for my relationship in a class. But if tomorrow there's a situation wher i get stuck in my code, which means i again need to change my design. Thats why people wont like to waste time in changing design for every flaw in programming, but would create a concrete design and then proceed.
Nagaraj Tantri
That's true, however developers only learn from their mistakes. The prototype stage is the fastest way to find mistakes. If you design the whole thing in UML first then all you have is a design that works well *in theory*, validated only by mental execution. It's a personal preference thing. To bo honest with you, the only thing I find useful from UML are sequence diagrams. I've rarely seen a class diagram throughout my career, they are pictures that don't paint a thousand words IMO.
James
+5  A: 

I would go back to the basics.

You should ask yourself if an ATM is an AccountHandler, or if an AccountHandler has an ATM. That should give you a general answer as to the question of using inheritance or composition.

Both would be correct. Only one would be a good design and that is dependent on what your application is trying to do.

Generally, there is a rule of thumb (taken from Effective Java) that states that you should favor composition over inheritance. Take that with a grain of salt, and make sure you are designing your app the right way. (For more info see http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance)

Yuval A
@Yuval thank you for a useful tip. I m a Newbie in this modelling.
Nagaraj Tantri
+5  A: 

Typically inheritance (or specialization) is used to model a "is-a" relation, while aggregation/composition is used for "has-a" relations.

Now you can ask yourself which one is correct:

  • an account handler is a bank or a bank has one or more account handlers
  • human cashier is a (special kind of) account handler or account handler has a human cashier

In my opinion the bold statements are correct. So you should use aggregation or composition for bank->account handlers and inheritance for account handler->human cashier.

M4N
@M4N thank you giving a nice explanation
Nagaraj Tantri
A: 

My thoughts

Answers given in terms of HAS A and IS A relationships are fine and i am touching one more area of improvement.

i can see that you are creating your dependencies by hand , would suggest that if you are creating whole thing once again , try to think about some Dependency Injectors and it would help you later in the project life cycle.

saurabh
A: 

Please talk to your domain experts and get the model validated from them. I think this is where the first few chapters in Domain Driven Design help. You should try to define the entities and their relationships (has or is a), draw them on a white board and discuss them with your domain experts.

Despite whatever you do please write unit tests around your implementation. Because with such confusions you are likely to modify the class structure and at that time your unit tests will ensure that you can smoothly re-factor the code.

Unmesh Kondolikar