With the principle of clear responsibility for object orientation for embedded developers
The Single Responsibility Principle (SRP) is the principle of clear responsibility. At first glance, it seems simple, but the details are fascinating. This principle provides an initial rule on how a system should be divided into subsystems.
This is the second part of a series of articles by Carsten Pitz on object-oriented programming for embedded developers (Part 1).
Single Responsibility Principle (SRP)
An object (clerk) offers exactly one, well-defined service that is as narrowly defined as possible. In this sense, a micro-service is an object that can be addressed via a web interface. This isomorphism becomes clearly visible again in the Interface Segregation Principle (ISP) in anticipation of Part 6.
It should be noted that objects act autonomously. Autonomy implies self-contained. However, self-contained does not mean that it does not use the services of other objects. An object may and should even use the services of other objects in order to avoid redundant implementations and to keep the objects as simple and small as possible.
The simpler an object is, the fewer sources of error it offers and the easier it is to test.
As already mentioned, objects may and should even use the services of other objects. This leads to dependencies between objects. These dependencies can be structured in the same way as in structured programming by layering. An object may only use objects in the same layer, on objects in the next layer down or on cross-sectional objects.
Complexity of a system
The Single responsibility principle (SRP) does not reduce the complexity of a system. The Complexity of a system is a property of the system itself, given by the totality of the explicit and implicit requirements on the system as well as the context including interfaces to neighboring systems. For example, in the case of controllers, the system to be controlled typically determines the complexity.
System complexity can only be influenced by the requirements situation. It is not without reason that Automotive SPICE the work step ENG.1 is named "Selection of requirements". Selection does not mean blind acceptance.
Decomposition into subsystems
Just as the cut of a jacket has only a minor influence on the amount of fabric required, but significantly determines how comfortable the jacket is to wear, the cut of a system into subsystems changes the realization complexity only insignificantly, but determines how well the overall system can be controlled.
The realization complexity is always higher than the system complexity. On the one hand due to the cuts that Interface descriptions require. On the other hand, due to redundancies in the implementation.
This reveals another trade-off: sections increase the complexity of implementation due to the necessary interface descriptions, but at the same time offer the potential to reduce the complexity of implementation by avoiding redundancies.
In the course of the article, I will give some indications of what this trade-off can look like. I deliberately chose "can" rather than "should", as there is no right or wrong here. Different solutions may be more or less elegant, but they are not fundamentally right or wrong.
Conclusion
It should be possible to describe a subsystem using a metaphor that is as generally understandable as possible. The metaphor should describe a service. Specialist services should be described in customer language (e.g. signal illumination), whereas technical services should be described using technical terms (e.g. logbook).
The third part, which deals with the open-closed principle (OCP), will be published in about a month's time.
Until then, I look forward to many questions and discussions in the comments section.
Photo by Nikolai Chernichenko on Unsplash
