Designfragen zu Klassen

DasPinsch

Hi!

Wollte mal fragen ob so eine klasse vom Aufbau her sinvoll ist:

class Klasse
{
    data *daten;
    bool loaded;

    public:
        Klasse();
        Klasse(std::string pfad);

        bool load(std::string pfad);

        ~Klasse();
}

Klasse::Klasse() 
{
    loaded=false;
}

Klasse::Klasse(std::string pfad)
{
    loaded=false;
    load(pfad);
}

bool Klasse::load(std::string pfad)
{
    if(loaded)
        return false;

    //öffne Datei, speichere sachen in "daten", etc, pp
    loaded=true;
}

Klasse::~Klasse()
{
     if(!loaded)
         return;

     //gib daten wieder frei
}

Und meine 2. Frage: sind private Funktionen ein schlechter Programmierstil?

Marc++us

zu 1)

Das ist kein guter Stil, denn wenn das Laden scheitert, so existiert Dein Objekt eigentlich nicht - Du mußt im Grund bereits den Konstruktor abbrechen, weil eine Konstruktion des Objekts nicht möglich ist. Die gegebene Lösung wäre hier, eine Exception im Ktor zu werfen statt mit einem Flag überall sämtliche Operationen zu verriegeln.

zu 2)

Nein. Sie sind sogar guter Stil - denn Du hast in einer Klasse immer wieder gleiche Vorgänge, die in einer Funktion zusammengefasst werden sollten (um Code nur einmal zu schreiben). Nicht jede dieser Funktionen ist aber sinnvoll von außen (public) ausführbar, weswegen sie also private sein sollten.

DasPinsch

Marc++us schrieb:

zu 1)

Das ist kein guter Stil, denn wenn das Laden scheitert, so existiert Dein Objekt eigentlich nicht - Du mußt im Grund bereits den Konstruktor abbrechen, weil eine Konstruktion des Objekts nicht möglich ist. Die gegebene Lösung wäre hier, eine Exception im Ktor zu werfen statt mit einem Flag überall sämtliche Operationen zu verriegeln.

und wie verhindert man dann, dass mehrfach geladen wird (und ein memory leak entsteht)? Oder soll man annehmen, dass diejenigen, die die klasse benutzen so das nicht machen?

MfG DasPinsch

Marc++us

Mehrfaches Laden und Memory Leaks, das geht bei mir nicht ganz zusammen?

Mehrfaches Laden kannst Du durch das Klassendesign verhindern - d.h. es gibt nur eine Ktor der lädt, aber die load-Methode ist nicht public. Demnach kann man das Objekt nur aus einer Datei heraus erzeugen, aber nicht mehr nachladen und das Objekt auch sonst nicht "ungeladen" erzeugen.
Memory Leaks durch Mehrfachladen verhinderst Du dadurch, daß die load-Methode richtig programmiert ist - d.h. sie muß eventuell notwendige Aufräumarbeiten selbst durchführen, bevor sie zuschlägt und andere Daten lädt. Das ist Aufgabe der Lade-Arbeiten.

DasPinsch

Marc++us schrieb:

Mehrfaches Laden und Memory Leaks, das geht bei mir nicht ganz zusammen?

naja, indem man zB. durch int *p; p=new int[50]; speicher reserviert, und dann nochmal mit zB. p=new int[200]; speicher reserviert.
Wenn man nun mit delete[] p; den speicher freigibt, wird doch nur der zuletzt reservierte speicher freigegeben (und es entsteht ein memory leak), oder habe ich da was falsch verstanden?

davie

das ist wahr, aber was hat das mit deiner klasse zu tun?

DasPinsch

Marc++us schrieb:

Mehrfaches Laden und Memory Leaks, das geht bei mir nicht ganz zusammen?

Mehrfaches Laden kannst Du durch das Klassendesign verhindern - d.h. es gibt nur eine Ktor der lädt, aber die load-Methode ist nicht public. Demnach kann man das Objekt nur aus einer Datei heraus erzeugen, aber nicht mehr nachladen und das Objekt auch sonst nicht "ungeladen" erzeugen.

Memory Leaks durch Mehrfachladen verhinderst Du dadurch, daß die load-Methode richtig programmiert ist - d.h. sie muß eventuell notwendige Aufräumarbeiten selbst durchführen, bevor sie zuschlägt und andere Daten lädt. Das ist Aufgabe der Lade-Arbeiten.

was ist denn die bessere methode? nur durch KTor laden können oder Lade-Funktion so schreiben, dass sie Aufräumarbeiten (falls nötig) selbst durchführt? oder hängt das mit dem verwendungszweck zusammen?

MfG DasPinsch

DasPinsch

davie schrieb:

das ist wahr, aber was hat das mit deiner klasse zu tun?

wenn speicher in der load-Funktion reserviert und nur im Destruktor freigegeben wird?!

Marc++us

Aber dann ist Dein Load falsch programmiert - es muß eben vorher auch noch alten Speicher freigeben, bevor es weiteren allokiert.