Java Design Principles
See additionally: Java Design Patterns
SOLID Principles
Principle | Meaning |
---|---|
Single Responsablility | Class shall do only one thing, have only one reason to change. |
Open – Close | Classes/Objects shall be: Open for extension (sub classing). Closed for modification. |
Liskov Substitution | A subclass must be applicable without problems in any place where its super class or interface is applicable. |
Interface Segregation | Better several small interfaces with dedicated functions than fewer interfaces with a mix of functions. |
Dependency Injection | High level modules shall not depend on low level module. Better both modules depend on an interface. |
Other Principles
Principle | Meaning |
---|---|
Don’t repeat yourself | dito |
Encapsulate what changes | dito |
Favor composition over inheritance | If classes in the real world has different natures then don’t solve this by putting that natures into the same class. Rather create separate classes to implement those natures. |
Program against interfaces on implementations | dito |
Java Design Patterns
Siehe auch: Java Design Principles
Ein wunderbarer Kurs: Design Patterns in Java: The Big Picture by Esteban Herrera
Design Pattern Types
Unterscheidung 1: Structural | Behavioral | Creational
Unterscheidung 2: Class | Object centric
Wichtigste Design Patterns
Creational
Abstract Factory
Factory Method
Gemäss Herrera: Gleich wie ‚Abstract Factory‘ aber links und Creator und Produkt haben nur eine Hierarchie.
Gemäss Steinhauser: Eine getFactory() Methode erzeugt die Factory anhand eines Discriminators.
Builder
Singleton Pattern
Sinn: Es soll in der Laufzeitumgebung nur genau ein Objekt einer bestimmten Klasse geben.
Vorgehen: Einzigen parameterlosen Konstruktor der Klasse auf private setzen. Statisches Feld ‚instance‘, das die eine Instanz aufnimmt. Eine statische getInstance Methode wird benutzt um 1., falls ‚instance‘ noch NULL ist die Klasse zu instqanzieren und ‚instance‘ zu setzen und 2. die Instanz zu retournieren.
Behavioural
Strategy
State
Command
Observer Pattern
Template Method Pattern
Eine Basisklasse enthälte eine Methode (Bsp. processDocument()), die sowohl Verarbeitungsschritte enthält, die für alle Spezialfälle gleich sind (Bsp. backup(), validate()), aber auch solche, die je nach Fall differenziert werden sollen (Bsp. process()). Die zu differenzierenden Schritte werden in der Basisklasse als abstrakte Methoden ausgelagert und in spezifischen Subklassen konkretisiert.
Spezialfall:
Hooks: Wie Template Pattern, aber methoden sind nicht abstrakt und müssen deshalb nicht überschriben werden (default).
Visitor
Beschreibung fehlt noch!
Iterator
Beschreibung fehlt noch!
Structural
Facade Pattern
Zweck: Einen Orchestrator haben, der weiss wo was zu holen und wie zu verarbeiten ist. ==> Wie eine Main Methode.
Decorator Pattern
Um eine Pizza mit verschiedenen Zutaten zu dekorieren:
Das bedingt, dass die Decorators eine Instanz des Decoree halten und eine gemeinsame Methode (=>Interface) implementieren:
Proxy Pattern
(Object) Adapter Pattern
Zweck: Koppelung von Services ohne direkt von ihren Interfaces abhängig zu sein.