programmierBar

[Kümmelkorn]

Du kannst von "einem Objekt" nicht "mehrere Instanzen" erzeugen.

Ein Objekt ist eine Instanz, und zwar die Instanz einer Klasse.

stimmt - Danke für den Hinweis Naja, wir hatten ja auch noch gar keine OOP, das war mein Vorwissen, was ich von C++ und ObjC gesammelt hab - wobei ich halt "Objekt" synonym für "Klasse" benutzt hab. Bei Grafikprogrammen erstellt man z.B. ein Dingens (=Irgendwas=Objekt, da kein Subjekt ), von dem man dann Instanzen erzeugen kann

Speichersparend ist das auch nicht, denn jede Instanz (also jedes Objekt) braucht eigenen Speicherplatz.

Klingt soweit logisch - Speichersparend ist es aber dann, wenn Vererbung ins Spiel kommt, bzw. wenigstens bei der Pseudo-Vererbung in meinem Beispiel, weil ich Zeiger benutzt hab, oder? Also mein Beispiel mit dem Männchen war ja schon speicherschonend, weil die Arme und Beine nur einmal im Speicher erzeugt werden, weil MännchenInstanz (schlechter Name...) die Arme und Beine erbt (=die selben benutzt.. in echtem OOP wäre es wieder anders, aber in meinem C beispiel benutzt doch MännchenInstanz die selben Arme wie Männchen, oder?)

 

[_ebm_]

Nein, du bringst da Vorlage und Objekt-Instanz durcheinander! Im Quelltext schreibst du die Vorlagen auf. Zur Laufzeit wird je Objekt Speicher nach der Vorlage ausgefasst und dem Programm zur Verfügung gestellt. Das hat nichts mit der Größe des Quelltextes zutun

Edit: Auch wenn die Vorlage aus mehreren Strukturen besteht, wird für jede Instanz Speicher je für alle Strukturen bereitgestellt

 

[Kümmelkorn]

Nein, du bringst da Vorlage und Objekt-Instanz durcheinander! Im Quelltext schreibst du die Vorlagen auf. Zur Laufzeit wird je Objekt Speicher nach der Vorlage ausgefasst und dem Programm zur Verfügung gestellt.

Soweit stimmt das allgemein. Wenn man aber mein gegebenes Beispiel ansieht und davon ausgeht, dass ich ein Männchen und hundert MännchenInstanz (ich spreche von der Struktur "MännchenInstanz" aus dem Beispiel oben) anlege, verbrauche ich doch - sofern ich Zeiger nicht vollkommen falsch verstanden habe - für jedes "MännchenInstanz" weniger Speicher als für das Männchen? eine Variable vom Typ MännchenInstanz muss ja nur einen Punkt und einen Zeiger auf Männchen speichern, was ja weniger Speicher verbraucht als zwei Arme und Beine, die in Männchen reserviert werden. Es wird ja nicht für jedes MännchenInstanz neue Arme und Beine angelegt!? Es gibt also im Speicher nur einen linken und einen rechten Arm und ein linkes und ein rechtes Bein, nicht 101 - folglich verbraucht diese Methode weniger Speicher als wenn ich 100 Männchen anlege, oder?

(Es mag sein, dass das immer weniger mit OOP zu tun hat und ein reines Zeiger Thema ist, aber das ändert nichts am Speicherverbauch)

Edit: Auch wenn die Vorlage aus mehreren Strukturen besteht, wird für jede Instanz Speicher je für alle Strukturen bereitgestellt

In meinem Beispiel hab ich die Strukturen ja gerade als Ersatz für Klassen angelegt, weil C keine Klassen kennt. deshalb ist ja mein Bauplan meiner "Pseudoklasse" die Struktur, d.h. jede "Instanz" meiner "Pseudoklasse" verbraucht genau den Speicher *einer* Struktur, nämlich je nach dem, aus welcher Struktur ich sie gemacht habe... also Männchen Mensch würde den Speicher eines Männchen verbrauchen, MännchenInstanz _ebm_ und MännchenInstanz Kümmelkorn jeweils den Speicherbedarf einer MännchenInstanz - insgesamt aber weniger Speicher als wenn ich Männchen _ebm_ und Männchen Kümmelkorn schreiben würde, ist das korrekt?
Insofern ist es bei echter Vererbung wie in C++ nicht speicherschonend (warum, habt ihr bereits ausgeführt), bei meinem Pseudo-OOP in C wäre es aber speicherschonend, korrekt?

 

