[Ralph's Little-Big OOP Post Start]
Zoo....
Nou, threadje nog eens gelezen, en nu gaan we eens goed replyen.
Er zijn in dit topic een heleboel dingen voorbij gekomen, die ik graag zou willen voorzien van commentaar ( in de positieve vorm ).
Punt 1
Ten eerste zou ik even een misverstandje de wereld uithelpen; in patrick's eerste post zegt hij :
Van B-Top heb ik nu begrepen dat ik niet meer een object kan aanmaken dmv. test = new Voorwerp (); maar dmv. van attachMovie.
Ik denk dat ik niet helemaal duidelijk heb gemaakt waar dit over gaat;
a = new b();
Blijft natuurlijk ook in MX nog van groot belang, sterker nog, het is nog veel belangrijker.
De nuance ligt hem in het feit dat als je met registerClass() een class aan een movieclip 'bind', dat bij initialisatie van de movieclip de 'gebinde' constructor uitvoert. Natuurlijk zijn er ook classes die geen relatie hebben tot movieClip, voorbeeldje : DataSources....arrays....whatever, en zo nog veel meer.
Maar zelfs als je een class hebt 'gebind' aan een movieclip, dan nog kan je deze instantieren met new, met dat verschil, dat er dan geen movieclip bijkomt/aanhangt. Het belang van het gebruik van attachMovie is dan ook dat als je dit gebruikt ism registerclass, deze dus eigenlijk een movieclip van die 'subclass' instantiert. Als je met 'new ..(); instantiert, instantier je een subclass van movieclip, zonder de movieclip.
Conclusie: attachMovieClip hoeft alleen gebruikt te worden als je een een subClass van MovieClip gaat instantieren.
Overigens hoef je hier geen attachMovieClip voor te gebruiken. Ook movieclips die je in de flash ide op de stage hebt gesleept, worden geinstantiert met de constructor van de desbetreffende class.
Punt 2
Ok, eigenlijk gaat het hier om de kern van je vraag.
Wat ik ervan begrijp, is dat je een class wil bouwen die randomjpg's inlaad. Hiervoor zijn in OOP verschillende methodes, op basis van welk perspectief jij erop hebt. Wat je in het oog moet houden is dat OOP een meer abstracte/conceptuele manier van programmeren is.
Het gaat dus niet zozeer om wat je typed, maar in welke structuur je je applicatie gaat opzetten.
Ik denk dat het probleem hier meer in de bedachte structuur ligt, dan in de code nl:
Wat je nu voorstelt is dat je lege movieclip's wil binden aan een class...op zich leuk idee, wat owen ook laat zien zijn post, met de info van VMC's van dave yang. Op zich is het ook helemaal geen gek idee.
Je moet je je alleen gaan bedenken waarom je dit zou willen. Als je een enkele (wel of niet lege) mc in je library hebt, wat is daar op tegen? De code om VMC's te kunnen gebruiken is groter in bytes, dan die ene lege mc....die mc zou overigens niet leeg moeten zijn.
Dit omdat je in flashmx dankzij de toegevoegde tools als registerclass ook lekker makkelijk kan organiseren. Je zet nl je constructor en methods in het eerste frame van de betreffende movieclip tussen de initclip en endinitclip cmd's.
Nu heb je een mc die echt een class representeert, zowel voor het gevoel, als in de 'echte' wereld.
In de toepassing die jij nu kiest zou ik dan ook voor de door flashmx aangeboden methode kiezen. Dus gewoon de class defineeren op het eerste frame van de movieclip met initclip.
Waar je ook voor kan kiezen, en wat meer benadert waar jij het over hebt is een class bouwen die inderdaad lege mc's aanmaakt en deze vult met een jpg.
Maar dan hoef je ook geen classes meer te binden aan mc's; je krijgt dan een soort randomImageMCManager, die al deze mc's managed. Of dat goed in het globale concept OOP past, vraag ik me wel af.
Zoals je dus kan zien aan deze twee oplossingen is het hier belangrijker hoe je omgaat met de relaties tussen de objecten.
Ik hoop dat dit nog een beetje te behappen was.
Punt 3
Reyer liet een stukje code zien, waar hij in de constructor methods aan de mc 'binde', dmv this.methodname.
Hoewel het logisch lijkt, is het slimmer om in flash uit te gaan van prototyping.
Dit omdat in de code van reyer in elke instantie van de betreffende class alle methods worden gezet.Dit lijkt onschuldig, maar in de grotere applicaties ga je toch geheugen problemen krijgen. Daarnaast kan je zien dat dit ook een stuk lastiger debuggen is; methods komen alleen naar boven in instanties van een class, en niet in de class zelf. In een nogal lomp uitgelegd principe moet je alleen dat wat individueel is voor de instances in 'this.' zetten. En alles wat dat niet is in het prototype. Let wel, dit was een lompe omschrijving, niet helemaal kloppend.
Als je de methods echter in het prototype van de class zet, 'kijken' alle mc's naar het prototype van 'hun' class; ze gaan allemaal naar 1 centraal punt, en als gevolg daarvan word het geheugen dus efficienter gebruikt. Dan kan je nog steeds per instantie over die prototypes worden heen geschreven, waardoor dat 'individuele' element blijft. Dit brengt een groot aantal voordelen.
Voorbeeldje: zo moet het
niet (reyer, no offence).
Flash ActionScript:
1
2
3
4
5
6
7
8
9
10
| foutClass = function(naam){
this.naam = naam;
this.methodnaam = function(){
trace('test');
}
this.showVariable = function(){
trace(this.naam+' zijn variable is :'+this.variable);
}
this.variable = 10;
} |
Zo zou het wel moeten:
Flash ActionScript:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| goedClass = function(naam){
this.naam = naam;
}
var p = goedClass.prototype;
p.methodnaam = function(){
trace('test');
}
p.showVariable = function(){
trace(this.naam+' zijn variable is :'+this.variable);
}
p.variable = 10;
delete p; |
Hieronder zal ik laten zien hoe dat prototyping nou precies dan in de praktijk in zijn werk gaat, dmv bovenstaande class:
Flash ActionScript:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
| //We maken 2 instanties van de class
myGoedClass_1 = new goedClass('myGoedClass_1');
myGoedClass_2 = new goedClass('myGoedClass_2');
//Van beiden zien we roepen we nu de method showVariable aan:
myGoedClass_1.showVariable();
myGoedClass_2.showVariable();
/*
output die word gegeven is dan:
myGoedClass_1 zijn variable is :10
myGoedClass_2 zijn variable is :10
*/
//Nu 'overrulen' we de prototype voor myGoedClass_1(
//voetnoot; variabelen hoor je nooit direct te accessen, dit doen we nu even zo voor het voorbeeld).
myGoedClass_2.variable = 3;
//Van beiden zien we roepen we nu de method showVariable aan:
myGoedClass_1.showVariable();
myGoedClass_2.showVariable();
/*
output die word gegeven is dan:
myGoedClass_1 zijn variable is :10
myGoedClass_2 zijn variable is :3
*/
//Nu gaan we iets grappigs doen. we gaan het prototype van de class overschrijven:
goedClass.prototype.variable = 'hahaha';
//Van beiden zien we roepen we nu de method showVariable aan:
myGoedClass_1.showVariable();
myGoedClass_2.showVariable();
/*
output die word gegeven is dan:
myGoedClass_1 zijn variable is :hahaha
myGoedClass_2 zijn variable is :3
Aan deze output kunnen we dus zien dat myGoedClass_1 nogsteeds het prototype van de class gebruikt, terwijl
myGoedClass_2 nu een 'individueel' variable heeft.
*/ |
Hier zie je dus al heel duidelijk de kracht van prototyping, combineer dit met een flinke dosis inheritance, super(), en de kracht van constructors (die ook weer hun eigen vars kunen bijhouden, zoals bv. het aantal instances dat er zijn), het var keyword om zgn privates aan te maken, en je hebt een heel krachte tool.
Ik hoop dat dit voor jullie allemaal wat meer heeft duidelijk gemaakt.
Opnieuw, sorry voor het gewijsneus, hoop dat jullie er wat aan hebben.
[Ralph's Little-Big OOP Post End]
[
Voor 4% gewijzigd door
Verwijderd op 10-03-2003 21:09
. Reden: kleine toevoeging. ]
)
