4. Anfänger-Verständnis-Frage: [saubere Programmierung] Dialogklasse als Member oder lokale Variable oder ganz anders?

Anfänger-Verständnis-Frage: [saubere Programmierung] Dialogklasse als Member oder lokale Variable oder ganz anders?

  • D

    Hallo allerseits!

    Ich habe ein Frage zu folgender Situation:

    Von einem Auswahldialog aus können mehrere andere Dialoge geöffnet werden.

    Meine Frage dabei ist:
    Wie legt man dabei sinnvollerweise die Instanzen der Dialogklassen an?

    Mein erster Ansatz war:
    Je eine Instanz der verschiedenen weitergehenden Dialoge als Membervariablen im Auswahldialog:

    //CAuswahlDlg.h
class CAuswahlDlg
{
public:
    CDialog0 m_dialog0; 
public:
    CDialog1 m_dialog1;
public:
    CDialog2 m_dialog2;
....
public:
    BOOL m_radiobutton_auswahl;
}
//CAuswahlDlg.cpp
...
if (m_radiobutton_auswahl == 0) 
    if (m_dialog0.DoModal() == IDOK) {....}
if (m_radiobutton_auswahl == 1) 
    if (m_dialog1.DoModal() == IDOK) {....}
if (m_radiobutton_auswahl == 2) 
    if (m_dialog2.DoModal() == IDOK) {....}
....

    Nach etwas Überlegen vermutete ich darin allerdings etwas verschwenderisches Verhalten:
    Sehe ich das richtig, dass beim Anlegen des Auswahldialogs auch gleichzeitig Instanzen von allen Dialogen mitsamt ihren enthaltenen Variablen angelegt werden? (Also insbesondere das Speicherplatz für das alles reserviert wird?)
    [Das wäre im Übrigen besonders verschwenderisch, da in allen Dialogklassen eine Instanz einer gemeinsamen weiteren Klasse angelegt wird, die wiederrum recht viele Variablen enthät, dann würden ja womöglich mehrere Instanzen dieser gemeinsamen Klasse erzeugt werden, obwohl immer nur eine benötigt wird.]

    Daher überlegte ich mir alternativ den zweiten Ansatz:
    Instanzen der Dialogklassen als lokale Variablen innerhalb der if-Bedingungen:

    //CAuswahlDlg.h