[_ebm_]

Du hast dann aber nur eine Instanz! Das ist das Singleton-Prinzip und geht mit OOP auch!

Deine MännchenInstanzen sind keine Instanzen sondern nur Referenzen auf ein und die selbe Instanz von Männchen! Manipulierst du eine MännchenInstanz, hat das Auswirkungen auf alle!

Erzeugst du dir wirklich echte Instanzen, fasst also neuen Speicher pro Instanz aus, schlägt das Manipulieren auf andere Instanzen nicht durch, da die ihren eigenen Speicher haben. Ich glaube immernoch, dir ist der Unterschied zwischen Klasse, Objekt und Instanz nicht ganz klar

 

[pi26]

Also ist Veerbung und (vereinfachte) "Objekt"-Instanzen nicht zwingend etwas, was nur objektorientierte Sprachen können? Stimmt das so?

Natürlich nicht, vielmehr ist ja jede Sprache über Maschinensprache auch wiederum nur ein Programm. Letztendlich ist es so wie mit Atomen und Molekülen, wo man aus Atomen ja auch Moleküle bauen kann.

 

[_ebm_]

In meinem Beispiel hab ich die Strukturen ja gerade als Ersatz für Klassen angelegt, weil C keine Klassen kennt. deshalb ist ja mein Bauplan meiner "Pseudoklasse" die Struktur, d.h. jede "Instanz" meiner "Pseudoklasse" verbraucht genau den Speicher *einer* Struktur, nämlich je nach dem, aus welcher Struktur ich sie gemacht habe... also Männchen Mensch würde den Speicher eines Männchen verbrauchen, MännchenInstanz _ebm_ und MännchenInstanz Kümmelkorn jeweils den Speicherbedarf einer MännchenInstanz - insgesamt aber weniger Speicher als wenn ich Männchen _ebm_ und Männchen Kümmelkorn schreiben würde, ist das korrekt?
Insofern ist es bei echter Vererbung wie in C++ nicht speicherschonend (warum, habt ihr bereits ausgeführt), bei meinem Pseudo-OOP in C wäre es aber speicherschonend, korrekt?

Ich hab mir nochmal oben dein Beispiel angeschaut. Was du dort machst, ist keine Vererbung, solange du in dem Männchen-Pointer in der MännchenInstanz immer die gleiche Instanz ablegst. Was mich etwas verwirrt hat, ist deine Namenswahl. MännchenInstanz ist keine Instanz sondern ein spezielles Männchen.

MännchenInstanz nimmt, wenn jedem MännchenInstanz ein eigenes Männchen zugeordnet ist (nichts anderes sollte passieren, wenn du wirklich von Vererbung und Entitäten sprichst), mehr Speicher ein, nämlich den von Männchen und den von MännchenInstanz. Deine Klassenvorschrift besteht für MännchenInstanz aus der Struktur Männchen, der Struktur MännchenInstanz und den zugehörigen Methoden. Die Vorschrift für die Basisklasse Männchen besteht aus der Struktur Männchen und den zugehörigen Methoden.


Mini-Exkurs Zustand oder was sind Instanzen:

Def: Klassen sind eine textuelle Vorschrift nach der Objekte erzeugt werden.
Def: Objekte sind Datenstrukturen eines Programms. Sie haben keinen inneren Zustand.
Def: (Objekt-)Instanzen werden aus Objekten hergestellt. Es wird Speicher ausgefasst und gegebenenfalls Variablen initialisiert, je nach dem, was in der Klasse definiert wurde (Construktor). Objektinstanzen haben einen (inneren) Zustand. Eine Instanz unterscheidet sich von einer anderen durch diesen Zustand. (Das liegt daran, dass jede Instanz ihren eigenen Speicherbereich hat)

 

