Single Reponsibility Principle (SOLID part 1)
Part of my SOLID programming principles series.
What is the Single Responsibility Principle?
The single responsibility principle is pretty self-explanatory. When designing objects, they should only serve a single purpose in a program. This also works in the inverse, in that each responsibility of your program should be handled, and completely encapsulated by a single class.
There are several benefits to designing software this way. One is maintainability. Single responsibility classes are clearly defined, so when a fix needs to take place, it is easy to find where and how to make the fix, and that this change will have less impact on other parts of the system. Another is that this makes code more reusable, and less tangled together.
Applying the Single Responsibility Principle to Objects
Looking at MVC frameworks is a great way to see how this principle can be applied. You have three types of objects, each that only handle one thing in the system. Models handle data abstraction, controllers handle routing, and views handle the user interface. There are also separate models, views, and controllers for each of the objects in your program. This way, each part of the logic is kept separate, and it is easy to move, extend, and maintain.
Applying the Single Responsibility Principle to Functions
If your function takes a lot of arguments, or has a ton of if/elses, then maybe it needs to be broken up into multiple functions. A good rule of thumb I use is to make sure my functions can be named in a