Object orientation for embedded developers with SOLID
This series of articles deals with a widespread problem in the development of embedded systems: A lot of development there is currently still procedural, not object-oriented. There are reasons for this: Some are justified, others perhaps not. The fact is, however, that object-oriented development for embedded systems is possible and in many cases even recommended.
In this series of articles, Carsten Pitz uses the SOLID principles to introduce readers to object-oriented development, specifically for developers of embedded systems.
Carsten has already written about object orientation in the past.
Guest article by Carsten Pitz
I have noticed that many software developers in the embedded development environment are not very familiar with the basic rules of object orientation.
My aim with this series of articles is not just to write the thousand and first article about SOLID to write. Rather, my aim is to show how SOLID can be implemented under the boundary condition of embedded development. The focus is on software development, although I have also successfully applied SOLID to hardware designs to define scalable hardware platforms.
SOLID
Central to object orientation for me is the SOLID principle. SOLID stands for
- Single responsibility principle
- Open-closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
SOLID experts will notice that I deviate here and there from the original sources. For one thing, this article is tailored to embedded development, and for another, these changes are based on conversations I had with Barbara Liskov, C.A.R. Hoare and Bertrand Meyer about 20 years ago, as well as my own experience.
Another reason for customization is that I see SOLID as an inseparable whole and communicate this principle as such. With this article, I hope to create a SOLID basis for these software developers.
But first a brief clarification of the two central terms object and class.
Object orientation - object as administrator
Over the last 20+ years, I have had very good experience interpreting objects as a clerk. A clerk
- receives an order and fulfills it independently.
- uses private knowledge (= private variables) and private skills (= private methods).
- acts autonomously and the quality of a clerk can be measured in isolation.
The fact that an object, interpreted as an agent, acts autonomously enables safe Multithreading.
Object is not the same as class
An object is an instance that is created on the basis of a class (template). Or a class is a static structural element, an object is "alive".
This connection is not only important for understanding but also for the allocation to memory areas. The class specifies the code and the static constants. Both are static, do not change during runtime and can be stored accordingly in ROM or flash memory.
The object adds the specific knowledge. These are the class variables and the transfer parameters. The class variables are stored on the heap, the transfer parameters on the stack. Both the heap and the stack are allocated in RAM areas.
If a class is instantiated multiple times for objects, only the memory for the knowledge of the respective object (= administrator) is allocated for each instantiation.
Object orientation is the choreography of clerks
A "real" object-oriented program thus choreographs clerks. This is in stark contrast to structured programming and is an initial adjustment for developers who have been programming in a structured way for decades.
On the other hand, choreography is much easier for non-developers to understand. Moreover, it is the natural way of thinking of people. When I build a house, the architect does not break down the work of the skilled workers down to the smallest detail, but choreographs the skilled workers (clerks).
Object-oriented development made possible:
- Customizability/optimizability: Clerks have specializations.
- Interchangeability: Clerks who are no good are replaced.
- TestabilityThe quality of each individual clerk can be determined in isolation.
Private knowledge of the clerks
Clerks have private knowledge and skills. At the class level, this is represented by
- private class variables (= private knowledge) and
- private operations (= own skills)
technically implemented.
Operations, also referred to as functions, procedures or methods depending on the programming language, encapsulate behavior (= skills). This is 1:1 as with structured programming.
Class variables
- belong to the class and can be accessed from all operations.
- are global variables in the context of the class.
- differ in this respect from transfer parameters and variables declared within operations.
In OO languages, the visibility of both operations and class variables can be restricted. Public operations and class variables are also visible from outside the class and can be manipulated accordingly. Private operations and class variables are only visible within the class.
I strongly recommend declaring everything that does not necessarily have to be visible from the outside as private (Black box thinking). SOLID provides the reasons for this below.
Outlook
In about 4 weeks, the next part will deal with the single responsibility principle. Questions and discussions can be asked and discussed in the comments section.
