Ich hatte vor einiger Zeit Mal mit einem Vorgesetzten eine kleine Diskussion über ctors. Ich wusste nicht mehr, um welche Klasse es ging, aber er hielt es für besser, eine statische Methode bereitzustellen, welchen ein Objekt der Klasse erstellt anstatt direkt einen ctor anzubieten. Der ctor selbst sollte also privatisiert werden. Er begründete das damit, dass man bei einer statischen Methode mit Parametern besser angeben kann, woher das Objekt kommt, ob es z.B. aus einer Datei geladen wird, aus bestimmten Ressourcen logisch hergeleitet wird etc., wobei diese Information bei einem ctor fehlt - der kann alles machen.

Ich habe das jetzt Mal für eine 3D-Modellklasse "Model" bei mir umgesetzt. Jetzt erbt eine andere Klasse "ViewedModel" davon. Die Frage ergibt sich jetzt für mich, wie ich den Model-Teil der ViewedModel instanziiere. Da der ctor von Model privat ist, muss ich ja über LoadModel gehen, aber ich muss ja trotzdem zunächst das Objekt selbst erstellen, also muss der ctor von Model ja protected sein.

D.h. dass ich den Model-ctor protected machen muss, auch wenn er nur leer ist, oder?

Frage: Ist das jetzt stilistisch einwandfrei, quasi immer bei Klassen, welche eine statische Methode zum Objekterzeugen anbieten, einen protected leeren ctor anzulegen oder ist das ganze System mit den statischen Erzeuger-Methoden bescheuert? Tue mich mit so etwas immer schwer und gebe in Diskussionen ziemlich früh auf, weil mir die Hintergründe und Argumente einfach fehlen.

Edit hat auch noch eine Frage: Die Instanziierung in der abgeleiteten Klasse durch die statische Methode ist dann ja auch etwas seltsam. Ich erstelle mir ein lokales Objekt der abgeleitet Klasse, was ja dank dem protected ctor jetzt klappt, auch wenn der nichts macht. Um aber das aufzurufen, was die Basisklasse im ctor eigentlich machen sollte, muss ich ja quasi auch deren statische Methode aufrufen... was natürlich blödsinnig ist, weil das falsche Objekt zurückkommt. Also müsste ich quasi eine protected Methode in der Basisklasse aufrufen, die das eigentliche übernimmt, oder?

Zu verworren, hier Pseudocode:

class A
{
protected:
	A() {}
public:
	static A* LoadA() {A* newA = new A(); /* Lade irgendwas */ return newA;}
};

class B : public A
{
protected:
	B() {}
public:
	static B* LoadB()
	{
		B* newB = new B();

		// Wie den A-Teil laden?

		return newB;
	}
};

und mein Lösungsvorschlag, bei dem mir die statischen Methoden aber noch unsympathischer werden:

class A
{
protected:
	A() {}

	void loadA()
	{
		// Mach irgendwas
	}
public:
	static A* LoadA()
	{
		A* newA = new A();
		newA->loadA();

		return newA;
	}
};

class B : public A
{
protected:
	B() {}
public:
	static B* LoadB()
	{
		B* newB = new B();
		newB->loadA();

		return newB;
	}
};

Konsequenter müsste man eigentlich in Klasse B auch noch eine protected loadB() erstellen, falls eine Klasse C von B erben möchte. LoadB() sollte dann auch loadB() statt loadA() benutzen... Dann hat man immer den Aufbau: LoadX() erstellt neues Objekt, ruft deren loadX() auf und gibt Objekt zurück. loadX() ruft übergeordnetes loadX() auf und macht irgendwas.

Wirkt trotzdem umständlich.

So simple Kleinigkeiten, die einen ins Nachdenken bringen... wie löst ihr so was geschickt?

Edit: Noch einige Fehler korrigiert.

Und bzgl. deines Code: wo ist jetzt die statische Methode?
Deine bisherigen Load-Methoden machen absolut keinen Sinn (und daran sieht man auch, daß ein guter Konstruktor entscheidend für ein Klassendesign ist).
Bei Erzeugung deiner A bzw. B-Objekte würden diese ja lokal auf dem Stack erzeugt und dann als Kopie(!) zurückgegeben (d.h. es müßte mindestens noch ein öffentlicher Kopierkonstruktor existieren - und nicht alle Klassen sind per Design kopierfähig).

