Was ist Klasse was ist Objekt?
-
Wann muss ich aufhören etwas als Klasse zu nennen und es als Objekt verwenden?
Ist es ok, wenn meine Klasse "Fortbewegungsmittel" repräsentiert und meine Objekte sind dann "grün lackierter VW Golf I Baujahr 1980. Mit Winterreifen, schwarzem Lederbezug und 14 Jahre lang nicht sauber gemachtem Handschuhfach", bzw. "Fahrrad mit blauen Aluminiumrahmen und Seitenschlag am Vorderrad".
Oder ist "Fortbewegungsmittel" eine Oberklasse, der Golf (mit denselben Eigenschaften natürlich) und das Fahrrad deren Spezialisierungen.
Ist diese Grenze zwischen Klasse und Objekt einfach willkürlich gewählt? Je nach dem wie viel Abstraktion man gerade benötigt? Oder gibt es irgendwelche gute Regeln dafür?
-
Objekte sind Instanzen von Klassen. Es gibt also keine Grenze.
-
http://tutorial.schornboeck.net/klasse_objekt.htm
http://de.wikipedia.org/wiki/Klasse_(Programmierung)
-
dfnn schrieb:
Objekte sind Instanzen von Klassen. Es gibt also keine Grenze.
Natürlich gibt es Grenze. Objekte kann ich beliebig viele zur Laufzeit erstellen und deren Eigenschaften ändern, wenn es durch die Schnittstelle die ich durch die Klasse habe möglich ist. Klassen nicht immer. In Java gehts, in C++ nicht. Außer COM-Klassen denke ich, aber das ist was anderes wieder....
Wenn es keine Grenze gibt, dann warum überhaupt Klassen und Objekte erzeugen? Reicht doch wenn man nur Objekte hat.
-
BigNeal schrieb:
http://tutorial.schornboeck.net/klasse_objekt.htm
http://de.wikipedia.org/wiki/Klasse_(Programmierung)Also das einzige ist ja dass man nur eine klasse haben kann mit selbem Namen aber viele Objekte vom selben Typ (also Klasse). Aber man könnte das einfach auch mit klassen die zwar genaudasselbe Verhalten haben aber unterschiedliche namen realisieren. Und Vererbung könnte man ja auch mit Objekten umsetzen, genauso das Verhalten der Objekte (mit hilfe der Attribute). Auch neue Objekte könnte man ja erstellen. In dem man alte einfach kopiert.
Mir gehts eigentlich so um die Trennung, wann ich aufhören soll Klassenhierarchie zu bauen und dann nur Objekte von diesen zu instanziieren.
-
Natürlich gibt es in der klassenbasierten OO eine Grenze zwischen Klasse und Objekt.
man darf sich eine Klasse nicht als eine Menge von Objekten darstellen, sondern als die Beschreibung einer Wesenheit. In der Platonischen Philosophie nennt man das "Idee".
OO-Systeme ohne eine solche Grenze gibt es auch
(vielleicht meinst du das):
die prototypenbasierte OO (Self, Cel, Javascript usw). Dort werden Objekte durch Klonierung erzeugt, anstatt durch Instanziierung von Klassen.
Das genaue Verhältnis zwischen den Begriffen Klasse und Objekt hängt sehr vom Objektmodell bzw der verwendeten Prog.Sprache ab.
In der reinen (klassenbasierten) OOP sind auch Klassen Objekte, nämlich Instanzen von Metaklassen. Metaklassen haben für gewöhnlich genau eine Instanz, nämlich die jeweilige Klasse. So entsteht eine zur Klassenhierarchie parallel verlaufende Hierarchie von Metaklassen, die an einer bestimmten Stelle zirkulär ist, damit nicht eine unendliche Schichtung von Meta-Ebenen entsteht. usw.
-
Die Frage nach ner Grenze zwischen Klasse und Objekt ist so sinnvoll, wie die Frage nach ner Grenze zwischen Hund und Waldi/Idefix/Lassie...
-
Eine Klasse beschreibt, wie z.B ein Schuhkarton aussieht, welche Eigenschaften er hat. Ein Objekt der Klasse Schuhkarton ist ein Schuhkarton.
-
matimatiker schrieb:
Ist es ok, wenn meine Klasse "Fortbewegungsmittel" repräsentiert und meine Objekte sind dann "grün lackierter VW Golf I Baujahr 1980. Mit Winterreifen, schwarzem Lederbezug und 14 Jahre lang nicht sauber gemachtem Handschuhfach", bzw. "Fahrrad mit blauen Aluminiumrahmen und Seitenschlag am Vorderrad".
Nein. "Grüner Golf" ist auch eine Klasse. Aber der grüne Golf, der in deiner Garage steht, ist ein Objekt (der Klasse "grüner Golf"). Entsprechend ist jedes Fahrrad ein Objekt / eine Instanz der Klasse "Fahrrad" und jedes Fahrrad mit blauen Aluminiumrahmen eine Instanz der Klasse "Fahrrad mir blauem Aluminiumrahmen".
Die Trennung ist also keinesfalls willkürlich. Eine Klasse beschreibt, wie die Objekte aussehen müssen, ein Objekt ist ein "real" existierendes Ding, was dieser Beschreibung entspricht.
Was man mehr oder weniger willkürlich festlegen kann, ist, wie stark man in dem jeweiligen Programm die Klassenhierachie spezialisiert. Also ob man z.B. tatsächlich eine Klasse "grüner Golf" braucht oder ob es nicht reicht, der Klasse "Auto" die Eigenschaften "Marke" und "Farbe" hinzuzufügen.
-
Stell dir das einfach so vor:
Klassen sind Schablonen.
Und mit diesen Schablonen werden dann im Presswerk aus einem großen Blech dann Teile gepreßt und diese dann noch mit nem Schriftzug graviert.
Diese Teile sind die Objekte und der Schriftzug deren indivuellen Daten.Das große Blech gibt's im übertragenen Sinne natürlich nicht, das wäre bestenfalls der Hauptspeicher.
Also:
Klassen = Schablonen
Objekte = mithilfe der Schablonen gepreßte Teile.Daher sagt man auch, daß Objekte Instanzen der Klassen sind.
-
Das Wrot "pressen" kannst du natürlich noch durch das Wort "herausstanzen" ersetzen, dann kann man es sich auch besser merken.
herausstanzen => Instanzen
Denn:
Instanzen von Objekte = herausgestanzte Teile
-
matimatiker schrieb:
Aber man könnte das einfach auch mit klassen die zwar genaudasselbe Verhalten haben aber unterschiedliche namen realisieren. Und Vererbung könnte man ja auch mit Objekten umsetzen, genauso das Verhalten der Objekte (mit hilfe der Attribute). Auch neue Objekte könnte man ja erstellen. In dem man alte einfach kopiert.
Mir gehts eigentlich so um die Trennung, wann ich aufhören soll Klassenhierarchie zu bauen und dann nur Objekte von diesen zu instanziieren.
Das ist aber keine Frage der Begriffsunterscheidung sondern Programmdesign. Die Begriffe sind (wie bereits mehrfach erwähnt) feste umrissen.