Komponentenbasierte Softwareentwicklung mit PHP. Oliver Schlicht - bitexpert

Transkript

1 Komponentenbasierte Softwareentwicklung mit PHP Oliver Schlicht - bitexpert

2 Überblick 1. Was ist eine Komponente? 2. Entwicklung eines Beispieldesigns 3. Dependency Injection 4. DI Container Garden 5. Demo 6. FAQ 7. Zusammenfassung ng 8. Ausblick Oliver Schlicht - bitexpert 2

3 1. Was ist eine Komponente Beispiel: Wohnraumkomponente ;) Oliver Schlicht - bitexpert 3

4 1. Was ist eine Komponente? Angebote Funktionalität von Fernseher ein- und ausschalten Sender wählen Funktionalitätsumfang basiert auf dem Interface Fernseher nicht auf dem eigentlichen Gerät Fernseher, nicht auf dem eigentlichen Gerät Oliver Schlicht - bitexpert 4

5 1. Was ist eine Komponente? Benötigte Funktionalität: Strom Fernsehanschluss es wird nur spezifiziert WAS benötigt wird, nicht WIE das Benötigte arbeitet es können verschiedene Geräte an den Fernsehanschluss angeschlossen werden, solang sie die benötigte Spezifikation erfüllen Oliver Schlicht - bitexpert 5

6 1. Was ist eine Komponente? Zusammenfassung: Angebotene Funktionalität (Provided Interface, PI) Benötigte Funktionalität (Required Interface, RI) Black Box austauschbar Übertragung in (PHP)OO-Welt Komponente == Klasse? Angebotene Funktionalität -> Klassenschnittstelle Benötigte Funktionalität ->? Oliver Schlicht - bitexpert 6

7 2. Entwicklung eines Beispieldesigns Ratingsystem - Anforderungen Ausgangspunkt: Ebay ohne Bewertungssystem Kunden sollen Anbieter nach erfolgter Geschäftsabwicklung bewerten können Anbieter tragen ein Rating mit sich, welches durch abgegebene g Reviews beeinflusst und verändert wird Komponente RatingManager Datentypen: BOCustomer, BOReview DAO: DAOCustomer, DAOReview Oliver Schlicht - bitexpert 7

8 2. Entwicklung eines Beispieldesigns Erster Entwurf Service Layer Komponente service::ratingmanager Business Objects (Datentypen) «interface» bo::ibo +bookreview(ein ireviewid : int) DAO Layer dao::dao +readbyprimarykey(ein iprimarykey : int) +save(ein pobo : IBO) dao::daocustomer dao::daoreview bo::bocustomer -icustomerid : int -sname : string -icustomernumber : int bo::boreview -ireviewid : int -icustomerid : int -iproviderid : int Abhängigkeiten Oliver Schlicht - bitexpert 8

9 2. Entwicklung eines Beispieldesigns Analyse Probleme Schritt 1 Kein PI Nutzende Komponenten binden sich direkt an die Implementierung Kein RI Benutzer der Komponente weiß nichts über versteckte Abhängigkeit direkte Kopplung an Implementierung von benötigten Komponenten Feste Bindung sorgt für schlechte Austauschbarkeit und Untestbarkeit Programmieren gegen Interfaces Oliver Schlicht - bitexpert 9

10 2. Entwicklung eines Beispieldesigns Interfaces für Komponenten einführen Service Layer «interface» service::iratingmanager +bookreview(ein ireviewid : int) impl::ratingmanager Business Objects (Datentypen) «interface» bo::ibo «interface» dao::idaocustomer DAO Layer impl::dao +readbyprimarykey(ein iprimarykey : int) +save(ein pobo : IBO) «interface» dao::idaoreview bo::bocustomer -icustomerid : int -sname : string -icustomernumber : int bo::boreview -ireviewid : int -icustomerid : int -iproviderid : int impl::daocustomer impl::daoreview Oliver Schlicht - bitexpert 10

11 2. Entwicklung eines Beispieldesigns Analyse Probleme Keine PI Nutzende Komponenten binden sich direkt an die Implementierung Kein RI Benutzer der Komponente weiß nichts über versteckte Abhängigkeit direkte Kopplung an Implementierung Feste Bindung sorgt für schlechte Austauschbarkeit und Untestbarkeit WiekommtdieKomponenteanInstanzenbenötigter Klassen? Oliver Schlicht - bitexpert 11

12 2. Entwicklung eines Beispieldesigns Analyse Probleme Kein RI Schritt 2 Benutzer der Komponente weiß nichts über versteckte Abhängigkeit Wie kommt die Komponente an Instanzen benötigter Klassen? Dependency Injection Oliver Schlicht - bitexpert 12

