© saicle/Shutterstock.com
PHP Magazin
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.

Tobias Schlitt


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 1class 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 ); } /* ... */ } 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 ); } /* ... */ } Das Single Responsibility PrincipleListing 2class WeatherLoader { public function __construct( WeatherService $service, WeatherParser $parser ) { // ... } public function getWeatherForLocation( Location $location ) { $data = $this->service->getWeather( $location ); return $this->parser->parseData( $data ); } } class WeatherLoader { public function __construct( WeatherService $service, WeatherParser $parser ) { // ... } public function getWeatherForLocation( Location $location ) { $data = $this->service->getWeather( $location ); return $this->parser->parseData( $data ); } } Es ist leicht erkennbar, dass durch das Refactoring die oben genannten Änderungsmotivationen verschwinden. Die Anpassungen können allesamt durch neue Implementierungen eines oder beider abhängiger Typen realisiert werden.Sozusagen als „zusätzl...

PHP Magazin
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.

Tobias Schlitt


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 1class 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 ); } /* ... */ } 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 ); } /* ... */ } Das Single Responsibility PrincipleListing 2class WeatherLoader { public function __construct( WeatherService $service, WeatherParser $parser ) { // ... } public function getWeatherForLocation( Location $location ) { $data = $this->service->getWeather( $location ); return $this->parser->parseData( $data ); } } class WeatherLoader { public function __construct( WeatherService $service, WeatherParser $parser ) { // ... } public function getWeatherForLocation( Location $location ) { $data = $this->service->getWeather( $location ); return $this->parser->parseData( $data ); } } Es ist leicht erkennbar, dass durch das Refactoring die oben genannten Änderungsmotivationen verschwinden. Die Anpassungen können allesamt durch neue Implementierungen eines oder beider abhängiger Typen realisiert werden.Sozusagen als „zusätzl...

Neugierig geworden?


    
Loading...

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