Objektorientiertes Programmieren

Ich bin ein alter Java-Fuchs und kenne mich daher ganz gut mit dem OOP aus, aber bei meiner jetzigen Aufgabe habe ich da so meine Probleme.

Es geht darum, dass ich nicht weiß, was ich alles in die eine Klasse an Methoden reinstecken soll, bzw. besser ein neues Objekt kreiieren soll.

Man stelle sich folgendes Problem vor:
Man hat ein Klasse Auto, die hat Attribute, wie u.a. die Wagenfarbe. Jetzt besteht meine Hauptaufgabe darin, Methoden zu entwickeln, die die Farbe des Wagens ändern. Und auch Methoden, die z.B. das Auto tunen.
Diese Methoden sind sehr komplex, da sie die Hauptarbeit des Programms machen.

Nach meinem objektorientierten Verstehen, verändern diese Methoden die Attribute des Objekts und gehören somit in die selbe Klasse.
Das Problem ist aber, dass ich dann eine riesen aufgeblähte Klasse Auto habe. - Deshalb habe ich mir dann gedacht, dass ich eine neue Klasse Färberei und Werkstatt schreibe. Diese Klassen bekommen dann ein Auto als Parameter übergeben, bearbeiten es und hinten raus kommt das modifizierte Auto. - Das gefällt mir dann aber auch nicht so richtig unter dem Punkt OOP, da ja dann die Färberei und die Werkstatt auf die Attribute von Auto zugreifen müssen.

Was ist die eleganteste Lösung?

Nebenbei habe ich mir überlegt (da ich mit c++ arbeiten muss), einfach die Klasse Auto von der Lackiererei und der Werkstatt erben zu lassen.

Wo ist das Problem? OOP ist doch ein Hilfsmittel, um solche Situationen weiter zu abstrahieren. Wenn du dir deine Auto-Klasse mal genauer betrachtest und etwas darüber nachdenkst, dürfte dir auffallen, dass ein Auto eine spezielle Art von Fahrzeug ist und als solche nicht von einer Werkstatt und auch nicht von einer Lackiererei erbt, sondern von der Basisklasse der Fahrzeuge.
Ein Fahrzeug ist wiederum eine spezielle Art der Fortbewegungsmittel, und so weiter...

Fahrzeuge haben grundlegende Eigenschaften wie beispielsweise die Anzahl der Räder, die Größe oder die Höchstgeschwindigkeit. Da du auch davon ausgehen kannst, dass irgendwo sehr weit oben eine Basisklasse für alle sichtbaren Gegenstände existiert, wird diese dann letztenendes die Farbgebung implementieren.

Beispiel:

Natürlich kannst du jetzt von deinem Lackiererei-Objekt die Farbe des Objektes verändern, was ja auch nicht ganz unlogisch ist. Die Klasse AutoWerkstatt als "Konstruktor" für die Auto-Klasse zu benutzen, ist natürlich auch eine Idee. Dazu müsstest du in der Werkstatt eine Methode namens "makeCar" einfügen, die ein Auto-Objekt zurückgibt. Diese Methode erstellt dann das Auto mit den gewünschten Eigenschaften.

Übrigens lässt sich das noch weiter verfeinern: Mit einer Klasse GolfWerkstatt wirst du die Methode "makeCar" aus der Klasse AutoWerkstatt überschreiben müssen, damit diese nicht mehr irgendwelche Autos zurückgibt, sondern nur noch Wagen der Golf-Klasse. Mit dem Aufruf der Basismethode kannst du hier aber natürlich auch auf das allgemeine Auto zugreifen, das die darüberliegende Hierarchieebene der Methode zurückgibt.

Mit einer klaren Vererbungshierarchie lässt sich da einiges machen, du musst nicht alles in einer Klasse implementieren.
(Was natürlich nicht heißt, dass Klassen nicht schonmal mehrere tausend Zeilen groß werden können.)

Das könnte man natürlich noch viel weiter ausführen, aber ich denke, das sollte erstmal als kleine Starthilfe reichen.

Anderer ansatz: Auto ist ein Kontainer-Objekt für verschiedenste (kompliziertere) Objekte (z.B. Motor, Lack, Getriebe, CD-Anlage usw.). Diese Objekte können dann ausgebaut und ersetzt werden (Tuning-Werkstatt tut das dann). Somit kann das Auto relativ simpel bleiben.
Einzig für die Objektklassen die eingebaut werden sollen, müsste ein definiertes Interface zur Verfügung stehen, dass z.B. das Auto leicht auf die PS Daten des Motors zurückgreifen kann, egal ob das nun ein Diesel oder was auch immer ist. Für das Auto ist es immer nur ein Motor.

Hallo!

Bin auch squeakers Meinung.
Erstelle die Klasse etwa nach dem Composite Pattern der GoF und verwende Delegates die die jeweilige Domänenkomplexität kapseln. Nach außen hin gibts dann ein einheitliches Interface das nach dem Facade Pattern den Zugriff / Interaktion mit dem Objekt kapselt.

Gruß Tom

Nun mal Butter bei die Fische!

Ich muss ein Bildanalyse-System entwickeln.

Dabei habe ich mir folgenden Objekte überlegt.

Klasse:
Dokument
Attribute:
- Informationen
- Bild
Methoden:
- Segmentierung
- Klassifikation
-----------------------
Klasse:
Bild
Attribute:
- Höhe, Breite
- Header
- Pixel[][]
Methoden:
- Rauschfilterung
- ...
-----------------------
Klasse:
Pixel
Attribute:
- Farbe
- Farbtiefe
Methoden:
- Binarisierung (setzt Farbe auf s/w)
- Grauwerterzeugung (setzt Farbe auf Grauwert)
-----------------------

Sowie natürlich get- und set-Methoden für alle Attribute.

Ihr seht, die Hauptaufgabe bei diesem Projekt sind die Methoden, die das Pixel/Bild verändern, und nachher die Informationen extrahieren.

Laut Aufgabenstellung soll ich diese Methoden als Module (der mir die Aufgabe erteilt hat, hat keine Ahnung von OOP) bereitstellen, so dass sie leicht weiterentwickelt und erweitert werden können.

Deshalb denke ich jetzt nach, jeweils eigene Klassen (Farbverarbeitung, Rauschfilterung, Segmentierung, ..) zu implementieren.

Die Frage für mich ist nun, was ich diesen aussenstehenden Methoden als Parameter übergeben soll, das ganze Objekt Bild bzw. Pixel, oder nur das Attribut, was verändert werden soll