Optimales OOP-Beispiel?

[Leonidas]

Hallo!

Ich wollt' mal eine Diskussion anstoßen, was wohl das Optimale Beispiel für Objektorientierung wäre. Was sollte man modellieren?

In vielen Beispielen sieht man Tiere, aber das macht wenig Sinn, an Tieren so etwas wie ``__add__`` etc. zu demonstrieren. Ein weiteres Standardbeispiel wären geometrische Formen, aber an diesen die Special-Methods zu demonstrieren wäre wohl etwas zu umfangreich. Dummerweise ist das aktuell das geeignetste was mir einfallen würde.

BlackJack hat mal vorgeschlagen Widgets eines UI-Toolkits als Beispiel zu nutzen, aber ich bin mir auch nicht sicher ob das nicht erstens zu umfangreich ist und zweitens hätte ich gerne etwas was es in der Realen Welt(TM) gibt, damit die Leser die nichts mit Widgets gemacht haben, sich darunter was vorstellen können.

[burli]

Interessante Idee und eine gute Frage. Vielleicht sollte man erst einmal definieren was das Beispiel alles demonstrieren soll. Da es wohl für Python sein soll fallen wohl Dinge wie Private Members und Getter/Setter raus.

Außerdem sollte es wohl etwas sein was auch weniger versierte Programmierer verstehen.

[BlackJack]

@Leonidas: Das Problem bei OOP-Beispielen ist IMHO immer, dass man bei kleinen Spielzeugbeispielen die Vorteile nicht richtig sieht.

Wo Du "reale Welt" ansprichst, da sind GUIs eben gut geeignet, weil dort alle Aspekte wie Vererbung und Polymorphie an echten Beispielen demonstriert werden können, also etwas, das man in realen Programmen auch so modellieren würde.

Also da wo bei "realen" Beispielen die Motivation fehlt. Warum sollte man Tiere modellieren und bei Kuh, Papagei, und Goldfisch dann `sag_was()` aufrufen. Also ein optimales OOP-Beispiel wäre in meinen Augen schon einmal eines, wo ein echtes Problem zugrunde liegt, dass gelöst werden will.

Und bei diesem Spielzeugbeispielen stört mich auch oft, dass sie selten dem KISS-Prinzip folgen und unnötige Komplexität hinzufügen. Da wird dann von einem Basistier geerbt, nur um mal zu vererben, nicht weil das *nötig* wäre. Das ist was für Javaaner, die können dann auch gleich noch zwei dutzend Interfaces definieren, die man vielleicht mal gebrauchen kann, oder halt auch nicht.

Man kommt in Python halt "leider" oft sehr weit ohne Vererbung, weil Klassenhierarchien nicht aus Typgründen, sondern nur bei gemeinsamen Verhalten von Klassen entstehen.

[burli]

Ich finde Personen-"Datenbanken" immer recht anschaulich. Als Basisklasse ein Personenobjekt mit den gemeinsamen Merkmalen und vererbte Klassen mit besonderen Merkmalen für bestimmte Gruppen.

Weiß aber nicht ob man damit auch alle anderen OOP Aspekte sinnvoll abdecken kann

[audax]

Natürlich, damit kann man auch gut Polymorphie zeigen!
if Lisa + Markus == ♥: ...

[gerold]

Hallo!

Ich mag die Lagerverwaltung recht gerne -- obwohl man hier ziemlich schnell auch in der Komplexität übertreiben kann.

- Läger - Regale - Paletten

- Regale: Unterschiedliche Lagertemperaturen, Feuchtigkeit, Kosten, mögliche Palettengrößen, belegte und freie Palettenplätze...

- Paletten: Unterschiedliche Palettengrößen und -arten

- Paletten werden mit Waren bestapelt/befüllt - Liste mit Artikelnummern, Seriennummern, Ablaufdatum jedes einzelnen Artikels, gewünschte Lagertemperatur,...

- Paletten, die in Regale eingelagert werden

- Paletten, die zwischen Regalen umgelagert werden

- Hinzufügen von Regalen an ein Lager

- Zusammenlegung von Lägern

Wie gesagt: Man kann es in der Komplexität auch übertreiben.

lg
Gerold

[burli]

Natürlich, damit kann man auch gut Polymorphie zeigen!
if Lisa + Markus == ♥: ...

Was ist daran falsch? Wenn es hieße if Lisa==Markus: würde ich mir schon eher Gedanken machen

@Gerold: Lager ist noch besser, stimmt

[.robert]

Ich finde Fahrzeuge super.

