The Value of Software and the Single Responsibility Principle

#1

Just watched Episode 9 of Bob Martins Clean Coders. If you haven’t watched them before I highly recommend this series I currently run lunch and learns with my company every week based on this series with whatever devs in the organization want to attend. https://cleancoders.com/episode/clean-code-episode-9/show

The key takeaways for me:

Bob Talked about the Primary and Secondary Value of software development and how organiziations tend to focus on the secondary value and no the prime value which leads to poor software design and a decrease in business value.

The secondary value of software development is the actual behavior of the software (What is does) People focus on this because it’s the easiest thing to deliver and without this there is no product. But here is the problem, what the software does changes over time. It WILL change over time, it Has to in order for it to retain value. Which leads to the primary value of software…

The primary value of software is that it is soft! No matter what changes the users require, the software can easily accommodate those changes and retain the current value to users and keep adding value indefinitely.

If every time you have to make a change the software breaks or takes a long time that software is less valuable over time. The market is changing so fast that if you don’t have easily adaptable architecture that “value” will one day cease to exist.

One way to work on the primary value of software is to use the SOLID principles. This particular episode i’m referencing focuses on the first principle. The “Single Responsibility Principle”

The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change.

When he’s talking about responsibility he’s talking about roles. We have to identify the actors of the system. Each class should only represent one “Role” or “Actor.” For much more detailed info from bob himself check out this article: https://8thlight.com/blog/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

Here are some pics from the episode as well.

bob martin 2.jpg865×500 112 KB

bob martin 1.PNG845×477 302 KB

#2

The SRP is definitely the #1 principle of software design, whether it’s OO or not. It goes back at least as far as David Parnas’s 1971 classic, “On the Criteria To Be Used in Decomposing Systems into Modules” (http://repository.cmu.edu/compsci/1980/). Here’s his conclusion paragraph, with emphasis added by me:

“It is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules.”