Code Quest

Notes on Object Oriented Design

25 Jun 2018

Encapsulation-Stock-Image Source: Unsplash

Encapsulation

Encapsulation is one of the four fundamental Object Oriented Programming (OOP) concepts. Traditionally,

Encapsulation is defined as Data Hiding

But in reality, Encapsulation refers to more than just data hiding so that other classes can accidentally use the data. Encapsulation refers to exposing right level of abstraction for a particular Class. In general term, we can refer Encapsulation to hide Implementation, Design Details, Instantiation Rules making it easy for a system to interact with other systems, leaving internal details and working of a Class to itself.

Encapsulation promotes strong cohesion and loosely coupling which are qualities for quality design.

associations-uml

Association

Association represents a relationship between two or more objects where all objects have their own lifeline and there is no owner. The name of an association specifies the nature of relationship between objects. It is represented by solid line.

Aggregation

Aggregation is a specialized 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 Car and Engine. An engine is a part of Car but it can also exist independently irrespective of Car. Deleting the Car Class, it can still exists. We can think about it as a HAS-A relationship.

Composition

Composition is again specialized 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.

composition-example

Composition Aggregation
Contained object is a part of containing object Contained Object are more like a collection of things

Principle of Least Knowledge / Law of Demeter

The Principle of Least knowledge, also known as The law of Demeter, or more precisely, the Law of Demeter for Functions/Methods (LoD-F) is a design principle which provides guidelines for designing a system with minimal dependencies. It is typically summarized as

“Only talk to your immediate friends.”

This principle prevents us from creating designs that have a large number of classes coupled together so that change in one part of the system cascade to other parts. When you build a lot of dependencies between many classes, you are building a fragile system that will be costly to maintain and complex for others to understand.

The goal of good software design is to minimize dependencies, and by carefully following the guidelines provide by The Principle of Least Knowledge this becomes much easier to accomplish.

According to Law of Demeter, a method M of object O should only call following types of methods:

  1. Methods of Object O itself
  2. Methods of Object passed as an argument
  3. Method of object, which is held in instance variable
  4. Any Object which is created locally in method M
  5. A global variable, accessible by 0, in the scope of M

References

Related Posts