Objects are the building blocks of an object-oriented program. The advantage of object-oriented programming is that data and operations used to interact with objects are contained within each object. In a distributed environment, objects can be created and transported across a network, fully containing their unique data and behaviors, and capable of receiving and sending messages, and processing data.

“Each object can be viewed as an independent little machine or actor with a distinct role or responsibility” (ObjectWiki, 2006). Since an object is comprised of data and behaviors, good design principles suggest that the each object have only one responsibility, and that all of its services should be aligned with that sole responsibility. This concept is known as the Single Responsibility Principle (SRP).

Single Responsibility Principle

The single responsibility principle states that “a class should have only one reason to change” (Martin, 2002). In essence, a class, its data and operations, should only have one reason to change. Each responsibility represents one reason. If a class has two responsibilities, then a change in one will force the entire class to change, which yields to a coupled class. Each responsibility should be independent of the other, so a change in one does not affect the other. In well designed systems, we strive for decoupled classes each with its own responsibility. This leads to flexible, extensible, and testable code.

An example to illustrate SRP’s principle concept is a Search class that is theoretically based upon KBSearch found in our hosted product. The Search class should be able to search for results that start with, or contain a given string. The Search class should not need to know how to connect to a database, nor create a dictionary file of noise words, nor display its results in a data grid. It should only know how to search. If the requirements change on what to display, we delegate that responsibility to a separate class, DisplayResults. If the requirements change on the underlying data source, and we need to implement a file system search, our Search class should not need to change.

Cohesion

SRP forms the greater part of another concept, cohesion. Cohesion is a term connoting the measurement of how well lines of source code within a module interact in order to produce a specific piece of functionality (CohesionWiki, 2005). It measures how strongly related and focused the responsibilities of a class are (CohesionWiki, 2005). Objects with a single responsibility exhibit low coupling, and have high cohesion.

Cohesion is an ordinal type of measurement, typically expressed as “high cohesion” or “low cohesion.” High cohesion suggest a loosely couple system, whereas low cohesion implies the opposite. High cohesion is desirable because it is associated with reliability, reusability, testability, understandability, and maintainability. Low cohesion corresponds to the opposite. There are different types of cohesive measurement, but this article will not cover those.

References:

CohesionWiki. (n.d.). Retrieve May 16, 2006, from http://en.wikipedia.org/wiki/Cohesion
Martin, R. C. (2002). Agile Software Development, Principles, Patterns, and Practices (1st ed.). Upper Saddle River, NJ: Prentice-Hall, Inc.
ObjectWiki. (n.d.). Retrieve May 16, 2006, from http://en.wikipedia.org/wiki/Object_%28computer_science%29