1 Ontwerppatronen. 1.1 Het Command patroon

Transcriptie

1 1 Ontwerppatronen Software-ontwikkelaars worden geconfronteerd met ontwerpproblemen: de manier waarop ze hun programma gestructureerd hebben geeft aanleiding tot slechte eigenschappen zoals rigiteit, fragiliteit,.... Om dit op te lossen, gaan de ontwikkelaar zijn ontwerp aanpassen eventueel volgens de richtlijnen gegeven door de ontwerpprincipes in het vorige hoofdstuk zodat het probleem verdwijnt. Dit is natuurlijk geen bandwerk, maar vereist creativiteit en inspiratie van de ontwerper. Ervaren software ingenieurs zullen echter merken dat bepaalde soorten van ontwerpproblemen steeds terugkomen. Eénmaal als je een probleem kan herkennen als een variant van een probleem dat je vroeger al een hebt opgelost, kan je natuurlijk nuttig gebruik maken van de inzichten die je toen verworven hebt. Een stap verder is nog dat je ook kan gaan overleggen met collega s en informeren of zij hetzelfde vaak terugkerende probleem ook al ervaren hebben. Indien ja, kan ook hun oplossing natuurlijk nuttige inspiratie bieden. Als je maar met genoeg collega s overlegt, zal er uiteindelijk wel een soort van standaardoplossing (of eventueel meerdere standaardoplossingen) voor dit probleem uit de bus komen. Dit is nu precies wat een ontwerppatroon is: een standaardoplossing voor een vaak voorkomend ontwerpprobleem. Deze patronen zijn belangrijk omdat ze je de moeite kunnen besparen om telkens opnieuw het warm water weer uit te vinden. Bovendien heeft elk patroon ook een eigen naam, wat ervoor zorgt dat het heel eenvoudige wordt om bepaalde complexe ideeën in een oogwenk te communiceren aan een andere programmeur. Bijvoorbeeld de volgende lijn Java code: SAXParserFactory. newinstance ( ). newsaxparser ( ) ; lijkt misschien ingewikkeld, maar elke ervaren software ingenieur zal onmiddellijk zien dat er hier twee design patronen gebruikt worden en daardoor ook meteen begrijpen hoe het achterliggende ontwerp in elkaar zit. Dit hoofdstuk zal een aantal van de belangrijkste ontwerppatronen op een rijtje proberen te zetten. 1.1 Het Command patroon In het ontwerp in Figuur 1 zie je motor die bestuurd wordt op basis van een sensor. Als de sensor bijvoorbeeld merkt dat de motor te snel aan het draaien is, kan hij hem het commando geven om te vetragen. De klasse Sensor zal in een oneindige lus zijn methode houinhetoog uitvoert, en telkens als deze methode een interessante gebeurtenis detecteert, zal ze handelgebeurtenisaf oproepen, die gaat beslissen of er iets aan de toestand van de motor moet veranderen en zo nodig de juiste methode zal oproepen. De klasse Sensor hangt in dit ontwerp dus af van Motor. Het principe van omgekeerde afhankelijkhei suggereert dat dit mogelijk problematisch zou kunnen zijn. Bovendien kunnen we onze sensor enkel maar gebruiken om motoren aan 1

2 Figuur 1: Een sensor die een motor aandrijft. Figuur 2: Het commando patroon. te drijven. Als dit door de ontwerpen ervaren wordt als een probleem, kan het Command patroon een oplossing bieden. Dit suggereert om de commando s die de sensor moet uitvoeren niet te implementeren als methodes in de klasse Motor, maar om een aparte klasse te voorzien die deze commando s voorstelt. Het resultaat wordt getoond in Figuur 2. We zien hier nu dat de tussenliggende interface Commando de afhankelijkheid van Sensor op Motor laat verdwijnen. Als gevolg hiervan kan de Sensor nu ook probleemloos andere zaken dan Motoren aandrijven. Een tweede voordeel is dat als de methode handelgebeurtenisaf complexe combinaties van operaties bevat (bv. om een motor op volle snelheid te laten stoppen, moet eerst met tussenpozen van 2 seconden vier keer de methode vertraag worden opgeroepen en dan de methode zetuit), dan kunnen deze combinaties óók commando s worden (bv. StopMotorOpSnelheid). Op deze manier kunnen andere apparaten die motoren willen aandrijven dan gebruik maken van dezelfde commando s zodat de herbruikbaarheid van de code erop vooruit gaat. Merk op dat de initializatie van ons programma nu wel wat ingewikkelder is geworden, aangezien we nu objecten moeten aanmaken van de verschillende subklassen van Commando, en ervoor zorgen dat de klasse Sensor een referentie 2

