Zusammenhang Klassen, Objekte, Attribute, Methoden

[ralf_matusch]

Hallo Ihr alle,

im aktuellen Semester soll ich ein kleines Programm in C# schreiben. Nach dem mehr oder weniger erfolgreichen Erstellen des Use Case Diagramms ist nun das Klassendiagramm fällig.

Mein Professor meinte, ich müsste mir dafür zuerst einzelne Objekte überlegen, aus denen ich dann die Klassen ableite.

Wenn ich mir jedoch den allgemeinen Aufbau eines Klassendiagramms anschaue, so besteht jede Klasse aus Attributen und Methoden - nicht aus Objekten (wie ich annahm).

Wie ist der grundsätzliche Zusammenhang zwischen Klassen, Attributen, Methoden und Objekten???

Ich bekomme da keinen roten Faden rein...

Da ich aus der Maschinenbau-Richtung komme, ist das alles absolutes Neuland für mich. Die Erklärungen so einfach und simpel wie möglich bitte!!!

Ich danke für jeden Hinweis...

[flashpixx]

Wie ist der grundsätzliche Zusammenhang zwischen Klassen, Attributen, Methoden und Objekten???

Ein Objekt ist eine Instanz einer Klasse. Ein Attribut und eine Methode ist ein Teil eines Objektes / Klasse

[lilith2k3]

Eine Klasse ist quasi so etwas wie eine Blaupause, ein Konstruktionsplan.

Das kann ein Plan für weitere Klassen sein (abstrakte Klasse als Blaupause für Klassen), das kann auch ein Plan für konkrete Objekte sein.

Attribute spiegeln den Zustand eines Objektes wieder und werden in Variablen festgehalten, e.g. die Variable Alter gibt an, wie alt bspw. ein Objekt der Klasse "Spielfigur" ist.

Bei Methoden unterscheidet man zwischen solchen, die am Objekt irgendwelche Zustandsänderungen veranlassen, bzw. veranlassen, dass das Objekt irgendwie in Aktion tritt und denen, die den Zustand des Objektes erfragen.

Grob gesagt, handelt es sich bei Objekten um eine Verbindung der Daten mit den Routinen, die diese Daten letztlich bearbeiten.

Während in anderen Programmiersprachen Verbundtypen genutzt werden, um zusammengehörige Daten in einem Block abzuhandeln, gibt es außerhalb der objektorientierten Sprachen keine solche Verbindung zwischen Daten und Routinen.

Der Vorteil liegt auf der Hand: das Objekt "kümmert" sich selbst um seine Konsistenz nach innen und erlaubt nur derartige Zugriffe, unter denen diese Konsistenz gewahrt bleibt.

Einher gehen damit die sog. Zugriffsmodifizierer in statisch typisierten OO Sprachen "private, public, protected" die als Kennzeichen dafür dienen, unter welchen Umständen, welche anderen Objekte mit diesem Objekt kommunizieren können.

Private spricht für sich selbst: Methoden (Funktionen/Routinen), die als Private gekennzeichnet sind, sind in der Regel von außen nicht aufrufbar (es gibt tatsächlich Außnahmen, die ich bei Seite lassen möchte).

Public ist das genaue Gegenteil: Alles was publik gemacht wird, davon kann jeder Gebrauch machen.

Protected ist ein Zwischending: Methoden die Protected sind, sind nicht publik, also nicht für jedermann nutzbar; aber auch nicht private - sondern meist für eine gewisse "Gruppe" von Objekten benutzbar.

An dem Punkt fiele dann jetzt das Wort "Vererbung"... usw. usf.

Wenn Dein Prof also meint, Du sollst Dir die Objekte überlegen, so meint er quasi soviel wie: Du sollst die Aufgaben, die zu erledigen sind aufteilen. Und die Aufgaben, die unbedingt zusammen erledigt werden müssen und thematisch eng verzahnt sind, sollten dann in einer Klasse zu finden sein. http://de.wikipedia.org/wiki/Koh%C3%A4sion_(Informatik)

Single Responsibility Prinzip

Das eine schließt das andere mit ein.

Halte Deine Klassen kurz, knapp und überschaubar.

Ebenso Deine Methoden.

So hast Du einerseits leserlichen und überschaubaren Code, der auf der anderen Seite die Fehlersuche ungemein erleichtert.

[ralf_matusch]

vielen dank fürs antworten... ich versuch das mal umzusetzen

[streffin]

lilith2k3 hat zwar absolut recht, aber für einen anfänger im programmieren vermute ich, schwer verdaulich.

(sorry litith, aber wenn einer grad anfängt programmieren, da kann ich mir nicht vorstellen dass der da viel von dem was du geschrieben hast versteht)

das gute alte schwer vereinfachte Auto beispiel ....

du hast eine Klasse Auto.

Sehr simpel definiert (nein das is kein uml diagramm)

Attibute :

Hersteller

Kennzeichen

Treibstoffverbrauch

BenzinMenge

[public] Methoden :

fahren(geschwindigkeit [float], dauerInSekunden [float])

So, das ist deine Blaupause.

Jetzt kannst du in deinem Programm ein Auto erstellen.

Sagen wir einen VW Golf mit Kennzeichen XY Z 0185 mit 10L/100km Verbrauch.

dem Golf kannst du dann sagen, dass er mit 100km/h für 3h fahren soll.

In der fahren Methode würde man dann sinnvollerweise rechnen, wie lange das Auto bei dem gegebenen Spritverbrauch und Tankinhalt fahren kann. Und auch den Tankinhalt entsprechend updaten. Das läuft dann aber in der Klasse, also nicht von außen sichtbar. Von außen hast du nur die Methode fahren, die Rechnerrei läuft dann intern.

Gleichzeitig kannst du noch einen BMW, Mercedes oder was auch immer erzeugen, mit den jeweiligen Attributen, und den auch fahren lassen.

Der Vorteil liegt darin, dass du die Klasse nur 1x schreiben und testen musst. Wenn die Klasse intern richtig rechnet, werden alle Objekte die du aus der Klasse erzeugst das tun was du von ihnen erwartest.

Die Klasse definiert also, was dein Objekt für Eigenschaften und Fähigkeiten hat. Aus der Klasse kannst du 0-N Objekte erzeugen, daher wird die Klasse gerne Blaupause genannt.

Sachen wie abstrakte Klassen, Vererbung, Polymorphismus, Interfaces, innere Klassen, statische Klassen / Methoden usw, das würd ich alles mal Richtung "erstmal mit dem Grundprinzip umgehen können und das vorallem verstehen" schieben.

Falls das zu vereinfacht war, nimmt bitte nicht als "ich halt dich für blöde" persöhnlich.

Ich geh immer nach dem Grundsatz, besser zu vereinfacht und verstanden, als zu korrekt und nicht verstanden

Gruß

Sven

Bearbeitet 29. Juni 2011 von streffin

[lilith2k3]

@streffin

Das mag sein. Die Frage, die sich mir dann stellt ist »Wie einfach ist "einfach"?«

Zumindest ist Deine Erklärung "einfacher" *g*

P.S.: Wobei ich es als problematisch empfinde mit dem "Auto"-Beispiel bzw. "Auto-Fahrzeug"-Vererbungsbeispiel. Anschließend den Leuten das Verhalten wieder abzugewöhnen, und dann mühselig beibringen: favour composition over inheritance... *g*