class CAuswahlDlg
{

....
public:
    BOOL m_radiobutton_auswahl;
}
//CAuswahlDlg.cpp
...
if (m_radiobutton_auswahl == 0) 
{
    CDialog0 dialog0;
    if (dialog0.DoModal() == IDOK) {....}
}
if (m_radiobutton_auswahl == 1) 
{
    CDialog1 dialog1;
    if (dialog1.DoModal() == IDOK) {....}
}
if (m_radiobutton_auswahl == 2) 
{
    CDialog2 dialog2;
    if (dialog2.DoModal() == IDOK) {....}
}
....

    Sehe ich das richtig, dass jetzt je nur eine Dialoginstanz dialogX (X=0,1,2,...) angelegt wird?
    Ist der zweite Ansatz somit "sauberer" als der erste?
    Gibt es noch eine bessere Möglichkeit?

    Danke und Gruß,
    dong

    0
  • E

    Ich finde den zweiten besser (solange es modale Dialoge sind).

    0
  • D

    estartu schrieb:

    Ich finde den zweiten besser (solange es modale Dialoge sind).

    Danke schön, sind ja modale Dialoge.
    Bisher hatte ich hauptsächlich Erfahrung mit Turbo Pascal, da erschein es mir eben ungewohnt, dass man an allen möglichen Stellen Variablen erzeugen kann. 🙂

    0
  • E

    Ja, aber wenn man sich daran gewöhnt hat, ist es schön übersichtlich. 👍
    Ich komme auch aus der TP-Ecke (ist aber schon 7 Jahre her). 🙂

    0
  • A

    dong schrieb:

    Danke schön, sind ja modale Dialoge.
    Bisher hatte ich hauptsächlich Erfahrung mit Turbo Pascal, da erschein es mir eben ungewohnt, dass man an allen möglichen Stellen Variablen erzeugen kann. 🙂

    Ja aber das geht doch in TP auch (bei mir sind das auch 7 Jahre), da nimmt sich das nichts im Vergleich zu C.
    Im übrigen finde ich Variante 2 auch besser, erzeuge nur Instanzen wenn Du sie brauchst.

    0
  • E

    AndyDD schrieb:

    Ja aber das geht doch in TP auch (bei mir sind das auch 7 Jahre), da nimmt sich das nichts im Vergleich zu C.

    Ähm, imho geht das erst ab C++.
    In C und TP muss man die Variablen am Anfang bzw. VOR dem Hauptprogramm deklarieren.
    Da gabs doch nen extra Block dafür. 😕

    0
  • A

    Stimmt, ist ja wirklich lange her. So ist man schon an c++ gewöhnt. Klar Du hattest ja vorher einen VAR-Teil und vorher einen USES-Teil. Tja, ich bin da schon zu lange raus, obwohl ich mich dunkel erinnere vor zwei Jahren nochmal ein Maschinensteuerprogramm umgeschrieben zu haben. Das war auch Pascal, dann sogar mit Turbo Vison 2.0 😃

    0
  • *

    Der 1. geht schon garnet klar weil da allse public Variablen sind 😉 dafür macht man setter und getter

    0
  • D

    (D)Evil schrieb:

    Der 1. geht schon garnet klar weil da allse public Variablen sind 😉

    Ja, vielleicht nicht ganz sauber, aber außer mir programmiert ja niemand an meinem Programm rum, daher ist es glaub ich egal... 🙂

    (D)Evil schrieb:

    dafür macht man setter und getter

    ??? Ich kenne zwar die typischen p->GetBla() und p->SetBla(x) Funktionen, weiß aber nicht, was sie hier sollen...

    0
  • E

    dong schrieb:

    (D)Evil schrieb:

    Der 1. geht schon garnet klar weil da allse public Variablen sind 😉

    Ja, vielleicht nicht ganz sauber, aber außer mir programmiert ja niemand an meinem Programm rum, daher ist es glaub ich egal... 🙂

    Jein. Wenn du dir sowas erstmal angewöhnt hast, isses schwer das wieder loszuwerden. 😉

    (D)Evil schrieb:

    dafür macht man setter und getter

    ??? Ich kenne zwar die typischen p->GetBla() und p->SetBla(x) Funktionen, weiß aber nicht, was sie hier sollen...

    Der Form halber halt - später ergibt sich da evtl noch was.
    ABER: Du verwendest die Variablen ja nur in DER Klasse, also brauchst du keine Get/Set, weils ja nicht von außen zugänglich sein muss. ⚠

    0
  • C

    Standpunktfrage, ich kenne da jemanden 😉 der verwendet prinzipiell auch private Getter und Setter. Halte ich auch für unnütz, aber was sagt ihr dazu?

    0
  • Administrator

    connan schrieb:

    Standpunktfrage, ich kenne da jemanden 😉 der verwendet prinzipiell auch private Getter und Setter. Halte ich auch für unnütz, aber was sagt ihr dazu?

    Also reine Getter und Setter im Sinne von:

    class X
{
    // ...
private:
    int m_nInt;

private:
    void SetInt(int nInt) { m_nInt = nInt; };
    int GetInt() const { return m_nInt; };
}

    Halte ich ehrlich gesagt für unnötig in der Klasse selber auch noch zu nutzen. Vor allem, da ich bei Member-Variablen das m_ davor nehme, ist es wohl klar. Zudem kann man so direkt auch die Member-Variablen verwenden und musst nicht noch irgendwelche Kopien erstellen oder sowas.

    Bei nicht reinen Setter und Getter kann ich es allerdings gut verstehen. Allerdings ist es da auch ein wenig was anderes. Die sind eben unrein. Zum Beispiel:

    class X
{
    // ...
private:
    int m_nInt;
    int m_nGot;
    int m_nSet;

private:
    void SetInt(int nInt) { m_nInt = nInt; ++m_nSet; };
    int GetInt() { return m_nInt; ++m_nGot; };
}

    Blödes Beispiel, aber ist eins ^^

    @connan, mit welcher Begründung benutzt denn derjenige private Getter und Setter?

    Grüssli

    0
  • C

    Dort gehts glaube ich, ums Prinzip. Ist eine Firma mit mehreren, wechselnden Mitarbeitern und man legt sich die Restriktion auf, nie direkt auf Variablen zuzugreifen. Ist vieleicht sogar doch sinnvoll, wir haben jedenfalls schon viele Stunden darüber gestritten... Deine Bsp. bringen jedenfalls neue Argumente für IHN 😉 aber beim G(S)etter noch irgendeine zusätzliche Funktion einzubinden finde ich auch schon kritisch.

    btw. man sollte halt konsequent 'const' nutzen 🙄

    0
  • T

    Bei den Zusatzfunktionen gehts doch um Redundanz, weil du dann jedesmal im Source schreiben musst,

    m_nInt = 4;
++m_nSet;
//statt
SetInt( 4 );

    und wenn Du das ändern willst, hast Du nur eine Stelle zu bearbeiten, und nicht bei allen Aufrufen noch.

    0
  • C

    Na klar, gibts Argumente dass so zu machen. Vieleicht sollte man abwägen, was öfters vorkommt, bei mir ist es jedenfalls höchst selten, dass ein G(S)etter noch zusätzlich eine Änderung vornimmt, noch dazu, wenn er privat ist. Aber man muss sich wohl entscheiden, entweder man macht es konsequent oder man verzichtet auf solche Konstrukte. Sich zu merken, für welche privates man den G(S)etter benutzen muss und für welche nicht, halte ich für schwierig.

    0
Anmelden zum Antworten