Stimmt es eigentlich, dass die Verwendung eines Objektes nur dann Sinn macht, wenn die zugehörige Klasse mehrfach (min. 2x) instanziiert wird? Somit haben unterschiedliche Codeblöcke ein eigenes Objekt der Klasse und können somit zur Laufzeit ein Unikat der Klasse als Objekt erzeugen und die Methoden und Membervariablen dynamisch verwenden?

Denn würde von einer Klasse im gesammten Code nur eine einzige Instanziierung stattfinden, könnte man die Klasse, bzw. die Methoden und Membervariablen, doch auch gleich statisch deklarieren. Verstehe ich den Sinn von der statischen und dynamischen nutzung von Klassen und Objekten richtig? Falls nein, bitte ich um genaue Erläuterung, warum und vor allem wann, man ein Objekt nutzt und wann die Klasse selbst. Abstrakte Klassen sind hierbei ausgeschlossen, da sie der Polymorphie dienen und der Hintergrund ein anderer ist.

Stimmt es eigentlich, dass die Verwendung eines Objektes nur dann Sinn macht, wenn die zugehörige Klasse mehrfach (min. 2x) instanziiert wird?

Nein.
Ob es in einem Programm nur ein Objekt einer Klasse gibt, oder ob es generell nur Sinn macht in einem Programm genau ein Objekt einer Klasse zu haben, sind zwei völlig unterschiedliche Dinge.

Nehmen wir also mal den zweiten Fall, ein Programm kann sinnvollerweise immer nur ein Objekt einer Klasse besitzen. (Dass man beim ersten Fall Klassen nimmt sollte wohl klar sein.) Aber auch dann gibt es einen Unterschied - Klassen können nämlich Kon- und Destruktoren haben.
Dafür gibt es übrigens ein Pattern (bzw. mehrere Ansätze für dieses Pattern), genannt Singleton.

Aber eine Klasse die keine nichtstatischen Membervariablen* hat macht natürlich keinen Sinn, das ist eher Missbrauch von Klassen für Namespaces.

* + Keine virtuellen Funktionen, Konstruktoren oder Destruktoren.

Konst- und Destruktoren

Kon- und Destruktoren würde ich mal vorschlagen. Ich hab mich zuerst gefragt was da const sein soll.

cooky451 schrieb:

Konst- und Destruktoren

Kon- und Destruktoren würde ich mal vorschlagen. Ich hab mich zuerst gefragt was da const sein soll.

Tatsache. Ist verbessert.

Ich finde leider den Rest nicht ganz aufschlussreich. Du meinst also, dass eine Verwendung als Objekt wegen der Verfügbarkeit von Konstruktor und Destruktor Sinn macht, ja? Was genau wäre hier denn der Vorteil? Ich schrieb in meinem Beispiel ja von Unikat, was in etwa das beschreiben sollte. Mit einem Unikat der Klasse, also ein Objekt, kann man damit dynamisch Arbeiten. Änderungen am Objekt sind dann voneinander unabhängig, anderst bei der Verwendung von der Klasse selbst, also statisch in dem Sinne. Daher verstehe ich das nicht so ganz, solltest Du das anderst gemeint haben.

Aber eine Klasse die keine nichtstatischen Membervariablen* hat macht natürlich keinen Sinn, das ist eher Missbrauch von Klassen für Namespaces.

Du meinst wenn alle Membervariablen einer Klasse static deklariert sind? Warum sollte das ein Missbrauch einer Klasse sein? Sicher das es keinen Fall gibt, in dem dieses Szenario in einer Klasse vorkommt?

* + Keine virtuellen Funktionen, Konstruktoren oder Destruktoren.

Das verstehe ich nicht. Wenn eine Klasse keine virtuellen Methoden hat? Meinst Du nicht eher das Gegenteil? Warum ist eine Klasse mit reinen Methoden ein Missbrauch seiner selbst? Und warum setzt Du Konstruktoren und Destruktoren voraus? Es gibt ja auch den Standard Konstruktor und Destruktor. Ich habe viele Klassen, in denen ich weder vom Konstruktor noch Destruktor gebrauch mache. Ist das Deiner Meinung nach nun falsch?

Danke

1. Wann und warum verwendet man Objekte oder die Klasse selbst?
2. Wann nutzt man Objekte auf dem Heap und wann auf dem Stack.
3. Wann sollte eine Methode statisch sein?

Meine eigenen Antworten:

1. Objekte sollten dann verwendet werden, wenn die Methoden und Membervariablen in ihrer Verwendung unabhängig von der Klasse bzw. anderen Objekten gebraucht werden. "Unikate Verwendung eines Klassenabbildes". Spielt dies keine Rolle, kann eine Klasse je nach Situation auch ohne ein Objekt benutzt werden. Zu beachten wäre hier jedoch, das beinahe alles statisch deklariert werden muss. Wann genau das Sinn macht, kann ich gerade nicht sagen.