Also vergiß diesen Ansatz und erstelle ein vernünftiges Klassendesign mit sinnvollen öffentlichen (public) Konstruktoren.

Okay, da waren ein paar Fehler drin. Die Methoden sollten statisch sein und ein neues Zeigerobjekt erstellen, letzteres war mein Fehlerchen, bin gerade etwas raus.

Es ging auch in der Diskussion nicht um C++, sondern um ne andere Programmiersprache, darf man das so übergreifend betrachten oder muss ich das für C++, Java und was es noch so gibt getrennt betrachten? Was sind denn an solchen statischen Methoden die Nachteile bzw. wie kann ich da gegenargumentieren, wenn er mit den gleichen Argumenten kommt? Sonst steh ich wieder da und muss in ne Richtung programmieren, die ich nicht sauber finde.
Laut Wiki bieten das Factory-Pattern ja durchaus den Vorteil, dass es mehrere Konstruktoren mit aussagekräftigerem Namen als dem Klassennamen geben kann. Zwar treffen die anderen Vorteile in dieser Variante nicht zu, doch bleibt der Vorteil. Wenn das Gegenargument ist, dass die Vererbung damit umständlich und verworren wird (s. Beispiel), könnte man für die Methode argumentieren, wenn Vererbung nicht vorgewesen ist/keinen Sinn ergibt.

Und findest Du, das Argument, statische Methoden zum Erstellen von Objekten zu verwenden, hält dann nicht? Du hast schon Recht, das geht in die Richtung von Factory-Klassen, nur ist die Factory hier irgendwie in der Klasse selbst. Bin auch nicht wirklich vertraut mit dem Pattern...

Okay, da waren ein paar Fehler drin. Die Methoden sollten statisch sein und ein neues Zeigerobjekt erstellen, letzteres war mein Fehlerchen, bin gerade etwas raus.

Das wäre meiner Ansich nach schon der größte Schwachpunkt. Ein C++-Programmierer versucht in der Regel rohe Zeiger zu vermeiden, wenn sie nicht notwendig sind. Und new und delete sowieso. Beides erfordert viel Aufmerksamkeit; memory leaks sind da nur eins von vielen potenziellen Problemen.

Es ging auch in der Diskussion nicht um C++, sondern um ne andere Programmiersprache, darf man das so übergreifend betrachten oder muss ich das für C++, Java und was es noch so gibt getrennt betrachten?

Natürlich getrennt. In Java ist z. B. new obligatorisch, in C++ vermeidet man es wo es geht und arbeitet mit Stackobjekten.

Hier geht es konkret um C++, mit Zeigern und ohne GC und so. Fragen zu Java oder anderen Programmiersprachen sind hier falsch, dafür gibts andere Unterforen. Dort würdest du vermutlich hilfreichere Antworten bekommen.

Zu Java gibts auch andere Foren, mit mehr Leuten die sich damit auskennen. Zum Beispiel unter www.javacore.de

Also eigentlich geht es mir halt darum, so eine gewisse Schnittmenge zu finden, worauf ich dann aufbauen kann, um mir Dinge selbst logisch herzuleiten.

Was bedeuten Stilfragen eigentlich? Ist das einfach nur, um die Erweiterbarkeit, Wartbarkeit, Lesbarkeit und Fehlerlosigkeit zu verbessern? Und reicht es in konkreten Bereichen einfach zu probieren, zu coden, nachher zu merken, dass es schlecht war und es anders zu machen? Ich meine, wie kann ich denn ein guter C++-Programmierer werden? Einfach nur coden reicht nicht. Ein paar Pattern kennen und boost anwenden auch nicht. Beides zusammen erscheint mir auch zu wenig. Hat da jemand Tipps, wie ich möglichst gut und schnell mein Wissen verbessern kann?

Ich arbeite eigentlich an einem speziellen Projekt, habe aber dafür sehr viel Zeit und würde halt gerne meine Fähigkeiten um ein Vielfaches verbessern, weil ich halt der totale n00b bin, auch wenn ich die Bereiche von C++ an sich kenne, OOP eigentlich auch verstehe/kann, aber halt noch zu wenig von den Feinheiten weiß und kein guter Architekt bin.

Geht jetzt über den Thread heraus. Hat trotzdem jemand Tipps?