01. november 2002 - 13:10Der er
5 kommentarer og 1 løsning
Klasse struktur
Jeg skal igang med et rimligt stort system med mange klasser. Så for at komme rigtig i gang ville jeg lige have slået nogle ting fast.
I Builder: Er der rigtigt når jeg siger at Builders klasser kun bruges som interface til de andre klasser som jeg opretter PersonKlasse, MaskinKlasse, OrdreKlasse
Altså i TForm1 Opretter man ikke diverse ting som Ordrenavn, fornavn og efternavn.
Dvs at de forskellige Form's bruges som en slags main hvor der oprettes objekter af de andre klasser
Jeg ville ikke sige at "Builders klasser kun bruges som interface", men måske lidt mere præcist, at de autogenererede klasser er high level kode bag det grafiske interface...?
Der er jo mange typer af interfaces, fx anvendes interfaces konstant i COM og Java. Her betyder ordet dog noget helt andet, så du skal være forsigtig!
Hvordan du designer dit program, er naturligvis op til dig, men et robust design vil typisk medføre at du kan udskifte viewet, uden at ændre noget i datamodellen.
>> Dvs at de forskellige Form's bruges som en slags main hvor der oprettes >> objekter af de andre klasser
Der er kun en main !!. Men ja det ville være smart hvis du IKKE ligger din funtionalitet vedrørende PersonKlasse, MaskinKlasse, OrdreKlasse i din TForm klasse, men ligger det ud i en seperat struktur.
Nej, de skal skelne mellem klasser som (primært) har noget med GUI'et (dvs. forms og alt det andet synlige som brugeren kan se), og de klasser som du gemmer dine data i.
I MVC (Model View Control eller 3-tiered applications) er førstnævnte normalt det man kalder VIEW, sidstnævnte det man kalder MODEL og de metoder der binder de to ting sammen CONTROL - som man godt kunne sammenligne med Interfaces på den måde disse fungerer i f.eks. JAVA.
Som jpk skriver er det vigtigste i dit design af klasser, at du forsøger at holde VIEW præsentationen (dvs. visning på en form) adskildt fra den måde du gemmer tingene på i dine MODEL klasser. Typisk klarer man dette ved at lave de faktiske dataværdier i klasserne PRIVATE, og så lave PUBLIC getters og setters. (Helt analogt til _property i BCB.) Lad mig give dig et lille kort eksempel:
class TmyForm : TForm { // Alt det som er på formen. };
Forskellen er synlig når du bruger dataene fra din MODEL klasse:
: myClass *pMyClass = new myClass(this); Edit1->Text = pMyClass->getText(); :
i stedet for:
: Edit1->Text = pMyClass->aText; :
Ved at pakke de reelle data ind i en wrapper (interfacet) bliver det muligt at ændre på både navne og repræsentation (f.eks. ændring fra String til char[]) UDEN at VIEW koden skal ændres.
Det din "main" kode (her regner jeg med at du mener den kode som ligger i constructoren til din "main" form) evt. gør i fht. dine MODEL klasser, er at instantiere dem - dvs. lave de nødvendige new ... (som ovenfor) for at der kommer til at eksistere en variabel af den pågældende type OG at den bliver slettet igen, når programmet lukker ned.
I en fuldstændig implementering af Model-view-Control, vil man laver en wrapper klasse imellem VIEW og MODEL, med en veldefineret snitflade (interface), og så lade de to klasser snakke sammen via den. Du kan i den sammenhæng betragte CONTROL som statiske, globale metoder der eksisterer i hele programmet køretid - uanhængigt af hvilken forms (VIEW) og MODEL klasser som er aktive/i brug på det pågældende tidspunkt. Ovenstående kode ville så f.eks. være:
class myControl { private: TMyForm *myForm; myClass *myModel; public: String getModelNumber(void) { if (myModel != NULL) return myModel->getText(); else return ""; }; // Og tilsvarende for de andre "interfaces" i MODEL og VIEW. };
: Edit1->Text = myControl->getModelText(); :
På denne måde kender TForm overhovedet ikke til MODEL, og MODEL overhovedet ikke til VIEW.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.