[Kümmelkorn]

Du hast dann aber nur eine Instanz! Das ist das Singleton-Prinzip und geht mit OOP auch!
Stimmt, da hast du recht. Vielleicht bist du mit der Annahme, dass mir der Unterschied zwischen Klasse, Objekt und Instanz noch nicht 100% klar ist, weniger falsch, als ich denke und mir wünsche.

Also wenn ich mich doch mal an C++ zurückerinnere, dann war das ja grob so:

Folgendes ist meine Klasse:
class Foo {
// Irgendwas halt...
}

Meine Instanz ist:
Foo Bar = new Foo();

Logischerweise kann ich mehrere Variablen vom Typ Foo erzeugen, die pro Variable eine Instanz darstellen. Also meinetwegen:
Foo Bar2 = new Foo();

Bar2 wäre eine Instanz, Bar eine andere.
Nun zwei Dinge, die mich daran nun noch irritieren:

1. Mein Quellcode ist falsch, wenn ich mich richtig erinnere. Korrekt müsste es heißen:
Foo* Bar = new Foo();
und
Foo* Bar2 = new Foo();

Warum sind Instanzen Zeiger und auf was zeigen Sie eigentlich? Wenn ich jetzt Bar2 ändere, ändere ich ja nicht Bar... hä?

2. Um nochmal zurück auf die Grafikprogramme zu kommen: Dort erstelle ich ein Grafikgedöngs (in 3D Programmen nennt man das dann Mesh, in 2d Programmen weiß ich es nicht). Davon kann ich dann sog. "Instanzen" erzeugen. Im Prinzip sind Instanzen Kopien von dem Mesh/..., die eine eigene Position, Skalierung und Rotation haben können, aber alle anderen Eigenschaften (Oberfläche, Textur, Form etc.) blind von dem Original kopieren. Der Vorteil ist nun: Wenn ich das Original verändere, änderen sich alle Instanzen automatisch mit. Eine Instanz kann ich aber (bis auf Position, Rotation und Skalierung) nicht ändern. Die Frage lautet nun: Was wäre das für einen Programmierer? Wenn ich das gerade beschreibe, hat das mehr mit Zeigern zu tun als mit Instanzen. Aber auch wieder nicht, weil ja Position, Rotation und Skalierung nicht identisch sind. Wie würdet ihr das nun verwirklichen? (also nur mal theoretisch, so vom Ansatz her)

3. Anderes Beispiel aus Grafikprogrammen (konkret: Flash), was mir gerade einfällt, was mMn gut ins Thema passt: In Flash gibt es Symbole (das sind Objekte, z.B. ein Viereck, ein Button, ein Charakter etc.), die man in die Bibliothek legen kann. Diese Symbole haben einen Namen, z.B. Bernd. Um diese Symbole nun auf dem Bildschirm zu sehen, ziehe ich es auf meine Bühne (=der Bildschirm). Damit erzeuge ich eine "Instanz" (so nennt es Flash). Das Objekt "Bernd" liegt immernoch in der Bibliothek, das Dinges auf meiner Bühne bekommt einen neuen Namen, z.B. dasBrot (dieser Name heißt in Flash übrigens "Instanzname"). Ich kann auch mehrere "Instanzen" erzeugen, die alle Unterschiedliche Eigenschaften (Farben, Ränder etc) haben können. Was passiert, wenn ich das Objekt in der Bibliothek ändere, weiß ich so spontan gar nicht.

Kann man das eher mit Klassen und Instanz vergleichen? Ist das Dinges in der Bibliothek "Bernd" eine Klasse und das auf der Bühne (=Bildschirm) "dasBrot" eine Instanz?

 

[_ebm_]

Also wenn ich mich doch mal an C++ zurückerinnere, dann war das ja grob so:

Folgendes ist meine Klasse:
class Foo {
// Irgendwas halt...
}

Meine Instanz ist:
Foo Bar = new Foo();