13 3. Dependency Injection Objekt erzeugt Referenzen nicht selbst sondern bekommt sie zugewiesen ( Inversion of Control ) Folge: Abhängigkeiten sind an der Schnittstelle erkennbar (RI) Objekt bleibt passiv Referenzen können ausgetauscht werden (bessere Testbarkeit Oliver Schlicht - bitexpert 13

14 3. Dependency Injection Constructor Injection Vorteil Nach dem Instanziieren der Komponente weiß ich, dass ich ein fertig konfiguriertes Objekt habe Nachteil Im Nachhinein ist keine Umkonfiguration mehr möglich Setter Injection Vorteil Komponente wird zur Laufzeit umkonfigurierbar Nachteil evtl. Nullpointer durch nicht initialisierte Referenzen Oliver Schlicht - bitexpert 14

15 4. DI Container - Garden Problem Wer instanziiert die Komponente bzw. steuert den Lebenszyklus? Woher weiß derjenige, welche Instanz er einsetzen soll? Lösung: Container Stück Software, dass Komponenteninstanzen erzeugt, zerstört und Funktionalität für K. anbietet ermöglicht das Eingreifen in den Zyklus über Callbackinterfaces Oliver Schlicht - bitexpert 15

16 4. DI Container - Garden Garden ( angelehnt an Spring ( Zugriff auf Komponenten über ApplicationContext im Prinzip eine Factory Beschreibung der Komponenten per XML Oliver Schlicht - bitexpert 16

17 4. DI Container - Garden Komponentenkonfiguration <beans> <! - Services --> <bean id= RatingManager class= service.ratingmanager > <constructor-arg ref= DAOCustomer /> <constructor-arg ref= DAOReview DAOReview /> </bean> <! DAOs --> <bean id= DAOCustomer class= dao dao.daocustomer DAOCustomer >.. </bean> <bean id= DAOReview class= dao.daoreview >.. </bean> </beans> Oliver Schlicht - bitexpert 17

18 4. DI Container - Garden Zugriff auf die Komponente <?php?> // Initialisieren des AC // XML File wird geparst $octx = ApplicationContext::getInstance(); // Komponente holen // (wird instanziiert oder aus dem Cache geladen) $oratingmanager = $octx->getbean( RatingManager ); $oratingmanager->bookreview(1); -> 5. Demo Oliver Schlicht - bitexpert 18

19 6. FAQ Welche Klassen werden Komponenten? Im allgemeinen Klassen die Dienste erbringen Keine Klassen die Datenstrukturen beschreiben Entwicklungsaufwand Overhead an XML Beschreibungsdaten Vorteile Klare Trennung von Komponentenschnittstelle, - implementierung und konfiguration (SOC) Komponente lässt sich durch einfaches Umkonfigurieren mehrfach nutzen Oliver Schlicht - bitexpert 19

20 6. FAQ Wie groß ist der Parsingaufwand? XML sollte nicht jedes Mal neu geparst werden -> Serialisieren i und din Datei ilegen Aktuelles Projekt (20000 Zeilen Code) -> ms Globale Abhängigkeit vom ApplicationContext ACs sollten möglichst selten instanziiert werden Konfigurationsdaten über configvalue setzen Zugriff auf den AC über IApplicationContextAware Oliver Schlicht - bitexpert 20

21 7. Zusammenfassung Methodische Aspekte Trennung von Interface und Implementierung Deklarierung von PI und RI (zumindest durch Doku) Mit DI / Garden möglich Offenlegung des RI an der Schnittstelle der Klasse Trennung von Implementierung und Konfiguration Bessere (Unit) Testbarkeit der Komponenten Bessere Wartbarkeit / Wiederverwendung Oliver Schlicht - bitexpert 21

22 8. Ausblick Erweiterte Features des bitframework DI gesteuertes MVC Framework (ähnlich Spring MVC) ActionResolver, ViewResolver, Validatoren FormActions Vorgefertigte Komponenten / Basisklassen Authentifiziertung, Authorisierung, Transaktionshandling Geschäftsobjekte (BO), DataAccessObjects (DAO) Integration für PHPUnit Unittest, Integrationstest, transaktionale Integrationstests Utilities Mail, Datumsklassen, Logging usw. Oliver Schlicht - bitexpert 22

23 8. Fragen? Oliver Schlicht - bitexpert 23

24 Quellen Martin Fowler Dependency Injection Steve MC McConnell Code Complete Second/dp/ X/sr=8-2/qid= /ref=pd 8 pd_ka_2/302 2/ ?ie=UTF8&s=books Kontakt: o.schlicht@bitexpert.de ht@bite t Oliver Schlicht - bitexpert 24