In This Article We Will Try To Understand Association, Aggregation, Composition, Inheritance, Generalization And Realization

i. Composition:

a. What is composition?

• Class A contains Class B. 

• This statement denotes a strong ownership between Class A, Where Class A is the whole and Class B is its part. 

• In composition the part class cannot meaningfully exist on its own without the whole class.

• This means life of Class B is dependent of life of Class A.

• For Example, A line item is part of an order so A line item cannot exist without an order.

• Remember, Composition, Aggregation and Association as considered as varieties of HAS-A relationship.

b. Composition examples:

• It is natural to think of objects as containing other objects.

• A computer contains video cards, keyboards and drives etc.

• In OOP practice, Computer can be considered an object onto itself; the drive is also considered a valid object.

• It is just that the computer contains other objects - such as drives. 

• In this way, objects are often built or composed from other object which is called composition.

c. Composition UML Diagram example:

• In Object-Oriented Analysis and Design where a BankAccount contained a Balance and a TransactionHistory. 

• Containment is represented in a class diagram by drawing a line between the two classes with a solid diamond on the side of the class that contains the other class.

• The Balance and TransactionHistory classes maintain a reference to their BankAccounts, but are contained within the BankAccount class itself.

• The BankAccount class creates private instances of the Balance and TransactionHistory classes. 

d. When to use composition:

• Composite aggregation, also known as composition, is a special form of aggregation where in each part may belong to only one whole at a time. 

• Composition is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it.

• In Composition, the object may belong to only one whole at a time. The parts are destroyed whenever the whole is destroyed.

e. Why prefer association:

• Do not get too confuse if you are unable to decide whether a particular whole-part relationship is best described as an aggregation or composition because the distinction is helpful, it is not critical.

• If you are not even sure whether the relationship is best described as Association or Composition or Aggregation, then model it as an Association. 

• In fact, there is nothing wrong with modelling all whole-part relationships as simple Associations.

• You lose a little bit of nuance in the model, but it will make no difference to the resulting IT solution.

ii. Aggregation:

Generally, there are three varieties to represent has-a relationship: 

1. Association 

2. Aggregation 

3. Composition

• In all cases, these relationships represent collaborations between the objects.

• All forms of composition include a has-a relationship, However, there are subtle differences between associations and aggregations based on how you visualize the parts of the whole. 

a. What is Aggregation:

• In an aggregation, you normally see only the whole, And In associations; you normally see the parts that make up the whole.

• Aggregation is a lighter form of composition.

• The whole class plays a more important role than the part class, but unlike the case of composition, the part class can meaningfully exist on its own without the whole class.

b. Aggregation UML notation example:

• A Player can be part of more than one Team and hence, When a Team is dissolved, the Player still remains.

• It is the most intuitive form of composition is aggregation, represents has-a relationship. 

• Aggregation means that a complex object is composed of other objects.

• Aggregations are represented in UML by lines with a diamond, such as an engine as part of a car.

• Example I : 

• TV set is a clean, neat package that you use for entertainment. When you look at your TV, you see a single TV. Most of the time, you do not stop and think about the fact that the TV contains some transistors, a picture tube, a tuner, and so on. 

• Sure, you see a switch to turn the set on and off, and you certainly see the picture tube. However, this is not the way people normally think of TVs,

• Example II: 

• When you go into an appliance store, the salesperson does not say - Let me show you this aggregation of transistors, a picture tube, a tuner, and so on.

• The salesperson says - Let me show you this TV.

• Similarly, when you go to buy a car, you do not pick and choose all the individual components of the car. You do not decide which spark plugs to buy or what door handles to buy.

• You go to buy a car. Of course, you do choose some options, but for the most part, you choose the car as a whole, a complex object made up of many other complex and simple objects.

 c. When to use Aggregation:

• You should make the choice of which kind of HAS-A relationship or Association you should use, Based the Life / Existence of the Integrated Objects.

• As I mentioned in the example of - Team has players, if team dissolve, Player will still exists!

• Hence of such kind of scenario when life of object is independent of container object then you should use Aggregation.

• In other words we can also say when there are two independent objects are there but One is the owner of the other object like:

1. Team owns Player.

2. Manager owns Employees / Team members.

3. Car owns Wheels.

iii. Association:

a. What is Association:

• Although aggregations represent relationships where you normally only see the whole, Associations present both the whole and the parts.

• As using a computer system as an example, the whole is the computer system. The components are the monitor, keyboard, mouse and CPU box.

• Each is a separate object, but together they represent the whole of the computer system.

