[gelöst] Problem mit Klassendesign

Hallo

ich brauch mal ne Hilfe bei nem Klassendesign. In c# ist es ja nicht möglich mit Mehrfachvererbung zu arbeiten. Daher zeigt das folgende Bild leider einen Fehler.

Siehe Anhang.

Generell zur Aufgabe:
Es gibt eine ganz allgemeine Basisklasse Vehicle. Aus dieser lassen sich Wasser- und Landfahrzeuge ableiten. Landfahrzeuge lassen sich noch einmal unterteilen in Car, Truck etc.
Nun ist es aber so, dass jedes Vehicle irgendwann produziert werden muss. Das kann sowohl ein eigenes Vehicle sein als auch ein Vehicle, was durch eine Firma produziert wird. Bevor ein Vehicle entstehen kann, muss aber feststehen, welche genaue Art es sein soll z.B. eben ein Landfahrzeug vom Typ Truck.

Das Klassendiagramm zeigt diesen Ablauf. Da aber tendenziell jede Ableitung von Wasser- und Landfahrzeugen produziert werden kann, kommt es zur Mehrfachvererbung. Und diese Lösung geht nicht!

Wie löse ich also das Problem???

Bist du dir sicher, dass du so eine Hierarchie brauchst? Welchen Vorteil versprichst du dir durch die Klasse ManufacturedVehicle, würde es da nicht eine Property auch machen, genauso bei CompanyCar und OwnVehicle würde es da nicht eine Owner Property das Problem lösen?

Eine Lösung, wenn du wirklich soviel zu vererben hast, sind Interfaces. Da kannst du soviele auf die Klasse klatschen wie du möchtest.

Hallo latogt,

Es macht überhaupt keinen Sinn "ManufacturedVehicle" von allen anderen Vehiceln abzuleiten.
Es gibt diverse andere Möglichkeiten, dies anders zu lösen, jedoch müssten wir dazu wissen, was du mit der Vererbung erreichen möchtest?

Gruß
Juy Juka

Für mich klingt das sehr wie Informatikunterricht ...
Ich hatte vor kurzem im Unterricht eine ähnliche Situation, bei der wir an jeder Stelle neue Klassen abgeleitet haben. Ich habe daraufhin meinem Lehrer "vorgeschlagen", die Sache anders zu lösen, et voilà ... Vielleicht versuchst du das mal (wenn es sich denn um Unterricht handelt)?

Also wichtig ist eigentlich zu wissen, welches Vehicle genau produziert werden will. Daher muss die Klasse ManufacturedVehicle wissen, um welches Object es sich handelt.

Die Logik dahinter ist: Es soll ein Vehicle produziert werden. Das Vehicle kann dabei egal was sein (ein Car, ein Truck etc.). Bevor man ein Vehicle produziert muss man aber genau wissen, welches dieser Möglichkeiten es ist. Ist es dann produziert, verpasst die Company noch Label und Model Name. Es kann natürlich auch von jemanden privates produziert werden, wodurch kein Label und Model vergeben werden soll. Daher die Klasse, die ManufacturedVehicle und deren Ableitung ob es nun von einer Company oder von jemand selber erstellt worden ist. ManufacturedVehicle könnte z.B. eine Art Bauanleitung sein, die von einer Company benutzt wird oder von einer Privatperson. Die Company erweitert das Vehicle aber noch und verpasst ihr einen eigenen Namen.

So viel zum Sinn hinter der Aufgabe.

Wenn ein jedes Vehicle ein bestimmtes Label und eine bestimmte Modellnummer bekommen, gib der Superklasse diese Properties und setze diese in OwnVehicles auf einen Leerstring oder null (je nachdem welchen Typ diese Properties haben)

In der Klasse die den Objekten dann das Label und das Model zuweist, prüfst du mit is einfach welcher Typ das ist. Die Klassen ManufacturedVehicle und die darunter sind, meiner Meinung nach, sinnlos.

Das widerspricht aber der philosophie der OOP. Weil die oberste Klasse möglichst abstract und allgemein sein soll. Kann ja sein, dass im nachhinein eine Klasse angebunden werden soll, die diese Properties nicht hat. Ferner ist es ja auch nicht schön, wenn du dann in nem anderen Object die auf NULL setzen musst. Abfragen kann man sie dann ja trotzdem noch und bekommt dann nur NULL raus.

Hallo latogt,

erstelle eine Company-Klasse (Factory-Pattern) welche Vehicles produzieren kann. Das Vehicle hat dann eine Eigenschaft (z.B. "Label") welche einen Verweis auf die Factory enthält aus der das Vehicle stammt. Der Verweis muss dem Vehicle im Konstruktor übergeben werden, damit es nicht möglich ist ein Fahrzeug ohne Fabrik zu erzeugen.

Die ManufacturedVehicle Klasse ist dann unnötig da es ja vor dem Verlassen der Fabrik überhaupt kein Vehicle gibt und Vehicles nur in der Fabrik gebaut werden können. Wenn du tatsächlich behaupten willst das jemand ein Fahrzeug ohne Fabrik oder Werkstatt bauen kann, dann kannst du das Label auf null setzen. 😉 Null ist ein legetimes mittel in der OO um zu sagen das irgendetwas nicht exestiert.

Wenn du nicht willst das man über das Label auf die gesamte Factory zugreifen kann, kannst du mit einem Interface (ILabel) arbeiten welches z.B. nur den Namen und die Modelbezeichnung des produzierten Fahrzeugs preisgibt.

Gruss
tscherno

Jopp sehe ich auch so, erstelle eine VehicleFactory klasse, die dann die verschiedenen Klassen rausgibt. Die klassen implementieren ein gemeinsames Interface und du kannst per "is" rausbekommen nach dem produzieren um welche Klasse es sich handelt.

Du hast es ja schon gesagt, du musst wissen welcher Typ Fahrzeug produziert werden will, das schreit nach der Factory Pattern, und dem Interface IVehicle.

OwnVehicle / CompanyVehicle sind sinnlos, mach einfach wie schon erwähnt wurde im Interface direkt eine property owner und fertig.

Factory ist nicht gleich Factory, wenn du eine Factory haben möchtest, die alle Vehicle erstellt, ist der Rückgabetyp IVehicle richtig. Hast du beispielsweise die Factory Auto muss der Rückgabetyp ICar sein. Wenn du noch detailierter werden willst, muss der Rückgabetyp der Factory Audi IAudi sein usw.

Audi kann anschließend beispielsweise direkt von IManufacturerVehicle (oder IManufacturerCar) abgeleitet sein.

Weiterhin sollte genau gewählt werden, was es für ein Factory verwendet werden soll, statische Factory-Klasse oder eine abstract-Factory-Klasse.

Hallo kleines_eichhoernchen,

Was hier im Thread gemeint ist, ist das Abstract-Factory Pattern.
Meistens wird diese Unterscheidung nicht gemacht, da man meistens das Abstract-Factory Pattern nimmt.

Gruß
Juy Juka