Frage von BOZZJANEK, 97

Klassen-objektorientierung?

Ich habe gelesen das klassen in der objektorientierung eine art bauplan für objekte sind. Ist eine klasse für immer nur eine gleiche art von objekten da oder können zB aus der klasse auto mehrere unterschiedliche autos entstehen(Also die sich in farbe und höchstgeschwindigkeit zb unterscheiden) Also ist der sinn von klassen das viele gleoche objekte auf einem aufbauplan basieren oder ist der sinn von klassen das man nicht jedes unterschiedliche auto komplett neu programmieren muss?

Hilfreichste Antwort - ausgezeichnet vom Fragesteller
von affe2, 52

Ich bin mir nicht sicher ob ich deine Frage richtig verstanden habe aber ich Versuch mal zu antworten. Ich denke in deiner Frage geht es um Java objekte? In java kann man eine klasse erstellen in der du dann sogenannte private oder public Attribute erstellen kannst. Das sieht dann zb so aus:
Klasse: Auto
Attribute: modell, farbe, gewicht, etc.

So kannst du dann jedes objekt (auto) nach diesem muster erstellen indem du die Attribute (modell, Farbe, gewicht) in der startklasse oder über eine Tastatureingabe eingibst.

Wenn du dich näher mit objektorientiertem programmieren in Java beschäftigen möchtest empfehle ich dir das buch "java ist auch eine insel". Damit kann man sehr gute ohne ausgeprägtes vorwissen in java einsteigen. Ein gewisses Vorwissen ist trotzdem von Vorteil, somit kann man einige Kapitel nur überfliegen anstatt Stunden aif einer seite zu hängen.. :)

Ich hoffe ich konnte helfen..

Gruß affe2

Kommentar von BOZZJANEK ,

vielen dank für deine antwort. im prinzip weist du glaube ich was ich meine. es geht mir eigentlich nur um ein kleines detail. mich interessiert ob eine klasse für viele GLEICHE objekte ein bauplan ist oder ob klassen dazu da sind für mehrere UNTERSCHIEDLICHE autos einen bauplan mit variablen sind anhand derer die autos deffeniert werden. (die methoden und attribute dieser unterschiedlichen objekte sind gleich es geht mir nur um die werte für die parameter)

Kommentar von affe2 ,

also du kannst in eine klasse, nennen wir sie wieder auto, alle "autos" packen. Es muss nur jedes auto auch alle Attribute haben. D.h wenn du die Attribute farbe,sitze und marke hast kann auto1 bspw rot,4,opel und auto2 grün,7,vw sein. Willst du jetzt aber ein cabrio hinzufügen und auch ausgeben lassen dass es ein cabrio ist brauchst du ein neues Attribut das du für alle autos festlegen musst. Ich finde das immer schwierig in Worte zu fassen :D

Kommentar von BOZZJANEK ,

du meinst ich brauche eine neue klasse für das cabrio welche aber das meiste von der auto klasse erbt?

Kommentar von BOZZJANEK ,

ich versuche meine frage nochmal zu konkretisieren:

wird aus klassen immer nur exakt das gleiche objekt erzeugt

oder

ist der sinn von klassen das mithilfe von parametern aus einer klasse verschiedene objekte erzeugt werden können ohne das man für jedes einen extra bauplan pogramieren muss?

Kommentar von NoHumanBeing ,

