The Single Responsibility Principle

One of the most foundational principles of good design is:

Gather together those things that change for the same reason, and separate those things that change for different reasons.

This principle is often known as the Single Responsibility Principle or SRP. In short, it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is a class that has methods that deal with business rules, reports, and database:

public class Employee {

public Money calculatePay() ...

public String reportHours() ...

public void save() ...

}

Some programmers might think that putting these three functions together in the same class is perfectly appropriate. After all, classes are supposed to be collections of functions that operate on common variables. However, the problem is that the three functions change for entirely different reasons. The calculatePay function will change whenever the business rules for calculating pay change. The reportHours function will change whenever someone wants a different format for the report. The save function will change whenever the DBAs change the database schema. These three reasons to change combine to make Employee very volatile. It will change for any of those reasons. More importantly, any classes that depend upon Employee will be affected by those changes.

Good system design means that we separate the system into components that can be independently deployed. Independent deployment means that if we change one component we do not have to redeploy any of the others. However, if Employee is heavily used by many other classes in other components, then every change to Employee is likely to cause the other components to be redeployed; thus negating a major benefit of component design (or SOA if you prefer the more trendy name).

public class Employee {

public Money calculatePay() ...

}

public class EmployeeReporter {

public String reportHours(Employee e) ...

}

public class EmployeeRepository {

public void save(Employee e) ...

}

The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component.

The astute reader will see that there are still dependencies in the above solution. That Employee is still depended upon by the other classes. So if Employee is modified, the other classes will likely have to be recompiled and redeployed. Thus,

Employee cannot be modified and then independently deployed. However, the other classes can be modified and independently deployed. No modification of one of them can force any of the others to be recompiled or redeployed. Even

Employee could be independently deployed through a careful use of the Dependency Inversion Principle (DIP), but that's a topic for a different book.

Careful application of the SRP, separating things that change for different reasons, is one if the keys to creating designs that have an independently deployable component structure.

by Uncle Bob

Start from Yes

Recently I was at a grocery store searching high and low for "edamame" (which I only vaguely knew was some kind of a vegetable). I wasn't sure whether this was something I'd find in the vegetable section, the frozen section, or in a can. I gave up and tracked down an employee to help me out. She didn't know either!

The employee could have responded in many different ways. She could have made me feel ignorant for not knowing where to look, or given me vague possibilities, or even just told me they didn't have the item. But instead she treated the request as an opportunity to find a solution and help a customer. She called other employees and within minutes had guided me to the exact item, nestled in the frozen section.

The employee in this case looked at a request and started from the premise that we would solve the problem and satisfy the request. She started from yes instead of starting from no.

When I was first placed in a technical leadership role, I felt that my job was to protect my beautiful software from the ridiculous stream of demands coming from product managers and business analysts. I started most conversations seeing a request as something to defeat, not something to grant.

At some point, I had an epiphany that maybe there was a different way to work that merely involved shifting my perspective from starting at no to starting at yes. In fact, I've come to believe that starting from yes is actually an essential part of being a technical leader.

This simple change radically altered how I approached my job. As it turns out, there are a lot of ways to say yes. When someone says to you "Hey, this app would really be the bees knees if we made all the windows round and translucent!" you could reject it as ridiculous. But it's often better to start with "Why?" instead. Often there is some actual and compelling reason why that person is asking for round translucent windows in the first place. For example, you may be just about to sign a big new customer with a standards committee that mandates round translucent windows.

Usually you'll find that when you known the context of the request, new possibilities open up. It's common for the request to be accomplished with the existing product in some other way allowing you to say yes with no work at all: "Actually, in the user preferences you can download the round translucent windows skin and turn it on."

Sometimes the other person will simply have an idea that you find incompatible with your view of the product. I find it's usually helpful to turn that "Why?" on yourself. Sometimes the act of voicing the reason will make it clear that your first reaction doesn't make sense. If not, you might need to kick it up a notch and bring in other key decision makers.

Remember, the goal of all of this is to say yes to the other person and try to make it work, not just for him but for you and your team as well.

If you can voice a compelling explanation as to why the feature request is incompatible with the existing product, then you are likely to have a productive conversation about whether you are building the right product. Regardless of how that conversation concludes, everyone will focus more sharply on what the product is, and what it is not.

Starting from yes means working with your colleagues, not against them.

By Alex Miller