Strategy pattern : een doodzonde voor hybride talen?

Examenroosters, algemene discussies, ...

Moderator: Praesidium

Glenn
Posts: 280

Strategy pattern : een doodzonde voor hybride talen?

Post#1 » Thu Jan 05, 2012 4:49 pm

Hoi allemaal,

Ik weet niet wat jullie daar van denken, maar ik heb het nooit echt gehad met het "Strategy pattern" (zie hier). Voor mij is het echt een doodzonde tegen het denken in termen van objecten. Waarom?

Het handige aan OO is dat het je toelaat om tijdens het programmeren objecten toe te voegen die iets tastbaar uit de werkelijkheid (eventueel fictieve werkelijkheid) voorstellen. Dat is volgens mij dan ook het grootste voordeel aan het werken met objecten.

Waarom niet gewoon werken met een else if ? Bijvoorbeeld.

Code: Select all


if (situation1) {
// Strategy one
} else if (situation2) {
// Strategy two
} else {
// Strategy three
}
Natuurlijk is het zo dat als bepaalde strategieen vaker gebruikt worden, of de .cpp file te lang wordt, dat we deze strategieen best in een aparte functie plaatsen. Ik zou gewoon deze drie stragieen plaatsen in een aparte file, en deze bijhouden in een namespace. Bijvoorbeeld:

distributionStrategies.cpp

Code: Select all


namespace strategies::distribution {
void firstNodeStrategy() {

}
void intermediateNodeStrategy() {

}
void lastNodeStrategy() {

}
}
Het voordeel van zo te werk te gaan is dat.
a) Je niet gaat zondigen tegen de kern van het object georienteerd programmeren (hoofdreden!)
b) Alle strategieen samen mooi in 1 file staan, in plaats van allemaal verspreid over verschillende klassen
c) Je het ook over meerdere files kan verdelen indien gewenst (indien de file bijvoorbeeld te lang zou worden)

Groeten,
Glenn

User avatar
Robbe
WOZ
Posts: 2161
Contact:

Re: Strategy pattern : een doodzonde voor hybride talen?

Post#2 » Thu Jan 05, 2012 7:21 pm

Ik denk dat je het Strategy pattern niet goed begrijpt. Uit de Wikipedia link maak ik op dat het eerder om policies gaat en dat je dus een compositie van gedrag wilt hebben. Als je met het vernoemde pattern werkt, is het maar een kwestie van een nieuwe strategie/policy in te pluggen. De logica voor het nieuwe gedrag zit dan in een nieuwe klasse zonder dat het oorspronkelijke object op enige manier moet worden aangepast.

De strategie wordt dus niet door het object op runtime gekozen maar door een hogerliggende entiteit die beslist dat het object een bepaalde strategie moet gebruiken.
"I'm not afraid of falling, I'm afraid of landing" -- Sam
How To Ask Questions The Smart Way

Zingen? UKA-n dat ook!

User avatar
Fristi
WOZ
Posts: 4565

Re: Strategy pattern : een doodzonde voor hybride talen?

Post#3 » Thu Jan 05, 2012 7:50 pm

Robbe wrote:Ik denk dat je het Strategy pattern niet goed begrijpt. Uit de Wikipedia link maak ik op dat het eerder om policies gaat en dat je dus een compositie van gedrag wilt hebben. Als je met het vernoemde pattern werkt, is het maar een kwestie van een nieuwe strategie/policy in te pluggen. De logica voor het nieuwe gedrag zit dan in een nieuwe klasse zonder dat het oorspronkelijke object op enige manier moet worden aangepast.

De strategie wordt dus niet door het object op runtime gekozen maar door een hogerliggende entiteit die beslist dat het object een bepaalde strategie moet gebruiken.
Ik moest zelf ook direct aan policies denken ja. Dan breekt het inderdaad absoluut geen encapsulatie.
Fristi Ad Infinitum

WINAK WOZ 2013 - ...
WINAK Magister Fristi 2012-2013
WINAK Feest 2011-2012
WINAK Schachtentemmer 2010-2011
WINAK Scriptor 2008-2009 | 2009-2010

