MaskedSprite discussie

[theFlashWizard]

Inleiding
Hey Mensen,
Ik wil een MaskedSprite clas maken.
Deze class moet zijn kinderen verbergen met een masker. Zie het als shortcut ten opzichte van een normale sprite maken, een shape maken, uittekenen, toevoegen aan displaylist en als masker gebruiken.
De class zou bijv. properties kunnen krijgen als:
maskWidth, maskHeight, maskEllipse, maskX, maskY.

Waarom ben ik überhaupt bezig met een mask ipv. een scrollRect? Omdat ik met afgeronde hoeken wil kunnen werken.

Groot nadeel van een masker is dat hij op de displaylist komt. Als iemand dat niet verwacht, een child toe voegt en probeert die op te halen met getChildAt(0) dan krijgt hij vervolgenss het masker terug. Wat dan natuurlijk niet gewenst is.

Eigenlijk wil ik ook background en border toevoegen. (Als ik dit via graphics doe krijg je nooit de border op children.). Dit betekend nog meer displayobjecten die ik eigenlijk wil controleren en verbergen.

Nu zou je veel DisplayObjectContainer properties en methods kunnen overschrijven om ervoor te zorgen dat men hier niks van merkt. Ik kan echter ook een content Sprite toevoegen om alle displayObjecten die gemaskeerd moeten worden toevoegen. (Ook erg handig als je er later een scroll functie aan wilt bouwen.)

Opties
Ik heb hierbij alleen een grote afweging.
Optie1 Content propertie toevoegen.
Je geeft een MaskedSprite class een public content property om displayObjecten (die gemaskeerd moeten worden) aan toe te kunnen voegen. Hiernaast kan je dan ook eventueel objecten aan de MaskedSprite zelf toe voegen. Hierbij zou je dan een aantal methods moeten overriden (methods als swapChild, removeChild()) om te voorkomen dat mensen aan de mask child komen.
optie2 Override.
Je override bijna alles van de Sprite class en je doet alsof je kinderen kan toevoegen aan de MaskedSprite instance. Op de achtergrond sluis je alles door naar een content child.
Je zou ook nog methods kunnen maken als:
addStyleChild(), removeStyleChild() enz.

Vergelijking
Optie1 content property toevoegen ten opzichte van optie2 Override.
Voordelen

Makkelijker
Iets minder kinderen te overschrijven.

Nadelen

Je dwingt de gebruiker een ongewone stap te doen, een content property te gebruiken.
Je linkt direct door naar een dieper object. Het is beter om doorsluis functies te maken. Dan kan je eventuele veranderingen nog opvangen onder dezelfde interface.
is niet zomaar te verwisselen met een Sprite.


Mijn mening
Ik zou voor optie2 de override gaan. Dit omdat:

Ik het heel erg belangrijk vind dat een interface consistent is met bijv. de gewone actionscript classes.
Ik containers graag makkelijk wil kunnen omwisselen.

Mijn collega's mening
Mij collega gaat voor optie 1 content property toevoegen omdat:

Minder overrides (want overrides zijn slecht)
Je legt de gebruiker minder op.


Jou mening?
Voor welke optie zou jij gaan en waarom?

Optie 3?
Als jullie nog een optie 3 weten hoor ik die natuurlijk ook heel graag.

Alvast bedankt voor jullie bijdrage.

[TheDutch]

TFW, ik lees dat je zegt "overrides zijn slecht". Binnen OO overerf je veelal een andere class en het komt vaak voor dat je een functionaliteit van een superclass wilt overriden. Dat is binnen OO heel normaal en zeker niet slecht. Het is daarom in mijn ogen een iets wat gewaagde uitspraak :).

Interessante discussie! Wanneer ik eventjes wat meer tijd heb zal ik het met meer aandacht gaan doorlezen en erop reageren.

[theFlashWizard]

Leuk dat je dit nog even hebt opgezocht na gister ;)
Ben benieuwd.