• The main computer is using the keyboard, mouse and monitor to delegate some of the work. In other words, the computer box needs the service of a mouse, but does not have the capability to provide this service by itself.

• Thus, the computer box requests the service from a separate mouse via the specific port and cable connecting the mouse to the box.

b. Association uml notation example:

• A client/server relationship fits this model. Although it is obvious that a client is not part of a server, and likewise a server is not part of a client, they both depend on each other.

• In most cases, you can say that a server provides the client a service.

c. When to use Association - HAS-A relationship:

• You should use Association as HAS-A relationship, When you have to separate independent objects (their life or existence are totally unrelated with each other), But one object may need to take the service of other object on such scenario we can use Association.

• Like I mentioned earlier: 

1. Computer uses keyboard as input device.

2. Client A uses services from Server B

3. Employee uses BusService for transportation

• Moreover, none of the associated objects are the owner of the other, they are the owner of themselves, they just consume the service from each other whenever required.

• Remember while coding or implementing this kind of relationship, Associated Objects creation should be done from different place not from within the code of each other files.

d. Aggregation vs Association:

• An aggregation is a complex object composed of other objects.

• An association is used when one object wants another object to perform a service for it. 

e. Association UML Notation:

Associations are represented by just the line (no diamond).

iv. Difference between Association, Aggregation and Composition:

Following is the comparison between all the varieties of HAS-A relationships:

1. Association

2. Aggregation

3. Composition

What if you are not sure what type of whole-part relationship to use?

• Do not get too confuse if you are unable to decide whether a particular whole-part relationship is best described as an aggregation or composition because the distinction is helpful, it is not critical.

• If you are not even sure whether the relationship is best described as Association or Composition or Aggregation, then model it as an Association. 

• In fact, there is nothing wrong with modelling all whole-part relationships as simple Associations.

• You lose a little bit of nuance in the model, But it will make no difference to the resulting IT solution.

v. Inheritance:

• Inheritance and composition plays major roles in the design of object-oriented systems.

• Many of the most complex and interesting design decisions come down to deciding between inheritance and composition.

• Both inheritance and composition provides mechanisms for RE-USE.

a. What is inheritance:

• Inheritance as its name implies, involves inheriting attributes and behaviors from other classes.

• Inheritance represents the is-a relationship between two entities or objects.

• There is a true parent/child relationship and the child (or subclass) inherits directly from the parent (or superclass).

• Remember that Composition is also as its name implies, involved building objects by using other objects. 

b. Inheritance example:

• One of the most powerful feature of Object Oriented programming is code Reusability.

• Structured design provides code reuse to a certain extent hence you can write a procedure and then use it as many times as you want.

• Inheritance also helps by organizing classes and factoring in commonalties of various classes.

• Inheritance is a primary means of providing this functionality.

• Inheritance allows a class to inherit the attributes and methods of another class.

• This allows creation of brand new classes by abstracting out common attributes and behaviors.

• One of the major design issues in OO programming is to factor out commonality of the various classes.

c. Inheritance UML notation example:

• You have a Dog class and a Cat class, and each will have an attribute for eye color.

• In a procedural model, the code for Dog and Cat would each contain this attribute.

• In an OO design, the color attribute could be moved up to a class called Mammal along with any other common attributes and methods.

• In this case, both Dog and Cat inherit from the Mammal class, as shown below:

• The Dog and Cat classes both inherit from Mammal.

• This means that a Dog class actually has the following attributes:

eyeColor         // inherited from Mammal 
barkFrequency    // defined only for Dogs
In the same vein, Dog object has the following methods:
getEyeColor    // inherited from Mammal 
bark         // defined only for Dogs

d. Inheritance represents Is-a Relationships:

• For example there is a parent class (Shape Class) and Circle, Square and Star all inherit directly from Shape Class.

• This relationship is often referred to as an is-a relationship because a circle is a shape, Square is a shape and Star is a shape.

• When a subclass inherits from a super class, it can do anything that the superclass can do.

• Thus, Circle, Square and Star are all extensions of Shape.

• In below figure, the name on each of the objects represents the Draw method for the Circle, Star and Square objects respectively.

• When we design this Shape system it would be very helpful to standardize how we use the various shapes.

• This way we could decide that if we want to draw a shape, No matter what shape, we will invoke a method called draw.

e. Advantages of Inheritance:

• There are two major benefits to inheritance. 

• The First, we can specialize existing classes (types) and write only the code that is changed. 

• In this way, we can reuse our existing classes (as base classes) and capitalize on the work already done. 

• <