Glenn
Posts: 280

Re: Strategy pattern : een doodzonde voor hybride talen?

Post#4 » Fri Jan 13, 2012 1:45 am

Robbe wrote:Ik denk dat je het Strategy pattern niet goed begrijpt. Uit de Wikipedia link maak ik op dat het eerder om policies gaat en dat je dus een compositie van gedrag wilt hebben. Als je met het vernoemde pattern werkt, is het maar een kwestie van een nieuwe strategie/policy in te pluggen. De logica voor het nieuwe gedrag zit dan in een nieuwe klasse zonder dat het oorspronkelijke object op enige manier moet worden aangepast.

De strategie wordt dus niet door het object op runtime gekozen maar door een hogerliggende entiteit die beslist dat het object een bepaalde strategie moet gebruiken.
Ja, dat weet ik nu ook nog wel juist he :D ! Het kan ook gebruikt worden als hulpmiddel om conditional code uit te factoren [1]. Maar net daar ben ik geen fan van. Althans toch niet in een hybride taal als C++ (Java is een ander geval).

Maar of je het nu ziet als een policy die je meegeeft als argument aan een andere functie of niet, het probleem van het denken in OO termen blijft wel. Dat probleem heb je sowieso al bij policies. Een object dat gedrag beschrijft daar ben ik sowieso al geen fan van. Dan staat heel de wereld op zijn kop.

[1] zie object oriented reengineering patterns p295, (zie hier)

PS: object oriented reengineering patterns vind ik trouwens een heel goed boek, ik heb er nog niet alles van gelezen maar het is een van de beste boeken die ik de afgelopen tijd heb vastgehad. In de vakantie lees ik er sowieso verder in. Een echte aanrader!
Last edited by Glenn on Fri Jan 13, 2012 2:13 am, edited 5 times in total.

Glenn
Posts: 280

Re: Strategy pattern : een doodzonde voor hybride talen?

Post#5 » Fri Jan 13, 2012 1:59 am

Over policies gesproken, weet er iemand goede toepassingen van policies.
Wat in mij opkomt is bijvoorbeeld een maker van een library die zijn gebruikers de mogelijkheid wil geven om eigen algoritmes in zijn code te injecteren. Volgens mij zou ik policies ook enkel maar in die situatie gebruiken. In elk ander geval zou ik het gedrag bij de data plaatsen denk ik (dus in dezelfde klasse) en de gebruiker de methode laten kiezen via een parameter.

User avatar
Joachimvdh
Prosenior
Posts: 1092

Re: Strategy pattern : een doodzonde voor hybride talen?

Post#6 » Fri Jan 13, 2012 2:33 am

ik ben grote fan van het verwijderen van conditionals dmv een object hierarchie. Dit om de boel leesbaar te maken. objecten moeten zelf hun staat veranderen. Als er dan achterliggend andere dingen gebeuren bij verschillende subtypen dan moet dat gaan (zie liskov substitutie principe) zoniet doet ge iets fout in uw hierarchie. Een voorbeeldje: bij compilers hebben we een boomstructuur. Alle nodes zijn afgeleid van het node type maar er zit een enorme hierarchie achter het node type. de functie om pcode te genereren is overschreven op al die types, en zo moet ik mij binnen de nodes geen zorgen maken over wat er wordt gegenereerd in andere nodes. Dit bespaart enorm veel werk.

Policies kunt ge ook doen in de context van templates. Wij hebben daar vorig jaar veelvuldig gebruik van gemaakt bij gevorderde programmeertechnieken. Wij moesten toen een matrix implementeren, via policies konden wij enorme performance winsten boeken voor grote matrices. Een vb: vermenigvuldiging van 2 grote matrices is een tijdrovend proces, echter als een vd 2 een diagonaalmatrix is kunt ge het aantal operaties aanzienlijk verminderen. Wij hadden dus een policy template voor de vermenigvuldiging, de juiste specialisatie werd op compile time uitgezocht dmv type parameters. De policy implementeerde dan de get methoden voor een matrixvermenigvuldiging. De context hierrond waren expression templates (zoek daar maar eens op) en die zijn gruwelijk graaf.