Logischerweise kann ich mehrere Variablen vom Typ Foo erzeugen, die pro Variable eine Instanz darstellen. Also meinetwegen:
Foo Bar2 = new Foo();

Bar2 wäre eine Instanz, Bar eine andere.
Nun zwei Dinge, die mich daran nun noch irritieren:

1. Mein Quellcode ist falsch, wenn ich mich richtig erinnere. Korrekt müsste es heißen:
Foo* Bar = new Foo();
und
Foo* Bar2 = new Foo();

Warum sind Instanzen Zeiger und auf was zeigen Sie eigentlich? Wenn ich jetzt Bar2 ändere, ändere ich ja nicht Bar... hä?

Foo Bar = new Foo();

ist in der C++-Welt falsch. Der Konstruktor fasst Speicher aus, ruft alle in ihm angegebenen Methoden (ggf keine, wenn er leer ist) und gibt einen Pointer - also die Startadresse - der angelegten Instanz zurück. Darum steht da auch richtigerweise

Foo* Bar = new Foo();

Foo ist die Vorschrift, die Klasse, der Typ.
Bar ist der Name der Instanz.
new Foo() ist der Ruf des Konstruktors (sic, das weißt du schon)

Nochmal, Klassen sind eine textuelle Beschreibung in einer Programmiersprache (Entwicklungszeit), Objekte sind Maschinencode, der ausgeführt werden kann (Compilezeit), Instanzen sind initialisierte Objekte, die bereit sind, den Code auszuführen (Ausführungszeit).

2. Um nochmal zurück auf die Grafikprogramme zu kommen: Dort erstelle ich ein Grafikgedöngs (in 3D Programmen nennt man das dann Mesh, in 2d Programmen weiß ich es nicht). Davon kann ich dann sog. "Instanzen" erzeugen. Im Prinzip sind Instanzen Kopien von dem Mesh/..., die eine eigene Position, Skalierung und Rotation haben können, aber alle anderen Eigenschaften (Oberfläche, Textur, Form etc.) blind von dem Original kopieren. Der Vorteil ist nun: Wenn ich das Original verändere, änderen sich alle Instanzen automatisch mit. Eine Instanz kann ich aber (bis auf Position, Rotation und Skalierung) nicht ändern. Die Frage lautet nun: Was wäre das für einen Programmierer? Wenn ich das gerade beschreibe, hat das mehr mit Zeigern zu tun als mit Instanzen. Aber auch wieder nicht, weil ja Position, Rotation und Skalierung nicht identisch sind. Wie würdet ihr das nun verwirklichen? Hat das entfernt irgendetwas mit Klassen und Instanzen zu tun?

Ah siehst du, Instanzen sind Kopien vom Mesh, also dem Objekt. Sie haben einen eigenen Zustand (Position, Skalierung,..). änderst du die Vorschrift von Mesh (die Klasse), änderst du die Eigenschaften der Instanzen, die ja aus diesem Objekt erzeugt werden. Vergiss hier die Zeiger! Die verwirren! Zeiger != Instanz!!

3. Anderes Beispiel aus Grafikprogrammen (konkret: Flash), was mir gerade einfällt, was mMn gut ins Thema passt: In Flash gibt es Symbole (das sind Objekte, z.B. ein Viereck, ein Button, ein Charakter etc.), die man in die Bibliothek legen kann. Diese Symbole haben einen Namen, z.B. Bernd. Um diese Symbole nun auf dem Bildschirm zu sehen, ziehe ich es auf meine Bühne (=der Bildschirm). Damit erzeuge ich eine "Instanz" (so nennt es Flash). Das Objekt "Bernd" liegt immernoch in der Bibliothek, das Dinges auf meiner Bühne bekommt einen neuen Namen, z.B. dasBrot (dieser Name heißt in Flash übrigens "Instanzname"). Ich kann auch mehrere "Instanzen" erzeugen, die alle Unterschiedliche Eigenschaften (Farben, Ränder etc) haben können. Was passiert, wenn ich das Objekt in der Bibliothek ändere, weiß ich so spontan gar nicht.

