OO Analyse in de praktijk OO Analyse in de praktijk V Enkele Design Patterns.

Presentatie over: "OO Analyse in de praktijk OO Analyse in de praktijk V Enkele Design Patterns."— Transcript van de presentatie:

1 OO Analyse in de praktijk OO Analyse in de praktijk V Enkele Design Patterns

2 2OO Analyse, V Enkele Design Patterns Boeken/tutorials: Design Patterns Design Patterns Gamma, Helm, Johnson, Vlissides Gamma, Helm, Johnson, Vlissides Object Oriented Software Construction Object Oriented Software Construction Bertrand Meyer Bertrand Meyer

3 3OO Analyse, V Enkele Design Patterns Inhoud Wat zijn design patterns ? Wat zijn design patterns ? Waarom design patterns leren ? Waarom design patterns leren ? Beperk de impact van veranderingen Beperk de impact van veranderingen Bloemlezing met voorbeelden Bloemlezing met voorbeelden Zie volgende slide

4 4OO Analyse, V Enkele Design Patterns Enkele design patterns Creational Creational Factory Method Factory Method Singleton Singleton Structural Structural Composite Composite Façade Façade Behavioral Behavioral Command Command State (hier behandeld) State (hier behandeld) Template (hier behandeld) Template (hier behandeld)

5 5OO Analyse, V Enkele Design Patterns Wat zijn design patterns ? =Standaard oplossingen voor standaard problemen. =Standaard oplossingen voor standaard problemen. Op niveau van ‘design’. Het gaat dus niet om herbruikbare code, wel om bruikbare ontwerpen. Op niveau van ‘design’. Het gaat dus niet om herbruikbare code, wel om bruikbare ontwerpen. Het gaat over iets grotere gehelen dan beschreven in OO principes en OO basisregels. Het gaat over iets grotere gehelen dan beschreven in OO principes en OO basisregels. ‘design patterns’ zijn in de bekendheid geraakt door het boek van de ‘gang of four’ GOF (zie slide 2) ‘design patterns’ zijn in de bekendheid geraakt door het boek van de ‘gang of four’ GOF (zie slide 2)

6 6OO Analyse, V Enkele Design Patterns Waarom design patterns leren ? Veel problemen ivm software-aanpassingen zijn algemeen. Ze hebben altijd te maken met een verandering die een te grote impact heeft op het softwaresysteem. Veel problemen ivm software-aanpassingen zijn algemeen. Ze hebben altijd te maken met een verandering die een te grote impact heeft op het softwaresysteem. Als je al enkele patronen/oplossing al kent, verlies je minder tijd. Als je al enkele patronen/oplossing al kent, verlies je minder tijd. Als iedereen eenzelfde patroon eenzelfde naam geeft, dan kan er beter gecommuniceerd worden. Als iedereen eenzelfde patroon eenzelfde naam geeft, dan kan er beter gecommuniceerd worden.

7 7OO Analyse, V Enkele Design Patterns Beperk de impact van veranderingen Probleem: Bij creatie van een object pinnen we ons vast aan een concrete klasse. Als die moet veranderen, moeten we onze code aanpassen. (voorbeeld van schending van Dependency Inversion) Probleem: Bij creatie van een object pinnen we ons vast aan een concrete klasse. Als die moet veranderen, moeten we onze code aanpassen. (voorbeeld van schending van Dependency Inversion) patroon/oplossing: Factory Method Probleem: We weten hoe we een nieuwe methode kunnen bijmaken door reeds eerder gebruikte elementaire methoden op te roepen (zie basisregels: gemeenschappelijke code). Probleem: We weten hoe we een nieuwe methode kunnen bijmaken door reeds eerder gebruikte elementaire methoden op te roepen (zie basisregels: gemeenschappelijke code). Omgekeerd komt het ook voor dat een methode moet toegevoegd worden met een gelijkaardige structuur als een bestaande methode, maar die andere elementaire methoden oproept. Hoe kunnen we gebruik maken van onze eerdere inspanningen ? patroon/oplossing: Template Method

8 8OO Analyse, V Enkele Design Patterns Beperk de impact van veranderingen Probleem: We hebben in een voorgaand project klassen gebouwd waarvan we nu 10% willen hergebruiken. Helaas hebben de klassen veel publieke methoden met lange parameterlijsten. Het lijk erop dat als we 1 klasse willen gebruiken, we een kluwen van andere klassen moeten meenemen. Probleem: We hebben in een voorgaand project klassen gebouwd waarvan we nu 10% willen hergebruiken. Helaas hebben de klassen veel publieke methoden met lange parameterlijsten. Het lijk erop dat als we 1 klasse willen gebruiken, we een kluwen van andere klassen moeten meenemen. patroon/oplossing: Façade Noot: Gebruik design patterns alleen als je de problemen die ze proberen op te lossen ook echt hebt.

