Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Grundlagen der Programmierung: Entwurfsmuster

Prinzip 7: Ein und nur ein Grund für Veränderung

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Je mehr Aufgaben ein Objekt zu lösen hat, desto größer und komplexer wird es. Das erschwert Änderungen und macht für Fehler anfälliger. Hat das Objekt nur eine einzige Aufgabe, sind Änderungen leichter durchführbar und Auswirkungen klarer vorherzusehen.
02:50

Transkript

Dieses Prinzip ist ein zentrales Prinzip in der Erstellung wartbarer Softwaresysteme und das heißt eine Klasse sollte nur einen Grund haben sich zu ändern. Das lässt sich auch anderes formulieren. Eine Klasse sollte nur eine Verantwortlichkeit haben. Wenn sich dann innerhalb dieses Verantwortungsbereichs irgendwas ändert, dann muss die Klasse natürlich geändert werden. Wenn sich aber in irgendeinem anderen Bereich etwas ändert, dann hat die Klasse nichts damit zu tun und ist deshalb von der Änderung nicht betroffen. Ich zeige das an einem Beispiel und verwende dafür das Entwurfsmuster Iterator. Ohne den Iterator stellt sich die Situation so dar. Ein Client möchte auf die Elemente verschiedener Datenstrukturen zugreifen. Die eine Struktur ist ein Baum, die nächste ist eine Liste und die dritte ist eine Map. Alles was der Client möchte, ist sich der Reihe nach alle Elemente einer solchen Datenstruktur geben lassen. Da die Strukturen aber völlig unterschiedlich aufgebaut sind und der Zugriff auf diese Elemente von außen auch völlig unterschiedlich funktioniert, muss der Client für alle drei Strukturen wissen, wie er darauf zugreift. Anders ausgedrückt, der Client versucht drei Aufgabenbereiche abzudecken, die eigentlich nichts miteinander zu tun haben. Wenn wir von einer anderen Stelle im Programm auf diese Datenstrukturen zugreifen wollen oder vielleicht auch nur auf den Baum oder auf die Liste, dann müssten wir die entsprechende Funktionalität dort nochmal implementieren und wenn sich nun die Struktur des Baumes ändern sollte, dann müssen wir genau wissen, wer alles mit diesem Baum arbeitet, damit wir auch ja überall die richtigen Änderungen einbauen können. Egal ob der Baum sich ändert oder die Liste oder die Map, unser Client hier ist immer betroffen. Die Lösung die das Iteratormuster nun vorschlägt, ist folgende. Wir ziehen alles, was datenstrukturspezifisch ist, aus dem Client raus. Wir packen das jetzt aber nicht in die jeweilige Datenstruktur hinein. Da hätten wir das Problem nur verlagert. Sondern wir packen es in ein separates Objekt und das ist dann das Iterator-Objekt. Unserem Prinzip folgend haben wir jetzt natürlich für jede Datenstruktur einen eigenen Iterator. Das heißt, für den Baum haben wir den Baumiterator, der genau weiß, wie man über eine Baumstruktur iteriert. Für die Liste den Listiterator und für die Map den Mapiterator. Um es dem Client so bequem wie möglich zu machen, bieten alle drei Iteratorobjekt obendrein auch noch eine gemeinsame Schnittstelle an, sodass der Client also auch nicht mehr wissen muss, mit welchem Iterator er gerade redet. Jetzt haben wir die Zuständigkeiten sauber verteilt und jedes unserer Objekte hat auch tatsächlich nur noch einen Grund sich zu ändern. Der Baumiterator muss sich nur noch ändern, wenn der Baum sich ändert. Das betrifft aber nur die Implementierung des Baumiterators. Die Schnittstelle für den Client bleibt die gleiche. Das heißt, der Client ist von dieser Änderung nicht mehr betroffen. Natürlich ist es fast unmöglich, eine solche Verteilung gleich im ersten Wurf richtig zu machen. Das ist auch gar nicht nötig. Aber jedes Mal, wenn Sie merken, dass bei Änderungen in völlig verschiedenen Bereichen dieselbe Klasse betroffen ist, dann sollten Sie herausfinden, welche zwei Gründe diese Klasse hat sich zu ändern. Also welche zwei Verantwortlichkeiten sie versucht abzudecken und einen davon dann in eine separate Klasse rauslösen.

Grundlagen der Programmierung: Entwurfsmuster

Erhalten Sie einen fundierten Einstieg in das Thema Entwurfsmuster (Design Patterns) und erfahren Sie, wie Sie Entwurfsmuster in objektorientierten Programmiersprechen umsetzen.

2 Std. 49 min (33 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!