Sauberes Design von nested class implementations

Eisflamme

Hi,

ich bombardiere das Forum gerade, sorry.

Aber meine nächste Frage ist die Folgende:
Ich habe eine Klasse, bei der es nur logisch ist, dass diese Subklassen hat. Die Elemente werden nur im Kontext dieser Klasse benötigt. Schlimmer noch, einen scope drüber wären sie vom Namen nicht mehr klar. Klar, ich könnte einen Namespace rumpacken, aber wenn für eine Klasse SomeClass der passendste Name für besagte Unterklasse SomeClassPart (Part sei irgendein Name) wäre, dann ist es doch wohl als nested class am Besten aufgehoben.

Jetzt finde ich es aber unschön, eine cpp-Datei mit all den Implementierungen für alle drei Klassen zu machen. Das ist ja ein Hin- und Hergewurschtel. Und eigentlich sind die Klassen ja drei eigene Klassen, nur stehen sie eben in einer Beziehung, die die nested-ness sinnvoll macht.

Vorschlag: Für jede nested class eine eigene cpp-Datei machen, obwohl nur ein Header da ist und die Datei dann SomeClassPart.cpp nennen?

Oder habt ihr schönere Ideen?

Skym0sh0

Solange die Datei dann nicht zu gross wird, alles rein in einen Header und eine cpp.

knivil

Ich mag keine nested classes. Warum sollen sie veroeffentlicht werden, wenn sie nur fuer die Klasse intern benutzt wird.

volkard

Vielleicht magst Du die innere Klasse erstmal nur Deklarieren.

class SomeClass{
public:
    class Part;
public:
    Part begin();
};

class SomeClass::Part{
public:
    int x;
};

Eisflamme

knivil:
Ich habe ja begründet, wieso ich sie hier sinnvoll finde. Gerne kannst Du darauf eingehen, ich freue mich auf gute Argumente:

Ich habe eine Klasse, bei der es nur logisch ist, dass diese Subklassen hat. Die Elemente werden nur im Kontext dieser Klasse benötigt. Schlimmer noch, einen scope drüber wären sie vom Namen nicht mehr klar. Klar, ich könnte einen Namespace rumpacken, aber wenn für eine Klasse SomeClass der passendste Name für besagte Unterklasse SomeClassPart (Part sei irgendein Name) wäre, dann ist es doch wohl als nested class am Besten aufgehoben.

Skym0sh0:
Ist richtig, aber leider wird sie groß (jedenfalls zu groß, aber auch wenn nicht, fände ich die Trennung sauberer).

volkard:
Die Syntax kannte ich nicht, das gefällt mir schon Mal. Dann würde ich die Definition jeweils in eine Header-Datei packen und dazu die entsprechende Quellcodedatei. Benennen würde ich die Dateien dann trotzdem SomeClassPart.h/cpp? Oder würdest Du dennoch alles in einen Header packen?

Skym0sh0

Eisflamme schrieb:

Skym0sh0:
Ist richtig, aber leider wird sie groß (jedenfalls zu groß, aber auch wenn nicht, fände ich die Trennung sauberer).

Naja, klar das stimmt schon irgendwo. Aber willst du für jede kleine Klasse immer eine neue Übersetzungseinheit?

Du kommst dann irgendwann an den Punkt, wo du 50-60 Dateien hast, die alle aber nur 20-50 Zeilen haben.

Eisflamme

Finde ich nicht schlimm. Klassen wachsen einfach gerne und wenn es Sinn macht aus den Dingern eigene Klassen zu machen können sie so klein sein, wie sie wollen. Solange sich ÜE nicht ändern, steigt ja auch nicht die Kompilierzeit an (außer die hängen von vielen Headern ab). Und der Überblick ist auch nicht geschädigt, dafür muss man dann evtl. namespaces einführen. Und in MSVC lege ich Filter an.

Skym0sh0

Beispiel std::vector

In der Standardbibliothek vom MSVC11 steht alles in einer Datei, inklusive beiden Iteratoren

Aber ja, du hast Recht. Grundsätzlich ist die saubere Trennung schöner und besser erweiterbar (anstatt ab einem gewissen Punkt eine ganze gewachsene Klasse zu emigrieren).

knivil

Ich habe eine Klasse, bei der es nur logisch ist, dass diese Subklassen hat.

Das ist keine Begruendung oder Logik, das ist nur dein Bauchgefuehl. Mein Bauchgefuel ist anders.

Du kommst dann irgendwann an den Punkt, wo du 50-60 Dateien hast, die alle aber nur 20-50 Zeilen haben.

In der Regel ist das kein Problem. Und std::vector aus der Standardbibliothek unterliegt keinen weiteren Aenderungen.

Da innere Klassen nichts besonderes sind, koennen sie auch nebeneinander in einem namespace existieren, anstatt ineinander. Enthalten Klassen innere Klassen, so geht Uebersichtlichkeit beim Lesen von Klassendefinitionen, da man sich erst durch den ganzen Muell von Klassen graben muss, die das Interface nicht betreffen.

volkard

Eisflamme schrieb:

Benennen würde ich die Dateien dann trotzdem SomeClassPart.h/cpp?

Ich würde lieber SomeClass_Part.h, um den :: in den Datenamen zu tun, aber Geschmachssache.

Eisflamme schrieb:

Oder würdest Du dennoch alles in einen Header packen?

Jo, ich hab nur ganz selten innere Klassen und die sind dann auch so dumm, daß sie innere structs nur sind, wie List::Node.