Grunsätzliche Frage zum Programmdesign mit OOP

[cybercrow]

Hi,
erstmal mus ich sagen, dass ich eigentlich fast nur imperativ programmiert habe, mich also mit OOP oft schwer tue. Jetzt zu meiner konkreten Frage:
Bei OOP erstellt man ja im Normalfall Klassen für die verschiedenen Objekte wodurch die Programmstruktur entsteht. Mit dieser Grundüberlegung habe ich mir immer bei GUI Programmen für jedes Fenster eine Klasse angelegt und dann noch eine Daten-Klasse.
Diese Aufteilung funktioniert bei kleinen Sachen recht gut, aber bei größeren hätte ich manchmal gerne eine feinere Aufteilung.
Ich sage mal als Beispiel, die Funktionen zum lande, speichern und importieren von Daten in einer eigenen Datei zu verwalten, einfach auch für die Übersichtlichkeit beim Programmieren, dass die MainWindow Klasse nicht zu groß wird und bestimmte Sachen etwas gruppiert werden. Aber diese Funktionen stellen ja kein Objekt für sich da.
Bei C würde ich die Funktionen einfach in eine loadsave.c schreiben und die Funktionen load(), save() und import() über die loadsave.h zugänglich machen.
Aber wie mache ich dass, wenn ich mit Klassen arbeite?
Eine loadSave Klasse, mit leerem Konstruktor und Destruktor und von der im Konstruktor der MainWindow Klasse einfach eine Instanz erstellt wird um nachher darüber auf die load, save und import Funktionen zugreifen zu können kommt mir irgendwie komisch vor...

Was meint ihr zu einer solchen Situation, wie würdet ihr das lösen?

[SeeksTheMoon]

Wenn Du OO programmierst, dann musst Du nicht zwangsweise für alles Klassen benutzen.
In C++ könntest Du es einfach so machen wie Du geschrieben hast und benutzt Klassen nur da wo sie die Sache für Dich vereinfachen.
Auch in Java kann man Klassen erstellen von denen man keine Instanzen erzeugen kann/muss, d.h. Klassen die nur Methoden zur Verfügung stellen, das würde dem entsprechen.

Aber natürlich könntest Du auch eine voll funktionsfähige Klasse mit Konstruktor usw. für alles erstellen und deren Methoden oder Operatoren benutzen:
Beispielsweise eine I/O-Klasse wie die aus der C++ Standardbibliothek.
Fertige OO Bibliotheken wie diese sind sogar nahezu immer komplett so durchdesigned, dass sie alles mit Klassen machen.

All diese Sachen könnte man sogar mit funktionaler oder logischer Programmierung machen, als Programmierer hat man fast immer die freie Entscheidung (in gewissem Rahmen). Hauptsache ist, dass man seine Gedanken so umsetzen kann, dass sie von der Maschine ausgeführt werden.

Vielleicht helfen Dir Stichworte wie "Model View Controller" oder [wie sie das bei Java genannt haben, hab ich grad vergessen] für Dein spezielles Problem.
Das ist eine Technik zur Trennung von Benutzerinterface/~interaktion und den Daten um die es geht.

[cybercrow]

