Welchen Sinn haben Konstruktoren?



  • Das Beispiel ist leider totaler Müll. Daher gibts bezüglich dieses Beispiels auch keine gute Aussage.
    Vielleicht nur soviel: Manchmal muß ein Objekt jedesmal nach dem Erzeugen auch initialisiert werden. Dafür kann man einen Konstruktor bauen, dann ist das Initialisieren zwangsweise und kann nie mehr vergessen werden.



  • Artchi schrieb:

    Genau das kommt noch mit hinzu: jede Klasse kann intern anders aussehen. Als Anwender müsste man aber die Interna wissen, um zu wissen, was man in einer Methode sinnvoll übergibt.

    Nein, es gibt keinen guten Grund, warum man für den Aufruf einer Init-Methode mehr wissen benötigen sollte als für den Aufruf eines Konstruktors. Wenn es keine Konstruktoren gäbe, hätte man statt der Konstruktoren entsprechende init-Methoden mit demselben Interface.

    Es gibt, außer dem Aspekt, dass man eine init-Methode vergessen kann, noch einen, der für Konstruktoren spricht. Ein Konstruktor kann in der Initialisierungsliste Member initialisieren, denen man anderweitig keinen Wert zuweisen kann, also Referenzen und konstante Member.



  • Ein weiterer Vorteil besteht darin, dass über Konstruktoren gleich temporäre Objekte erzeugt werden können, ohne dass eine Kopie angestellt werden muss.

    Function(2, MyClass("test", 27, true));
    

    ist schöner und lokaler als

    MyClass Tmp;
    Tmp.Init("test", 27, true);
    Function(2, Tmp);
    

    Man kann andererseits zwar Factory-Funktionen einrichten, die immer gleich Init() aufrufen, allerdings bringt dieses Vorgehen zusätzlichen Aufwand für jede Klasse mit sich und ist unter Umständen ineffizienter.



  • Das Beispiel ist wirklich sinnfrei... sich das ganze im Internet zusammenzusuchen ist für den Lernerfolg eher hinderlich, mir hätte sich der Sinn von Konstruktoren anhand dieses Beispiels jedenfalls auch nicht erschlossen.
    Ein gutes Buch, welches erstmal mit ein wenig Theorie anfängt, um dir das Konzept von OOP ansatzweise zu vermitteln, spart viel Zeit und Kopfschmerzen.
    Wenn dein Englisch gut genug ist, kann ich nur Thinking in C++ empfehlen. Das Buch ist kostenlos online verfügbar und trotzdem besser als so manche Bücher, für die man bares Geld bezahlen muss.



  • der Destruktor ist dem Beispiel auch klasse.

    ne im ernst, hohl such dir ne gut Lernqulle, die ist Murx.



  • Krux schrieb:

    der Destruktor ist dem Beispiel auch klasse.

    Wer den Fahrstuhl anmacht, muß ihn auch wieder ausmachen. Deswegen drücke ich immer außen nochmal den weißen Knopf, wenn ich von ihm weggehe.



  • Typisch C++-Programmierer, alles wollen sie selbst verwalten.



  • Abstraktion fasst die wesentlichen Eigenschaften einer Gruppe von Objekten zusammen, die diese von anderen Objekten unterscheidet. Das Ziel hierbei ist die Schaffung einer Klasse, die alle für die Programmaufgabe wesentlichen Merkmale und Beziehungen abbildet. Klassen abstrahieren Objekte, die ähnliche Eigenschaften und Verhaltensweisen haben. Die Klasse ist somit der zentrale Begriff der objektorientierten Programmierung (OOP).

    Aus Sicht des Softwareentwicklers sind Klassen vor allem auch "Baupläne" für Objekte. Ein Objekt ist umgekehrt die Konkretisierung einer Klasse. Man spricht auch vom Erzeugen einer Instanz der Klasse. Klassen enthalten Member-Funktionen und Member-Variablen. Öffentliche ("public") Member-Funktionen einer Klasse nennt man Methoden. Member-Variablen bezeichnet man als Attribute.

    Der "Bau" der Objekte erfolgt in der Konstruktor-Funktion, kurz Konstruktor genannt. Der Konstruktor trägt in C++ den gleichen Namen wie die Klasse. Die Zerstörung erfolgt in der Destruktor-Funktion, kurz Destruktor, genannt.

    http://www.henkessoft.de/C++/C++ Fortgeschrittene/C++_Fortgeschrittene.htm#2.1._Abstraktion_von_Objekten_f�hrt_zur



  • Erhard Henkes schrieb:

    http://www.henkessoft.de/C++/C++ Fortgeschrittene/C++_Fortgeschrittene.htm#2.1._Abstraktion_von_Objekten_f�hrt_zur

    Ist nicht böse gemeint:
    Aber die Farben... urks.. die Farben.. 😞 Da muss ich erst Drogen nehmen um das zu ertragen :D.
    lg



  • Bashar schrieb:

    Typisch C++-Programmierer, alles wollen sie selbst verwalten.

    😃 👍



  • Aber die Farben... urks.. die Farben..

    Sagen meine Kinder auch, werde ich wohl etwas machen müssen. 😉
    Dieses grelle Türkis sah auf meinem alten Bildschirm blau aus. 😃



  • Erhard Henkes schrieb:

    Aber die Farben... urks.. die Farben..

    Sagen meine Kinder auch, werde ich wohl etwas machen müssen. 😉
    Dieses grelle Türkis sah auf meinem alten Bildschirm blau aus. 😃

    Machs einfach weiss. Damit kann man nicht viel falsch machen.



  • Hi,

    noch 2 "Gründe für Konstruktoren", die mir noch eingefallen sind:
    1.) Sonst klappts weder mit Referenz- noch mit const-Membern und
    2.) Sie unterstützen ein "Ahängigkeits-Design": Ich kann mein Objekt erst dann erzeugen, wenn ich alle notwendigen Voraussetzungen erfüllt (= Werte bestimmt) habe.

    Gruß,

    Simon2.



  • Ich muss jetzt mal ´ne Lanze für die Gegenseite brechen:
    Es kann Situationen geben, wo eine two stage Initialisierung Sinn macht, z.B. wenn es teuer ist, Objekte zu kopieren und der Zugriff auf entsprechende Elemente nicht abzusehen ist (z.B. copy-on-write). Das sind allerdings fortgeschrittene Optimierungen die in einem Einsteigertutorial wohl nichts zu suchen haben.

    Edit:
    Copy-on-write passt jetzt vielleicht nicht ganz so gut hierher...



  • Wurde hier schon der Konstruktoraufruf der Basisklasse im Konstruktor der abgeleiteten Klasse erwähnt? 😃



  • Na hoffentlich nicht.



  • DocShoe schrieb:

    ...Es kann Situationen geben, ...

    Ich denke, das ist klar: Es gibt keine "universelle Programmiertechnik" (außer evtl. dem hiermit vertretenen Grundansatz, dass das Werkzeug optimal zum Problem passen sollte 😉 ).

    Aber die Frage war eben: Welchen Sinn haben Knstruktoren? ... und weniger "Wann sind Konstruktoren nicht sinnvoll?" 😉
    Ist zwar letztlich dieselbe "Straße" aber in der anderen Richtung angeschaut.

    Gruß,

    Simon2.


Anmelden zum Antworten