| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung | |
| modul:archiv:m320:learningunits:lu06:theorie:lu07-kapitel_6 [2026/08/30 14:06] – ↷ Seite von modul:m320:learningunits:lu06:theorie:lu07-kapitel_6 nach modul:archiv:m320:learningunits:lu06:theorie:lu07-kapitel_6 verschoben msuter | modul:archiv:m320:learningunits:lu06:theorie:lu07-kapitel_6 [2026/08/30 14:10] (aktuell) – ↷ Links angepasst, weil Seiten im Wiki verschoben wurden 74.7.243.195 |
|---|
| ===== 6. Appendix: die hohe Kunst der OOP ===== | ===== 6. Appendix: die hohe Kunst der OOP ===== |
| In den bisherigen Beispielen und Übungen haben wir immer die naheliegenden Lösungen für das Design von Beziehungen gewählt. So haben wir z.B. die Spezialisierung von ''Kunde'' und ''Mitarbeiter'' als Vererbung einer Oberklasse ''Person'' realisiert.\\ | In den bisherigen Beispielen und Übungen haben wir immer die naheliegenden Lösungen für das Design von Beziehungen gewählt. So haben wir z.B. die Spezialisierung von ''Kunde'' und ''Mitarbeiter'' als Vererbung einer Oberklasse ''Person'' realisiert.\\ |
| {{modul:m320:learningunits:lu06:theorie:lu07-abb1.12-appendix-1.png?200|}}\\ | {{modul:archiv:m320:learningunits:lu06:theorie:lu07-abb1.12-appendix-1.png?200|}}\\ |
| //Abb 6.11: //Vereinfachte, naheliegende Vererbungshierarchie \\ | //Abb 6.11: //Vereinfachte, naheliegende Vererbungshierarchie \\ |
| Diese Sichtweise hat aber Nachteile. So kann eine Person nicht gleichzeitig Kunde und Mitarbeiter sein. Wenn man den Sachverhalt genauer betrachtet, erkennt man auch, dass ''Kunde'' und ''Mitarbeiter'' ja nicht wirklich eine Spezialiserungen von ''Person'' darstellen, sondern ''Rollen'' sind, die eine Person einnimmt. Dass der vereinfachte Ansatz problematisch ist, fällt dann auf, wenn wir z.B. eine weiter Spezialisierung wie ''Lieferant'' zufügen.\\ | Diese Sichtweise hat aber Nachteile. So kann eine Person nicht gleichzeitig Kunde und Mitarbeiter sein. Wenn man den Sachverhalt genauer betrachtet, erkennt man auch, dass ''Kunde'' und ''Mitarbeiter'' ja nicht wirklich eine Spezialiserungen von ''Person'' darstellen, sondern ''Rollen'' sind, die eine Person einnimmt. Dass der vereinfachte Ansatz problematisch ist, fällt dann auf, wenn wir z.B. eine weiter Spezialisierung wie ''Lieferant'' zufügen.\\ |
| Eine verbesserte Lösung im Sinne guten OO-Designs würde also wie folgt aussehen:\\ | Eine verbesserte Lösung im Sinne guten OO-Designs würde also wie folgt aussehen:\\ |
| {{modul:m320:learningunits:lu06:theorie:lu07-abb1.13-appendix-1.png?325|}}\\ | {{modul:archiv:m320:learningunits:lu06:theorie:lu07-abb1.13-appendix-1.png?325|}}\\ |
| //Abb. 6.12: //Optimiertes Design mit einer Klasse Role (Rolle) | //Abb. 6.12: //Optimiertes Design mit einer Klasse Role (Rolle) |
| \\ | \\ |
| Wenn Ihr Programm auf eine Ressource wie z.B. eine Datenbank zugreifen soll, so muss das "geordnet" erfolgen. Sie können nicht an x-beliebigen Stellen in Ihrem Code DB-Zugriffsobjekte erzeugen. Das gleiche gilt auch für Kommunikationsschnitstellen. Wie aber kann man sicherstellen, dass es von einem Objekt immer nur eine Instanz gibt?\\ | Wenn Ihr Programm auf eine Ressource wie z.B. eine Datenbank zugreifen soll, so muss das "geordnet" erfolgen. Sie können nicht an x-beliebigen Stellen in Ihrem Code DB-Zugriffsobjekte erzeugen. Das gleiche gilt auch für Kommunikationsschnitstellen. Wie aber kann man sicherstellen, dass es von einem Objekt immer nur eine Instanz gibt?\\ |
| Dazu dient das Design-Pattern des ''Singleton''.\\ | Dazu dient das Design-Pattern des ''Singleton''.\\ |
| {{modul:m320:learningunits:lu06:theorie:lu07-abb1.14-appendix-4.png?275|}}\\ | {{modul:archiv:m320:learningunits:lu06:theorie:lu07-abb1.14-appendix-4.png?275|}}\\ |
| //Abb. 6.13: //Singleton-Pattern\\ | //Abb. 6.13: //Singleton-Pattern\\ |
| Aber was macht denn dieses ''Singleton''? Ein Singleton fällt vorerst dadurch auf, dass sein Konstruktor private deklariert ist. Man kann also von ausserhalb der Klasse den Konstruktor gar nicht aufrufen.\\ | Aber was macht denn dieses ''Singleton''? Ein Singleton fällt vorerst dadurch auf, dass sein Konstruktor private deklariert ist. Man kann also von ausserhalb der Klasse den Konstruktor gar nicht aufrufen.\\ |