Das Observer-Muster

Definition

Das Observer-Muster (Beobachter) ist eines der GoFEntwurfsmuster (Design Pattern) und gehört zu der Kategorie der Verhaltensmuster (Behavioral Design Pattern). Das Muster „definiert eine Eins-zu-viele-Abhängigkeit zwischen Objekten in der Art, dass alle abhängigen Objekte benachrichtigt werden, wenn sich der Zustand des einen Objekts ändert“ (EvKbF S. 51).

Beschreibung

Die Interaktion der Objekte ist ein essentieller Bestandteil der objektorientierten Programmierung. Fälle, in denen bestimmte Objekte über Veränderungen in anderen Objekten informiert werden müssen, sind recht häufig. Das Ziel sollte daher ein Entwurf sein, in dem so viel wie möglich entkoppelt ist und die Abhängigkeiten reduziert sind. Das Observer-Muster setzt auf ein OO-Entwurfsprinzip, das uns hilft dieses Ziel zu erreichen:

„Streben Sie für Objekte, die interagieren, nach Entwürfen mit lockerer Bindung.“

Die bekannteste Implementierung des Observer-Musters sind die Event Handler. Die Event Handler zeichnen sich durch eine einheitliche Schnittstelle aus, durch die der Entwurf flexibel bleibt. Um jedoch ein besseres Verständnis des Observer-Musters zu erhalten, wollen wir uns an einem Beispiel anschauen, wie man das Observer-Muster selbst implementieren kann.

Weiterlesen

Das Strategy-Muster

Definition

Das Strategy-Muster (Strategie) ist eines der GoFEntwurfsmuster (Design Pattern) und gehört zu der Kategorie der Verhaltensmuster (Behavioral Pattern). Das Muster „definiert eine Familie von Algorithmen, kapselt sie einzeln und macht sie austauschbar. [Es] ermöglicht, den Algorithmus unabhängig von den Clients die ihn einsetzen, variieren zu lassen“ (EvKbF S. 24).

Beschreibung

Die einzig wahre Konstante, auf die man sich bei der Software-Entwicklung immer verlassen kann, ist die Veränderung. Das Ziel sollte daher sein, die Entwürfe stets so zu gestallten, dass Änderungen minimale Auswirkungen auf den bestehenden Code haben. Das Strategy-Muster vereinigt drei OO-Entwurfsprinzipien, die helfen dieses Ziel zu erreichen.

Weiterlesen

Das Dependency Inversion Principle

Definition

Das Dependency Inversion Principle (Abhängigkeits-Umkehrungs-Prinzip, DIP) ist eines der SOLID-Prinzipien. Es sagt aus:

  1. „High level modules should not depend upon low level modules. Both should depend upon abstractions.“
  2. „Abstractions should not depend upon details. Details should depend upon abstractions.“
  1. „Höherstufige Module sollten nicht von niedrigstufigen Modulen abhängig sein. Beide sollten von Abstraktionen abhängen.“
  2. „Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.“

Weiterlesen

Das Interface Segregation Principle

Definition

Das Interface Segregation Principle (Schnittstellenaufteilungsprinzip, ISP) ist eines der SOLID-Prinzipien. Es lautet:

„Clients should not be forced to depend upon Interfaces that they do not use.“
„Clients sollten nicht gezwungen werden von Schnittstellen abhängig zu sein, die sie nicht verwenden.“

Klassen mit „überladenen Schnittstellen“ sind nicht kohäsiv. Die Schnittstellen solcher Klassen können in Gruppen von Methoden aufgeteilt werden. Das hat den Vorteil, dass ein Client dann nur eine Schnittstelle, mit einer Gruppe von Methoden nutzt, die es auch wirklich braucht.

Weiterlesen

Das Liskov Substitution Principle

Definition

Das Liskov Substitution Principle (Liskovsche Substitutionsprinzip, LSP) ist eines der SOLID-Prinzipien. Es wurde erstmals 1987 von Barbara Liskov auf der Konferenz Data abstraction and hierarchy vorgestellt und wurde 1993 von Barbara Liskov und Jeannette Wing formuliert. „Es besagt, dass ein Programm, das Objekte einer Basisklasse T verwendet, auch mit Objekten der davon abgeleiteten Klasse S korrekt funktionieren muss, ohne dabei das Programm zu verändern.“

Weiterlesen

Das Open-Closed Principle

Definition

Das Open-Closed Principle (Offen-Geschlossen-Prinzip, OCP) ist eines der SOLID-Prinzipien. Es wurde 1988 von Bertrand Meyer beschrieben und es lautet:

„Software Entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.“
„Software Entitäten (Klassen, Module, Funktionen, usw.) sollten offen für Erweiterungen sein, aber geschlossen für Modifikationen.“

Ein intelligenter Entwurf einer Anwendung sollte stets die häufigen Änderungen während der Entwicklung und der Wartungsphase berücksichtigen. Fügt man einer Anwendung neue Funktionalität hinzu, sind Änderungen am Code unumgänglich. Diese Änderungen im existierenden Code sollten jedoch auf das Minimum reduziert werden. Bedenkt man, dass der Code bereits getestet wurde, können Änderungen im geschriebenen Code unerwünschte Nebenwirkungen haben oder zu unbeabsichtigten Fehler führen.

Das Offen-Geschlossen-Prinzip sagt aus, man sollte Module so entwerfen, dass sich diese niemals ändern. Wenn sich die Anforderungen ändern, sollte man das Verhalten durch das hinzufügen neuen Codes erweitern, statt den existierenden Code zu ändern, der bereits funktioniert. Der existierenden Code sollte soweit wie möglich unverändert bleiben.

Weiterlesen

Das Single Responsibility Principle

Definition

Das Single Responsibility Principle (Eine-Verantwortlichkeit-Prinzip, SRP) ist eines der SOLID-Prinzipien. Es wurde von Robert C. Martin im gleichnamigen Teilartikel in seiner Publikation Principles of Object Oriented Design eingeführt und es lautet:

„There should never be more than one reason for a class to change.“
„Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern.“

Weiterlesen