JAVA & Objektorientiertes Programmieren 2
Erweiterung der ersten Kartei
Erweiterung der ersten Kartei
Fichier Détails
| Cartes-fiches | 203 |
|---|---|
| Langue | Deutsch |
| Catégorie | Informatique |
| Niveau | Université |
| Crée / Actualisé | 19.01.2017 / 09.01.2024 |
| Lien de web |
https://card2brain.ch/box/20170119_java_objektorientiertes_programmieren_2
|
| Intégrer |
<iframe src="https://card2brain.ch/box/20170119_java_objektorientiertes_programmieren_2/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
Wie sieht das Codefragment eines Listeners, welcher Events von mehreren Komponenten empfängt?
(siehe Beispiel)
Eigentliche Behandlung wird in Methoden ausgelagert:
Code wird übersichtlicher; Methoden sind Wiederverwendbar
Wie sieht das gesamte UML eines Autos mit einem Motor und Lichtern, welches das Eventhandling implementiert hat?
(siehe Bild)
Weshalb sollte man so weit möglich und sinnvoll immer bereits bestehende Eventklassen und Listener-Interfaces verwenden?
- weniger Programmieraufwand, bekannte Semantik
- eigene Event-Klassen immer von EventObject ableiten
Behandlung von Events am Besten an (private) ______ delegieren, Code wird dadurch übersichtlicher.
Methoden
Was sind die allgemeinen Namenskonventionen vom Event-Handling?
(siehe Bild)
Was sind Unschönheiten beim Event-Handling? Was gibt es für Lösungen?
- Beim Event-Handling kann es viele verschiedene Quellen für gleichartige Events geben: Registriert sich ein Objekt bei mehreren Quellen für die gleichen Events, treffen diese somit alle in der selben Funktion ein!
- Das Event-Objekt enthält als Information auch die Quelle (source) was die Differenzierung ermöglicht. (Auswertung über ein if-Konstrukt nötig, SRP nicht eingehalten, unübersichtlich und fehleranfällig!)
- Schöner wäre es, wenn man bei jeder Quelle ein eigenständiges Objekt registrieren könnte. (Dafür müsste man aber für jede Quelle wiederum eine eigenständige Listener-Klasse implementieren! -> geringe Kohäsion, gehört ja eigetnlich in die Listener-Klasse)
Wir können in Java Klassen innerhalb von Klassen definieren. Geht auch: Interfaces in Interfaces?
Ja, auch möglich
Was ist eine sinnvolle Anwendung von inneren Klassen?
Damit kann man "private" (Hilfs-)Klassen definieren, welche nur innerhalb einer Klasse sichtbar sind (public und static geht auch, aber komplizierter)
Was für Beispiele gibt es für Innere Klassen aus den Datenstrukturen?
- Das Interface Map definiert ein internes Interface Map.Entry
- Die Klasse HashMap definiert eine interne Klasse Node (welche Map.Entry implementiert)
Wir können die Technik der inneren Klassen u.a. bei Event-Listeners gut einsetzen. Weshalb kann das sinnvoll sein?
Um weniger Code schreiben zu müssen und eine höhere Kohäsion zu erreichen
Zeige ein Beispiel einer Inneren Klasse für Eventhandling (Car-Beispiel).
Was ist der Vorteil einer solchen Implementation?
(siehe Bild)
Individuelle Listener pro Registrierung/Quelle möglich!
Wenn wir wissen, dass wir eine innere Klasse genau nur einmal und nur an einer Stelle instanziieren, können wir diese auch wie definieren?
als anonyme innere Klasse
Was sind anonyme innere Klassen?
- Haben keinen Namen
- Werden an Ort und Stelle der Verwendung definiert!
Achtung: Die Syntax ist zwar logisch, aber dennoch etwas gewöhnungsbedürftig!
Zeige ein Beispiel einer anonymen inneren Klasse für Eventhandling
(siehe Bild)
Anonyme Klassen auf Basis von Interfaces oder Klassen definiert und dabei an Ort und Stelle implementiert bzw. spezialisiert!
Zwei sehr fundamentale Kriterien für guten Design sind:
(möglichst) starke Kohäsion und _______ ?
möglichst lose Kopplung
Was bedeutet Kohäsion?
Eine Programmeinheit (Methode, Klasse, Modul etc.) ist für genau eine wohldefinierte Aufgabe verantwortlich (Single Responsibility Prinzip)
Betrachten Sie folgendes Beispiel einer Klasse.
Ist dies ein gutes oder schlechtes Beispiel?
Schlechtes Beispiel. Schon der Name CalcUtil lässt es ahnen: Ein Gemischtwarenladen von Methoden die nicht wirklich zusammengehören!
Schlechte, tiefe, schwache Kohäsion und SRP verletzt
Ist dies ein gutes Beispiel der Implementierung von Klassen (Tipp: Kohäsion)
Gutes Beispiel! Starke Kohäsion, SRP eingehalten!
Klasse wurde in vier einzelne Klassen aufgebrochen.
Nebeneffekt: Namensgebung wurde spezifischer und besser!
Achtung: Jede weitere neue Methode die ergänzt wird, kann ein erneutes Aufbrechen sinnvoll bzw. notwendig machen!
-> Refactoring ist eigentlich ein ständiger Prozess
Was sind Vorteile von Klassen mit hoher Kohäsion?
Das Single Responsibility Principle (SRP) wird eingehalten.
Die Klassen sind dadurch:
- kleiner spezifischer
- schneller und leichter überschaubar / verständlich
- besser wiederverwendbar
- wesentlich einfacher testbar
Was ist Kopplung?
Kopplung beschreibt wie stark einzelne Programmeinheiten untereinander in Verbindung stehen
Weshalb ist Kopplung grundsätzlich notwendig?
Damit überhaupt eine Interaktion (Zusammenarbeit) zwischen Klassen erfolgen kann
Wie manifestiert sich Kopplung?
- Verwendung von Datentypen
- Aufruf von Methoden
- explizite Beziehungen zwischen Klassen
Was ist das Ziel bei Kopplung?
So starke Kopplung wie nötig, so lose Kopplung wie möglich!
Die Rechtecke stellen Klassen, die Pfeile ihre Beziehungen untereinander, dar.
Ist dies ein gutes Beispiel von OO-Design?
Schlechtes Beispiel!
Zwar aus vielen, kleinen Einheiten (Klassen) aufgebaut (positiv!) -> Kann ein Indiz für hohe Kohäsion der Einzelklassen sein
Aber extrem stark vernetzt, ohne sichtbare Struktur (negativ!) -> ist ein direkter Hinweis für eine zu hohe Kopplung
Was sind Konsequenzen von zu hoher Kopplung?
Funktionsweise schwer durchschaubar und schwer verständlich
- grundsätzlich langsamere und aufwändigere Entwicklung
- schlechte Testbarkeit (spziell auch Unit-Testing)
- führt potentiell zu mehr Fehlern!
- die Fehlersuche ist noch dazu aufwändiger
Weiterentwicklung und Wartung wird dadurch erschwert
- Spätere Änderungen und/oder Erweiterungen sind schwierig
- Schlimmster Fall: Entwicklung wird abgebrochen
Ist dies ein Beispiel von gutem OO-Design?
Ja,
- Klassen gruppiert, hohe Kohäsion innerhalb der grauen Teile
- Beziehungen zwischen Klassen grundsätzlich reduziert
- Schmale Schnittstellen (blau) zwischen den grauen Teilen
Was ist gutes OO-Design und welche Auswirkungen hat es?
Tendenziell mehr, und kleinere Klassen. Daraus resultiert:
- bessere und schnellere Verständlichkeit / Lesbarkeit
- einfachere und bessere Testbarkeit
- höhere Wiederverwendbarkeit (auch in anderem Kontext)
- höhere Prallelität in der Entwicklung möglich
Änderungen sind einfacher möglich
- weil lokaler, betreffen weniger andere Elemente
- Auswirkung von Fehlern schneller eingrenzbar
- somit tendenziell auch weniger Fehler!
Was sind die Eigenschaften des Beziehungstyp: use?
Schwächste Form einer Beziehung
- Eine Klasse nutzt einen anderen Typ (meist nur temporal oder in einer/wenigen Methoden
- Manifestion im Code: Lokale Variable, formale Parameter, Returntyp, statischer Aufruf
Visualisierung in UML (siehe Bild):
A hängt von B ab, weil B von A verwendet wird (Methode verwendet Math.PI zur Berechnung des Kreisumfanges)
Was sind die Eigenschaften des Beziehungstyp: Assoziation?
Häufigste Form einer Beziehung
- Eine Klasse hat eine explizite Beziehung zu einem anderen Typ (Beziehung ist essentiell für die Funktion / das Modell.
- Manifestation im Code: Häufig ein Attribut von einem anderen Typ
- Visualisierung in UML (siehe Bild):
A kennt (und nutzt) B. (Bidirektional möglich)
Ein Student A besucht ein Modul B
Was sind die Eigenschaften des Beziehungstyp: Aggregation?
Spezialisierung der Assoziation: Hierarchisch, "Ist Teil von".
- Eine Klasse hat eine explizite Beziehung zu einem anderen Typ (Dieser Typ ist ein logischer Teil (part of) der Klasse)
- Manifestation im Code: Wie Assoziation, sehr häufig ein Attribut vom anderen Typ.
- Visualisierung in UML (siehe Bild)
A hat (und nutzt) B. (auch mehrere möglich)
Ein Auto A hat einen Motor B
Was sind die Eigenschaften vom Beziehungstyp: Komposition?
Spezialisierung der Aggregation: Existenziell gekoppelt.
- Eine Klasse nutzt einen anderen Typ als Teil von sich selber (dieser Teil ist existenziell (lebensdauer) gekoppelt
- Manifestation im Code: Wie Aggregation, zusätzlich erstellt (new...) die Klasse den teil
- Visualisierung in UML (siehe Bild)
A erzeugt und hat B (auch mehrere möglich)
Ein Mensch A hat einen Kopft B
Was sind Eigenschaften des Beziehungstyp: Implementation (implement)?
Eine Klasse Implementiert ein (oder auch mehrere) Interfaces
- Manifestation im Code: Schlüsselwort implement
- Visualisierung in UML (siehe Bild)
Was sind Eigenschaften des Beziehungstyp: Vererbung (extends)?
Eine Klasse erbt von einer anderen Klasse
- analog auch zwischen Interfaces
- stärkste Form der Kopplung!
- Manifestation im Code: Schlüsselwort extends
- Visualisierung in UML (siehe Bild)
Beurteile die Kopplung
ganz ok!
Beurteile die Kopplung
Zyklische Beziehung -> eher nicht zu empfehlen
Was sind die zehn wichtigen Designprinzipien?
1. Single Responsibility Principle (SRP)
2. Don't repeat yourself (DRY)
3. Favor composition over inheritance (FCoI)
4. Design for inheritance, oder prohibit it
5. Achte auf hohe Kohäsion und lose Kopplung
6. Differenziere zwischen Datenkapselung und Information Hiding
7. Verwende Schnittstellen zu Entkopplung und Abstraktion
8. Teste mit Unit-Tests nach dem Test First Prinzip
9. Viele kleine Einheiten sind besser als wenige Grosse
10. Aussagestarke Namensgebung und formatierter Quellcode
Was sagt das Single Responsibility Principle aus?
Eine Klasse hat möglichst nur eine Zuständigkeit
Änderungen oder Erweiterungen sollten sich immer auf möglichst wenige Klassen beschränken (hohe Kohäsion bleibt erhalten)
Viele kleine Klassen sind besser als wenige grosse Klassen
Was ist ein wichtiges Vorteil beim Einhalten des SRP?
Stark verbesserte Testbarkeit!
Was bedeuted DRY?
Don't repeat yourself
Duplizierung von Code wenn immer möglich vermeiden.
- Einfache Duplizierung: Kopierte Codefragmente
- Subtile Duplizierung: Wiederholte, immer gleiche Bedingungskonstrukte, Identische Algorithmen, unterschiedlich implementiert
Was ist eine Lösung wenn man DRY vermeiden möchte? Was hat das Vermeiden für einen Vorteil?
Lösungen: Unterfunktionen, Objektorientierung, Design Patterns
Vermeidung von Duplizierung erhöht die Produktivität!
-> Wiederverwendung wird verbessert / erst möglich.
