You are on page 1of 2

Cohesion and Coupling: Principles of Orthogonal, Object-Oriented Programming

Posted on March 10, 2011 by Jason Coffin This is the first in a small series on the fundamental principles of object-oriented programming. Most examples will be in Ruby.

Orthogonal Software
In mathematics, orthogonality describes the property two vectors have when they are perpendicular to each other. Each vector will advance indefinitely into space, never to intersect. Well designed software is orthogonal. Each of its components can be altered without effecting other components. Making precise changes with predictable outcomes is easy. Orthogonal design is the union of two principles, cohesion and coupling.

Vectors A and B are orthogonal to each other.

Cohesion
Cohesion describes the focus of an individual software component. When a component has only one responsibility, and therefore only one reason to change, then it has high cohesion. When a component has many responsibilities, and therefore many reasons to change, then it has low

cohesion. Low cohesion is also noticeable when common responsibilities are spread throughout unrelated components. Components with high cohesion are more robust than components with low cohesion. If an object representing an engine is responsible for both accelerating and decelerating, then a change to the acceleration implementation could inadvertently effect the deceleration implementation. If, however, the engine object is responsible for acceleration and a separate brake object is responsible for deceleration, then a change to the acceleration implementation in the engine object is unlikely to effect the deceleration implementation in the brake object. Maintaining highly cohesive components is easy. If all the logic dealing with deceleration is in the brake object, and that logic is not spread throughout your system, then you wont have to go hunting around your system whenever you make changes to the deceleration logic. You only need to look at your break object. Orthogonal design requires highly cohesive components. Keep your components small and focused.

Coupling
Whereas cohesion is used to describe a single software component, coupling is used to describe the relationship between components. Coupling is the extent to which a component of your software depends on other components. Loosely coupled components have fewer dependencies than tightly coupled components. Modifying a tightly coupled component is difficult. If a car object, boat object, and plane object are all tightly coupled to an engine object, then a modification to the engine object will necessitate changes to the car, boat, and plane objects. And if any of those objects are tightly coupled to other objects, then those other objects will also have to be changed, and so on and so forth. Orthogonal software requires software components to be loosely coupled to one another.

Two Simple Examples


Below are two examples of a simple Dictionary written in Ruby. The dictionary supports reading and writing definitions to a file in either plain text or XML. We will compare them using the principles of cohesion and coupling to prove the second example is more orthogonal than the first.

You might also like