Die Objekte einer Klasse sind (zumindest solange wir Vererbung ignorieren, dann wird's etwas komplizierter) immer dahingehend "gleich", dass sie die gleichen Attribute und Methoden haben, aber natürlich können sie sich in den Attributausprägungen (Werten, die in den jeweiligen Attributen stehen) unterscheiden.

Kommentar von BOZZJANEK ,

aber das sich die objekte voneinander in den attributen unterscheiden ist kein muss für die verwendung einer klasse oder? ich meine es gehört doch nicht zur allgmeinen deffenition von klassen das diese objekte erstellen welche sich in den attributen unterscheiden können müssen, das is ja nicht der sinn von klassen?

sorry für meine komplizierte anfängerhafte ausdrucksweise

Kommentar von NoHumanBeing ,

Nunja, der Gag bei Objektorientierung ist ja, dass Du die Klasse mehrfach instanziieren kannst. Wenn Du ein "Ding" hast, das es nur in exakt einer einzigen Ausprägung gibt, kannst Du es trotzdem in eine Klasse packen, würdest aber eventuell ein so genanntes "Singleton-Pattern" drum herum basteln, was eine Art ist, zu verhindern, dass man mehrere Instanzen einer Klasse erzeugen kann. So etwas braucht man aber eher selten.

Ich verstehe die Frage nicht so ganz. Du könntest z. B. eine Klasse "Counter" bauen, die einen Zähler implementiert.

public class Counter
{
private int val;

public Counter()
{
this.val = 0;
}

public void Increment()
{
this.val++;
}

public void GetValue()
{
return this.val;
}

}

Diesen Zähler könntest Du jetzt mehrfach instanziieren.

Counter ctr1 = new Counter();
Counter ctr2 = new Counter();

Dann hättest Du zwei Zähler, die Du unabhängig voneinander inkrementieren und den Wert auslesen könntest.  Die würden auch dann noch getrennte Objekte bleiben, wenn sie zufällig in allen Attributwerten übereinstimmen (hier gibt es ja nur eines).

(Das "Ding", was als "public Counter()" definiert ist, nennt sich "Konstruktor". Dieser Code wird durchlaufen, wenn mit dem "new"-Operator eine Instanz des Objekts erzeugt wird. Er initialisiert das Attribut. Hätte man in diesem Fall auch direkt bei der Deklaration machen können, "vermeide" ich aber eher, weil es ja "Code" ist und keine "Daten".)

Aber wenn sie grundsätzlich immer in allen Attributwerten übereinstimmen, dann ... brauchst Du kein Objekt gewissermaßen. Oder Du brauchst eben ein "Singleton". Eine Klasse, von der es immer nur exakt ein Objekt pro "Instanz Deines Prozesses" geben kann. (Wenn man Deine Anwendung mehrfach ausführt, kann es natürlich auch von einem Singleton mehrere "Instanzen" in den verschiedenen Prozessen geben. Die Prozesse haben ja getrennte Adressräume und "teilen" sich somit auch nicht die Daten. Und Objekte sind ja letztlich Datenstrukturen mit "drangeklebten" Methoden.)

Ich hoffe, ich verwirre Dich jetzt nicht mehr, als ich Dir nütze. Als jemand, der mit objektorientierter Programmierung vertraut ist, verstehe ich die Frage leider nicht so ganz. ;-)

Kommentar von NoHumanBeing ,

Und ich schreibe schon wieder Unsinn. Die Methode "GetValue()" muss natürlich als "public int GetValue()" deklariert sein, sonst kann sie ja keinen Wert zurückgeben. ;-)

Kommentar von affe2 ,

achso die Vererbung habe ich gar nicht in betracht gezogen. Man kann natürlich auch eine neue subklasse cabrio erstellen die die Attribute von der superklasse auto erbt. ich meinte es aber so dass man ein Attribut cabrio in der klasse auto festlegt (die true oder false als wert bekommt) und dann in der Fachklasse eine zeile programmiert (zb prüfeCabrio() ) die prüft ob der wert des Attributs cabrio true oder false bzw ja oder nein ist :) aus klassen werden objekte eines typs in einer klasse zusammengefasst (hier: alle autos in der klasse auto). Beim programmieren gibt es viel Freiheit deshalb gibt es immer verschiedene wege die zum gleichen Ergebnis führen :)

Kommentar von BOZZJANEK ,

ok also gibt es keine feste deffinition für das verwenden von klassen?

Kommentar von BOZZJANEK ,

also würde es egal sein ob ich eine eigene klasse für ein grünes auto mache oder es nur mit dem attribut grün aus der klasse auto erzeugen würde

Kommentar von NoHumanBeing ,

Eine neue "abgeleitete" Klasse machst Du, wenn sich Objekte so sehr unterscheiden, dass Du neue Attribute und Methoden definieren musst, die für den "übergeordneten" Typ überhaupt keinen Sinn machen (nicht einmal mit einem "Nullwert").