Die Symbole sind die Objekte, welche mit einem Stift beschrieben wurden (Klasse). Das Ziehen dieser Symbole erzeugt im Programmcode die Anweisung des Erzeugens einer Instanz, führst du also den Flash-Film aus, wird dort eine Objekt-Instanz angelegt und ihr Construktor durchlaufen.

Kann man das eher mit Klassen und Instanz vergleichen? Ist das Dinges in der Bibliothek eine Klasse und das auf der Bühne (=Bildschirm) eine Instanz?

NEIN! Eben nicht! (siehe meine Definitionen oben).

Edit: Nochmal, differenziere hier zwischen Programmiersprache (in der die Vorschrift geschrieben wurde), dem Konzept, das sich irgendwann mal jemand schlaues überlegt hat und dem Geschehen zur Laufzeit!

 

[_ebm_]

Ich glaube, ich muss noch einen Nachtrag bezüglich Typ, Objekt und Objekt-Instanz bringen.

Typ ist nur eine Markierung, ein Hinweis darauf, welche Klasse verwendet wird. Es gibt ungetypte aber trotzdem objektorientierte Sprachen.

Manche unterscheiden auch zwischen Objekt und Objekt-Instanz nicht. Bei PHP wird das zum Beispiel recht schwierig, wann man von was spricht. So kann ein Objekt ohne Weiteres auch im Speicher liegen. Wichtig ist die Unterscheidung zwischen Zustand haben und eben nicht. Instanzen haben einen Zustand, Objekte selbst noch nicht! Man könnte locker gesprochen Objekte auch als Vorschrift für Instanzen ansehen, wie die Klasse eine Vorschrift für ein Objekt ist.

Edit, nachdem ich nochmals drüber geschlafen hab: Insofern ist mein vehementer Einspruch am Ende des letzten Beitrags zwar korrekt aber vielleicht nicht Zielführend. Bildlich kann man sicher davon sprechen, dass in der Bibliothek die Klasse liegt, auf der Bühne während des Entwurfs das Objekt und während der Film dann läuft eine Instanz. Technisch ist es aber anders. Die Klasse gab es beim Programmieren von Flash (bzw der Bibliothek), das Objekt liegt jetzt in der Bibliothek, mit dem Ziehen des Objektes auf die Bühne wird eine Anweisung zum Erzeugen einer Instanz in den Quellcode des Flashfilmes geschrieben und während der Ausführung ist diese Instanz dann existent.

 

[Darii]

Nochmal, Klassen sind eine textuelle Beschreibung in einer Programmiersprache (Entwicklungszeit), Objekte sind Maschinencode, der ausgeführt werden kann (Compilezeit), Instanzen sind initialisierte Objekte, die bereit sind, den Code auszuführen (Ausführungszeit).

Also rein für das Verständniss von OOP ist diese Definition nicht hilfreich. Da stößt du schon bei ObjC an eine Grenze, da dort Klassen reale Objekte(-Instanzen) sind. Sie sind nämlich Instanzen ihrer Metaklasse. Von Sprachen wie Smalltalk(Squeak) will ich gar nicht erst anfangen, da sind Klassen hauptsächlich im Speicher und nicht in Quellcodeform präsent.

Das wäre jetzt auch meine Empfehlung an dich, Krümelkorn, wenn du OOP mal näher verstehen willst einfach mal Smalltalk angucken.

 

[_ebm_]

Also rein für das Verständniss von OOP ist diese Definition nicht hilfreich. Da stößt du schon bei ObjC an eine Grenze, da dort Klassen reale Objekte(-Instanzen) sind. Sie sind nämlich Instanzen ihrer Metaklasse. Von Sprachen wie Smalltalk(Squeak) will ich gar nicht erst anfangen, da sind Klassen hauptsächlich im Speicher und nicht in Quellcodeform präsent.

