Modell meines Infoprojekts in OOP

[Niko]

Zitat von devnull:

Ist es erlaubt, in der Klasse Auto (sie besitzt das Objekt Fahrer da im protected...) eine public-Methode namens "getFührerscheinklasse" einzurichten?

Verboten ist es sicher nicht , entspricht aber auch nicht dem Sinn der OOP, denn das Auto hat mit dem Führerschein des Fahrers nichts zu tun. Wie wär's stattdessen mit Auto.getFahrer.getFuehrerscheinklasse?

[Speedmaster]

Fangs doch anderst an:

TNukleon -> TProton / TNeutron / TElektron -> TMolekül....

Wenn du das fertig hast bis zum Menschen, ( und das alles in OpenGL darstellst, ) gehst in die Geschichte ein!

[Khabarakh]

[ignore Speedmaster]
Warum keine Property "Fahrer"? IMO sollte man von "außen" keine "Get..."/"Set..."-Methoden sehen können.
[/ignore Speedmaster]

[edit] Jedes Auto ist eine Fabrik ?

[alcaeus]

Zitat von Niko:

Wie wär's stattdessen mit Auto.getFahrer.getFuehrerscheinklasse?

Und wie waers mit einer Property auf den TFahrer-Member? Das ist der Weg, den man in der OOP beschreitet. Wenn du naemlich dem Fahrer des Autos eine Verletzung zufuegen willst (dummes Beispiel, aber egal), musst du schreibend zugreifen. AFAIK ist das mit der Funktion nicht wirklich moeglich (ich kann mich aber auch irren). Also:

Delphi-Quellcode:

type TAuto = class(TObject)
  private
    fFahrer: TFahrer;
  published
    property Fahrer read fFahrer write fFahrer;
end;

Und schon hast du deinen Zugriff. So sollte man es uebrigens fuer alle Member machen, auf die man von aussen zugreifen muss

@Speedmaster: Wenn du etwas sinnvolles beitragen kannst, spricht nichts dagegen. Tipps wie deiner helfen aber nicht wirklich

Greetz
alcaeus

[devnull]

Mit propertys hab ich noch nie gearbeitet. Was es nich so alles gibt?! Das schau ich mir erst nochmal an.
Bis jetzt, hol ich mir die Information über Funktionsaufrufe (sollte auch in OOP legal sein):
  Auto.getFahrer.getfKlasse; Soll genug sein für heute

mfg
devnull

[leddl]

Also mit Properties zu arbeiten ist nicht besonders schwer und es ist verdammt praktisch. Dadurch kannst du vor allem bewirken, daß nur gültige Daten angegeben werden. Du könntest also zB beim Erzeugen des Fahrers prüfen, ob es die angegebene Führerscheinklasse überhaupt gibt, usw.

[Hansa]

Das mit dem TMann/TFrau ist ja wohl geklärt durch TMensch. Du hast doch nach Polymorphie/Vererbung gefragt. Und was hat das Auto mit der Fabrik gemeinsam ? Nichts ! Du willst wohl lediglich darauf hinaus, daß die Fabrik mehrere hat. Bei dem Thema geht es aber darum, welche Dinge sich wiederverwenden lassen, wegen gemeinsamer Eigenschaften. Das ist OOP ! Was nützt also jetzt der Fabrik eine Eigenschaft "Viertürer", die sie von TAuto erbt ? Für das Auto ist das eventuell aber schon wichtig. Die Fabrik hat also mit dem Auto genauso wenig zu tun, wie dieses mit dem Fahrer. Siehe die Schuhgröße. Die ist ja jetzt tatsächlich in Deinem Diagramm drin. Und die habe ich nur deshalb gewählt, weil sie bei dem Auto völlig überflüssig wäre.

Du mußt das Prinzip der Vererbung usw. nochmals komplett überdenken. Und zwar in der Richtung, was jetzt wo gebraucht wird. Dein Beispiel ist auch nicht so gut geeignet, das alles zu erklären. Weil man kaum eine Hierarchie darstellen kann.

So könnte die aussehen :

Delphi-Quellcode:

TKonzern -> TFabrik (erbt vom Konzern alles, hat aber zusätzlich eigenen Standort)

TFahrzeug -> TAuto (4 Räder) -> TPkw -> TKombi (zusätzlich Kofferraumvol.)
                             -> TLkw (x Achsen)

TMensch (egal, ob Führerschein usw.) -> TFahrer

Bei den 3 Basisklassen sehe ich kaum verwertbare Sachen für OOP. Du schleppst eher mehr Ballast mit rum.

Edit : zu früh abgeschickt.