Programmierprinzipien

Zweck

Um nützliche und dennoch preiswerte Programme und Anwendungen erstellen zu können, sollte man eine Reihe von Programmierprinzipien beachten.

Bevor die Programmierprinzipen näher beschrieben werden können, werden zunächst die Ziele genannt, die mit diesen Prinzipien erreicht werden sollen.

Ziele

Ziel eines jeden Softwareentwicklungs-Vorhaben sollte die Erstellung von Software sein, die zwei Eigenschaften aufweist:

nützlich (useful)

Die Software sollte für den Benutzer nützlich sein.

preiswert (inexpensive)

Die Software sollte so geringe Kosten und Folgekosten verursachen wie möglich.

Software-Eigenschaften zur Erfüllung der beiden Ziele

Um die beiden vorgenannten Ziele zu erreichen, sollte ein Softwarepaket folgende Eigenschaften haben:

spezifiziert (specified)

Um die Nützlichkeit und die Korrektheit des Softwarepakets beurteilen zu können, sollte eine Spezifikation vorliegen, die detailliert die Aufgaben und Eigenschaften des Paketes beschreibt.

⇒ Nützlichkeit (ist abschätzbar)

korrekt (correct)

Die Implementierung des Paketes sollte korrekt sein, es sollte also die Spezifikation in allen Punkten erfüllen.

⇒ keine Kosten durch falsches oder unerwartetes Verhalten

robust (robust)

Das Softwarepaket sollte auch in abnormalen (nicht-spezifizierten) Situationen stabil laufen.

⇒ keine Kosten durch Inkonsitenzen

⇒ geringe Kosten bei Bedienungsfehlern und Systemausfällen

benutzbar (usable)

Das Softwarepaket sollte einfach zu erlernen und zu benutzen sein.

⇒ Nützlichkeit wird verbessert

⇒ geringe Schulungskosten

⇒ fehlerhafte Nutzung verursacht nur selten Kosten

⇒ keine Kosten durch frustierte Benutzer

sicher (secure)

Unautorisierter Zugriff auf Daten oder Programme sollte unmöglich sein.

⇒ keine Kosten durch Sicherheitsmängel

effizient (efficient)

Das Softwarepakt sollte eine möglichst gute Laufzeit- und Speichereffizienz aufweisen, d.h. die vorhandenen Ressourcen möglichst gut ausnutzen.

⇒ geringe Personalkosten durch geringe Wartezeiten

⇒ geringe Kosten durch geringe Hardwareanforderungen

wartbar (maintainable)

Das Softwarepaket sollte leicht an neue Gegebenheiten angepasst werden können. Fehler sollten leicht behoben werden können (da sie sich nie ganz vermeiden lassen).

⇒ geringe Wartungskosten

Für die Eigenschaft „wartbar“ gibt es drei Spezialfälle, die hier gesondert genannt werden sollen:

kompatibel (compatible)

Das Softwarepaket sollte komaptibel zu bestehenden Systemen sein, es sollte also standardisierte Schnittstellen unterstützen.

⇒ geringe Intergrations- und Anpassungskosten

portabel (portable)

Das Softwarepaket sollte einfach auf neue Systeme portiert werden können.

⇒ geringe Kosten bei Änderung der Ablaufumgebung

erweiterbar (extensible)

Erweiterungen der Spezifikation sollten schnell implementiert werden können.

⇒ geringe Wartungskosten

Programmierprinzipien

Um die vorgenannten Ziele zu erreichen, sollten folgende Programmierprinzipien beachtet werden:

• Schreibe lesbaren Code (Lesbarkeit, readability)

  Der Programmcode sollte so einfach wie möglich gelesen und verstanden werden können. Das heißt, der Code sollte sauber formartiert werden, es sollten sprechende Bezeichner verwendet werden, es sollten sinnvolle Kommentare eingefügt werden etc.

⇒ Überprüfbarkeit (durch Programmierer und nicht nur durch Compiler u.Ä.) (⇒ Korrektheit, Robustheit)

⇒ Wartbarkeit (da die Programme auch von anderen Programmierern verstanden werden)

⇒ Erweiterbarkeit (da die Programme auch von anderen Programmierern verstanden werden)