2. Ich denke man sollte Objekte dynamisch erzeugen, wenn der Speicher auf dem Stack dafür grenzwertig ist und natürlich auch dann, wenn ein Objekt eine längere Laufzeit als die Funktion, die das Objekt erzeugt hat, besitzen soll, um mit Zeigern auf das Objekt zugreifen zu können.

3. Statische Methoden kann man, so finde ich, immer dann verwenden, wenn für die Abarbeitung in der Methode kein this Zeiger, also somit Zugriff auf Membervariablen stattfindet. Somit kann die Methode auch schnell und einfach ohne ein Objekt benutzt werden, was den Rest der Klasse in seinem Entwurf aber unberührt lässt.

Ich würde nun gerne mal eure drei Meinungen zu den drei Fragen lesen. Und bitte listet alles auf.

fg34 schrieb:

Das verstehe ich nicht. Wenn eine Klasse keine virtuellen Methoden hat?

Mir fällt keine sinnvolle Möglichkeit ein eine Klasse zu verwenden, die
- Keine virtuellen Methoden bereitstellt.
- Keine nichtstatischen Membervariablen hat.

fg34 schrieb:

Wann und warum verwendet man Objekte oder die Klasse selbst?

Wird oben quasi schon beantwortet. Unikat eines Objekts -> Singleton. Sammlung von Funktionen / Konstanten -> Namespace.

fg34 schrieb:

2. Wann nutzt man Objekte auf dem Heap und wann auf dem Stack.

Man achtet darauf, dass die unterste Ebene immer auf dem Stack liegt. Objekte auf dem Heap nur durch Container und/oder Smartpointer* erstellen. (unique_ptr/shared_ptr)

fg34 schrieb:

Wann sollte eine Methode statisch sein?

Wenn sie keinen this Pointer braucht. Wenn du aber eine Klasse hast die nur aus statischen Methoden besteht, ist die Wahrscheinlichkeit hoch, dass du dein Design verkackt hast.
Da du ja bestimmt irgendein Problem im Hinterkopf hast könntest du das ja mal nennen, Beispiele helfen oft.

* Und auch nicht nicht direkt new nutzen, sondern make_shared und make_unique. (make_unique ist leider noch nicht im Standard vertreten, wird aber vielleicht bald nachgeliefert.)

Ich frage sonst mal konkreter:

1. Wann und warum verwendet man Objekte oder die Klasse selbst?
2. Wann nutzt man Objekte auf dem Heap und wann auf dem Stack.
3. Wann sollte eine Methode statisch sein?

Meine eigenen Antworten:

1. Objekte sollten dann verwendet werden, wenn die Methoden und Membervariablen in ihrer Verwendung unabhängig von der Klasse bzw. anderen Objekten gebraucht werden. "Unikate Verwendung eines Klassenabbildes". Spielt dies keine Rolle, kann eine Klasse je nach Situation auch ohne ein Objekt benutzt werden. Zu beachten wäre hier jedoch, das beinahe alles statisch deklariert werden muss. Wann genau das Sinn macht, kann ich gerade nicht sagen.

Kann es sein, dass du vorher schon mit Java oder einer anderen Sprache, die keine freien Funktionen hat, gearbeitet hast. In C++ kann man Namespaces verwenden, anstatt eine "Klasse" die nur aus statischen Methoden besteht zu bauen.

2. Ich denke man sollte Objekte dynamisch erzeugen, wenn der Speicher auf dem Stack dafür grenzwertig ist und natürlich auch dann, wenn ein Objekt eine längere Laufzeit als die Funktion, die das Objekt erzeugt hat, besitzen soll, um mit Zeigern auf das Objekt zugreifen zu können.

Im prinzip ja, aber man arbeitet eigentlich nicht mehr viel mit rohen Pointern, oft werden Smartpointer verwendet, die die Objekte selber aufräumen. Außerdem kann man in c++ Objekte auch per Referenz übergeben bzw. const ref.

3. Statische Methoden kann man, so finde ich, immer dann verwenden, wenn für die Abarbeitung in der Methode kein this Zeiger, also somit Zugriff auf Membervariablen stattfindet. Somit kann die Methode auch schnell und einfach ohne ein Objekt benutzt werden, was den Rest der Klasse in seinem Entwurf aber unberührt lässt.

Wie gesagt namespaces.

cooky451 schrieb:

Man achtet darauf, dass die unterste Ebene immer auf dem Stack liegt.

Keine Ahnung, was die unterste Ebene eines Objektes sein soll, aber auch wenn du das meinst, was ich vermute, ist das immer quatsch.

cooky451 schrieb:

Man achtet darauf, dass die unterste Ebene immer auf dem Stack liegt.

Keine Ahnung, was die unterste Ebene eines Objektes sein soll, aber auch wenn du das meinst, was ich vermute, ist das immer quatsch.

Die unterste Ebene des Objekts ist die erste (besitzende) Ebene die kein Klassenscope mehr ist. (Ausnahme sind natürlich static/globale Variablen)