9 9OO Analyse, V Enkele Design Patterns Het State-pattern Een veranderlijke eigenschap wordt voorgesteld door een attribuut (zie basisregels). We kunnen dan geen subklassen gebruiken, omdat een object niet van klasse kan veranderen. Toch kunnen we m.b.v. het State-pattern, gebruik maken van subklassen en polymorphisme. Een veranderlijke eigenschap wordt voorgesteld door een attribuut (zie basisregels). We kunnen dan geen subklassen gebruiken, omdat een object niet van klasse kan veranderen. Toch kunnen we m.b.v. het State-pattern, gebruik maken van subklassen en polymorphisme. In het voorbeeld laten we zien hoe de if-testen kunnen vermeden worden. In het voorbeeld laten we zien hoe de if-testen kunnen vermeden worden.

10 10OO Analyse, V Enkele Design Patterns State: het probleem public double getBelPerc(){ public double getBelPerc(){ if ( burgStand == GETROUWD ) if ( burgStand == GETROUWD ) return NORM_PERC - AFTREK; return NORM_PERC - AFTREK; else else return NORM_PERC; return NORM_PERC; } Werknemer +getBurgStand() : int -burgStand : int +getBelPerc() : double +getPensioen() : double

11 11OO Analyse, V Enkele Design Patterns State: het probleem Het probleem met de code in de vorige slide is hetvolgende: Het probleem met de code in de vorige slide is hetvolgende: Als er een nieuwe burgerlijke stand bijkomt (samenwonend, weduwnaar), dan moeten al de bestaande if-tests doorlopen en evt. gewijzigd worden, met alle gevaren vandien.

12 12OO Analyse, V Enkele Design Patterns State: de oplossing > BurgStand Getrouwd Alleen Werknemer +getBurgStand() : BurgStand -burgStand : BurgStand +getBelPerc() : double +getPensioen() : double public double getBelPerc(){ return burgStand.getBelPerc(); return burgStand.getBelPerc();} // opm: In sommige gevallen moeten // we this meegeven, op deze manier: // return burgStand.getBelPerc(this); +getBelPerc() : double +getPensioen() : double +getBelPerc() : double +getPensioen() : double +getBelPerc() : double +getPensioen() : double public double getBelPerc(){ return NORM_PERC; return NORM_PERC;} public double getBelPerc(){ return NORM_PERC - AFTREK; return NORM_PERC - AFTREK;}

13 13OO Analyse, V Enkele Design Patterns Het Template Method-pattern Het komt vaak voor dat een structuur (de template of ‘mal’) van een methode steeds dezelfde is, maar dat de meer elementaire operaties verschillen. Zo zullen we een lijst vaak op dezelfde manier doorlopen en ondertussen dezelfde tests willen uitvoeren. Het komt vaak voor dat een structuur (de template of ‘mal’) van een methode steeds dezelfde is, maar dat de meer elementaire operaties verschillen. Zo zullen we een lijst vaak op dezelfde manier doorlopen en ondertussen dezelfde tests willen uitvoeren. In het voorbeeld laten we zien hoe we de elementaire operaties kunnen aanpassen zonder aan de template-method te raken. In het voorbeeld laten we zien hoe we de elementaire operaties kunnen aanpassen zonder aan de template-method te raken.

14 14OO Analyse, V Enkele Design Patterns Template Method: het probleem public void verhoog(){ public void verhoog(){ for(int i = 0 ; i < lijst.size(); i++) for(int i = 0 ; i < lijst.size(); i++) …; // verhoog elk element …; // verhoog elk element } public void verlaag(){ public void verlaag(){ for(int i = 0 ; i < lijst.size(); i++) for(int i = 0 ; i < lijst.size(); i++) …; // verlaag elk element …; // verlaag elk element } public void drukAf(){ public void drukAf(){ for(int i = 0 ; i < lijst.size(); i++) for(int i = 0 ; i < lijst.size(); i++) System.out.println( lijst.get(i) ); System.out.println( lijst.get(i) ); } IntegerLijst +verhoog() -lijst : List +verlaag() +drukAf()

15 15OO Analyse, V Enkele Design Patterns Template Method: het probleem Het probleem met de code in de vorige slide is hetvolgende: Het probleem met de code in de vorige slide is hetvolgende: De code slaagt er niet in het gemeenschappelijke stuk, namelijk de for-lus af te zonderen. Bij elke nieuwe methode waarbij de lijst moet doorlopen worden, moet de for-lus herschreven worden. Het probleem verergert, als naast de for-lus, ook extra conditionele code, steeds herhaalt moet worden. De structuur blijft hetzelfde, de elementaire operaties, verschillen telkens (verhogen, verlagen, afdrukken, …)

16 16OO Analyse, V Enkele Design Patterns Template Method: de oplossing public void voerUit(){ for(int i = 0 ; i < lijst.size(); i++) for(int i = 0 ; i < lijst.size(); i++)operatie(i);} > Iteratie Verlaging Verhoging +voerUit() +operatie(int i) Afdruk +-operatie(int i) public void operatie(int i){ System.out.println(lijst.get(i)); System.out.println(lijst.get(i));} IntegerLijst +verhoog() -lijst : List +verlaag() +drukAf() public void drukAf(){ (new Afdruk(lijst)).voerUit(); (new Afdruk(lijst)).voerUit();} -lijst : List

17 17OO Analyse, V Enkele Design Patterns Opdracht Zoek enkele andere patterns op op internet, en probeer ze uit in een werkend stuk code.