Hmpf. Wozu schreib ich mir eigentlich die Finger wund. Klassen sind die textuelle Beschreibung, die Vorlage, auch bei Objective C! Du öffnest einen Editor und notierst dort das Aussehen des Objektes in Form von einer Klasse! Diese wird dann vom Compiler übersetzt und es liegt ein Objekt im Programmcode vor. Das wird dann zur Laufzeit instanziiert! Das alles gilt auch für Objective C und Smalltalk!

Das wäre jetzt auch meine Empfehlung an dich, Krümelkorn, wenn du OOP mal näher verstehen willst einfach mal Smalltalk angucken.

Gute Idee! *hmpf*


Die Informatik hat eine eindeutige und feste Nomenklatur! Wenn man sich nicht daran hält, redet man pausenlos aneinander vorbei!

 

[wegus]

Normalerweise betrachte ich ja das heranwachsen von "noch einer C-Sprache" inzwischen mit Argwohn, wenn aber Google dahinter steckt und schonmal von einem Google-OS die Rede war, dann ist das hier sicher etwas was uns beschäftigen wird oder?

http://www.golem.de/0911/71113.html


und

http://golang.org/

 

[_ebm_]

Normalerweise betrachte ich ja das heranwachsen von "noch einer C-Sprache" inzwischen mit Argwohn, wenn aber Google dahinter steckt und schonmal von einem Google-OS die Rede war, dann ist das hier sicher etwas was uns beschäftigen wird oder?

http://www.golem.de/0911/71113.html


und

http://golang.org/

Geht mir sehr ähnlich! Ich weiß zwar jetzt nicht, warum wir nach dem Erfolg von C# noch eine C-Sprache brauchen, aber bitte Vielleicht wird Go ja dann von Google unter Closed Source gestellt, wenn MS ein Patent auf C# angestrebt hat.


Edit: Lustig finde ich die Bemerkung von Golem, dass die Sprache kein do und while kenne. Wozu auch? for reicht vollkommen...

Edit2: Hust. UTF-Support aber s (s ist ein String) gibt nur 1 byte zurück? das klingt alles etwas zusammengeschustert. Also wirklich nur was zum Spielen und nicht sauber designt. Wo schlechtes Design hinführt sieht man ja bei Java.... ^^

 

[wegus]

Lustig finde ich die Bemerkung von Golem, dass die Sprache kein do und while kenne. Wozu auch? for reicht vollkommen...

Die haben falsch gelesen! Richtig ist: Es gibt nur noch for als Loop-Element, das läßt sich aber unterschiedlich nutzen. Sprich

for(Bedingung) {do}

und ob Bedingung while-like wirklich eine Bedingung ist oder eine iterierende Anweisung ist egal. Die Konstrukte gibt es also schon noch, nur heißen sie alle for

 

[_ebm_]

Ja Wegus, die Loops sind untereinander austauschbar.

while (Bedingung) { do }

for ( ; Bedingung ; ) { do }

Einzig die Semantik von do.. while ist eine andere, da die Bedingung erst nach dem ersten Durchlauf geprüft wird, die Schleife wird also immer mindestens ein mal betreten.

Wie auch immer, wirklich ausgereift ist das Design wirklich nicht.

 

[wegus]

wirklich ausgereift ist das Design wirklich nicht.

