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
⇒ geringe Kosten durch Falschnutzung
⇒ 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 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)

• 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.
  ⇒ Warbarkeit (insbesondere Erweiterbarkeit)
  ⇒ Wiederverwendbarkeit (wenn die Module weitgehend unabhängig voneinander sind)
  ⇒ Überprüfbarkeit (⇒ Korrektheit, Robustheit)
  ⇒ Lesbarkeit (kann bei extensiver Nutzung auch leiden)

  • 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 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).

• 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.

• Benutze Schnittstellen zur Kommunikation mit Modulen, Objekten etc. ((Daten-)Kapselung, Geheimnisprinzip, encapsulation, information hiding)

  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 Module, Objekte etc. hat (solange sich die Schnittstellen nicht ändern).
  ⇒ Lesbarkeit
  ⇒ Stetigkeit (⇒ Warbarkeit und Wiederverwendbarkeit).
  ⇒ Überprüfbarkeit
  ⇒ Modularität

• Definiere schlanke Schnittstellen zur Kommunikation mit Modulen, Objekten etc. (Schlanke Schnittstellen, Lean APIs)

  Schnittstellen sollten nicht mit Funktionalität überfrachtet werden.
  ⇒ Lesbarkeit
  ⇒ Wartbarkeit

• Definiere Schnittstellen, die nur selten geändert werden müssen (Dauerhafte Schnittstellen, Stable APIs)

  Jede Schnittstellenänderung (mit Ausnahme von reinen Erweiterungen) hat zur Folge, dass viele Module, Objekte etc. angepasst werden müssen. So ist es z.B. besser, von Anfang an Setter- und Getter-Methoden zu verwenden, wenn eine Sprache (wie z.B. Java) keine echten Attribute unterstützt.
  ⇒ Lesbarkeit
  ⇒ Wartbarkeit

  • Benutze standardisierte Schnittstellen (Standard-Schnittstellen, Standardized interfaces): Dies ist die beste Art, für dauerhafte Scnittstellen zu sorgen.

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

  Ein Objekt sollte nur Methoden von Objektem 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

Quellen

• Kowarschick, W.: Multimedia-Programmierung

Siehe auch

• Software-Engineering
• wikipedia:Prinzipien_Objektorientierten_Designs

Dieser Artikel ist GlossarWiki-konform.