Basics types of relationship Objects



Association is a relationship where all objects have their own lifecycle and there is no owner. Let’s take an example of Teacher and Student. Multiple students can associate with single teacher and single student can associate with multiple teachers, but there is no ownership between the objects and both have their own lifecycle. Both can create and delete independently. In Association with can have  one-to-one, one-to-many, many-to-one, many-to-many sub-types of relationships. Persistence framework Hibernate in ORM use that.

Aggregation is a specialised form of Association where all objects have their own lifecycle, but there is ownership and child objects can not belong to another parent object. Let’s take an example of Department and teacher. A single teacher can not belong to multiple departments, but if we delete the department teacher object will not be destroyed. We can think about it as a “has-a” relationship.

Composition is again specialised form of Aggregation and we can call this as a “death” relationship. It is a strong type of Aggregation. Child object does not have its lifecycle and if parent object is deleted, all child objects will also be deleted. Let’s take again an example of relationship between House and Rooms. House can contain multiple rooms – there is no independent life of room and any room can not belong to two different houses. If we delete the house – room will automatically be deleted. Let’s take another example relationship between Questions and Options. Single questions can have multiple options and option can not belong to multiple questions. If we delete questions options will automatically be deleted.

Generalization uses a “is-a” relationship from a specialization to the generalization class. Common structure and behaviour are used from the specializtion to the generalized class. At a very broader level you can understand this as inheritance. Why I take the term inheritance is, you can relate this term very well. Generalization is also called a “Is-a” relationship.

Realization is a relationship between the blueprint class and the object containing its respective implementation level details. This object is said to realize the blueprint class. In other words, you can understand this as the relationship between the interface and the implementing class.

Dependency: with a change in structure or behaviour of a class affects the other related class, then there is a dependency between those two classes. It need not be the same vice-versa. When one class contains the other class it this happens.


Thanks Varun Gupta and Ajay from

A controversials TDD


This paper is about TDD, how convenient it can be in development cycle, Here we can see how TDD is not a technology instead of that this is a culture and good practice (discipline) that must to be encouraged for the project sponsors and the management people. Other important thing is how testability can contort the code because the code must to be tested and could be worse if you work with high code coverage.
Attention point of development performance, Usually with TDD it could be less than usual.
Very good point of view by Pete Preston. You can read all this paper here.

Microservices-architecture and Monolithic application

Very nice article for  Mrityunjay Kumar, He talks about interesting point of view using micro and monolithic  architecture (Microservices and Monolithic application).

In coming years, It will be no surprise to see it growing at a level in which software engineers will be using monolith for just prototyping. Who would not want to have a modular, highly performing and easy to scale application in the deployment in the time of Internet of Things?

The microservics architecture is not a new approach; its soul was always there for years in the form of SOA (Service Oriented Architecture), web services, and in a modular and layered architecture.

You can see all post from Kumar here, enjoy!