Es gibt verschiedene Arten von Fahrzeugen (Luft, Land, Wasser), die wiederum Unterarten haben (Luft-> Flugzeug/Helikopter, Land->Auto/Motorrad/Lastwagen).

Diese haben wiederum Klasseneigenschaften (Anzahl der Räder) und Instanzeigenschatften (Marke, Farbe etc).

Jedes Fahrzeug besteht aus Einzelteilen (-> Aggregation), die wiederum bestimmte Eigenschaften haben. So hat z.B. jedes Fahrzeug einen Motor, der eine bestimmte Leistung hat. Auch könnte man Motor wieder vererben nach Diesel, Benziner, Turbine etc.

... damit bekommt man schon sehr komplexe Sachen hin.

Aber ich denke es ist nicht unbedingt sinnvoll zu versuchen, ''alle'' Eigenschaften der OOP an einem Beispiel erklären zu wollen, sondern sich für jede Problemstellung ein eigenes, besonders gut passendes, Beispiel zu konstruieren.

[BlackJack]

Aber genau da bekommt man doch schon wieder Probleme. Es werden willkürliche Hierarchien aufgebaut, die gar kein Problem lösen, sondern einfach nur um ihrer selbst willen existieren. Ein Hovercraft erbt jetzt von was? `Luftfahrzeug`, `Landfahrzeug`, `Wasserfahrzeug`, oder einer Kombination davon? Solange diese drei und die Basisklasse `Fahrzeug` nicht konkretes Verhalten implementieren, das auch von entsprechenden konkreten Fahrzeugen benutzt wird, ist das IMHO ein blödes Beispiel.

Und was ist die Anzahl der Räder einer Planierraupe? Ist "Camouflage" eine Farbe? Aus welchen Einzelteilen besteht ein Fahrzeug? Karosserie als ganzes, als Einzelteile die am `Fahrzeug` hängen, oder über eine weitere Klasse `Karosserie` an das `Fahrzeug` gebunden?

Wo hört man mit der Zerlegung der "Realität" in Objekte auf? Das kann man nur beantworten, wenn man eine konkrete Aufgabe lösen will, und nicht wenn man einfach so ins Blaue Klassen bastelt, ohne überhaupt ein Problem zum Lösen zu haben.

[Leonidas]

@Leonidas: Das Problem bei OOP-Beispielen ist IMHO immer, dass man bei kleinen Spielzeugbeispielen die Vorteile nicht richtig sieht.

Richtig, deswegen Suche ich etwas worauf man Inkrementell aufbauen kann, aber ohne schon externe Libs zu benutzen. Bei GUI-Libs baut man auf den Strukturen die die Toolkits bieten auf, eignet sich für Demonstrationszwecke weniger da zu komplex. "Abstrakte" GUIs, also solche die kein Toolkit nutzen und bei dem man sich die Fenster vorstellen müsste fallen raus, da der Leser das schlecht selbst testen könnte.

Bisher scheint mir das Lagerverwaltungs-Beispiel von Gerold am interessantesten, da es sowohl ein reales Problem modelliert und eben beliebig einfach oder kompliziert werden kann. Danke aber auch für alle anderen Vorschläge. Falls noch jemand gute Ideen hat: nur her damit.

Falls sich jemand wundert wofür ich das brauche: aufgrund der Kritik am Openbook und des Releases von Python 3 würde ich gerne eine Dokumentation zu OOP in Python 3 schreiben. Und zwar diesmal etwas was auch auch semantisch sinnvoll ist nicht nur im Hinblick "es funktioniert". Also ich hoffe dass die Beispiele dann Best-Practice sind, auch in einem gewissen Hinblick auf OOA/OOD. Daher werdet ihr wohl noch mehr so grundsätzliche Fragen sehen - es ist mir auch wichtig, dass ich Meinungen von anderen dort einfließen lasse. Für mehr Infos zu dem Thema könnt ihr mich via Jabber ansprechen, denn ich mag noch nichts öffentlich versprechen.

[Pekh]

Ich habe in letzter Zeit mal ein wenig mit der Modellierung von Verkehrssystemen gespielt. Wenn man unter der Prämisse arbeitet, daß alle OOP-Konzepte an einem Themenbereich demonstriert werden sollen, ist das glaube ich ein recht dankbarer Bereich:

Auf der untersten Ebene könnte man Straßen / Kreuzungen modellieren. In der nächsten Ebene dann Haltestellen und Linien. Haltestellen gibt es als einfache Halte- und als Umsteigepunkte. Dann gibt es verschiedene Verkehrsmittel (Straße / Schiene /Kombinationen). Je nach Zweck des Modells kann man noch einzelne Fahrgäste modellieren. Es gibt Container, in denen andere Elemente "aufbewahrt" werden ("Netz", "Linie") und andere Objekte, die bestimmte Eigenschaften und Methoden zur Verfügung stellen (Fahrzeug: Berechnung Durchschnittsgeschwindigkeit / Auslastung etc).

