nicht angemeldet
Tach!
das scheint ja langsam ein philosophisches oder archäoligisches Problem zu werden. Graben wir doch mal in den Bits.
Zu tief graben ist für das allgemeine Verständnis zunächst nicht notwendig. Für den Anfang reicht zu wissen, dass 1 + 1 eine 2 als Ergebnis hat und nicht was der Prozessor dabei in seinen Registern anstellt. Das ist nicht komplett uninteressant, nur eben nicht jetzt.
Eine Klasse ist nur ein Baumuster. Das liegt statisch vor, wenn das Programm läuft.
Das Wort statisch würde ich an dieser Stelle meiden. Nahezu jeder Programmcode liegt statisch vor. Es ist also keine Besonderheit des Baumusters. Den Begriff statisch brauchen wir aber noch an anderer Stelle, wenn es als Synonym für Klassen-Mitglieder verwendet wird (im Gegensatz zu den Objekt-Mitglieder). Der Code einer statischen Methode (also Klassenmethode) liegt ebenso fest im Code-Teil wie der einer Instanzmethode.
Auch ist eine Klasse weit mehr als ein Baumuster. Der Bauplan eines Gebäudes beschreibt die Räume und andere Einrichtungen (zum Beispiel dass Toilettenspülkästen eingemauert sind). Er sagt aber nichts zur anschließenden Verwendung aus. Er beschreibt also nur Eigenschaften und es fehlen ihm alle Methoden. Beim Instantieren ist allerdings nur der Bauplan wichtig für das Erstellen der Instanz und ihrer Eigenschaften. Der Konstruktor ist dann der Einzug mit dem Platzieren der Möbel im Haus. Danach kommt das Wohnen.
Nun wird eine neue Instanz angefordert. Das geschieht durch
newinstance = new(baumuster);
Die PHP-Syntax ist zwar eine andere, aber egal.
Was passiert hier?
Ich sag mal so: es kommt darauf an, nämlich ob es ein generisches Klassensystem (C++), ein typisierendes Klassensystem (Delphi) oder ein Interpretersystem (z.B. PHP) ist. Was in allen aber gleich ist:
Du deutest zwar hier eine Trennung nach Systemen an, aber führst in den nachfolgenden Teilen nicht aus, was dabei die Unterschiede sind/sein sollen.
es wird Speicherplatz für die Klassenvariable allokiert, egal, wieviel daws jetzt ist.
"Klassenvariable"? Den Begriff verwendet man üblicherweise für eine statische Variable einer Klasse. Du meinst, es wird eine Instanz erstellt. Ob dabei Speicher benötigt wird, ist für die Diskussion nicht weiter relevant. Ebensowenig muss die Instanz in einer Variable abgelegt werden. Die Instanz kann auch direkt erzeugt, verwendet und anschließend fallengelassen werden, ohne dass jemals eine Variable darauf verwiesen hätte ((new Foo)->bar(); in PHP erst ab 5.4). Deswegen spreche ich von Instanz und nicht Instanzvariable, denn dieser Begriff wäre eher ein Synonym für eine Variable in einer Instanz (auch Objekt-Variable). Allerdings gebe ich zu, dass die Sprache hier nicht eindeutig genug verwendet wird. Eine Integer-Variable ist eine Variable, die einen Integer-Wert enthält, eine Instanz-Variable demzufolge eine Variable, die auf eine Instanz verweist. Hier muss man dann aus dem Kontext erkennen, was gemeint ist.
Darüberhinaus wird i.a. auch Speicherplatz für die statischen Teile der Klasse allokiert
und diese werden dort hineinkopiert. Das sind einfache Variablen und z.B. die Adressen zu
den Methoden.
Es sieht mir so aus, als ob das ein Zitat ohne Quellenangabe ist, oder ist das einfach nur eine Aussage deinerseits, die eingerückt wurde? Statische Teile einer Klasse werden sinnvollerweise zum Programmstart oder bei nachgeladenen Code-Bibliotheken direkt nach dem Laden initialisiert, ansonsten wären die statischen Teile aus der Sicht des Programms ähnlich wie Schrödingers Katze, vielleicht schon initialisert, vielleicht aber auch nicht.
Damit ist die (Kern-)Instanz gebildet, noch bevor irgendwelche Initialisierungen stattgefunden haben, mit Ausnahem der statischen Werte. Die stehen jetzt bereits hardcoded im Speicher.
Was wie im Speicher steht, ist für unsere Betrachtungen nicht relevant. Hartkodiert sind eher Konstanten in kompilierten Programmen. Alles andere wird vermutlich zur Laufzeit im Datenteil des Speichers angelegt. Aber um diese Feinheiten brauchen sich PHP- und Programmierer anderer Systeme üblicherweise keine Sorgen zu machen, wenn sie darauf keinen Einfluss nehmen können. (Vielleicht ist C hier die Ausnahme - das kenne ich kaum.)
Damit ist aber klar, der Konstruktor war noch gar nicht tätig. Dieser kann nämlich erst ins Spiel kommen, wenn er selber abgebildet worden ist, entweder durch Codekopie, oder durch Referenz auf den Standardkonstruktor.
Welches System kopiert denn Code in die Instanzen eines Objekts? Gängiges Vorgehen bei der OOP ist, dass für die Klasse eine Tabelle existiert, die zu jeder Methode auf den jeweiligen Code verweist (virtual method table). Durch Vererbung können ja Teile des Codes den Elternklassen "gehören".
Was ist jetzt für dich der Standardkonstruktor? Ist das der Teil im System, der die Instanz erzeugt oder die Konstruktor-Methode einer Superklasse, von der alle anderen Klassen abgeleitet werden?
Wenn jetzt als nächstes die Kontrolle an den Konstruktor übergeben wird, kann er für neue Speicherall0kation sorgen und diese Fragmente innerhalb der statisch vorbereiteten Teile der Instanz eintragen. Wohin sollte der Konstruktor denn die Referenzen schreiben, wenn noch kein Variablenplatz ("Ankeradresse") dafür vorgesehen wäre?
Auch hier gehst du wieder zu sehr ins Detail. Ob Speicher allokiert werden muss (für die Instantiierung von Referenztypen), bereits da ist (Wertetypen, deren Größe beim Erzeugen der Instanz ja bereits bekannt ist und deren Speicher gleich mit angefordert werden kann), von einer Wurst abgeschnitten wird oder aus der Cloud kommt, ist alles nicht so wichtig für das Verständnis der Aufgaben einer Konstruktor-Methode. Vereinfacht würde ich das so formulieren:
Wenn jetzt als nächstes die Kontrolle an den Konstruktor übergeben wird, kann er für weitere Initialisierungen innerhalb der Instanz sorgen. Wie soll der Konstruktor denn die Eigenschaften ansprechen, wenn diese noch nicht zusammen mit der Instanz existiert?
Ich mag OOP-Programmierung nicht, weil alle Systeme es "innen drin" anders machen.
Na das ist ja kein Alleinstellungsmerkmal zwischen OOP-Systemen. Ziemlich viele Systeme (Programmiersprachen, unterschiedliche Compiler einer Sprache, Betriebssysteme, Anwendungen) machen "innen drin" so manches anders als andere. Du dürftest mit der Logik also gar nichts mögen.
Das große Problem ist jetzt nur, dass man wissen muss, welches System dem anderen (teilweise) zugrunde liegt.
Nein, muss man nicht. Man kann durchaus die Dinge im Untergrund wegabstrahieren.
dedlfix.