Single responsibility principle

Latest revision as of 04:36, 19 October 2010

As the name suggests each class in a program should only have one responsibility.

Each responsibility that a class fulfils is an axis of change. When the requirements of a responsibility change so to must the class. In the case of multiple classes this can result in conflicting pressures. This leads to fragile design that is hard to maintain and hard to change.

A responsibility is in this context a reason for change. For example Uncle Bob

Modem.java -- SRP Violation 
interface Modem 
{ 
    public void dial(String pno); 
    public void hangup(); 
    public void send(char c); 
    public char recv(); 
}

In this case the interface is handling two responsibilities, one for connection and one for data transfer. It needs to be split into two separate interfaces.

A note from Uncle Bob

"The SRP is one of the simplest of the principle, and one of the hardest to get right. Con- joining responsibilities is something that we do naturally. Finding and separating those responsibilities from one another is much of what software design is really about. Indeed, the rest of the principles we will discuss come back to this issue in one way or another. "Uncle Bob

Benefits

According to Uncle Bob, keeping a single responsibility for a class makes the design solid and helps in long-term maintenance. When requirements change, different responsibilities could demand a change in different directions. This coupling between responsibilities of a single class can easily break the design, on change in requirements.

Conflicts with

Model the real world as real world concepts often have multiple responsiblities. Despite this, it is often possible to adhere to both principles if the developer is able to use appropriately granular real world concepts. In my view it is acceptable for developers to violate Model the real world if it results in a design that is easier to understand or more open to change User:BenjaminTaylor.

Keep it simple is often the simplest thing would be two keep a of number related (but slightly differing) functions in the same class. In the above example, it can be argued that it is simpler to leave the class as it is. Changing and creating a new class for such as small problem would not following this Maxim User:Nelson Shaw.

See also

• Separation of concerns
• God object
• One key abstraction
• Design maxims
• Behavioral completeness