Using aggregation by aggregation

Question

I have this cool model, where the Bank is the class that is now being assembled for a computerized banking network. This should be an ATM (automatic ATM), as well as a cashier.

I used Generalization and took a class called AccountHandlers , which inherits the Bank class. This AccountHandlers also has aggregated ATM and HumanCashier .

Now the fact is that my friend claimed that I took everything wrong. According to him, AccountHandlers should be aggregated in the Bank and that ATM and HumanCashier should inherit AccountHandlers .

I am a bit confused. How can I model it! or are both methods correct?

Answer 1

I would like to return to the basics.

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

Both will be correct. Only one will be a good design, and it depends on what your application is trying to do.

As a rule of thumb, there is a rule of thumb (taken from Effective Java) that says you must approve composition over inheritance. Take this with salt and make sure that you are developing your application correctly. (For more information, see Prefer composition over inheritance? )

Answer 2

Typically, the is-a model is used for inheritance (or specialization), while aggregation / composition is used for has-a relationships.

Now you can ask yourself which one is correct:

• account handler - this is a bank or a bank that has one or more account handlers
• Human cashier is a (special type) account handler or account handler has a human cashier

In my opinion, bold statements are true. Therefore, you should use aggregation or composition for banking> account handlers and inheritance for the account handler → person cashier.

Answer 3

If it works correctly. Don't get carried away with unnecessary UML modeling time. Write a prototype, and all design flaws will soon become apparent.

Answer 4

Please talk to domain experts and get a model from them. I think the first few chapters in driving Driven Design help here. You should try to determine the entities and their relationships (whether or not), draw them on a white board and discuss them with experts from your domain.

Despite what you are doing , please write unit tests around your implementation . Since with such confusion, you are likely to change the structure of the classes, and at the same time, your unit tests will ensure smooth code changes.