© saicle/Shutterstock.com
Kolumne: Quality Time

Von den Verantwortlichkeiten


Wer sich bei Designentscheidungen einige Prinzipien verinnerlicht, kann beim Aufbau von Klassen, Modulen und Komponenten wart-, erweiter- und anpassbare Software erzeugen. Den Anfang macht das Single Responsibilty Principle.

Gutes, objektorientiertes Softwaredesign führt zu wartbarer, erweiterbarer und anpassbarer Software. Doch wer beim Thema Softwaredesign sofort bei hinlänglich bekannten Patterns hängt, hat zu kurz gedacht: Den meisten anständigen Designentscheidungen liegen viel subtilere Prinzipien zugrunde, die sich, einmal verinnerlicht, intuitiv beim Aufbau von Klassen, Modulen und Komponenten anwenden lassen. In diese Kategorie fallen insbesondere die SOLID-Prinzipien, die von Robert C. Martin [1], alias Uncle Bob, bekannt gemacht wurden. Grund genug für uns, in den nächsten Ausgaben jeweils eines der Prinzipien unter die Lupe zu nehmen, beginnend bei S, wie Single Responsibility Principle.

Das folgende Beispiel zeigt eine einfache Klasse, die in einem Projekt dafür verwendet wird, Wetterdaten für einen bestimmten Ort von einem Web Service abzurufen. Hierzu stellt sie die Methode getWeatherForLocation() bereit (Listing 1).

Listing 1

class WeatherLoader { public function getWeatherForLocation( Location $location ) { $xml = $this->fetchData( $location->city ); return $this->parseData( $xml ); } protected function fetchData( $city ) { $url = sprintf( 'http://...?city=%s', $city ); return $this->fetchFromUrl( $url ); } /* ... */  } 

Wie leicht zu erkennen ist, verrichtet diese Methode indirekt einiges an Arbeit: Zunächst werden Wetterdaten mittels eines HTTP Requests geholt. Im Anschluss werden sie geparst und in ein Datenobjekt gekapselt. Die Details dieser Prozesse wurden hier aus Platzgründen ausgelassen. Und damit zeigt sich auch schon das Problem: Die Klasse verrichtet zu viel Arbeit.

Das Single Responsibility Principle

Das Single Responsibility Principle, also das Prinzip der einzelnen Verantwortlichkeit, widmet sich genau diesem Problem: Jede Klasse sollte genau eine einzelne Verantwortlichkeit haben. Oder, wie in der Formulierung des Prinzips selbst ausgedrückt: Für jede Klasse sollte es nur einen Grund geben, sie zu ändern. Im gezeigten Beispiel fallen einem aber umgehend mehrere Gründe ein, warum hier Code angepasst werden müsste, von der Behebung von Bugs einmal abgesehen: Der angefragte Provider ändert seine URL-Struktur, seine Datenstruktur oder gar seine Lizenzbedingungen, sodass in Zukunft ein ganz anderer Anbieter verwendet werden mu...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang