SOLID Principles
Cohesion, coupling/connasence and how these concepts relate to SOLID principles.
Single Responsibility Principle (Cohesion)
In object-oriented programming, the single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.
The term was introduced by Robert C. Martin. Martin described it as being based on the principle of cohesion, as described by Tom DeMarco in his book Structured Analysis and Systems Specification. Cohesion is a measure of the strength of association of the elements inside a module. A highly cohesive module is a collection of statements and data items that should be treated as a whole because they are so closely related. Any attempt to divide them up would only result in increased coupling and decreased readability.
We refer to a sound line of reasoning, for example, as coherent. The thoughts fit, they go together, they relate to each other. This is exactly the characteristic of a class that makes it coherent: the pieces all seem to be related, they seem to belong together, and it would feel somewhat unnatural to pull them apart. Such a class exhibits cohesion.
- Glenn Vanderburg
Gather together those things that change for the same reason, and separate those things that change for different reasons. This principle is often known as the single responsibility principle, or SRP. In short, it says that a subsystem, module, class, or even a function, should not have more than one reason to change.
This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together.
- Doug McIlroy
Open/Closed Principle (Cohesion and Coupling)
The principle stated that a good module structure should be both open and closed:
Closed, because clients need the module's services to proceed with their own development, and once they have settled on a version of the module should not be affected by the introduction of new services they do not need.
Open, because there is no guarantee that we will include right from the start every service potentially useful to some client.
- Bertrand Meyer, Object-Oriented Software Construction
"Closed with respect to X" means that clients are not affected if X changes.
Published Interface is a term I used (first in Refactoring) to refer to a class interface that's used outside the code base that it's defined in. The distinction between published and public is actually more important than that between public and private. The reason is that with a non-published interface you can change it and update the calling code since it is all within a single code base. [...] But anything published so you can't reach the calling code needs more complicated treatment.
- Martin Fowler
Identify points of predicted variation and create a stable interface around them.
If you predict more variation than is actually warranted, you waste effort on over-engineering. If you predict less variation than is required, you usually end with lots of breaking changes.
Plugin ability creates a system that is flexible enough to allow you to extend it without being too generic.
Inflexion point defines the maximum amount of investment we are comfortable to make in a desired type of flexibility at a given moment in time. Beyond this point, the investment is not worth anymore.
I’ll tell you what the problem is mate," said Majikthise, "demarcation, that’s the problem!" […] "That’s right!" shouted Vroomfondel, "we demand rigidly defined areas of doubt and uncertainty!"
- The Hitchhiker’s Guide to the Galaxy by Douglas Adams
Interface Segregation Principle (Cohesion)
The dependency should be on the interface, the whole interface, and nothing but the interface.
We refer to a sound line of reasoning, for example, as coherent. The thoughts fit, they go together, they relate to each other. This is exactly the characteristic of an interface that makes it coherent: the pieces all seem to be related, they seem to belong together, and it would feel somewhat unnatural to pull them apart. Such an interface exhibits cohesion.
Liskov Substitution Principle (Cohesion)
In simple terms, LSP says that derived classes should keep promises made by base classes. This also applies to interfaces, and it means that classes that implement some interface, should keep the promises made by that interface
Another way to state this principle is to say that sub-classes should be contravariant of overridden method input types and covariant of overridden method output types; or that a derived class should be less or equally restrictive on input types and more or equally restrictive on output types for overridden methods. Exceptions are the hidden return values in C# and other languages. The same conformance rules apply. Do not throw exceptions from derived classes that are not the same type or sub-types from exceptions thrown by the base class. Remember the refused bequest code smell?
Inheritance is an “Is A” relationship where sub-classes are specialisations of the base classes; they don’t change the behaviour they make it more specific.
Dependency Inversion Principle (Coupling)
In object-oriented programming, the dependency inversion principle refers to a specific form of decoupling where conventional dependency relationships established from high level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details.
Last updated