For those of you who have not been exposed to the Single Responsibility Principle it states that an object should have a single responsibility and therefore a single reason to change. This results in a codebase having many small classes that do one task.

Today I got asked why SRP is important and came up with a few good reasons off the top of my head:

Readability: The class is easier to read as it performs one task. Anyone should be able to spend under a minute and fully comprehend what the class does.
Testability: There is only one things to test so you write simple small tests that cover the few scenarios the object will experience
Reusability: The class is easier to reuse as it is not locked into one scenario. It can be used in multiple ways as it has set input/output expectations.
Easier To Code: It is easier and faster to code in small chunks than it is in large segments. When coding with SRP it is easy to break off a small chunk of functionality, write it, test it, then tackle another small chunk.
Bugs: By having code broken into many small classes bugs become easier to track down. If you have a 2000 line function and an exception occurs you will know there is a problem in that method. If the code is properly broken out into small 5-20 line methods you can track it down to that small function and usually spot the error in seconds.
Navigation:
Now many developers hate SRP as they end up having hundreds to thousands of classes in their projects. To me this is the only mild detractor of SRP but it is really not that hard to break classes into logical folders/namespaces to make it manageable. And honestly I find this makes things even easier to work with. If I want to get the data for student attendance by day report I may just type:

var reportDataRetriever = new Reporting.Students.Attendance.ByYear.Retriever();
var data = reportDataRetriever.GetDataFor(DateTime.Now.Year);

I find that this is quicker to navigate as I know first off that I want a report and that is in the “Reporting” namespace. Then Intellisence prompts me with all the possible things I can report off of so I pick “Students”. Then what I want for the student and that is “Attendance”. And on and on we go of narrowing things down. This allows me to find what I am looking for without having to remember the name of the class I would want to call.

I have seen way to many classes like this:
Public Class Reports
{
  Public Function GetAllStudentsAttendanceByYear(int year)
  Public Function FindTeachersWhoTaught(Course course)
  …. 20 other report methods
  Public Function StudentAttendanceFor(DateTime startDate, DateTime endDate)
  Public Function GetTeachersWhoTaught(int courseId)
  … 30 other report methods
}

To use this class becomes completely unwieldy. Naming convents first off are not consistent which is quite common so it makes it hard to use in intellisense if you have to try “Get______” or “Find_____” or “Student______”. If this was done with SRP then you would still have an inconsistent naming conventions but it would not be a problem as your code would still be easily navigable.

You will also notice that the Reports class example has two methods that return teachers who taught a course. This happens more than one might think in that a developer thought the method did not exist as they did not take the time to look through a massive class to find it did already so they created their own. If you were using SRP you would see in seconds that in the Reports\Teachers\ folder a class called something like a file named WhoTaughtCourse.cs or something similarly named that easily communicates that this work is already done.

A good debate in the development community is whether or not to specialize in something and tout yourself as an expert in just that. If you do specialize you probably will be able to find some good money as people pay well for an expert. On the other hand work is harder to find as you are in a niche and need to find people looking for an expert. Also when your specialization is not popular any longer you need to re-specialize in a new area.

One of the popular sayings in the development circuit is “Specialization is for Insects” taken from Heinlein’s Time Enough For Love. Most of us feel that specialization is the sure way to be good at something and terrible at everything else. Lets face it, as developers we need to solve many different problems and need a well rounded background to solve those problems effectively. Bringing in an expert may solve one problem but then they are discarded and the rest of the team carries on.

One overlooked item is that our offices need diversification (and not just in the we need more than white males working in our industry kind of diversification). By having and encouraging developers to learn things that others don’t know contributes to the entire knowledge of the team. If we are approaching a client/server design and one developer only knows COM+ but the other has a knowledge of WCF then we can discuss the pros/cons of each technology to make an informed choice.

I feel that is important to not have a homogeneous team in some areas. To debate something shows the strengths and weaknesses of decisions and yields a better outcome in most cases. Encourage and hire people that don’t 100% match what you do and bring their diversity into yours. It can help you open up doors to new clients or solve problems with current ones.