Fragen zur OOP

[Gast]

Hallo,

ich beschäftige mich seit ein paar Wochen mit der objekt-orientierten Programmierung. Angefangen hat eigentlich alles bei PHP5 vor längerer Zeit, aber dessen Möglichkeiten der oop werden ja oftmals belächelt, schliesslich bin ich bei C# gelandet.
Eigentlich hatte ich gedacht, es hätte bei mir klick gemacht, was das Verstandnis der oop angeht... scheint leider doch nicht ganz so zu sein. (Bem.: ich rede jetzt von der Philosophie dahinter, nicht vom technischen).

Es ist ja immer die Rede davon, dass das ganze Konzept ein Abbild der Realität ist. In vielen Büchern findet man so z.B. das Objekt Auto - es hat als Eigenschaften Farbe, PS, Gewicht, Sitzanzahl... und Methoden wie Fahren, Hupen und Bremsen. in fortgeschritteneren Beispielen ist es dann die Luftfahrzeugklasse, von welcher Hubschrauber, Propellermaschine usw. erben.

Kurz gesagt eine Einheit eben, welche sich selbst verwaltet, seine eigenen Daten und Methoden besitzt, auf Anstöße von Außen reagieren kann, ohne dabei aber zuviel Einblick in sich selbst zu geben (Datenkapselung).

Soweit, so gut.

Nun dachte ich, eine Klasse "Unternehmen" ließe sich doch sicher auch umsetzen. Diese hat Methoden wie z.B. WarenAnnehmen(), WarenVerpacken(), StaplerFahren(), QualitätSichern(), was ein Unternehmen eben so hat.

Das hätte echt gut in mein derzeitiges Bild der OOP gepasst. Etwas, das sich selbst verwalten kann, seine Daten kapselt, wo man was reintun kann und etwas wieder rauskommt, seine Mitarbeiter hat und von Außen betrachtet einfach eine wasserdichte Einheit ist, die sich, einmal getestet, überall einsetzen lässt.

Im Pseudocode könnte man das so ansehnlich machen:

fima = new unternehmen();
firma.WarenAnnehmen(...);
firma.WarenPrüfen();
firma.StaplerFahren(Lager/Datenbank);

(Natürlich auch als statische Klasse denkbar).

Jetzt wurde mir gesagt, dass das in der OOP so nicht gemacht wird. Jede der obigen Methoden bekommt ihre eigene Klasse, das Unternehmen gibts nichtmehr.
Grund dafür ist die Wiederverwertbarkeit des Codes. Das leuchtet mir ein, jedoch steht das bei mir im Konflikt mit dem bisherigen Denken.
Es gibt jetzt eine Klasse Lagerhaus, eine Klasse Staplerfahrer, eine Klasse Qualitätssicherung, eine Klasse Verpacker...
Die Klassen können unabhänngig voneinander Arbeiten, dem Staplerfahrer ist egal, ob die anderen Teile seiner ehemaligen Fima noch existieren, er arbeitet selbstständig. Wiederverwertbarer Code eben - aber es gibt keine große, autonome Einheit mehr.

Obiger Code müsste so aussehen:

new Warenlager().WarenAnnehmen(new Qualitätssicherung.Prüfe(new Staplerfahrer.Hole(Packet))).

Eine imho unschöne Verschachtelung irgendwie, aber das gehört sich anscheinend so. Es kam mir außerdem erst verschwenderisch vor, für jede kleine Sache gleich eine neue Klasse zu erstellen, aber muss wohl so sein ("Da bekommst du eine Klasse, die genau tut, was du willst"), selbst wenn sie nur ein XML-File (=Packet in meinem Beispiel) holt.

Kann mir vielleicht irgendwer helfen, das ganze nochmal verständlicher zu machen warum und weshalb?

Danke

[Hardwaretoaster]

Naja, allgemein kann ich es dir nicht erklären. Mein Ansatz wäre aber: Eine Klasse kann Klassen als Felder haben.

