Programming Microsoft ASP.NET 4 - Dino Esposito [294]
In general, though, the principle of SoC manifests itself in different ways in different programming paradigms, and so it is also for modularity and information hiding.
Note
Separation of concerns is the theoretical pillar of multitiered (or just multilayered) systems. When you try to apply SoC to classes, you run across just one fundamental concept that you can then find formulated in a number of different ways. You essentially achieve separation of concerns by isolating dependencies and abstracting them to interfaces. This is called low coupling, interface-based programming or, perhaps in a more formal way, the Dependency Inversion principle that I’ll cover in just a moment. Different names—each appropriate in its own context—but just one key idea.
SOLID Principles
Recently, a particular acronym is gaining a lot of popularity—SOLID. The acronym results from the initials of five design principles formulated by Robert Martin. The S stands for Single Responsibility; the O is for the Open/Closed principle; the L is for Liskov’s principle; the I is for Interface Segregation; and finally, the D is for Dependency Inversion.
Taken individually, these principles are nothing new. Any experienced developer and architect should be at least vaguely familiar with the idea behind each principle, either because it is part of the developer’s personal education or because of the experience the developer has gained the field.
SOLID principles are just a further specialization and refinement of universal and object-oriented design principles. Their definition is relatively simple; yet the adoption of these principles can be fairly complex.
Note
As you’ll see in a moment, not all principles should be taken literally. Some of them are just driving vectors that attempt to show you the right direction, but without being dogmatic. You can download the original papers describing the SOLID principles and their canonical examples from http://www.objectmentor.com.
The Single Responsibility Principle
The Single Responsibility Principle (SRP) is a formal way of rephrasing the idea behind cohesion. The principle states that there should never be more than one reason for a class to change. Applied to the design of the class, it means each class you add to your solution should focus on just one primary task.
The responsibilities of a class that does just one thing are much smaller than the responsibilities of a class that does multiple things. A responsibility is defined as a “reason to change”; more specifically, it’s a reason for you—the developer—to put your hands on the class’s source code and edit it.
The purposes of SRP are to simplify maintenance and improve readability. Keeping the code simple at the root—by taking out additional features—is an effective way to smooth maintenance chores. At the end of the day, SRP is a form of defensive programming.
SRP Canonical Example
Like any other SOLID principle, SRP has its own canonical example aimed at illustrating the point of the principle. Here’s a piece of code that contains the gist of SRP:
public class Modem
{
public void Dial(String number);
public void Hangup();
public void Send(Char c);
public Char Receive();
}
How many sets of responsibilities do you see in the Modem class? Dial and Hangup represent the connection management functionality, whereas the Send and Receive pair of methods represent communication functionalities. Should these two sets of responsibilities be separated? As usual, it depends.
SRP Real-World Considerations
An effective implementation of SRP passes through the identification of specific responsibilities in the programming interface of the class. One task is identifying responsibilities; it is quite a different task to actually split the class into two other classes, each taking care of a specific responsibility.