Factory Method Design Pattern
- 3. „Definiere eine Klassenschnittstelle zum Erzeugen eines Objekts, aber lasse Unterklassen entscheiden, welche Klasse instanziiert werden soll. Factory-Methods ermöglichen es einer Klasse, die Erzeugung von Objekten an Unterklassen zu delegieren.“
- 4. • Entkopplung des Clients von der konkreten Instanziierung einer Klasse • Trennung von Objektverwaltung und Objektherstellung • Factory-Methoden erübrigen die Notwendigkeit, anwendungsspezifische Klassen in den Code einzubinden. Der Code behandelt nur die Schnittstelle.
- 6. • Eine Klasse kann die Klasse der Objekte, die sie erstellen muss, nicht vorhersehen. • Eine Klasse möchte, dass ihre Unterklassen die zu erstellenden Objekte definieren. • Klassen delegieren die Verantwortung an eine von mehreren Helfer-Unterklassen, und man möchte wissen, welche Helfer- Unterklasse der Delegierte ist.
- 7. Idee und Fotos: https://www.philipphauer.de/study/se/design-pattern/factory-method.php
- 10. • Geringe Kohäsion • Geringe Wiederverwendbarkeit • Für Erweiterungen am Programmportfolio muss der bestehende Code geändert werden. Entwürfe sollten für Erweiterungen offen, aber für Veränderungen geschlossen sein.
- 11. Die Logik zur Programmerstellung in einer Klasse kapseln (Factory)
- 16. •Kohäsionsgewinn durch Trennung der Objekterstellung von der Objektverarbeitung •Wiederverwendbarkeit der Factory •Zentrale Stelle für Wartung und Erweiterung
- 19. Die Objekterstellung (createOfficeProgramm) kann direkt aufgerufen werden, und die notwendigen Verarbeitungsschritte der holeApp()-Methode umgangen werden.
- 22. • Die Subklasse entscheidet welches Objekt erstellt wird. • Softwareshop delegiert die Objektinstanziierung an seine Subklasse. Von außen ist die Methode unsichtbar (protected). Somit ist gewährleistet, dass der Verarbeitungsprozess immer durchgeführt wird.
- 36. Creator – abstrakter SoftwareShop ConcreteCreator – konkrete OfficeSuiteFactories Product – abstrakte OfficeProgramm-Schnittstelle ConcreteProduct – konkrete Programme Quelle: https://bit.ly/2LJEUCl
- 37. • Herstellungsprozess ist von konkreter Implementierung getrennt • Wiederverwendbarkeit und Konsistenz durch: • Kapselung des Objekterstellungscodes (zentrale Schnittstelle für Client) • Kapselung des allgemeinen Herstellungscodes in der Creator Klasse • Erweiterbarkeit, Austauschbarkeit, Flexibilität durch: • Problemlosen Einführen neuer Produkte und Ersteller
- 38. • Enge Kopplung eines konkreten Creators und konkreten Products • Für jedes neue Produkt muss ein neuer Creator geschrieben werden
- 39. • Authentifizierungssysteme: • Für jeden User wird nach dem Login ein Ticket erstellt, das seine Rechte im System repräsentiert. • TicketFactory -> createTicket()-Methode
- 40. • Pizzeria: • Pizzeria erstellt je nach Parameter verschiedene Pizzen. • Regionale Wünsche -> spezielle Pizzen • Neue Pizzasorten und Pizzerias können ins System integriert werden
- 42. • Backend: Java JAX-RS REST-Schnittstelle zum Speichern der Eigenschaften von Immobilien • Admin-Anwendung: C# WPF Anwendung zum Hinzufügen, Ändern, Löschen von Immobilien • Client-Anwendung: Typescript Angular Anwendung zum Anzeigen der Immobilien Code: https://github.com/mhinterdorfer/FactoryMethod
- 43. • Es gibt drei Arten von Immobilien: Apartment, House und Villa • Jeder Ort (Factory) erstellt die Immobilien nach den aktuellen Preisen. • Neue Orte können einfach hinzugefügt werden, in dem die Factory Klasse abgeleitet wird. Code: https://github.com/mhinterdorfer/FactoryMethod