In den allermeisten Fällen kommt man aber vollkommen ohne Vererbung aus oder kann sie durch Komposition ersetzen, also ein Objekt, das bei Erzeugung ein anderes Objekt erzeugt und eine Referenz auf dieses hält, die es dann bei Bedarf nutzt. Wenn das möglich ist, ist diese Vorgehensweise eigentlich immer vorzuziehen, weil sie zu stärkerer Kapselung führt.

Was man dann noch ab und an braucht, ist Vererbung der Schnittstelle, wofür es in den meisten Sprachen ein eigenes Konstrukt namens "Interface" gibt, das der Klasse ähnlich ist, aber keine Implementierung bereitstellt. Es ist quasi wie eine Klasse, die nur "abstrakte Methoden" enthält. Wenn ein Interface für das, was man machen möchte, reicht, sollte man dieses auch einer Klasse vorziehen. (Eigentlich logisch. Immer die "restriktivste/schlankste Lösung" sozusagen.)

Mit Komposition und Interfaces kann man im Grunde 99.99999 % aller Anwendungsfälle erschlagen. "Echte" Vererbung braucht man eigentlich sehr selten. Es gibt Entwickler, die viel zu oft Vererbung nutzen, weil "Sprache ist ja objektorientiert, kann ich Vererbung nutzen, jedes Sprachfeature möglichst oft nutzen". Meiner Meinung nach ist das Unsinn und ich meide Vererbung (zumindest bei eigenen Klassen - manchmal muss man z. B. von Frameworkklassen erben, vor allem wenn man GUIs entwickelt - da musst Du dann in der Regel neue Klassen von einer "Fensterklasse" des GUI-Frameworks ableiten) wie der Teufel das Weihwasser.

Kommentar von BOZZJANEK ,

ok danke für deine mühe

Kommentar von NoHumanBeing ,

Keine Ursache! :-)

Antwort
von NoHumanBeing, 48

Ich glaube das "Bild" sollte man nicht zu wörtlich nehmen.

Klassen fassen Code (Methoden) und Daten (Attribute) zusammen und "kapseln" sie dabei, sodass auf den Daten nur die Methoden arbeiten können, die zu der jeweiligen Klasse gehören.

Den Vorgang, aus einer Klasse ein Objekt zu erzeugen, nennt man "Instanziierung". Bei diesem Vorgang wird Speicher für den Datenbereich des neu zu erstellenden Objekts reserviert, in dem dann die entsprechenden Attributwerte für das konkrete Objekt hinterlegt werden. Welche Werte das sind, wird durch die Definition der Klasse festgelegt. Die Methoden sind im Prinzip Prozeduren, die zusätzlich zu den übergebenen Parametern auch immer eine implizite "Selbstreferenz" (in vielen Sprachen mit dem Schlüsselwort this bezeichnet) erhalten. Diese benötigen sie, um auf den Datenbereich des konkreten Objekts zuzugreifen. Ein Objekt bezeichnet man dementsprechend auch als "Instanz einer Klasse".

Ein "Objekt" im Sinne der objektorientierten Programmierung muss kein Modell eines "physischen Gegenstands" sein. Dieses Bild wird meiner Meinung nach sehr stark "überstrapaziert".

Kommentar von BOZZJANEK ,

vielen dank für deine antwort. es geht mir eigentlich nur um ein kleines detail. mich interessiert ob eine klasse für viele GLEICHE objekte ein bauplan ist oder ob klassen dazu da sind für mehrere UNTERSCHIEDLICHE autos einen bauplan mit variablen sind anhand derer die autos deffeniert werden. (die methoden und attribute dieser unterschiedlichen objekte sind gleich es geht mir nur um die werte für die parameter)

Kommentar von NoHumanBeing ,

Natürlich kann jedes Objekt unterschiedliche Attributwerte besitzen. Das ist gewissermaßen der ganze "Witz" an der Sache. Diese können z. B. im Konstruktor gesetzt werden oder auch zur Laufzeit verändert, je nachdem, was die Klasse eben so "unterstützt".

