SO what?
When I asked professional software developers in companies what software development and design principles, they follow I oftentimes get a blank stare. Our industry has not matured enough to be able to extract out the major principles of constructing software the way civil engineering has been able to extract out the major principles of constructing physical structures. However, we are a young industry.
Perhaps the best-known principles in software development are the SOLID principles that were described by Robert C Martin in his book Agile Software Development. I find these principles are invaluable, especially the first two: The Single Responsibility Principle (SRP) and The Open-Closed Principle (OCP). The other three SOLID principles are still valuable, but I find the first two give me the biggest bang for the buck. Let’s take a look at them.
The Single Responsibility Principle is perhaps the best advice for building accurate and resilient domain models. It simply says that each responsibility in the system should be encapsulated within its own entity. This may be a module or function, or it could be a class or method in an object-oriented system. Every programming paradigm provides some mechanism for encapsulation and the Single Responsibility Principle is saying to use it to encapsulate responsibilities in a system.
But what is a responsibility? It’s a thing. Something that you can name. Software development is after all a linguistic activity and being able to name something accurately and precisely is a strong indicator of its cohesion. The Single Responsibility Principle is saying that software should be cohesive, that each encapsulated entity should be about one thing–something that we can easily name.
Bob Martin describes a responsibility as a “reason to change” and I find that a useful definition. We want to spread out the reasons to change our code for any possible situation so that it has a minimal impact on the program that we are changing. In order to do this, we spread the responsibilities out across classes so that every class is about one thing. This also helps clarify the domain model because you can see the groups of classes and the relationship to each other and that should give you insight as to the design of your system, what it’s resilient to in terms of changes, and where it’s rigid and inflexible.
This leads us to the second principle, the O in SO. This stands for the Open-Closed Principle and to me, it is the guiding light in software development. Bertrand Myers defines the Open-Closed Principle as “…software entities should be open for extension but closed for modification.” What this means is that we should construct software in such a way that when we go to extend it we are minimally changing existing code. To do this we typically don’t write code in the most expeditious way instead, we come up with an appropriate design that encapsulates the right things to minimize the future impact on the system.
Indeed, these principles reinforce each other so a system that is following the Single Responsibility Principle is also more open for extension. Whenever I think about a design or a piece of code I asked myself where is it open for extension and where is it close for modification. This is a valuable question to ask when evaluating a design so that you understand its strengths and weaknesses.
Flexibility is great but it often comes at a cost. Performance, clarity, and flexibility can end up at odds with each other, so we have to make trade-offs. The trick is making the right trade-offs. To me, these two principles, The Single Responsibility Principle and The Open-Closed Principle represent the core of a disciplined software development practice. They are lenses by which I can view software and evaluate their strengths and weaknesses so that I can make the best tradeoffs in each situation I’m in.
The post SO what? appeared first on To Be Agile.