• Verwende eine Programmiersprache und -umgebung, die dich beim Schreiben des Codes unterstützt (Schreibbarkeit, writability)

  Der Programmcode sollte so einfach wie möglich geschrieben werden können. Zum einen sollte es die Programmiersprache ermöglichen, einfachen und eleganten Code zu schreiben. Und zum anderen sollten die Programmwerkzeuge einen bei der Erstellung des Codes möglichst gut unterstützen.

⇒ Korrektheit (Fehler/Warnungen werden von der Programmierungebung zeitnah gemeldet; der Code oder zumindest ein Codegerüst wird automatisch aus der Spezifikation generiert)

⇒ Lesbarkeit (⇒ Überprüfbarkeit, Korrektheit, Robustheit, Wartbarkeit, Erweiterbarkeit)

• Schreibe überprüfbaren Code (Überprüfbarkeit, veriafiability)

  Die Korrektheit eines Softwarepakets sollte plattformunabhängig sein und automatisch überprüft werden können. Viele Programmierparadigmen und auch Projekttechniken verlangen zu diesem Zweck, dass gleichzeitig mit der Software auch passende Softwaretests implementiert werden. Noch besser ist es, wenn die Semantik des Programmes formal spezifiert und überprüft werden kann (Abstrakte Datentypen, Integritätsbedingungen, ...)

⇒ Korrektheit (insbesondere, wenn die Erfüllung der Spezifikation verifiziert, d.h. formal nachgewisen wird)

⇒ Robustheit (wegen ausführlicher Tests)

⇒ Portierbarkeit (wegen der Plattformunabhängigkeit)

• Schreibe stetigen Code (Stetigkeit, continuity)

  Schreibe den Code so, dass kleine Änderungen an der Spezifikation auch nur kleine Änderungen am Code zur Folge haben.

⇒ Warbarkeit (insb. Erweiterberkeit)

⇒ Wiederverwendbarkeit, da der Code schnell an neue Gegebenheiten angepasst werden kann

• Schreibe konfigurierbaren Code (Konfigurierbarkeit, customizability)

  Konstante Werte sollten im Allgemeinen nicht direkt in den Code eingefügt werden, sondern als konstante Werte separat definiert werden (Ausnahme: triviale Konstanten, die sich sicher nie ändern werden, wie z.B. Vergleiche mit dem Wert 0). Konstanten, die das Programmverhalten beeinflussen, sollten im Allgemeinen bei Programmstart aus einer Konfigurationsdatei ausgelesen werden.

⇒ Stetigkeit (⇒ Warbarkeit und Wiederverwendbarkeit)