Bsp. in Pseudocode:
FirmaX.Lager.WarenPrüfen()
Die Firma hält also ein Lager Objekt (was zu zB gleich im Konstruktor der Firma initialisieren kannst.

[Monger]

Es gibt da keine festen Gesetzmäßigkeiten. Das wichtigste ist immer noch, dass hinten etwas verständliches, wartbares, erweiterbares und funktionierendes rauspurzelt.

Was du beschreibst, ist deshalb kein Widerspruch. Nach Top-Down Prinzip fängt man halt mit einem großen Klotz an (in deinem Fall das Unternehmen), und versucht dann dort Struktur reinzubringen. Und bei allen Strukturen die gegeneinander klar abgrenzbar sind, oder sich sogar wiederholen bzw. ähneln, bietet es sich an diese als Objekt zu modellieren.
Ein komplexes Problem erfordert selbstverständlich auch ein komplexes Objektmodell, und damit kann es bei großen Aufgaben schonmal passieren dass man ein riesiges Sammelsurium an Klassen erstellt.

Das kann man aber letztendlich nur am realen Beispiel demonstrieren.
Nicht vergessen: OOP soll die Entwicklung von Software VEREINFACHEN!

Nehmen wir mal an, wir würden ein Malprogramm schreiben. Natürlich könnte unser Malprogramm einfach einen großen Satz an Methoden beinhalten:


drawLine(x1, x2, y1, y2)
drawRectangle(x1, x2, y1, y2, rotation)
drawCircle(x1, y2, radius)
...

Klar: jede Methode kann intern dann diese Parameter interpretieren, und dann versuchen irgendwas auf den Bildschirm zu malen. Damit schreibt man immer wieder ganz ähnlichen Code n-mal. Außerdem muss man für jede neue Form wieder eine neue Methode schreiben. Wollen wir wirklich ein paar hundert Methoden haben? Wäre sowas nicht viel schöner?

draw(shape)

Jetzt müssen wir nur noch eine Allgemeingültige Systematik finden wie wir Formen jeder Art beschreiben können, und dann sind wir schon fertig. Und zwar ein für allemal, denn jeder kann ab sofort seine 38-Ecke basteln, und wir können es trotzdem mit genau dem selben Code verarbeiten.

Immer dann, wenn ähnliche Probleme (möglicherweise unbekannter Art) auftauchen, kann Abstraktion den Unterschied zwischen einer Lebensaufgabe und einem einzelnen Nachmittag ausmachen.

[FlashBFE]

Wäre auch meine Antwort gewesen: Du kannst deine Unternehmensklasse behalten und die anderen als geschachtelte Unterklassen davon betrachten.

Wichtiger wäre mir:

Es ist falsch, von jemandem eingetrichtert zu kriegen, wie genau man die OOP (was ja noch viel mehr beeinhaltet) nun zu nutzen hat.
Viele große Klassen kann man einfach nicht sinnvoll weiter unterteilen.
Zu kleine Klassen bringen in der Praxis keinen Vorteil mehr, weil man sie im nächsten Programm einfach nochmal neu schreibt, was schneller geht, als seine alten Programme nach was Brauchbarem zu durchsuchen. Wiederverwendbarkeit ist in der Theorie ein schöner Vorteil, in der Praxis brauchst du das meiste eh nichtmehr, wenn dein Programm fertig ist. Das ist auch der Grund, warum ich nur relativ wenig von meinen Klassen und Prozeduren mit Beschreibungen versehe. Das meiste von dem Zeug wird eh nie ein Kollege je weiterbearbeiten müssen.

Die einzigen drei Klassen, die ich öfter mal wiederverwende, sind für Dateioperationen, Automatisierung von MS Office und Datenbankoperationen. Und das sind jeweils sehr große Klassen geworden, die man nicht mal eben neu geschrieben hat.

Wenn du ein bisschen Orientierung suchst, bist du beim .NET- Framework auch garnicht so falsch aufgehoben. Bei einer so modernen Klassenbibliothek kann man sich viel abgucken.

[Monger]

Wiederverwendbarkeit ist in der Theorie ein schöner Vorteil, in der Praxis brauchst du das meiste eh nichtmehr, wenn dein Programm fertig ist. Das ist auch der Grund, warum ich nur relativ wenig von meinen Klassen und Prozeduren mit Beschreibungen versehe. Das meiste von dem Zeug wird eh nie ein Kollege je weiterbearbeiten müssen.

An der Stelle sollte man wohl auch nochmal klar zwischen Anwendungs- und Bibliotheksentwicklung unterscheiden. Da liegen Welten dazwischen. Ersteres soll einfach nur möglichst schnell fertig werden, zweiteres soll so robust und vielseitig sein, dass man von ersterem möglichst viel darauf aufbauen kann! ;)

Was man über OOP üblicherweise hört, bezieht sich vorwiegend auf Bibliotheken.