3 naar deze objecten te pakken krijgt. Dergelijke code kan er bijvoorbeeld als volgt uitzien: class C o n t r o l l e r { public void i n i t ( ) { Motor m = new Motor ( ) ; Command j u = new VersnelCommando (m) ; Command how = new VertraagCommando (m) ; Sensor s = new Sensor ( ) ; s. setvertraagcommando (how ) ; s. setversnelcommando ( ju ) ; Het is natuurlijk ook mogelijk om een klasse Gebeurtenis te voorzien en een Sensor dan Gebeurtenissen te laten koppelen aan Commando s, zodat de laatste twee regels vervangen kunnen worden door iets als: s. l i n k (new TeTraagEvent ( ), ju ) ; s. l i n k (new TeSnelEvent ( ), how ) ; Als we eenmaal onze commando s in objecten gegoten hebben, kunnen we nog meer interessante dingen doen. Zo wordt het bijvoorbeeld mogelijk om commando s bij te houden in een lijst. Dit kan van pas komen als we bijvoorbeeld een undo-mechanisme willen implementeren. We geven ieder commando s dan naast een do methode ook een undo methode, en houden een stack bij van de commando s die al zijn uitgevoerd. Als de gebruiker een commando wilt ongedaan maken, halen we het bovenste element van de stack en undoen dit. Een andere mogelijkheid is het toevoegen van een validate methode aan commando s, waarmee zo n commando kan nagaan of het wel mag worden uitgevoerd. Het leuke van een dergelijk ontwerp is dat alle informatie over een bepaald commando dwz. wanneer mag het worden uitgevoerd, hoe moet het worden uitgevoerd, en hoe kunnen we het weer ongedaan maken samen in één object verpakt wordt. Dit betekent dat het mogelijk wordt om eenvoudig nieuwe commando s toe te voegen, zonder aan bestaande code te morrelen, zoals het open-gesloten principe vereist. Figuur 3 toont een laatste voorbeeld. Hier hebben we commando s die kunnen worden uitgevoerd door een grafische user interface. Daarnaast is er echter ook een batch mode voorzien, zodat gebruikers in een tekstbestand een aantal commando s kunnen opsommen, die dan allemaal na elkaar door het systeem zullen worden uitgevoerd. 1.2 Het ActiveObject patroon Dit patroon bouwt voort op het Commando patroon om een soort van goedkoop parallellisme te simuleren. Een ActiveObjectEngine houdt een lijst met commando s bij. Op basis van één of andere scheduling algoritme kiest het één van de commando s uit deze wachtrij en voert dit uit. Als resultaat hiervan kunnen 3

4 Figuur 3: Batchverwerking met het commando patroon. mogelijk weer nieuwe commando s in de wachtrij komen. De engine herhaalt dit dan zolang er nog commando s zijn. Een zeer eenvoudige implementatie van een ActiveObjectEngine klasse kan er bijvoorbeeld zo uitzien: import java. u t i l. LinkedList ; import java. u t i l. I t e r a t o r ; public class ActiveObjectEngine { LinkedList commands = new LinkedList ( ) ; public void addcommand(command c ) { commands. add ( c ) ; public void run ( ) throws Exception { while (! commands. isempty ( ) ) { Command c = (Command) commands. g e t F i r s t ( ) ; commands. removefirst ( ) ; c. execute ( ) ; 4

5 Figuur 4: Een actief object. De volgende klasse SleepCommand bootst de functionaliteit van de Thread.sleep(int millis) methode na: telkens als de engine een SleepCommand uitvoert, controleert dit of het al lang genoeg in de wachtrij van de engine gezeten heeft, en zoniet gaat het weer achteraan aanschuiven. public c l a s s SleepCommand implements Command { private Command wakeupcommand = null ; private ActiveObjectEngine engine = null ; private long sleeptime = 0 ; private long starttime = 0 ; private boolean s t a r t e d = f a l s e ; public SleepCommand ( long m i l l i s e c o n d s, ActiveObjectEngine e, Command wakeupcommand) { sleeptime = m i l l i s e c o n d s ; engine = e ; t h i s. wakeupcommand = wakeupcommand ; public void execute ( ) throws Exception { long currenttime = System. c u r r e n t T i m e M i l l i s ( ) ; i f (! s t a r t e d ) { s t a r t e d = true ; starttime = currenttime ; 5

6 engine. addcommand( this ) ; else i f ( ( currenttime starttime ) < sleeptime ) { engine. addcommand( this ) ; else { engine. addcommand(wakeupcommand ) ; Deze klasse kunnen we nu bijvoorbeeld gebruiken om twee Strings in pseudoparallel te laten afprinten: public c l a s s DelayedTyper implements Command { private long delay ; private char char ; private static ActiveObjectEngine engine = new ActiveObjectEngine ( ) ; private static boolean stop = f a l s e ; public static void main ( S t r i n g args [ ] ) throws Exception { engine. addcommand(new DelayedTyper (100, 1 ) ) ; engine. addcommand(new DelayedTyper (300, 3 ) ) ; engine. addcommand(new DelayedTyper (500, 5 ) ) ; engine. addcommand(new DelayedTyper (700, 7 ) ) ; Command stopcommand = new Command( ) { public void execute ( ) { stop=true ; ; engine. addcommand(new SleepCommand (20000, engine, stopcommand ) ) ; engine. run ( ) ; public DelayedTyper ( long delay, char c ) { delay = delay ; char = c ; public void execute ( ) throws Exception { System. out. p r i n t ( char ) ; i f (! stop ) delayandrepeat ( ) ; private void delayandrepeat ( ) throws CloneNotSupportedException { engine. addcommand(new SleepCommand ( delay, engine, this ) ) ; 6

7 1.3 De Template en Strategy patronen Zoals reeds in het hoofdstuk over ontwerpprincipes besproken, is het geen goed idee om een algoritme dat personeelsleden sorteert volgens leeftijd op onderstaande manier te implementeren. import java. u t i l. ; public class P e r s o n e e l S o r t e e r d e r { public List <Werknemer> l i j s t ; public P e r s o n e e l S o r t e e r d e r ( List <Werknemer> l ) { l i j s t = l ; public void s o r t e e r ( ) { boolean g e s o r t e e r d = f a l s e ; while (! g e s o r t e e r d ) { g e s o r t e e r d = true ; for ( int i = 0 ; i < l i j s t. s i z e ( ) 1 ; i ++) { i f ( l i j s t. get ( i ). g e t L e e f t i j d ( ) > l i j s t. get ( i +1). g e t L e e f t i j d ( ) ) { v e r w i s s e l ( i, i +1); g e s o r t e e r d = f a l s e ; private void v e r w i s s e l ( int i, int j ) { Werknemer tmp = l i j s t. get ( i ) ; l i j s t. s e t ( i, l i j s t. get ( j ) ) ; l i j s t. s e t ( j, tmp ) ; Er is hier immers een te grote afhankelijkheid van het sorteeralgoritme op de specifieke details van wat er gesorteerd moet worden. Het Template patroon stelt voor om dit op te lossen door middel van een abstracte klasse en overerving, zoals getoond in Figuur 5, waarbij de methode vergelijk abstract is. Deze oplossing heeft natuurlijk als nadeel dat elke klasse ten hoogste één superklasse kan hebben, zodat bijvoorbeeld de methode die gebruikt wordt om personeelsleden te vergelijken niet herbruikt kan worden door andere sorteeralgoritmes. 7

8 Figuur 5: Het Template patroon. Figuur 6: Het Strategy patroon. Een andere oplossing voor hetzelfde probleem wordt geboden door het Strategy patroon, dat voorstelt om een interface te gebruiken ipv. een abstracte klasse. Dit leidt tot het ontwerp in Figuur 6. Een mogelijk nadeel hiervan ten opzichte van de Template oplossing is dat nu de klasse Werknemer moet weten dat zijn objecten gesorteerd gaan worden, aangezien ze de interface Sorteerbaar moet implementeren. In de Template oplossing zou de klasse WerknemerSorteerder een link naar de klasse Werknemer bevatten, zodat deze laatste niets hoeft te weten van het bestaan van sorteeralgoritmes. Als we hetzelfde effect willen bekomen met een interface, kunnen we kiezen voor het ontwerp dat getoond wordt in Figuure 7. Hier doen we met andere woorden iets als dit volgende: private void sorteerwerknemers ( Werknemer [ ] w l i j s t ) { S o r t e e r b a a r [ ] s l i j s t = new S o r t e e r b a a r [ w l i j s t. length ] ; for ( int i = 0 ; i < w l i j s t. length ; i ++) s l i j s t [ i ] = maaksorteerbaar ( w l i j s t [ i ] ) ; (new S o r t e e r d e r ( s l i j s t ) ). s o r t e e r ( ) ; private S o r t e e r b a a r maaksorteerbaar ( f i n a l Werknemer werk ) { return new S o r t e e r b a a r ( ) { public boolean v e r g e l i j k ( Object o ) { Werknemer w = ( Werknemer ) o ; 8

9 Figuur 7: Een complexere variant van het Strategy patroon. Figuur 8: Het Facade patroon. ; return (w. g e t L e e f t i j d ( ) < werk. g e t L e e f t i j d ( ) ) ; 1.4 Het Facade patroon Veronderstel dat je een programma schrijft dat gebruik maar van één of andere bibliotheek, bijvoorbeeld om de toegang tot een databank te verzorgen. Des te meer klassen van je eigen programma deze bibliotheek rechtstreeks aanspreken, des te moeilijker wordt het om deze later te vervangen door een andere. Dit patroon stelt daarom voor om alle toegang tot zo n externe bibliotheek te laten verlopen via één enkele klasse (de facade ). Figuur 8 toont hoe een dergelijk ontwerp. Indien de externe bibliotheek nu ooit moet worden ingeruild voor een andere, dient enkele de facade klasse herschreven te worden. 1.5 Mediator In het algemeen verzorgt een Facade de communicatie van een component van een systeem met een een andere. De Facade doet dit op een erg zichtbare manier: 9

10 telkens als de eerste component met de tweede wil spreken, roept hij niet die tweede component rechtstreeks op, maar wel de Facade. Het is dus belangrijk dat elke programmeur van elke klasse op de hoogte is van het bestaan van de Facade. Een Mediator zal ook zorgen voor communicatie tussen twee componenten, maar doet dit achter de schermen. Met andere woorden, niemand hoeft eigenlijk op de hoogte te zijn van het bestaan va de Mediator: noch de componenten tussen wie gecommuniceerd wordt, noch andere klassen die deze componenten gebruiken. We kunnen dit patroon het best illustreren met een voorbeeld. De onderstaande Mediator zorgt achter de schermen! voor communicatie tussen een tekstveldje en een mogelijke lijst van waarden die in dit tekstveldje getypt zouden kunnen worden. De Mediator zal ervoor zorgen dat in de geselecteerde waarde altijd overeenkomt met de hetgeen dat de gebruiker reeds heeft getypt in het tekstveldje. package u t i l i t y ; import javax. swing. ; import javax. swing. event. ; / QuickEntryMediator. This c l a s s t a k e s a JTextField and a J L i s t. I t assumes t h a t the user w i l l type c h a r a c t e r s i n t o the JTextField t h a t are p r e f i x e s o f e n t r i e s in the J L i s t. I t a u t o m a t i c a l l y s e l e c t s the f i r s t item in t he J L i s t t h a t matches the c urrent p r e f i x in the JTextField. I f the JTextField i s n u l l, or the p r e f i x does not match any element in the JList, then the J L i s t s e l e c t i o n i s c l e a r e d. There are no methods to c a l l f o r t h i s o b j e c t. You simply c r e a t e i t, and f o r g e t i t. ( But don t l e t i t be garbage c o l l e c t e d... ) Example : JTextField t = new JTextField ( ) ; J L i s t l = new J L i s t ( ) ; QuickEntryMediator qem = new QuickEntryMediator ( t, l ) ; // t h a t s a l l f o l k Robert C. Martin, Robert S. 30 Jun, (SLAC) / 10

11 public c l a s s QuickEntryMediator { public QuickEntryMediator ( JTextField t, J L i s t l ) { i t s T e x t F i e l d = t ; i t s L i s t = l ; i t s T e x t F i e l d. getdocument ( ). adddocumentlistener ( new DocumentListener ( ) { public void changedupdate ( DocumentEvent e ) { textfieldchanged ( ) ; public void insertupdate ( DocumentEvent e ) { textfieldchanged ( ) ; public void removeupdate ( DocumentEvent e ) { textfieldchanged ( ) ; // new DocumentListener ) ; // adddocumentlistener // QuickEntryMediator ( ) private void textfieldchanged ( ) { S t r i n g p r e f i x = i t s T e x t F i e l d. gettext ( ) ; i f ( p r e f i x. l e n g t h ( ) == 0) { i t s L i s t. c l e a r S e l e c t i o n ( ) ; return ; ListModel m = i t s L i s t. getmodel ( ) ; boolean found = f a l s e ; for ( int i = 0 ; found == f a l s e && i < m. g e t S i z e ( ) ; i++) { Object o = m. getelementat ( i ) ; S t r i n g s = o. t o S t r i n g ( ) ; i f ( s. startswith ( p r e f i x ) ) { i t s L i s t. s e t S e l e c t e d V a l u e ( o, true ) ; found = true ; i f (! found ) { i t s L i s t. c l e a r S e l e c t i o n ( ) ; // textfieldchanged 11

12 private JTextField i t s T e x t F i e l d ; private J L i s t i t s L i s t ; // c l a s s QuickEntryMediator 1.6 De Singleton en Monostate patronen Normaalgezien worden er van een Java klasse een aantal verschillende objecten aangemaakt. Het kan echter ook voorkomen dat een bepaalde klasse bedoeld is om maar één keer geïnstantieerd te worden. Bijvoorbeeld, een MVC applicatie heeft typisch maar één Controller object. Het kan bovendien zelfs zo zijn dat er ernstige bugs zouden optreden, moest iemand toch meerdere objecten van een dergelijke klasse aanmaken. In dergelijke omstandigheden kan het interessant zijn om de klasse zo te implementeren dat het gewoon niet mogelijk is om meerder objecten ervan aan te maken. Onderstaande code toont een eenvoudige implementatie van een dergelijke singleton klasse: public class S i n g l e t o n { private S i n g l e t o n ( ) { private static S i n g l e t o n i n s t a n c e ; public static S i n g l e t o n g e t I n s t a n c e ( ) { i f ( i n s t a n c e == null ) i n s t a n c e = new S i n g l e t o n ( ) ; return i n s t a n c e ; Gezien de private constructor, is de enige manier om aan een object van deze klasse te geraken de methode getinstance(), die ervoor zal zorgen dat er ten hoogste één object wordt aangemaakt. Deze aanpak heeft een aantal voordelen: Je kan op deze manier van elke klasse een singleton maken; Als je een bestaande klasse hebt, kan je hiervan een subklasse maken die een singleton is; Het unieke object wordt pas aangemaakt zodra dit de eerste keer opvraagt. Er zijn echter ook nadelen: Als je een subklasse maakt van een klasse die een singleton is, is deze niet automatisch zelf ook weer een singleton; Deze methode is niet transparant: iedereen die deze klasse gebruikt, moet weten dat ze een singleton is en dat dus getinstance() gebruikt moet worden ipv. een constructor; 12

13 Een detail: elke oproep van getinstance gaat sowieso een if-test doen, ook al heeft eigenlijk alleen de eerste oproep deze nodig. Een andere mogelijkheid om het gewenste effect te bekomen is om ipv. Singleton het Monostate patroon te gebruiken. Dit patroon bestaat erin om alle attributen van de klasse statisch (static) te maken, maar niet de methodes. De klasse is dan geen écht singleton, in de zin dat er meerdere objecten van de klasse kunnen zijn, maar al die objecten zijn volledig identiek aan elkaar en gedragen zich dus alsof hetzelfde zijn en er dus in feite maar één is. Eigenschappen van deze methode: + Andere klassen hoeven niet te weten dat deze klasse een Monostate klasse is; + Een subklasse van een Monostate klasse is zelf automatisch ook weer een Monostate; Als je al een klasse hebt, kan je hiervan geen subklasse maken die een Monostate is; Zelfs als er geen enkel object van een Monostate klasse wordt aangemaakt, zal er toch geheugenruimte voorzien worden voor de gedeelde statische variabelen. 1.7 Het Null object patroon Een veel voorkomende conventie is dat een methode die dient om gegevens op te zoeken, de waarde null zal teruggeven als de gezochte gegevens niet gevonden werden. In de methode die de gegevens opvraagt, zal dit dan aanleiding geven tot code als deze: Werknemer w = getwerknemer ( naam ) ; i f (w!= null && w. isbetaaldag ( vandaag ) ) w. b e t a a l ( ) ; of eventueel zoiets: Werknemer w = getwerknemer ( naam ) ; try { i f (w. isbetaaldag ( vandaag ) ) w. b e t a a l ( ) ; catch ( NullPointerException n ) { //... Vermoedelijk zal zo elke methode die getwerknemer() gebruikt een dergelijk stukje code bevatten. Dit betekent dat het feit dat deze ene methode soms null teruggeeft, ervoor zorgt dat tientalle methodes een extra if of try-catch 13

14 Figuur 9: Het Null object patroon. nodig hebben. Dit lijkt niet zo ideaal, maar de vraag is natuurlijk of wie hier iets aan kunnen doen. Het Null object patroon suggereert de oplossing die getoond word in Figuur 9. Als we deze oplossing volgen, moeten we er natuurlijk voor zorgen dat het null object de methodes van Werknemer zodanig implementeert dat er niets gebeurt. Bijvoorbeeld: c l a s s NullWerknemer extends Werknemer { public boolean isbetaaldag ( ) { return f a l s e ; public void b e t a a l ( ) { Statements als if (getwerknemer(n)!= null) zijn dan niet meer nodig. Let wel: de informatie over wat er moet gebeuren indien een Werknemer niet gevonden wordt, verdwijnt daarmee uit de oproepende functie en komt terecht in dit nieuwe NullWerknemer object. Dit is natuurlijk niet altijd mogelijk! Indien nodig, kan een functie natuurlijk wel nog altijd testen of de werknemer gevonden geweest is door deze test: i f (! ( getwerknemer ( n ) instanceof NullWerknemer ) ) {... Het heeft natuurlijk weinig zin om meer dan één NullWerknemer object te hebben, dus deze klasse is een voor de hand liggende kandidaat voor het Singleton patroon: c l a s s NullWerknemer extends Werknemer { private NullWerknemer ( ) { private static NullWerknemer i n s t a n c e ; public static NullWerknemer g e t I n s t a n c e ( ) { i f ( i n s t a n c e == nul ) i n s t a n c e = new S i n g l e t o n ( ) ; return i n s t a n c e ; public boolean isbetaaldag ( ) { 14

15 return f a l s e ; public void b e t a a l ( ) { Een bijkomend voordeel is dat bovenstaande instanceof nu vervangen kan worden door: i f ( getwerknemer ( n )!= NullWerknemer. g e t I n s t a n c e ( ) ) ) {... De canonieke vorm van it patroon gaat zelfs nog een stap verder en schermt de klasse NullWerknemer helemaal af van de buitenwereld er is inderdaad geen enkele reden waarom andere klassen zouden moeten weten wat, bijvoorbeeld, nu precies de naam is van de klassie die een niet-gevonden Werknemer voorstelt. public class Werknemer { public static f i n a l Werknemer NULL = new Werknemer ( ) { public boolean isbetaaldag ( ) { return f a l s e ; public void b e t a a l ( ) { ;... De test om te zien of een werknemer gevonden is, wordt dan: i f ( getwerknemer ( n )!= NullWerknemer.NULL) {... Ander nuttig gebruik van dit patroon vinden we bijvoorbeeld in implementaties van lijsten, waar de lege lijst een Null object kan zijn. 15