Wie ich schon schrub, eigentlich wäre es mir egal die wievielte Sprache da auf den Markt rollt (C,C++,Objective-C,C#,D,Java,...Go...). Das Problem ist das da Google drunter steht und damit - egal wie gut oder schlecht das Design und der Grund für YetAnotherCLanguage sein mag mit dem Auftreten dieser Sprache zu rechnen ist.

Ob das Design schlecht ist weiß ich noch gar nicht, mir fehlt die Zeit die Sprache wirklich zu probieren.


Witzig finde ich: Es gibt Compiler für LINUX und OS X, für Windows bietet man das derzeit wohl nicht an.

 

[_ebm_]

Wie ich schon schrub, eigentlich wäre es mir egal die wievielte Sprache da auf den Markt rollt (C,C++,Objective-C,C#,D,Java,...Go...). Das Problem ist das da Google drunter steht und damit - egal wie gut oder schlecht das Design und der Grund für YetAnotherCLanguage sein mag mit dem Auftreten dieser Sprache zu rechnen ist.

Ob das Design schlecht ist weiß ich noch gar nicht, mir fehlt die Zeit die Sprache wirklich zu probieren.


Witzig finde ich: Es gibt Compiler für LINUX und OS X, für Windows bietet man das derzeit wohl nicht an.

Ja, Google hat Manpower. Ich hoffe nur, das setzen sie auch wirklich mal richtig ein.


Unter Windows sollte es mit MinGW oder Cygwin kein Problem sein. Gefordert sind laut Heise Ticker GCC und Bison.

 

[pi26]

Wie ich schon schrub, eigentlich wäre es mir egal die wievielte Sprache da auf den Markt rollt ...

Und was hältst du von der neuen Form von "schrub"? ;-)

 

[Darii]

Hmpf. Wozu schreib ich mir eigentlich die Finger wund. Klassen sind die textuelle Beschreibung, die Vorlage, auch bei Objective C! Du öffnest einen Editor und notierst dort das Aussehen des Objektes in Form von einer Klasse! Diese wird dann vom Compiler übersetzt und es liegt ein Objekt im Programmcode vor. Das wird dann zur Laufzeit instanziiert! Das alles gilt auch für Objective C und Smalltalk!

Mich würde mal interessieren wo du deine Nomenklatur her hast diese Definitionen sind mir nämlich noch nicht über den Weg gelaufen.

Wenn ich deine Definitionen auf C++ übertragen machen sie schon Sinn, auf Smalltalk(Squeak) angewendet nicht. Klassen sind zwar die Beschreibung der Objekte, diese muss aber nicht in Textform erfolgen und natürlich dürfen Klassen auch durch Objekte repräsentiert werden. Beispielsweise arbeitet man in Smalltalk(Pharo) zu keiner Zeit mit dem Quellcode der kompletten Klasse, sondern ändert zur Laufzeit die schon vorhandene Klasse(die zu diesem Zeitpunkt auch keinen Quellcode mehr haben muss) ab.

Und im Grunde genommen ist es auch egal was wie, wo und wann im Speicher oder in Quellcodeform vorliegt, das sind nur Implementierungsdetails ändern aber nichts am Prinzip.

Ich zitiere einfach aus „ Smalltalk-80: The Language and its Implementation“:
object -- A component of the Smalltalk-80 system represented by some private memory and a set of operations.
class -- A description of a group of similar objects.
instance -- One of the objects described by a class.

 

[_ebm_]

Ich zitiere einfach aus „ Smalltalk-80: The Language and its Implementation“:
object -- A component of the Smalltalk-80 system represented by some private memory and a set of operations.
class -- A description of a group of similar objects.
instance -- One of the objects described by a class.

Bis auf die Feinheiten, was wann wo liegt. Wo unterscheidet sich das von meiner Beschreibung?

Dass man zur Laufzeit Objekte manipulieren kann, ist eine Spezialität von Smalltalk. Bitteschön... Es ging hier aber darum, einem Anfänger Grundlagen zu vermitteln! Ausnahmen gibt es immer und bestätigen nur die Regel!

Eine Quelle muss ich nicht liefern, da selbst dein Zitat aus dem Smalltalk-Buch meine Definitionen bestätigt.

Edit: Einziger Unterschied: deine Quelle unterscheidet nicht zwischen Objekt und Objektinstanz bzw finde ich die Beschreibung sehr unsauber. Was unterscheidet hier Objekt und Instanz? Wozu eine sprachliche Unterscheidung, wenn es eigentlich das gleiche ist? Was ist das Ding im Programmcode, das noch nicht instanziiert wurde? Ist das eine Klasse? Ist das ein Objekt. Beides passt nicht so recht.

Edit2: Nimmt man an, dass Private Memory Speicher des Programms ist, welches nicht "aktiv" (sprich ohne Zustand) ist, stimmt auch meine Definition wieder. Instanzen sind dann eine Kopie der Objekte mit Zustand. Übersehe ich etwas?