Bernard gaf gister aan dat het waarschijnlijk het beste is om er een decorator van te maken. Maar dat leek me eigenlijk geen optie omdat je dan custom properties als maskWidth (bij maskedSprite) of een gap (bij een list) of een scrollX (bij een scroller) niet kan bereiken. Maar als ik hierbij iets over het hooft zie hoor ik dat natuurlijk graag.

Daarnaast moet je evengoed altijd een Sprite extenden, omdat je er anders geen displayobjectContainer hebt, wat betekent dat je er geen displayObjects in kan zetten en je hem bijv niet in de displaylist kan zetten.

[theFlashWizard]

Eigenlijk hoop nog wat meer respons op dit topic te kunnen krijgen (a)

[Tommyfied]

Ik heb even nagedacht over wat hierboven gezegd is.
Een gedacht die daarbij steeds terug kwam is dat de class, zoals altijd, intuïtief en logisch in gebruik moet zijn.

Met deze gedachte in mijn achterhoofd ben ik tot de volgende conclusie gekomen:

1) MaskedSprite dient Sprite te extenden.
Dit zorgt voor een consistente intuïtieve interface.

2) MaskedSprite kan ook gewoon aan de displaylist toegevoegd worden.
Dat is te verwachten als je de naam van de class bekijkt / weet dat het een subclass van Sprite is / de interface van MaskedSprite bekijkt.

3) Alle normale methods van Sprite moeten bruikbaar zijn voor de gebruiker van de class.
Dat is te verwachten omdat Sprite geëxtend wordt.

4) Private content property want de relatie tussen je Mask en je Maskee(s) dient afgeschermd te worden (i.e. Je wilt zogoed mogelijk proberen te voorkomen dat de werking van je Mask gebroken wordt (dit doe je door dus overrides te maken van de methods van Sprite waar nodig en die door te sluizen naar je content).

5) Eventueel public mask property want je wilt de vorm van het mask eventueel editable maken voor de gebruiker. Een andere optie is om specifieke methods/properties te maken om je mask te editten (maskWidth, maskHeight etc.) om zo meer controle te houden.

6) De methods addChild en removeChild (en alle samenhangende methods zoals getChildAt() etc.) dienen dus overriden te worden om gebruik te maken van een (private) content property in MaskedSprite.
Aan de ene kant een logische, consistente interface van groot belang maar aan de andere kant is het gebruik van een (private) content property en een (public) mask property / mask modifiers de makkelijkste oplossing voor het daadwerkelijk maken van het Mask gedeelte van de class. Dus ontkom je mijns inziens niet aan het overriden van methods die voor conflicten kunnen zorgen.

Als je de class op deze manier opzet denk ik dat je een logische interface en relatief veel gebruikersgemak kunt combineren en aan de meeste van jouw wensen kan voldoen.
Het is wel meer werk om de class zelf te schrijven (zeker om alle overrides goed te maken).

Het is wel een moeilijke discussie. Ik ben zelfs geneigd om te zeggen dat de oplossing ingewikkelder is dan het probleem dat je wilt oplossen?

[Baukereg]

@ tfw

Ik snap nooit echt waarom je zo benauwd bent dat mensen die je class gebruiken ongewenst childs kan toevoegen als je class Sprite extend. Je kan de class natuurlijk zo inrichten dat eventuele extra childs geen invloed hebben op de mask en het gemaskeerde deel, dan zou het geen kwaad kunnen. Trouwens denk ik dat er weinig actionscripters zijn die achterloos childs toevoegen aan custom classes.

[theFlashWizard]

Tommyfied,
Top dat je hier over na wilde denken. Vind het erg motiverend dat je zo achter mijn keuzes staat :)

Baukereg,
Vooral nu ik met wat grotere projecten bezig ben merk je dat je steeds meer moeite krijgt de details te onthouden van al die verschillende classes.
Om een class dus "gebruikersvriendelijk" te maken moet ik (en anderen) me om dit soort dingen dus niet druk te hoeven maken.