Optimales OOP-Beispiel?

[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.

[cofi]

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

Duerfte daher kommen, dass da sowohl Java als auch Python abgefruehstueckt wird.

Damit man mich richtig versteht: Das war keinerlei Empfehlung ich bin nur vor einer Weile druebergestolpert - nachdem ich da gerade durchgestoebert habe, bin ich nochmal gestolpert. Ich glaube nicht, dass ich das noch lesen werde.

@sma Das duerfte der Zweisprachigkeit und dem schwerfaelligen Aufbau geschuldet sein. Irgendwie hab ich das Gefuehl, dass du hier morgen eine perfekte Abhandlung in 10 Seiten abgibst

[jerch]

Ich finde Reale-Welt-Bsp. prinzipiell griffiger als gleich mit UI-Kits zu kommen. Bei der Frage "Wie erklärs ichs meinem Kinde?" finde ich "Autos" ganz passend. (Die schon angesprochenen Fahrzeuge implizieren vllt. auch schon zuviel Abstraktion.)

Ein schöner Nebeneffekt bei einem Bsp. aus der Konstruktionswelt ist auch, daß so Sachen wie class templates/Metaklassen am Bsp. einfach erklärbar werden. Oder Fabrikklassen

Und für die wichtigsten Grundzüge der OOP-Paradigmen reicht Bsp. Auto allemal.

[jbs]

In vielen Beispielen sieht man Tiere, aber das macht wenig Sinn, an Tieren so etwas wie ``__add__`` etc. zu demonstrieren.

Das würde bei Autos auch nicht veil mehr Sinn machen, oder?

[jerch]

Naja, objA + objB hat auch erstmal nix mit OOP zu tun.

__add__() und Co. sind doch einfach nur Spezialfälle, die Python für (meist) mathematische Operatoren vorhält. Das macht bei vielen Objekten wenig Sinn. Das Wissen darum erhöht auch nicht gerade das Verständnis um OOP-Konzepte zu Anfang.

Ich würd sowas als Sonderfälle abhandeln und explizit darauf verweisen, bzw. wenn die erste Verwirrung um die Grundkonzepte abgeklungen ist, das mit einem abstrakteren mathematischen Bsp. einführen.

[DasIch]

Ein schöner Nebeneffekt bei einem Bsp. aus der Konstruktionswelt ist auch, daß so Sachen wie class templates/Metaklassen am Bsp. einfach erklärbar werden. Oder Fabrikklassen

Wenn du "Metaklassen" und "einfach" in einem Satz erwähnst ist die Aussage höchstwahrscheinlich sowieso schon falsch. Ich würde sowas in einem OOP Tutorial gar nicht erst erwähnen. Solange man keine API mit deklarativen Teilen o.ä. hat braucht man fast nie Metaklassen und mal ehrlich wann war dass letzte mal dass hier jemand ein ORM geschrieben hat?

[jerch]

Wenn du "Metaklassen" und "einfach" in einem Satz erwähnst ist die Aussage höchstwahrscheinlich sowieso schon falsch.

Da hast Du Dir die falsche Konnotation in meiner Aussage ausgesucht, der Umgang damit ist keineswegs einfach. Was ich meinte, ist die phänomenologische Bedeutung dieser Konstrukte, die im Freitext an einem solchen Bsp. einfacher zu erklären ist, da die Hierachie dahinter mit Alltagssachverstand begreifbar wird.

Auch glaube ich, daß eine Freitexterklärung ohne sofortige Codeumsetzung in irgendeiner Sprache sinnvoller ist (bzw. man Pseudocode verwenden sollte), da die Sprachen z.T. recht unterschiedliche Wege gehen während eine phänomenologische Betrachtung nicht von der Konzeptmächtigkeit aufgrund syntaktischer Unzulänglichkeiten, die der Leser meist mitbringt, ablenkt.

Letztendlich plädiere ich für ein intuitiveres Verständnis der OOP und behaupte, daß das Konzept auch mit einer intuitiveren Erklärung leichter zu durchdringen ist. Eine gewisse Objektbezogenheit ist unserem Denken zu eigen und kann meiner Meinung nach zur Erläuterung bedient werden.

[sma]

@sma Das duerfte der Zweisprachigkeit und dem schwerfaelligen Aufbau geschuldet sein. Irgendwie hab ich das Gefuehl, dass du hier morgen eine perfekte Abhandlung in 10 Seiten abgibst :twisted:

Das überlasse ich unserem spartanischen König in zwei Seiten. Ich kann nur Programmiersprachen. Und ich schrieb ja schon in diesem Thread früher einmal, dass ich ein MUD für ein gutes Beispiel halten würde. In einem anderen Thread habe ich auch ein simples MUD mal implementiert.

Ich kann mir auch vorstellen, dass TDD/BDD helfen könnten, sich die richtige Denkweise draufzuschaffen. Ian Bicking schlug dafür 2006 mal doctests vor was prinzipiell auch funktioniert, aber gerade nicht hilft, die Denkweise zu erlernen. Aber wahrscheinlich muss man doch noch einfacher anfangen. Ich kann dazu CRC-Cards empfehlen. Entscheidend ist, die Objekte zu erkennen und zu benennen und dann ihr Verhalten zu erarbeiten. Man muss weg davon kommen, ein Datenbankschema modellieren zu wollen und sich dadurch nur auf die statischen Eigenschaften und den Zustand der Objekte zu konzentrieren.

Stefan

[C4S3]

Mahlzeit!

Was ich gut finde/fand und was mir als Hobbyist sehr geholfen hat in OOP einzusteigen:
Objects First
(Ja, die verwenden eben Java, aber der Aufbau und die Entscheidung einfach mal auf die Sprache NICHT einzugehen, sondern auf OOP, finde ich gut!)
Und bei Herrn Weigend ist ein sehr anschauliches Beispiel zu einem Karteikasten-Lernsystem drin. Das fand' ich auch recht nett.

Mit den Fahrzeugen / Tiere / Sonstwas - Beispielen bin ich nie warm geworden. Es lässt den Anfänger meist im Regen stehen, weil dann auf die Schnittstelle zum User nicht eingegangen wird, oder wie die Objekte untereinander kommunizieren.
Gerade bei den Tier/Auto-Beispielen werden zwar fleissig Objekte modelliert, aber mehr als dann ein "paar Tiere auf der Weide", die unabhängig von einander agieren (ohne Zaun, Bauer, Wetter,..), hat man nix.

So ist's für Newbies zumindest oft.