Welke concrete Flyweight klassen?

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • Avalaxy
  • Registratie: Juni 2006
  • Laatst online: 16:15
Ik heb een vraagje over het Flyweight pattern...

Ik heb een reeks buttons (zeg voor het gemak 10 rijen van 10 buttons). Deze buttons zijn allemaal leeg; ze hebben geen kleur, geen value, alleen aparte coördinaten. Echter kunnen buttons ook verkleuren aan de hand van een actie. Dit is dus mogelijk:

- Lege button
- Rode button
- Gele button

Oftewel, de intrinsic state is het type button (leeg, geel, rood) en de extrinsic state zijn de coördinaten waar de button is te vinden?

Nu kom ik er niet goed uit wat voor concrete Flyweight classes ik moet maken... Ik heb alle voorbeelden op Google bekeken en ik heb het hoofdstuk over Flyweights uit mn GoF boek gelezen, maar het wordt me niet echt duidelijk...

Ik heb nu dit:
- ConcreteFlyweights: EmptyButton, YellowButton, RedButton

Maar dan zijn er ook nog UnsharedConcreteFlyweights, en dat is het punt waarop ik het niet meer begrijp... Is dit relevant voor mij? In het GoF boek werden bijvoorbeeld 'rows' en 'columns' aangehaald als voorbeelden van UnsharedConcreteFlyweight, echter zijn sommige rows (en columns) identiek aan elkaar als in dat ze allemaal 10 lege buttons hebben, terwijl het punt van een UnsharedConcreteFlyweight toch is dat hij niet gedeeld wordt?

Stel dat ik alsnog een row en column aanmaak, dan moeten andere ConcreteFlyweights weer inheriten van deze UnsharedConcreteFlyweight? Dit zie ik echter niet terug op de UML voorbeelden.

Voor het gemak even een illustratie van het Flyweight pattern zoals deze op internet te vinden is:

Afbeeldingslocatie: http://www.dofactory.com/Patterns/Diagrams/flyweight.gif

Acties:
  • 0 Henk 'm!

  • Herko_ter_Horst
  • Registratie: November 2002
  • Niet online
Waarom verschillende klassen voor verschillende buttons? De kleur/het type was toch state?

Voor w.b.t. Row en Column: die bepalen de volgorde en daarmee de locatie van je buttons. Ze worden dus niet hergebruikt, want elke Row en Column heeft een andere locatie.

"Any sufficiently advanced technology is indistinguishable from magic."


Acties:
  • 0 Henk 'm!

  • Avalaxy
  • Registratie: Juni 2006
  • Laatst online: 16:15
Herko_ter_Horst schreef op zaterdag 08 januari 2011 @ 17:52:
Waarom verschillende klassen voor verschillende buttons? De kleur/het type was toch state?
Hmm, dus in principe heb je 1 ConcreteFlyweight klasse nodig die van state kan veranderen (State pattern)? Dat maakt het wel makkelijker denk ik :)
Voor w.b.t. Row en Column: die bepalen de volgorde en daarmee de locatie van je buttons. Ze worden dus niet hergebruikt, want elke Row en Column heeft een andere locatie.
Locatie is toch iets wat extrinsic state is? Waarom gaat dat niet op voor UnsharedConcreteFlyweights?

Acties:
  • 0 Henk 'm!

  • Herko_ter_Horst
  • Registratie: November 2002
  • Niet online
Avalaxy schreef op zaterdag 08 januari 2011 @ 17:59:
[...]


Hmm, dus in principe heb je 1 ConcreteFlyweight klasse nodig die van state kan veranderen (State pattern)? Dat maakt het wel makkelijker denk ik :)
Je bent wel helemaal los op patterns, of niet? :) Schiet er niet in door: patterns zijn een middel, geen doel op zich. Soms is state gewoon state (d.w.z. een simpel field in de Button class).
[...]


Locatie is toch iets wat extrinsic state is? Waarom gaat dat niet op voor UnsharedConcreteFlyweights?
Of locatie extrinsic is, hangt af van de class. Misschien is locatie (als in: X,Y-coordinaten) in dit geval de verkeerde term: het gaat bij rows en columns om relatieve volgorde: rij 2, kolom 4. De context bepaalt dan inderdaad de locatie in X,Y.

"Any sufficiently advanced technology is indistinguishable from magic."


Acties:
  • 0 Henk 'm!

  • Avalaxy
  • Registratie: Juni 2006
  • Laatst online: 16:15
Herko_ter_Horst schreef op zaterdag 08 januari 2011 @ 18:24:
[...]

Je bent wel helemaal los op patterns, of niet? :) Schiet er niet in door: patterns zijn een middel, geen doel op zich. Soms is state gewoon state (d.w.z. een simpel field in de Button class).
Ik wil mezelf graag zoveel mogelijk verbeteren op het gebied van software architectuur, dus vandaar dat ik veel aan het experimenteren ben met het zo flexibel mogelijk maken van m'n code :) Maar ok, ik zal morgen eens kijken wat het handigst is :)
[...]
Of locatie extrinsic is, hangt af van de class. Misschien is locatie (als in: X,Y-coordinaten) in dit geval de verkeerde term: het gaat bij rows en columns om relatieve volgorde: rij 2, kolom 4. De context bepaalt dan inderdaad de locatie in X,Y.
Ok, thanks :)

Dan nog mijn laatste vraag: wat is dan de beste manier om bij te houden welke objecten bij een row horen en bij welke column een row hoort? Gewoon iets van een list inbouwen in je UnsharedConcreteFlyweights?

Acties:
  • 0 Henk 'm!

  • Herko_ter_Horst
  • Registratie: November 2002
  • Niet online
Gewoon iets van een lijst inbouwen in je Column en Row, bedoel je. Dat het gebruikt wordt als een UnsharedConcreteFlyweight doet echt niet terzake.

P.S. Ik hoop niet dat je UnsharedConcreteFlyweight in je class hierarchy hebt zitten...

"Any sufficiently advanced technology is indistinguishable from magic."


Acties:
  • 0 Henk 'm!

  • Avalaxy
  • Registratie: Juni 2006
  • Laatst online: 16:15
Ja klopt :) Verkeerde bewoording.
Pagina: 1