Vor allem läßt sich das ganze beliebig fein modellieren. Von recht abstrakten aber trotzdem sinnvollen Beispielen bis hin extrem detaillierten Modellen läßt sich so ziemlich alles machen. Vor allem läßt es sich auch gut Schritt für Schritt komplexer gestalten.

[Hyperion]

Wenn man sich im akademischen Umfeld bewegt wäre auch das übliche "Bibliotheken"-Beispiel eine Möglichkeit. Bei den dort verfügbaren Medien könnte man anfangen (book, article, usw) und versuchen eine sinnvolle Hierarchie aufzubauen. Orietieren könnte man sich da u.U. an BibTex und den dort verfügbaren Attributen.

Wenn man nun noch die Medien in Institute, Bibliotheken und Regale einräumt kommt man schon in die Nähe von Gerolds Lager Beispiel.

Zugegeben ist das wenig originell - aber dafür für jeden Studenten greifbar

[lunar]

Wenn man sich im akademischen Umfeld bewegt wäre auch das übliche "Bibliotheken"-Beispiel eine Möglichkeit. Bei den dort verfügbaren Medien könnte man anfangen (book, article, usw) und versuchen eine sinnvolle Hierarchie aufzubauen. Orietieren könnte man sich da u.U. an BibTex und den dort verfügbaren Attributen.

Wenn man nun noch die Medien in Institute, Bibliotheken und Regale einräumt kommt man schon in die Nähe von Gerolds Lager Beispiel.

Zugegeben ist das wenig originell - aber dafür für jeden Studenten greifbar

Bibliotheken? Heute gibt's das Internet, welcher Student braucht da noch Bibliotheken

[sma]

Zwei Beispiele, die ich gerne je nach Kontext benutze sind Schach und ein Textadventure/MUD. Letzteres funktioniert IMHO recht gut, weil man Räume, Verbindungen, Gegenstände, Personen usw. modellieren kann, Gegenstände Container für andere Gegenstände sein können, Personen spezielle Gegenstände - oder auch nicht - hier kann man prima das Dilemma Vererbung zum Codesparen vs. Vererbung als Subtyprelation ansprechen und schließlich kann man auch zu nicht-realen Objekten wie Worten oder Befehlen kommen. Verhalten gibt es jede Menge, Gegenstände kann man nehmen, weglegen, benutzen, Personen können sich bewegen, usw.

Wer dazu keine Draht hat, kennt aber wahrscheinlich Schach mit seinen Figuren, dem Spielbrett und Regeln.

Ich würde zustimmen, dass das Problem eine gewisse Grundkomplexität haben muss, um überhaupt ein "Gefühl" für OO zu vermitteln. Von dem klassischen Bankkonto-Beispiel halte ich daher nicht so viel.

Stefan

[AntagonisT]

Falls sich jemand wundert wofür ich das brauche: aufgrund der Kritik am Openbook und des Releases von Python 3 würde ich gerne eine Dokumentation zu OOP in Python 3 schreiben. Und zwar diesmal etwas was auch auch semantisch sinnvoll ist nicht nur im Hinblick "es funktioniert". Also ich hoffe dass die Beispiele dann Best-Practice sind, auch in einem gewissen Hinblick auf OOA/OOD. Daher werdet ihr wohl noch mehr so grundsätzliche Fragen sehen - es ist mir auch wichtig, dass ich Meinungen von anderen dort einfließen lasse. Für mehr Infos zu dem Thema könnt ihr mich via Jabber ansprechen, denn ich mag noch nichts öffentlich versprechen.

Huhu, was ist denn aus deinem Projekt geworden?

[Leonidas]

Naja, der gute Wille ist da. Und grob 2 Seiten Text.

[AntagonisT]

Naja, der gute Wille ist da. Und grob 2 Seiten Text.

Also ich würde mich freuen, da mal was kompetentes lesen zu dürfen.

[cofi]

Nuja es gibt Building Skills in OOP von Steven Lott: http://homepage.mac.com/s_lott/books/oodesign.html

Allerdings hab ich das noch nicht gelesen.

[sma]

Hm. Über 200 Seiten für ein doch recht einfaches Beispiel? Das muss doch wesentlich kürzer gehen bei gleichzeitig komplexerem Beispiel.

Stefan

[Leonidas]

Und dann ist der Code-Stil in dem Buch relativ... seltsam.