• Wiederhole dich nicht (Don't repeat yourself, DRY)

  Das Prinzip „Separation of concerns“ kann man noch verallgemeinern: Code sollte nicht dupliziert werden, oder allgemeiner: Jedes Wissenselement muss im System ein einziges Mal, unzweideutig und geeignet repräsentiert werden. Wenn Code mehrfach verwendet wird, liegt ein allgemeineres Prinzip zu Grunde, das explizit ins System eingearbeitet werden sollte. Code ohne Duplikate von Anweisungen wir häufig als dry bezeichnet. Mit to dry code wird der Vorgang bezeichnet, Anweisungs-Duplikate aus dem zugehörigen Code zu entfernen.

⇒ Wartbarkeit (da Änderungen nicht an mehrere fast identischen Stellen vorgenommen werden müssen)

⇒ Lesbarkeit (da weniger Code exitiert)

• Benutze Schnittstellen zur Kommunikation mit Objekten, Modulen etc. (Interfaces)

  Die Verwendung von Schnittstellen zum Zugriff auf und zur Modifikation von Daten/Informationen (an Stelle eines direkten Zugriffes) ermöglicht es, Code lokal zu ändern, ohne dass dies Auswirkungen auf andere Objekte, Module etc. hat (solange sich die Schnittstellen nicht ändern).

⇒ Lesbarkeit

⇒ Stetigkeit (⇒ Warbarkeit und Wiederverwendbarkeit)

⇒ Überprüfbarkeit

⇒ Modularität

• Liskovsches Substitutionsprinzip (LSP, Ersetzbarkeitsprinzip): Eine Methode sollte nicht so überschrieben werden, dass sich ein Objet einer abgeleiteten Klasse anders verhält, als man es aufgrund der Definition der Basisklasse erwarten würde. Mit anderen Worten:

Methoden, die in abgeleiteten Klassen neu definiert werden, müssen alle Integritätsbedingungen (d.h. die Spezifikation) der Basisklasse beachten.

⇒ Spezifikation

• Benutze und beachte Integritätsbedingungen (integrity constraints)

  Das vorangegangene Prinzip kann noch verallgemeinert werden: Wann immer möglich, sollten Integritätsbedingungen — Vorbedingungen (pre conditions), Nachbedingungen (post conditions), Invarianten (invariants), Zusicherungen (Assertions) etc. — definiert und deren Einhaltung auch überprüft werden.

⇒ Spezifikation

⇒ Robustheit

• Gesetz von Demeter (Law of Demeter, LoD, „Sprich nur zu deinen nächsten Freunden“)

  Ein Objekt sollte nur Methoden von Objekten aufrufen, die es „persönlich“ kennt:

  • Objekte, die in Zustandsvariablen gespeichert sind
  • Objekte, die über direkte direkten Beziehungen zugänglich sind
  • Objekte, die mittels Parametern beim Methodenaufruf übergeben wurden
  • Objekte, die das aktuelle Objekt selbst erzeugt hat

⇒ Wartbarkeit

Modularität

Eines der wichtigsten Programmierprinzipien ist die Modularität (modularity). Berdrand Meyer war einer der ersten, der die Bedeutung der Modularität erkannt und beschrieben hat (vgl. Meyer (1997)).

• Teile und herrsche (Divide et impera, Modularität, modularity)

  Ein komplexes Problem (Vorhaben, Projekt, ...) kann man nur dadurch in den Griff bekommen, dass man es solange in kleinere, möglichst unabhängige Teilprobleme (Teilvorhaben, Phasen, Vorgänge, ...) zerlegt, bis diese lösbar (= beherrschbar) sind. Ein Programm sollte daher modularisiert werden.

⇒ Überprüfbarkeit (⇒ Korrektheit, Robustheit)

⇒ Warbarkeit (insbesondere Erweiterbarkeit)

⇒ Wiederverwendbarkeit (wenn die Module weitgehend unabhängig voneinander sind)

⇒ Lesbarkeit (kann bei extensiver Nutzung auch leiden)

Bertrand Meyer hat insgesamt fünf Anforderungen formuliert, die bei der Definition von Modulen beachtet werden sollten:

• Modulare Zerlegbarkeit (modular cecomposability)

  Zerlege in Problem in unterschiedliche, seperat lösbare Teilprobleme.

⇒ Überprüfbarkeit (⇒ Korrektheit, Robustheit)

⇒ Warbarkeit (insbesondere Erweiterbarkeit)

⇒ Lesbarkeit

• Modulare Zusammenfügbarkeit (modular composability)

  Module sollten in möglichst vielen (unterschiedlichen) Situationen/Anwendungen eingesetzt werden können. Das heißt, Module sollten auf unterschiedliche Art und Weise zu neuen Funktionseinheiten zusammengefügt werden können.

⇒ Wiederverwendbarkeit

⇒ Erweiterbarkeit

⇒ Überprüfbarkeit

⇒ Wartbarkeit

⇒ Schreibbarkeit

• Modulare Verständlichkeit (modular understandability)

  Die Aufgaben eines Moduls sollten verstanden werden, ohne dass man viele andere Module kennen muss.

⇒ Überprüfbarkeit (⇒ Korrektheit, Robustheit)

⇒ Wartbarkeit

⇒ Lesbarkeit

• Modulare Stetigkeit (modular continuity)

  Kleine Änderungen an den Anforderungen sollten nur Änderungen an einer geringen Zahl von Modulen zur Folgen haben. Im besten Fall ist nur ein einziges Modul betroffen.

⇒ Stetigkeit

⇒ Warbarkeit (insb. Erweiterberkeit)

⇒ Wiederverwendbarkeit, da der Code schnell an neue Gegebenheiten angepasst werden kann

• Modulare Robustheit (modular protection)

  Ein Modul sollte alle abnormalen Fälle selbst behandeln. Das heißt, es sollte sich nicht darauf verlassen, dass ein anderes Modul die Schnittstellen nur gemäß der Spezifikation verwendet.

⇒ Korrektheit

⇒ Robustheit

⇒ Überprüfbarkeit

⇒ Wartbarkeit

Aus diesen Forderungen leitet Bertrand Meyer sechs Prinzipien ab, die bei der Entwicklung von Modulen beachtet werden sollten.

• Module sind syntaktische Einheiten (syntactiacal units)

  Module sollten unabhängig voneinander übersetzt und in Bibliotheken zur Verfügung gestellt werden können.

⇒ Wiederverwendbarkeit

⇒ Korrektheit

⇒ Robustheit

⇒ Überprüfbarkeit

⇒ Wartbarkeit

• Module sollten wenige Schnittstellen haben (few interfaces)

  Module sollten mit so wenig anderen Modulen kommunizieren wie möglich.

⇒ Wiederverwendbarkeit

⇒ Lesbarkeit

⇒ Wartbarkeit

⇒ Überprüfbarkeit

• Module sollten schlanke Schnittstellen haben (small interfaces)

  Schnittstellen sollten nicht mit Funktionalität überfrachtet sein. Das heißt, zwei Module sollten über möglichst umfangarme Schnittstellen miteinander kommunizieren.

⇒ Lesbarkeit

⇒ Wartbarkeit

⇒ Überprüfbarkeit

• Module sollten über explizite Schnittstellen kommunizieren (explicit interfaces)

  Ein Modul sollte nicht über globale Variablen oder andere implizite Kommunikationswege mit anderen Modulen kommunizieren, sondern über explizite Schnittstellen.

⇒ Lesbarkeit

⇒ Wartbarkeit

⇒ Überprüfbarkeit

• Informationen sollten in Modulen gekapselt sein ((Daten-)Kapselung, Geheimnisprinzip, encapsulation, information hiding)

  Jede Information, die nicht notwendig ist, um die Aufgaben bzw. die Funktionalität eines Moduls zu verstehen, sollte von außen nicht zugänglich sein.

⇒ Wartbarkeit

⇒ Robustheit

⇒ Überprüfbarkeit

⇒ Wiederverwendbarkeit

• Module sollten sowohl offen, als auch geschlossen sein (open-closed principle)

  Module sollten sowohl offen für Veränderungen, als auch abgeschlossen gegenüber Veränderungen sein. Da heißt, ein funktionierendes Modul sollte möglichst nicht mehr verändert werden, aber andererseits sollte es problemlos möglich sein, ein Modul an neue Gegebenheiten anzupassen. In objektorientierten Sprachen wird dies vor allem durch Vererbung, Überschreiben von Methoden und die Verwendung von Abstrakten Klassen (insbesondere Interfaces) erreicht.

⇒ Wiederverwendbarkeit (wenn Module offen sind)

⇒ Erweiterbar (wenn Module offen sind)

⇒ Robustheit (wenn getestete Module geschlossen sind)

⇒ Wartbarkeit (wenn funtionierende Module geschlossen sind; jede Änderung an einem Modul hat eventuell weitere Änderungen zu Folgen → dies soll nach Möglichkeit vermieden werden)

Seit den wegweisenden Arbeiten von Bertrand Meyer aus den späten 80er-Jahren wurden weitere Prinzipien entwickelt, die die Definition von Modulen betreffen:

• Separation of concerns

  Bei der Modularisierung eines Softwarepakets sollte man darauf achten, dass jede konkrete Aufgabe von genau einem Modul erfüllt wird. Man muss also die „Verantwortlichkeiten“ unter den Modulen aufteilen, sonst gehen die Vorteile der Modularisierung zum Teil wieder verloren.

• Single responsibility principle

  Bei der objektorientierten Programmierung treibt man die Modularisierung manchmal sogar so weit, dass nicht nur für jede Aufgabe höchstens ein Objekt zuständig ist (Separations of Conerns), sondern dass umgekehrt auch jedes Objekt für genau eine Aufgabe zuständig ist (Single responsibility principle).

Das heißt, für jedes Modul gibt es genau einen Grund, warum es geändert werden muss: Die eine Aufgabe die es hat, ändert sich.

⇒ Robustheit

Quellen

• Kowarschick, W.: Multimedia-Programmierung

Siehe auch

• Software-Engineering
• Wikipedia:Prinzipien_Objektorientierten_Designs

Dieser Artikel ist GlossarWiki-konform.