Die "Fähigkeiten" eines Objekts legst Du als Entwickler fest. Dazu kann auch die Fähigkeit gehört, von einem Auto nachträglich ein Rad zu entfernen und es zu einem "Dreirad" zu machen. Dadurch wird es natürlich nicht zu einem Objekt einer anderen Klasse. ;-)

Kommentar von BOZZJANEK ,

ich meinte das halt so das nichts nachträglich verändert wird sondern das man dem objekt beim erstellen entsprechende parameter gibt welche dann am ende mehrere unterschiedliche objekte EINER klasse ergeben. also ob das der sinn und zweck von klassen ist?

Kommentar von NoHumanBeing ,

Ja, das ist so ziemlich genau der Sinn und Zweck von Klassen, "wie er im Buche steht". :-)

Letztlich kommt es aber darauf an, was Du machst. Klassen fassen Daten (Attribute) und Code (Methoden), der auf diesen Daten operiert, zu einer Einheit zusammen und kapseln die interne Struktur hinter einer wohldefinierten Schnittstelle.

Objekte im Sinne der objektorientierten Programmierung müssen nicht Objekten im alltäglichen Sinne entsprechen (diese Sichtweise wird in der Literatur oft vermittelt, aber ich finde sie wird sehr stark "überstrapaziert"), sondern können viel "abstrakter" sein. Wenn ich in meiner Software beispielsweise Datenströme verarbeiten möchte, habe ich vielleicht Klassen, wie "DataSource", "Processing", "DataSink". Je nachdem, wie ich die Daten selbst repräsentieren möchte, habe ich eventuell auch für die Daten selbst noch Klassen, sofern die Daten selbst strukturiert sind. Sind sie eher unstrukturiert (z. B. "eine Sequenz aus Gleitkommazahlen"), kann ich sie mit "normalen" Datentypen (z. B. einem Array aus "floats") repräsentieren.

Wenn ich die implementiert habe, erstelle ich mir vermutlich zunächst eine "DataSource" (ein "Ding, das Daten liefert") und eine "DataSink" (ein "Ding, das Daten aufnimmt") und anschließend ein "Processing"-Objekt, dem ich Referenzen auf diese beiden gebe, damit es sich Daten zur Verarbeitung holen (z. B. "myDataSource.getData()" und Ergebnisse wegschreiben (z. B. "myDataSink.postData(...)" kann.

Sobald Du ein "Ding" hast, das irgendwie "etwas zusammenhängendes tut" und eine Schnittstelle haben soll, machst Du eine Klasse draus. Da gibt es auch nicht immer ein "richtig" und "falsch". Wenn Du größere Software schreibst, wirst Du eventuell im Laufe der Entwicklung mehrere Klassen zu einer zusammenfassen oder andere Klassen aufteilen. Welche Aufteilung "sinnvoll" ist, lernst Du nur mit der Zeit über Erfahrung. Und unterschiedliche Entwickler würden es vermutlich auch unterschiedlich machen, ohne dass einer notwendigerweise "Recht haben muss" und die anderen "daneben liegen". ;-)

Antwort
von vikingo22, 10

Du hast 4 Klassen

  1. class Auto{}: enthält das rohe Auto
  2. class Lackiererei{}: enthält verschieden Farben und Pinsel
  3. class Motor{}: enthält verschieden starke Motoren
  4. class Ladentheke{}: nimmt deine Bestellung an, kümmert sich um die Auftragserfüllung und gibt die dein Traumauto zurück

Jeder nach seinen Wünschen: der eine möchte ror und 100PS, der andere grün und nur 80PS. Dazu werden aus benötigten Klassen Objekte instanziiert und mit dieses Objekten wird dein Auto gefertigt und ausgeliefert.

Das ist Teil des Prinzip der der Objektorientierten Programmierung, übrigens nicht nur in JAVA, auch in anderen Programmier- & Skriptsprachen.

Hier ein Beispiel Tutorial Model View Controller mit PHP, vielleicht unterstützt es Dich beim Verstehen: http://symfony-lernen.de/php_framework_tutorial/model-view-controller

Keine passende Antwort gefunden?

Fragen Sie die Community