Konstructor - Name

Hi,

muss ein Konstructor immer denselben Namen wie die Klasse haben oder laesst scih das durch irgend einen boesen Trick umgehen?

Gruesse

GPC

Konstruierer schrieb:

muss ein Konstructor immer denselben Namen wie die Klasse haben

Ja.

oder laesst scih das durch irgend einen boesen Trick umgehen?

Nein, aber du kannst dir ja ne Factory-Methode schreiben... nur ruft die auch bloß den Ctor auf. Also Augenwischerei.

Hi,

habs mir fast gedacht... nicht weiter tragisch. Waere halt nur schoen gewesen, den Leere-Liste-Konstruktor fuer eine Liste Nil() zu nennen ...

Michael E.

Wieso denn das? Konstruktorenaufrufe schreibt man doch ohnehin nicht explizit in den Code.

Simon2

Konstruierer schrieb:

Hi,

habs mir fast gedacht... nicht weiter tragisch. Waere halt nur schoen gewesen, den Leere-Liste-Konstruktor fuer eine Liste Nil() zu nennen ...

Dann schreib Dir doch eine freie Funktion mit dem Namen (wenn es unbedingt sein muß - ich halte es für eher unnötig):

MyListe Nil() { return MyListe() }

... 
{
    MyListe a = Nil();
    ...

oder als staticMethode in MyListe:

class MyListe {
...
public:
    static MyListe Nil() { return MyListe() }
...
};

... 
{
    MyListe a = MyListe::Nil();
    ...

Ist aber IMO total überflüssig: Dass der StandardCtor aufgerufen wird, kann man durch nichts eindeutiger dokumentieren als durch:

MyListe a;

Gruß,

Simon2.

groovemaster

Oder du nimmst einen Nil Typ.

const struct NilType
{
} Nil;

class Liste
{
public:
    Liste(const NilType&)
    {
    }
};

Liste blubb = Nil;

Aber wie Simon schon schrieb

Ist aber IMO total überflüssig

hustbaer

Naja, was soll ne default konstruierte Liste schon sein ausser leer? Sie könnte natürlich ein Element mit dem Wert 42 enthalten, aber ob das Sinn macht...?

DEvent

Es macht aber in manchen Fällen schon Sinn einen Namen für ein Konstruktor zu vergeben. Das meist gebrauchteste:

Singleton s = Singleton.createInstanz();

Für Enums oder Wrapper-Klassen:

Double d = Double.valueOf("1.34987");
Farbe e = Farbe.valueOf("ROT");

usw.

Simon2

DEvent schrieb:

Es macht aber in manchen Fällen schon Sinn einen Namen für ein Konstruktor zu vergeben. Das meist gebrauchteste:
Singleton s = Singleton.createInstanz();
Für Enums oder Wrapper-Klassen:
Double d = Double.valueOf("1.34987");
Farbe e = Farbe.valueOf("ROT");
usw.

Also Ersteres ist bewußt kein Konstruktor (ihm fehlt z.B. die Eigenschaft, daß er automatisch aufgerufen wird bei Stackobjekten), sondern eine Factorymethode und für Letzteres sehe ich gar keinen Bedarf.
Was ist an

Double d1("1.34987");
Double d2 = Double("1.34987");
Farbe e("ROT");
Farbe e = Farbe("ROT");

(mit geeigneten explicit Konstruktoren)
falsch oder unverständlich oder unsicher ?

Alternativ kann man natürlich mit templates

Double d = valueOf<Double>("1.34987");
Farbe e = valueOf<Farbe>("ROT");

oder wie in Deeinem Beispiel statics FactoryMethoden bauen - aber wie gesagt: Sind eigentlich keine Konstruktoren.

Gruß,

Simon2.

sowas wie

Double d = Double.valueOf("0.23");

macht tatsächlich keinen sinn. methoden dieser art sind für sowas gedacht (und zudem eigentlich static, da keine eigenschaft eines objekts):

double d = Double::valueOf("0.23"); // bedeutungs-"korrekter" wäre parseDouble()

(man beachte das kleine double).

hier wird einem datentyp double ein wert zugewiesen, den eine statische methode, zugehörig zum objekt Double, liefert.

wichtig ist dabei die unterscheidung zwischen einem primitiven datentyp und einem objekt. gibt programmiersprachen, die gar keine primitive zur verfügung stellen.

Konstruktör

hoschi23 schrieb:

hier wird einem datentyp double ein wert zugewiesen, den eine statische methode, zugehörig zum objekt Double, liefert.

wichtig ist dabei die unterscheidung zwischen einem primitiven datentyp und einem objekt. gibt programmiersprachen, die gar keine primitive zur verfügung stellen.

Eine statische Methode funktioniert ohne Objekt. Eine statische Methode gehört zu einer Klasse, ohne dass es möglich sein müsste, Objekte dieser Klasse erstellen zu können.

sprich lieber von instanz, wenn du schon wortklauber sein willst. unter der definition von objekt als instanz einer klasse hast du recht. aber diese definition ist eh fragwürdig.

klasse beschreibt die formale spezifikation eines typs. als objekt bezeichne ich die verwendung des typs und methoden des typs zur laufzeit. das dabei keine instanz der klasse existieren muss, ist für statische methoden unter c++ selbstverständlich. in sprachen ohne statische konstrukte macht die unterscheidung objekt, instanz, klasse mehr sinn.

Konstruktör

Wieso soll Verwendung oder Methoden eines Typs ein Objekt sein? Umgangssprachlich ist ein Objekt eine Sache, Gegenstand oder Ding und in der objektorientierten Programmierung ist ein Objekt eine Instanz oder ein Exemplar einer Klasse.

Mathias

Weil es Leute gibt die meinen man kann alles als Objekt definieren, womit sie durchaus auch recht haben.
Man redet dadurch nur aneinander vorbei, weil man eine Aufgabe auf unterschiedlichen Abstraktionsebenen beschreibt.

Generell gilt: Ein Objekt definiert sich durch einen Zustand (Membervariablen) und seine Methoden.

Klassenfunktionen sind keine Objekte, da sie keinen Zustand besitzen.

Jetzt kann man argumentieren, das kann man in C/C++ aber in Kombination mit statische Variablen dies realisieren kann...

Das fällt meiner Meinung allerdings eher darunter wie kann man ein Objekt funktional abbilden.

Konstruktör

Mathias schrieb:

Generell gilt: Ein Objekt definiert sich durch einen Zustand (Membervariablen) und seine Methoden.

Nein, generell gilt folgendes:

<a href= schrieb:

wikipedia">Als Objekt bezeichnet man in der Informatik ein Exemplar eines beliebigen Datentyps.

in diesem speziellen fall behaupte ich, dass in der wikipedia zu dem thema großer humbug steht. der ganze artikel ist schwammig geschrieben.

Mathias

@Konstruktör
Der Artikel ist in der Form nicht korrekt. Ein Objekttyp (Klasse) ist ein Datentyp aber nicht umgekehrt.
Integer/Float/Real/Char z.B sind in C++ Datentypen aber keine Objekttypen.
Dies ist unter anderem daran erkennbar, dass sie keinen Konstruktor/Destuktor besitzen, nicht abgeleitet werden können, ...
(Datentypen gibt es auch bei relationalen Datenbanken, oder rein funktionalen Programmiersprachen.)

Konstruktör

Man glaubt es kaum, aber Objekte gab es in der Informatik schon bevor es Objektorientierung gab. Hier noch ein paar Infos und Zitate, wie zum Beispiel

ISO/IEC ISO/IEC 14882:2003(E), 1.8 The C++ object model schrieb:

An object is a region of storage.

DEvent

Also Ersteres ist bewußt kein Konstruktor

Ich meine natürlich eine Factory-Methode, das war ja sowas von deutlich aus dem Code herauszulesen. Aber solche Factory-Methode sind eben ein Ersatz für eine Namenvergebung bei Konstruktoren. Ich wollte nur anmerken das es eben manchmal Sinn macht einem Konstruktor einen Namen zu geben um eine zusätzliche Information zu verbreiten.

Ausserdem ist es klar das man sowas explizit aufrufen muss, etwas implizites verbirgt ja zusätzliche Information. Wir wollen aber eine zusätzliche Information.

Konstruktör schrieb:

Man glaubt es kaum, aber Objekte gab es in der Informatik schon bevor es Objektorientierung gab.

natürlich gabs objekte schon, bevor es objektorientierung gab. was meinst du ulknudel, woher der begriff stammt? :p

dein zitat stammt übrigens aus der oo zeit und hält sich dabei strikt an die c/c++ auffassung von objekten: das sind nämlich structs, also datenstrukturen. c++ ist zwar oo, aber das grundkonzept ist immer noch rein c. deshalb ist c++ denkbar schlecht geeignet, um objektorientierung zu diskutieren. dafür ist smalltalk oder von mir aus auch java besser geeignet.

Simon2

DEvent schrieb:

...Ich meine natürlich eine Factory-Methode, das war ja sowas von deutlich aus dem Code herauszulesen. Aber solche Factory-Methode sind eben ein Ersatz für eine Namenvergebung bei Konstruktoren. Ich wollte nur anmerken das es eben manchmal Sinn macht einem Konstruktor einen Namen zu geben um eine zusätzliche Information zu verbreiten....

DEvent schrieb:

Es macht aber in manchen Fällen schon Sinn einen Namen für ein Konstruktor zu vergeben....

Was jetzt: Konstruktor oder Factorymethode ?

Ja: Factorymethoden können sinnvoll sein.(Wobei das Wesentliche an ihnen nicht ihr Name ist, sondern ihre Aufgabe im Design)
Nein: Ich habe noch keinen Fall gesehen, wo ein Konstruktor einen anderen Namen haben sollte als den der Klasse.

Gruß,

Simon2.