Hi SeeksTheMoon,
ich muß mich zur Zeit hauptsächlich mit java und c# herum schlagen.
Ich habe jetzt etwas herumgespielt mit dem was du geschrieben hast.
Ich kann also Klassen erstellen mit static Methoden, auf diese Methoden kann ich dann zugreifen ohne dass ich vorher eine Instanz des Objekts erstellt habe.
Also z.B. (C#):

class Data {
    public static void Load(string filename) { 
        ....
    }    

   public static void Save(string filename) { 
        ....
    }  

   public static void Import(string filename) { 
        ....
    } 
    
    ...

}

und dann kann ich im Programm von jeder Klasse aus jederzeit Data.Load(filename) usw. aufrufen.
Das ist doch ungefähr das was du gemeint hast, oder?

[RogerJFX]

In Java könntest Du jetzt diese Klasse

abstract class

nennen. Eben weil sie nicht instanziert werden kann. Schreibst Du einen Konstruktor dazu, könntest Du sie zwar instanzieren, aber das wäre relativ sinnlos.

Instanzieren macht z.B. Sinn für Kapselungen. Und Kapseln muß man z.B. bei Entitäten, also wenn etwas im Speicher hängen bleiben soll, aber gleichzeitig eindeutig zuzuordnen zu sein hat, oder auch im weiten Feld des Multithreadings. Dann SOLL es ja unter Umständen zwei oder mehr eigenständige Instanzen geben.

Außerdem: wie willst Du denn je eine statische Variable/Methode wieder aus dem Speicher rauskriegen? Wenn man also weiß, daß eine Klasse nur kurzfristig gebraucht wird, und dann nie wieder, dann bloß nix statisches verwenden. Instanzieren, arbeiten lassen und Tschüß! Workhorses hingegen sollten da für immer drinbleiben, alles schön statisch. So ne Instanzierung kostet schließlich Prozessorpower und neuen Speicher.

Cheers,

Roger

[anda_skoa]

Ich sage mal als Beispiel, die Funktionen zum lande, speichern und importieren von Daten in einer eigenen Datei zu verwalten, einfach auch für die Übersichtlichkeit beim Programmieren, dass die MainWindow Klasse nicht zu groß wird und bestimmte Sachen etwas gruppiert werden. Aber diese Funktionen stellen ja kein Objekt für sich da.

Aber vermutlich arbeiten sie mit Objekten, d.h. deine Daten werden ja aus etwas bestehen.

In der Datenklasse des Hauptfensters, sowas wird oft die Dokumentklasse genannt), hättest du zB eine load Methode, die einen Dateinamen bekommt.

In der Methode würdest du wahrscheinlich so Sachen machen wie die Existenz der Datei zu prüfen, ob du sie Lesen darfst, etc., und sie dann Öffnen.
Dann würdest dieses Dateihandle (zb eine Instanz einer generischen File Klasse) an eine neue Instanz deiner Datenobjekte geben.

In etwa so

bool load(string filename)
{
    // check file, return false if it cannot be opened

    MyDataClass myData = new MyDataClass();
    myData.load(file);
}

Es spricht nichts dageben, OOP mäßig, wenn sich Datenobjekte selbst schreiben oder lesen können.

Ciao,
_

[RapidMax]

Um die Aussage anda_skoa zu verfeinern: Mit OOP hast du die Möglichkeit die Daten und das Verhalten zu kapseln. Wenn du nun eine Applikation hast, wird die vermutlich Daten darstellen und/oder manipulieren und sie intern in gewissen Strukturen ablegen (Listen, Bäume oder einfache Records/Structs). Mit OOP Programmierung kannst du diese Datenstrukturen in Klassen ablegen, welche auch wissen, wie sie sich selber speichern und laden können. Je nachdem manipuliert die Anwendung auch nicht direkt die Datenstruktur, sondern benutzt die Methoden der Klassen um bestimmte Operationen durchzuführen. Damit ist es einfach, die GUI von der Logik/Datenstruktur zu trennen. Üblicherweise wird die GUI durch eigene Klassen beschrieben und diese holen sich über ein definiertes Interface die Daten um sie darzustellen und schreibt die geänderten Werte damit zurück. Damit ist es auch einfacher die GUI auszuwechseln, da diese nicht mit der Logik verzahnt ist. (Hier nochmal ein Hinweis auf das Model-View-Controller-Pattern).

Ich möchte nochmal erwähnen, dass es hier kein Patent-Rezept gibt: Schlussendlich hängt es von der Anwendung ab. z.B. um nur zwei Zählerwerte zu laden und anzuzeigen wird niemand eine grössere Klassenhierarchie aufziehen.

Gruss, Andy