Design patterns joost.vennekens@mechelen.lessius.eu
Wat zijn dat? Programma zit niet goed in elkaar Zondigt tegen ontwerpprincipes En dat zorgt voor probleem Ontwerppatroon: standaard oplossing voor een bepaald soort van dergelijke problemen
Voorbeeld Dit is een ingewikkelde methode, die afhangt van Motor Wijziging aan Motor -> Sensor aanpassen Sensor kan niet herbruikt worden voor andere apparatuur Geen hergebruik als Motor wordt aangedreven door iets anders dan Sensor
Command patroon Motor en Sensor zijn losgekoppeld Complexiteit verschuift naar initializatie
Voorbeeld van init class Controller { public void init() { Motor m = new Motor(); Command ju = new VersnelCommando(m); Command how = new VertraagCommando(m); Sensor s = new Sensor(); s.setvertraagcommand(how); s.setversnelcommand(ju);
Andere voordelen In wachtrij steken Ongedaan maken Valideren validate()
Active Object Voorbeeld
import java.util.*; public class PersoneelSorteerder { public List<Werknemer> lijst; public PersoneelSorteerder(List<Werknemer> l) { lijst = l; public void sorteer() { boolean gesorteerd = false; while (!gesorteerd) { gesorteerd = true; for (int i = 0; i < lijst.size() - 1; i ++) { if (lijst.get(i).getleeftijd() > lijst.get(i+1).getleeftijd()) { verwissel(i,i+1); gesorteerd = false; private void verwissel(int i, int j) { Werknemer tmp = lijst.get(i); lijst.set(i, lijst.get(j)); lijst.set(j, tmp);
Template patroon Nadeel: overerving is sterke relatie Vergelijkingsfunctie kan niet herbruikt worden in andere sorteeralgoritmes
Strategy
Facade
Mediator Facade: zichtbare implementatie van beleid over gebruik van klassen Mediator: invloed achter de schermen Vb: QuickEntryMediator
Singleton Kan een applicatie meerdere ProduktDatabank objecten maken? Kan een applicatie meerdere Controller objecten maken?
Singleton public class Singleton { private Singleton() { private static Singleton instance; public static Singleton getinstance() { if (instance == null) instance = new Singleton(); return instance;
Voordelen Kan voor elke klasse Kan door overerving: class BlaSingleton extends Bla Lazy evaluation: pas aangemaakt als nodig
Nadelen Niet transparent: gebruikers moeten weten dat het Singleton is Kan niet worden overgeerfd class Bla extends Singleton Efficientie: elke getinstance() heeft if
Monostate Alle variabelen statisch Geen methoden statisch Effect: alle instances zijn hetzelfde
Voordelen Transparant Kan worden overgeerfd: subklasses hebben dezelfde statische variabelen
Nadelen Niet door overeving: class Monostate extends Bla Efficientie: elk Monostate object moet worden aangemaakt, en statische variabelen zijn er altijd
Null object Werknemer w = getwerknemer(naam); if (w!= null && w.isbetaaldag(vandaag)) w.betaal(); Werknemer w = getwerknemer(naam); try { if (w.isbetaaldag(vandaag)) w.betaal(); catch (NullPointerException n) { //...
Null object class NullWerknemer extends Werknemer { public boolean isbetaaldag() { return false; public void betaal() { Werknemer w = getwerknemer(naam); if (w.isbetaaldag(vandaag)) w.betaal();
Uniek null object class NullWerknemer extends Werknemer { private NullWerknemer() { private static NullWerknemer instance; public static NullWerknemer getinstance() { if (instance == nul) instance = new Singleton(); return instance; public boolean isbetaaldag() { return false; public void betaal() { if (getwerknemer(naam) == NullWerknemer.getInstance()) //...
Of nog beter public abstract class Werknemer { public static final Werknemer NULL = new Werknemer() { public boolean isbetaaldag() { return false; public void betaal() { ; if (getwerknemer(naam) == Werknemer.NULL) //...
Factory of toch niet? Vorm v = new Cirkel(5);
Factory Wordt ergens in de initializatie aangemaakt Bij toevoegen van nieuwe vorm, moet interface veranderen Wijzigingen hebben geen effect meer
Alternatief Nadeel: typfouten in naam van vorm, leiden nu tot runtime ipv. compile time errors
Meer flexibiliteit SAXParser parser = SAXParserFactory.newInstance().newSAXParser();
Composite Alle elementen van samengesteld object moeten identiek behandeld worden Voordeel: clienten hoeven niet te sukkelen met lijsten, enkel het samengesteld object doet dat
Observer
Observer Pull model: Er is iets veranderd, kijk zelf maar Standaard klassen Uitvissen wat veranderd is kan veel werk zijn Push model: Dit is veranderd
Proxy + SQL
Proxy
Proxy return new DBProdukt(new ProduktImpl());
Proxy
Visitor Je moet een nieuwe methode toevoegen aan een klassehierarchie, maar dit is pijnlijk of schadelijk voor het ontwerp + configureforunix()
Visitor public void ontvang(modembezoeker bezoeker) { bezoeker.bezoek(this);
Matrix: [Modem,OS] Visitor
Visitor Toepassing: rapportering lokaaloverzicht docentenoverzicht studiegroepoverzicht
Visitor
Decorator
Decorator
Decorator public class Decorator { public Decorator(Venster a) { achterliggend = a; private Venster achterliggend; public void paintcomponent(graphics g) { achterliggend.paintcomponent(g); //... Venster v = new HorizontalScrollbarDecorator( new VerticalScrollbarDecorator( new BorderDecorator(new VensterImpl())));