Hoewel templates een zeer algemene vorm van programmeren met zich mee brengen zijn ze belachelijk krachtig, zonder templates en bijhorende policies had ik die code niet zo vlot kunnen schrijven.

Glenn
Posts: 280

Re: Strategy pattern : een doodzonde voor hybride talen?

Post#7 » Wed Jan 18, 2012 5:14 pm

Joachimvdh wrote:ik ben grote fan van het verwijderen van conditionals dmv een object hierarchie. Dit om de boel leesbaar te maken. objecten moeten zelf hun staat veranderen. Als er dan achterliggend andere dingen gebeuren bij verschillende subtypen dan moet dat gaan (zie liskov substitutie principe) zoniet doet ge iets fout in uw hierarchie. Een voorbeeldje: bij compilers hebben we een boomstructuur. Alle nodes zijn afgeleid van het node type maar er zit een enorme hierarchie achter het node type. de functie om pcode te genereren is overschreven op al die types, en zo moet ik mij binnen de nodes geen zorgen maken over wat er wordt gegenereerd in andere nodes. Dit bespaart enorm veel werk.
Ik ben daar ook grote fan van op de manier zoals jij het beschrijft. Ik ben alleen geen fan van het maken van een klassen als: Strategy (interface), SpecificStrategyA, SpecificStrategyB, SpecificStrategyC, die enkel een methode execute implementeren. Op de manier zoals jij het beschrijft als een methode van node, vind ik het heel goed!
Joachimvdh wrote: Policies kunt ge ook doen in de context van templates. Wij hebben daar vorig jaar veelvuldig gebruik van gemaakt bij gevorderde programmeertechnieken. Wij moesten toen een matrix implementeren, via policies konden wij enorme performance winsten boeken voor grote matrices. Een vb: vermenigvuldiging van 2 grote matrices is een tijdrovend proces, echter als een vd 2 een diagonaalmatrix is kunt ge het aantal operaties aanzienlijk verminderen. Wij hadden dus een policy template voor de vermenigvuldiging, de juiste specialisatie werd op compile time uitgezocht dmv type parameters. De policy implementeerde dan de get methoden voor een matrixvermenigvuldiging. De context hierrond waren expression templates (zoek daar maar eens op) en die zijn gruwelijk graaf.

Hoewel templates een zeer algemene vorm van programmeren met zich mee brengen zijn ze belachelijk krachtig, zonder templates en bijhorende policies had ik die code niet zo vlot kunnen schrijven.
Ja, wij hebben dat project ook gemaakt. Wij hebben gebruik gemaakt van een policy om de gebruiker van onze bibliotheek toe te laten zijn eigen storage facility te laten meegeven. Hierdoor moet hij de code van onze library niet hebben en kan hij als het ware zijn eigen mechanisme meegeven. Op die manier vond ik het heel goed.

Wat jij voorstelt kan je inderdaad doen. Wij hebben geen policy gemaakt van de vermenigvuldigen maar werkten gewoon met inheritance. Ge hebt gewoon een DiagonalMatrix en die is een Matrix. Dus die overschrijft zijn methodes. Met een policy werken gaat hier ook maar dat is dan weer de wereld op zijn kop vind ik. Ge gaat dan u mechanisme centraal zetten ipv u hiërarchie.

User avatar
Joachimvdh
Prosenior
Posts: 1092

Re: Strategy pattern : een doodzonde voor hybride talen?

Post#8 » Wed Jan 18, 2012 6:58 pm

Glenn wrote: Wat jij voorstelt kan je inderdaad doen. Wij hebben geen policy gemaakt van de vermenigvuldigen maar werkten gewoon met inheritance. Ge hebt gewoon een DiagonalMatrix en die is een Matrix. Dus die overschrijft zijn methodes. Met een policy werken gaat hier ook maar dat is dan weer de wereld op zijn kop vind ik. Ge gaat dan u mechanisme centraal zetten ipv u hiërarchie.
Dat ging dus niet meer in de context van expression templates...

Return to “Algemeen”

Who is online

Users browsing this forum: No registered users and 5 guests

cron