Mit SOLID zur Objektorientierung für Embedded Entwickler

In dieser Artikelreihe geht es um ein verbreitetes Problem in der Entwicklung eingebetteter Systeme: Dort wird zur Zeit noch viel prozedural entwickelt, nicht objektorientiert. Da gibt es Gründe für: Manche sind berechtigt, andere vielleicht nicht. Fakt ist jedoch, dass objektorientierte Entwicklung für eingebettete Systeme möglich und in vielen Fällen sogar empfehlenswert ist.

In dieser Artikelreihe führt Carsten Pitz anhand der SOLID-Prinzipien die Leser in die objektorientierte Entwicklung ein, und zwar gezielt für die Entwickler eingebetteter Systeme.

Carsten schrieb bereits in der Vergangenheit zur Objektorientierung.

Gastartikel von Carsten Pitz

Ich habe bemerkt, dass im Umfeld der embedded Entwicklung viele Softwareentwickler wenig vertraut mit den grundlegenden Regeln der Objektorientierung sind.

Mein Anspruch an diese Artikelserie ist nicht nur den tausend und ersten Artikel über SOLID zu schreiben. Vielmehr ist mein Anspruch zugleich mitzugeben, wie SOLID unter der Randbedingung embedded Entwicklung umgesetzt werden kann. Der Fokus liegt auf Softwareentwicklung auch wenn ich SOLID auch schon äußerst erfolgreich auf Hardwaredesigns zur Definition skalierbarer Hardwareplattformen angewendet habe.

SOLID

Zentral für die Objekt-Orientierung ist für mich das SOLID Prinzip. SOLID steht für

  • Single Responsibility Prinzip
  • Open-closed Prinzip
  • Liskov Substitutions-Prinzip
  • Interface Segregation Prinzip
  • Dependency Inversion Prinzip

SOLID Experten werden bemerken, dass ich hier und da von den ursprünglichen Originalquellen abweiche. Zum einen ist dieser Artikel auf embedded Entwicklung zugeschnitten, zum anderen basieren diese Änderungen auf Gesprächen, die ich vor etwa 20 Jahren mit Barbara Liskov, C.A.R. Hoare und Bertrand Meyer geführt habe sowie meiner eigenen Erfahrung.

Ein weiterer Grund für Anpassungen ist, dass ich SOLID als untrennbare Gesamtheit sehe und dieses Prinzip auch so vermittele. Ich hoffe mit diesem Artikel eine SOLIDe für diese Softwareentwickler Basis zu schaffen.

Jedoch zuerst eine kurze Klärung der beiden zentralen Begriffe Objekt und Klasse.

Objektorientierung – Objekt als Sachbearbeiter

In den letzten 20+ Jahren habe ich sehr gute Erfahrung damit gemacht, Objekte als Sachbearbeiter zu interpretieren. Ein Sachbearbeiter

  • erhält einen Auftrag und erfüllt diesen eigenständig.
  • nutzt dabei privates Wissen (= private Variablen) und private Fähigkeiten (= private Methoden).
  • agiert autonom und die Qualität eines Sachbearbeiters ist isoliert messbar.

Der Fakt, dass ein Objekt, interpretiert als Sachbearbeiter autonom agiert ermöglicht sicheres Multithreading.

Objekt ist nicht gleich Klasse

Ein Objekt ist eine Instanz, die auf Basis einer Klasse (Schablone) erzeugt wird. Oder eine Klasse ist ein statisches Strukturelement, ein Objekt „lebt“.

Dieser Zusammenhang ist nicht nur wichtig für das Verständnis sondern auch für die Allokation auf Speicherbereiche. Die Klasse gibt den Code und die statischen Konstanten vor. Beides ist statisch, ändert sich nicht während der Runtime und kann entsprechend in ROM- bzw. Flash-Speicher abgelegt werden.

Das Objekt fügt das spezifische Wissen hinzu. Dies sind die Klassenvariablen und die Übergabeparameter. Die Klassenvariablen werden auf dem Heap, die Übergabeparameter auf dem Stack gespeichert. Sowohl Heap als auch Stack sind in RAM-Bereichen allokiert.

Wird eine Klasse mehrfach zu Objekten instanziiert, so wird bei jeder Instanziierung ausschließlich der Speicher für das Wissen des jeweiligen Objekt (= Sachbearbeiter) allokiert.

Objektorientierung ist die Choreographie von Sachbearbeitern

Ein „echtes“ objektorientiertes Programm choreographiert somit Sachbearbeiter. Dies steht im krassen Gegensatz zur strukturierten Programmierung und ist für Entwickler, die seit Dekaden strukturiert programmiert haben erst einmal eine Umgewöhnung.

Auf der anderen Seite ist Choreographie von Sachbearbeitern Nicht-Entwicklern deutlich einfacher zu verstehen. Mehr noch es ist die natürliche Denkweise von Menschen. Wenn ich ein Haus baue, dann bricht der Architekt nicht die Arbeit der Facharbeiter bis in das kleinste Detail auf sondern choreographiert die Facharbeiter (Sachbearbeiter).

Objektorientierte Entwicklung ermöglicht:

  • Anpassbarkeit/Optimierbarkeit: Sachbearbeiter haben Spezialisierungen.
  • Austauschbarkeit: Sachbearbeiter, die nicht taugen werden ersetzt.
  • Testbarkeit: Die Qualität jedes einzelnen Sachbearbeiters ist isoliert ermittelbar.

Privates Wissen der Sachbearbeiter

Sachbearbeiter haben privates Wissen und eigene Fertigkeiten. Auf Ebene der Klassen wird dies durch

  • private Klassenvariablen (= privates Wissen) und
  • private Operationen (= eigene Fertigkeiten)

technisch umgesetzt.

Operationen, je nach Programmiersprache auch als Funktion, Prozedur oder Methode bezeichnet kapseln Verhalten (= Fertigkeiten). Dies ist 1:1 so wie bei der strukturierten Programmierung.

Klassenvariablen

  • gehören der Klasse und können von allen Operationen aus zugegriffen werden.
  • sind entsprechend im Kontext der Klasse globale Variablen.
  • unterscheiden sich in diesem Punkt von Übergabeparametern und innerhalb von Operationen deklarierten Variablen.

In OO-Sprachen kann die Sichtbarkeit sowohl von Operationen als auch von Klassenvariablen eingeschränkt werden. Öffentliche (public) Operationen und Klassenvariablen sind auch von außerhalb der Klasse sichtbar und entsprechend manipulierbar. Private Operationen und Klassenvariablen sind ausschließlich innerhalb der Klasse sichtbar.

Ich empfehle dringend, alles was nicht zwingend von außen sichtbar sein muss als private zu deklarieren (Black-Box-Denken). Die Gründe hierfür liefert im folgenden SOLID.

Ausblick

In ca. 4 Wochen geht es im nächsten Teil um das Single-Resonsibility Prinzip. Frangen und Diskussionen können im Kommentarbereich gestellt und diskutiert werden.

Photo by Ben Neale on Unsplash

Carsten Pitz

Autorenprofil