Anwendung der Aspektorientierung: Design Patterns

Transkript

1 Anwendung der Aspektorientierung: Design Patterns Seite 1

2 Agenda Allgemein: Design Patterns Adapter Decorator Observer Design Patterns in der AOP Adapter Decorator Observer Zusammenfassung Seite 2

3 Allgemein: Design Patterns Design Principles: Identify the aspects of your applicaion that vary and seperate them from what stays the same. [1] Program to an interface, not an implementation. [1] Favor composition over inheritance. [1] Patterns werden nicht erfunden, sondern entdeckt Helfen dabei Systeme mit guten OO design Qualitäten zu bauen Gemeinsames Vokabular Bieten Lösungen zu Standard Design Problemen Seite 3

4 Adapter Definition: The Adapter Pattern converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn t otherwise because of incompatible interfaces.[1] Seite 4

5 Adapter 2 Möglichkeiten: Object Adapter: implementiert das von Client benötigte Interface und hat eine Referenz auf Adaptee Seite 5

6 Adapter Class Adapter: implementiert das von Client benötigte Interface und ist eine Unterklasse von Adaptee Seite 6

7 Beispiel zu Adapter Seite 7

8 Decorator Definition: The Decorater Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.[1] Ziel: Verhalten der Klassen dynamisch zur Laufzeit zu erweitern Bsp:Erweiterung einer Textanzeige/Graphik eines Rahmens einer Scrollbar etc. Seite 8

9 Decorator Klassendiagramm: Seite 9

10 Beispiel zu Decorator Java I/O FileInputStream ist die Komponente BufferdInputStream ist ein konkreter Dekorierer puffert den Input und hat eine weitere Methode readline() LineNumberInputStream ist ebenfalls ein konkreter Dekorierer Zählt Anzahl der Zeilen Seite 10

11 Beispiel zu Decorator Grober Überblick: Seite 11

12 Observer Metapher des Zeitungs-Abonnements(Publisher + Subscribers) Observer-Pattern = Publisher + Subscribers Seite 12

13 Observer Definition: The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependencies are notified and updated automatically.[1] Subjects und Observers sind lose gekoppelt Observers können jederzeit, auch zur Laufzeit, hinzugefügt/ersetzt werden Folge: flexible OO Systeme 2 Möglichkeiten: push: Subject gibt Änderungen an Object mittel notifyobserver() weiter pull: Objects holen sich die Daten selber von Subject Seite 13

14 Observer Klassendiagramm: Seite 14

15 Beispiel zu Observer JDK: Swing JButton ist nach dem Prinzip des Observer Patterns aufgebaut Observer = ActionListener AbstractButton hat viele add()/remove() Methoden zum Hinzufügen/Entfernen von ActionListeners ActionListener lassen in sich hineinhören um jegliche Art von Ereignissen zu erfahren: Bsp. Man drückt auf den Button Seite 15

16 Design Patterns in der AOP AspectJ implementation of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements are manifested in terms of better code locality, reusability and (un)pluggability.[4] Grad der Modularitätsverbesserung variiert sehr stark Die meisten Design Patterns sind bereits crosscutting und können direkt in Aspekten ausgedrückt werden Seite 16

17 Adapter in der OOP Adapter übersetzt das Interface einer Klasse, so dass es dem Interface von Client entspricht Interface von Client und Target können in versch. Paketen liegen Folge: es ist nicht mehr so einfach ersichtlich wo Adapter liegt und was er genau macht Wiederverwendbarkeit: Für jedes Problem muss ein neuer Adapter implementiert werden Seite 17

18 Beispiel Adapter Seite 18

19 Adapter Pattern ist in einem Aspekt realisiert anstatt in mehreren Adapter Klassen Hinzufügen von neuen Adaptees bedeutet Schreiben einer neuen Methode anstatt einer ganzen Klasse Bei wachsender Anzahl wird der Aspekt lang Bei OOP würden immer mehr Adapter Klassen hinzukommen AOP Variante ist entkoppelt von der eigentlichen Applikation Seite 19

20 Decorator Decorator in der OOP: erweitert dynamisch das Verhalten von Klassen Using AspectJ, the implementation of some patterns completely disappears, because AspectJ language constructs implement them directly. This applies to [Decorator]. [4] In gewisser Weise kann man in AspectJ alles dekorieren Seite 20

21 Beispiel Decorator Seite 21

22 Beispiel Decorator Seite 22

23 Decorator Verständnis: AOP vermittelt das Gefühl das nichts besonderes passiert OO Variante braucht mehrere Klassen, AOP nur einen Aspekt Wiederverwendbarkeit: Decorator ist in AspectJ eingebaut, d.h. fast alle Aspekte verwenden dieses Pattern Neue Decorator können zu den Objekten hinzugefügt werden Falls sich Methoden ändern muss man nur den pointcut anpassen anstatt alle Decorator anzupassen Seite 23

24 Observer in der OOP Subject speichert die Observers in einer Liste Falls sich der Status ändert ruft Subject notify() auf, die wiederum update() in den Observers aufruft Code wird auf die Klassen verteilt Dadurch: Wiederverwendbarkeit gering Entscheidung zwischen pull und push Seite 24

25 Beispiel Observer Seite 25

26 Observer Wiederverwendbarkeit möglich durch Erweiterung von ObserverProtocol ObserverProtocol generalisiert das Observer Pattern Innere Interfaces werden von Subaspekten genutzt, um festzulegen, welche Typen die Observers/Subjects haben Im Subaspekt: durch declare parents wird festgelegt wer Observer/Subject ist Code locality: Pattern ist nur im abstract aspect und in subaspects In den Klassen ist nichts von dem Pattern zu sehen Folge: keine Kopplung zwischen Aspekten und Klassen Update logic: updateobserver() : Entscheidung zwischen pull und push entfällt subjectchange() : conceptual operation wird hier konkretisiert Seite 26

27 Zusammenfassung Wiederverwendbarkeit Generalisierung durch Abstrakte Aspekte Aspekte ersetzen Pattern Handhabung von crosscutting concerns vereinfacht sich Verständnis: Design Patterns können meistens in einem Aspekt realisiert werden Code locality: Pattern wird vom eigentlichen Code entkoppelt Auswirkung von AOP auf Design Patterns sind sehr unterschiedlich: Patterns können verschwinden Kein Unterschied zu OOP Meistens Verbesserung Seite 27

28 Quellen [1] Freeman, Eric; Freeman, Elisabeth; Bates, Bert; Sierra, Kathy: Head First Design Patterns [2] [3] [4]Jan Hannemann and Gregor Kiczales's "Design Pattern Implementation in Java AspectJ Seite 28