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.