class: center, middle, first # Software-Entwicklung 2 ### Applikationsarchitektur --- # Fragen? > Fragen zur letzten Vorlesung? --- # Themen - Applikationsarchitektur * Architektur einer OO-Applikation * Interfaces * Factories --- # Applikationsarchitektur * Anforderungen an eine Applikation * Grundmuster der OO-Applikation * Applikationskern und Erweiterungen * Interfaces und Factories im Zusammenspiel --- # Anforderungen an eine Applikation * Klare, verständliche Struktur des Codes ➡️ Packages, Clean Code Regeln * Aufteilung in Hotspots und Coldspots ➡️ Hotspot: Bereich großer Änderungserwartung * Wartbar: Fehler können schnell gefunden werden ➡️ Einsatz von Logging Framework * Anpassbar an Kunden und Branchen ohne große Code-Änderungen ➡️ Interfaces und Factories * Updates durch Releases müssen möglich sein ➡️ Aufteilung des Codes in Core und Erweiterungen --- # Grundmuster der OO-Applikation
> Beim Start einer OO-Applikation werden Objekte erzeugt und miteinander verbunden. Die Steuerung geschieht durch die Verwendung verschiedener Factories oder durch Konfigurationsfiles. --- # Applikationskern und Erweiterungen
> Ziel ist es, Kern und Erweiterungen so unabhängig wie möglich zu halten, sonst kann der Kern nicht weiterentwickelt werden oder Kunden müssen dauernd Code anpassen. --- # Interfaces und Factories
> Die linke Seite definiert ein Puzzleteil durch das Interface `IVehicle`. Die rechte Seite holt aus einer Factory passende Teilchen heraus. Der String "`10 passengers`" beschreibt eine inhaltliche Anforderung! --- # Herausforderung bei Interfaces > Die Kunst beim Definieren von Interfaces ist, alle nötigen Methoden zu finden, mit denen die Verarbeitung im Kern der Applikation gemacht werden kann. Nachträgliches Einfügen ist hart weil meist **alle** Implementationsklassen angepasst werden müssen! (Außer man kann die zusätzliche Methode als Default in einer abstrakten Klasse im Kern unterbringen, so dass Customerklassen sie nicht implementieren müssen) --- # Wie funktionieren Interfaces? * Bedeutung des Begriffs * Syntax * Einsatzzweck * Typen von Interfaces * Was: Methodenkopf * Wie: Logik, Implementierung * Polymorphische Verwendung * Kapselung! --- # Bedeutung des Begriffs * "`Interface`" als Java Schlüsselwort beschreibt eine Klasse mit nur abstrakten Methoden die Ableiter implementieren müssen. * "Interface einer Klasse" bedeutet es ALLES, was nach außen für Verwender sichtbar ist: `public` Attribute (**verboten**!) und `public` Methoden sowie die `protected` Versionen für ableitende Klassen. Das umfasst Parameter, ihre Typen, Anzahl, Reihenfolge, `return`-Werte und Typen, Exceptions, Namen der Felder und Methoden, Sichtbarkeit von Feldern und Methoden. > Jede Änderung am "Interface" oder "Interface einer Klasse" hat schwere Konsequenzen für bereits existierende Ableiter oder Verwender! --- # Syntax (I) * Ähnlich Abstrakte Klasse * Anstatt `class` → `interface` * Alle Methoden sind automatisch `abstract` und `public` * Ausschließlich Deklaration des Methodenkopfes, keine Implementierung! * Abschluss des Methodenkopfes mit `;` * Seit Java 8: Default-Implementierung möglich > Tipp: Sie können auch mit einer abstrakten Klasse anfangen und ihre Methoden definieren. --- # Syntax (II) * Keine Konstruktoren * Von Interfaces können keine konkreten Objekte erzeugt werden * Aber als Typ können und sollen sie auf der linken Seite vom `==`/`=` verwendet werden. * Nur Konstanten erlaubt * `static final` (implizit) --- # Einsatzzweck * Realisierung der Mehrfachvererbung in Java * Trennt das "**Was**" vom "**Wie**" - bzw. Form von Inhalt * Was: Methodenkopf * Wie: Logik, Implementierung * Maximale Unabhängigkeit der implementierenden Klasse da kein Code "geerbt" wird. * Ähnlich einem API (Application Programming Interface) schreibt es Services vor, die implementiert werden müssen. --- # Modellierungsbeispiel > Zusammenfassendes Beispiel * `Person`, `Student`, `Employee` --- # Interfacetypen * Marker Interfaces (Missbrauch, da es in den ersten Java-Versionen keine Annotationen gab...) * z.B. `Remote`, `Serializable` etc. * keine Methoden enthalten * "Abstraktionsinterfaces" * `IStudent`, `IPerson` * Dienen der Erweiterbarkeit und Austauschbarkeit**!!** --- # Factories * Sog. Design-Pattern (GoF) * Nur verwendet für Klassen die evtl. angepasst werden müssen und für die es Interfaces gibt. * Factories erzeugen intern konkrete Klassen und geben Sie als `Interface Typ` zurück. * Außerhalb von Factories tauchen die konkreten Klassennamen **nicht** auf! * Damit können spezifische Anpassungen leicht pro Kunde ausgetauscht werden! * Vermeidung/Kapselung von Konstruktoraufrufen im Kern der Applikation * Anti-Pattern im Kern der Applikation: > `KonkreterTyp x = new KonkreterTyp(); // bei x1: Anpassung im Code nötig` --- # Code-Beispiel ```java public class StudentFactory{ public static IStudent getInstance(String type, String firstName, String lastName, String bannerId){ if("hdm".equals(type){ return new HdMStudent(firstName, lastName, bannerId); }else if(type.equals("hft")){ return new HfTStudent(firstName, lastName, bannerId); }else{ // TODO: Default-Implementierung, Exception, Logging } } } ``` > nur ein simples Beispiel. Richtige Factories verwenden Config-Files und Java Reflection zum dynamischen Laden ohne die "`if`"... --- # Beispiel: Verwendung von Interfaces und Factories im Framework > Demo! --- # Die ideale Software-Architekt:in * kennt mehr als ein Programmierparadigma (funktional, OO, prozedural) und deren Stärken und Schwächen * sucht die Technik die zum Problem passt und nicht umgekehrt * ist nicht verbohrt (golden Hammer Antipattern) * ist pragmatisch und langfristig unterwegs (80/20 Regel, kennt den Kunden) * kennt agiles Projektmanagement und respektiert den Human Factor * sorgt dafür, dass alle im Team Analysis, Design und Implementation machen * kennt Lösungsmuster und bildet sich täglich theoretisch weiter * entwickelt mit im Team * und vieles mehr.... --- class: center, middle # Fragen? [javainsel01]: http://openbook.galileocomputing.de/javainsel/javainsel_05_013.html