Prinzipiell ist immer der Konstruktor vorzuziehen.
Was die create Methode mit Rückgabetyp angeht, gibt es da zwei Ansichten:
1. Wenn es fehlschalgen kann, gehört es nicht in den Konstruktor. Dann gehört es in eine init/create Methode, die einen Rückgabewert hat oder anders Fehlerinformationen liefert (zb. Exceptions)
2. Du kannst aus einem Konstruktor genau wie aus jeder Funktion eine Exception werfen, die einen Fehlerfall anzeigt. Wenn du vorher schon Heap Speicher alloziert hast, musst du den natürlich wieder freigeben, wenn du so eine Exception fängst.
Das entspricht dem RAII (Resource Aquisition is Initialisation) Prinzip.
Wie gesagt, in C++ sollte man eher zu 2. tendieren, denn dafür gibt es die Sprachmittel.
Wer aus der C Welt kommt, wird eher an init Methoden gewöhnt sein, da RAII so in C nicht vorkommt und Klassen die meisten sowieso schon genug überfordern :p Java Programmierer kommen damit noch klar (init Methoden gibt es da eher selten), dafür sieht es da anders mit Destruktoren aus, die es dort einfach nicht gibt (ein Java Programmierer muss seine Resourcen also immer explizit freigeben und kann sie nicht automatisch im Destruktor freigeben lassen).
Kommt halt auch immer drauf an, ob du Exceptions oder einen Rückgabewert haben willst. Immer dann, wenn Exceptions eher ungeeignet wären (und solche Fälle gibt es), macht es mehr Sinn eine init Methode mit entsprechendem Rückgabetyp zu erstellen.
Wenn du sowieso mit Exceptions arbeitest, ist es im Grunde genommen wurscht, dann kommt es einfach auf dein Design an (soll das Objekt sofort mit der Erstellung auch initiailisiert sein oder soll es erstmal ein "Zombie-Objekt" sein und wirklich erst dann sinnvolle Daten enthalten, wenn du es explizit angibst?).
Quote:
|
Ist es irrelevant, ob man structs, unions oder class für die Klassen Definition verwendet? Abgesehen von den Voreinstellungen der jeweiligen Definitionsarten.
|
class und struct sind im Grunde das gleiche.
Eine Klasse hat standardmäßig alle Mitglieder (Methoden und Datenelemente) auf private und public Zugriff muss explizit angegeben werden. Bei einer Struktur ist es genau umgekehrt.
Strukturen werden i.d.R. nur für reine Datenansammlungen, die man unter einem Namen zusammenfassen will, verwendet, während man komplexere Designs mit Methoden, Polymorphie etc. eigentlich nur für Klassen verwendet, obwohl es auch bei Strukturen möglich wäre.
Eine union ist veraltet und meines Wissens wird davon abgeraten, sie noch zu verwenden.
Soweit ich weiß, fasst sie ein und dieselben Daten unter verschiedenen Namen zusammen:
Code:
union FloatOderInt
{
int x;
float y;
};
FloatOderInt var;
var.x = 5;
var.y = 5.0f;
x und y greifen auf dieselben Daten zu, nur werden sie einmal als Int und einmal als Float interpretiert.
Wie gesagt, normalerweise lassen sie sich vermeiden und werden deshalb auch nur selten verwendet.
Es kann aber praktisch sein, ein und dieselbe Variable unter verschiedenen Namen anzusprechen (wobei meines Erachtens dann einfach das Design Schrott ist), wie es in der Windows API gerne mal passiert.
Sie sind eingeschränkte Klassen, können also auch Methoden, Konstruktoren etc. haben, können aber werder von anderen Klassen erben noch vererben und dementsprechend auch nicht polymorph sein.
Sie haben wie Strukturen einen Standard-Public-Zugriff.