Wie erklärt man Ahnungslosen die Objektorientierung?

[Gast]

Fang am besten mit einem Beispiel-Problem an, zerlege es genau, sag, was Nachteile anderer Lösungen sind und erkläre, wieso OO hierfür gut ist. Viele Dozenten machen den Fehler, dass sie erst mit zusammenhanglosen Fakten wie

- Eine Klasse ist ein Bauplan für ein Objekt.
- Ein Objekt hat Eigenschaften (Attribute) und kann Aktionen (Methoden) ausführen.
- Objekte kommunizieren über definierte Schnittstellen (Attribute und Methoden) miteinander.
- Aus der Kommunikation bzw. Interaktion entsteht die Programmlogik
- Kapselung, Polymorphie, Vererbung (da wirds schon schwieriger mit einer verständlichen Erklärung)
- dadurch Modularität und bessere Übersichtlichkeit/Wiederverwendbarkeit/Wartbarkeit

kommen und jeder frägt sich dann "interessiert mich nicht, warum überhaupt"?
Im besten Fall halten sie dich für einen Freak.

[Gast]

Und in kurzer Zeit geht das eigentlich nicht. Ich sag mal, dass jeder wenigstens eine Handvoll kleine Klassenhierarchien selber designen muss, um die Idee vollständig zu verstehen. Zumindest die Ideen der Objektbasiertheit wie Kapselung kann man aber schnell einsehen. Vererbung wirklich richtig einzusetzen, braucht zumindest schon ein wenig Erfahrung.

[volkard]

um was geht's eiegntlich? willste dennen programmieren in modernem c++ (naja, templates lassen wir mal weg) im gegensatz zu fortran beibringen? dann kannste gut in 90 minuten ein beispiel sehr praxisnah am code mit beamer machen. oder willste was anderes vorstellen und in 15 minuten vorher was über oo sagen? dann geht's halt nicht anders, als ne liste von buzzwords an die wand zu werfen, raffen kann man in 15 minuten sowas nicht.

[volkard]

Thomas++ schrieb:

Aber die verstehen den Zusammenhang mit dem Programm nicht. (Maschis halt. )

und hier mußte ansetzen. das problem haste gut erkannt.

Aber am besten wird wohl sein, falls die Frage kommt:
- Eine Klasse ist ein Bauplan für ein Objekt.
- Ein Objekt hat Eigenschaften (Attribute) und kann Aktionen (Methoden) ausführen.
- Objekte kommunizieren über definierte Schnittstellen (Attribute und Methoden) miteinander.
- Aus der Kommunikation bzw. Interaktion entsteht die Programmlogik
- Kapselung, Polymorphie, Vererbung (da wirds schon schwieriger mit einer verständlichen Erklärung)
- dadurch Modularität und bessere Übersichtlichkeit/Wiederverwendbarkeit/Wartbarkeit

setzen, sechs.
die jungs sind kluge ingenieure. du darfst ihnen sagen, was der kern der sache ist. klassen sind begriffe. und oo programmieren ist etwas ganz anderes, als hin und wieder ein oo-feature zu benutzen. mit deiner liste der features bringste denen nix näher. der oo coder hat die objekte im blick und deren interkationen. bring ihnen die äquivalenz ziwschen "jemand schickt einem anderen objekt eine nachricht und wartet auf die antwort" und "jemand ruft eine funktion auf, deren erster parameter das subjekt ist" bei.

in c schrieb man noch fwrite(FILE* file,void* data,int len) nebst fwrite(datei,"hallo",5). naja, man hat sich angewönht, das subjekt einheitlich this zu nennen. später also fwrite(File* this,void* data,int len) nebst fwrite(datei,"hallo",5). und dann kam syntaktischer zucker, daß man in die struktue schrieb write(void* data,int len) nebst datei.write("hallo",5) und der this-zeiger wird vom compiler im geheimen übergeben. aber an der verwendung ändert das nix. (oo entmystifizieren erstmal.)

und dann kommt halt das schwierige. was ist gute oo? eine klasse hat nur einen zweck. class Datum imer verwenden, wenn datumsangaben gebraucht werden. *immer*. und schin gibt es kein jahr-2000-problem. man kann an einer stelle, in der klasse Datum nämlich, die sache reparieren, neu compilieren und fertig. damit haste die wartbarkeit. und dann stell vor, wie mehrere leute zuzsammenarbeiten und der chef feuert den, der am fehler schuld ist. also macht jeder recht sichere schnittstellen, macht assert rein und so viel wie möglich private. netterweise erwischt jetzt der compiler (oder wenigstens frühes assert) so enorm viele fehler (enorm viel mehr, als man in c schaffte, warum eigentlich?), daß man viel komplexere probleme schaffen kann.

[Thomas++]

Ich will denen neben den Programmfunktionen eigentlich nur ein wenig erklären, wie ich das Softwareproblem strukturiert habe.
Die Frage ist, in welcher Tiefe ich es ihnen zumuten kann.

Mit dem ausgelieferten Programm sind sie absolut zufrieden, mit der inneren Struktur wahrscheinlich hoffnungslos überfordert.

Ich muss also möglichst an der Oberfläche bleiben. Wahrscheinlich werde ich daher eher von Modulen reden, als den Klassen- und Objektbegriff ausgiebig zu verwenden, ansonsten kommen Fragen, die in der Kürze der Zeit sowieso nicht verständlich geklärt werden können.

[volkard]

Thomas++ schrieb:

Ich will denen neben den Programmfunktionen eigentlich nur ein wenig erklären,

also die werden allein keine große änderung am code machen? dann müssen sie oo nicht anz raffen.

wie ich das Softwareproblem strukturiert habe.
Die Frage ist, in welcher Tiefe ich es ihnen zumuten kann.

mir scheint, dann biste sehr gut dabei miut deinem ansatz. so ein bißchen kapselung und so. das kennen die auch in fortran und c (oder wünschen es sich).

Ich muss also möglichst an der Oberfläche bleiben. Wahrscheinlich werde ich daher eher von Modulen reden, als den Klassen- und Objektbegriff ausgiebig zu verwenden, ansonsten kommen Fragen, die in der Kürze der Zeit sowieso nicht verständlich geklärt werden können.

naja, kannst ruhig "Klasse" sagen. wäre besser. natürlich sagste vorher, daß ne klasse ein modul ist.

[Thomas++]

Nee, für das Problem war ich die einzige Kompetenz in der Abteilung. Da schraubt keiner mehr irgendwas am Code rum.
Aber die wollen halt mal über ihren Tellerrand schauen.

volkard schrieb:

du darfst ihnen sagen, was der kern der sache ist. klassen sind begriffe.

Ohne Beispiel werde ich da wohl in lauter leere Gesichter gucken.

Ich denke, es ist ganz gut, es in Form eines realen Beispiels zu erklären (Ein Auto hat Räder und kann fahren...)

Wobei, da werden sie wahrscheinlich genauso blöd gucken.

Gruß, Thomas.

[volkard]

Thomas++ schrieb:

volkard schrieb:

du darfst ihnen sagen, was der kern der sache ist. klassen sind begriffe.

Ohne Beispiel werde ich da wohl in lauter leere Gesichter gucken.

Ich denke, es ist ganz gut, es in Form eines realen Beispiels zu erklären (Ein Auto hat Räder und kann fahren...)

Wobei, da werden sie wahrscheinlich genauso blöd gucken.

jo.
vielleicht was einfacheres, was, was auch was echtes tut.

die klasse Datum.
class Datum{int tag; int monat; int jahr;...};
und class Mitarbeiuter{Datum geburtsDatum; string name;}

mit bool less(Datum& a,datum& b);//musst du ausprogrammieren mit denen
und int diff(Datum& a,Datum& b);//reicht, festzustellen, wie schwierig das ist mit den schalktjahren

dann zeigen, daß man sehr nett das datum optimierne kann, ohne auch nur eigrned eine zeile des abhängigen codes anzufassen.

class Datum{char tag; char monat; short jahr;...};
mit bool less(Datum& a,datum& b);
und int diff(Datum& a,Datum& b);

und dann feststellen, daß ein-ausgaben um den faktor 10000 seltener als vergleiche sind und

class Datum{int tageSeitJesuGeburt;...};
mit bool less(Datum& a,datum& b);//aus einmal trivial
und int diff(Datum& a,Datum& b);//kostet einen takt, also recht schnell

[HumeSikkins]

@volkard
Deine Geschichte mit Klassen sind Begriffe und der Mensch denkt in Begriffen und deshalb OOP gleich gut ist zwar ein schöner Gedanke, es gibt meines Wissens nach aber nach wie vor nicht eine einzige Statistik die hier eine Allgemeingültigkeit belegt. Für dich und mich mag diese Denkweise natürlich und die OOP deshalb schön sein, dass gilt aber keinesfalls für alle (oder wenigstens ausreichend viele) Menschen. Demzufolge würde ich das auch nicht als Vorteil der OOP ansehen.

Vorteile wie "bessere Übersichtlichkeit/Wiederverwendbarkeit/Wartbarkeit" sind Marketingmärchen aus den 80igern. Die sind auf jeden Fall nicht in der Packung enthalten. Man muss aktiv etwas dafür tun.

Imo sollte man dem Unwissenden lieber erstmal erklären *was* OOP ist statt ihm gleich die Vorteile aufzudrücken (die er dann nichtmal bewerten kann). Ich würde da mit so Grundgedanken wie Dependency Inversion o.Ä. kommen.

[volkard]

HumeSikkins schrieb:

@volkard
Deine Geschichte mit Klassen sind Begriffe und der Mensch denkt in Begriffen und deshalb OOP gleich gut ist zwar ein schöner Gedanke, es gibt meines Wissens nach aber nach wie vor nicht eine einzige Statistik die hier eine Allgemeingültigkeit belegt.

widersprichst du? willst du behaupten, der der mensch nicht in begriffen denkt?

Ich würde da mit so Grundgedanken wie Dependency Inversion o.Ä. kommen.

was ist das denn? und warum ist das was wesentliches der oop? gibt es statistiken, die das belegen? nein. also hast du unrecht, oder wie war das?

[elise]

Thomas++ schrieb:

Nee, für das Problem war ich die einzige Kompetenz in der Abteilung. Da schraubt keiner mehr irgendwas am Code rum.
Aber die wollen halt mal über ihren Tellerrand schauen.

volkard schrieb:

du darfst ihnen sagen, was der kern der sache ist. klassen sind begriffe.

Ohne Beispiel werde ich da wohl in lauter leere Gesichter gucken.

Ich denke, es ist ganz gut, es in Form eines realen Beispiels zu erklären (Ein Auto hat Räder und kann fahren...)

Wobei, da werden sie wahrscheinlich genauso blöd gucken.

Gruß, Thomas.

achtung: unterschätz sie nicht. ich unterrichte monatlich maschinenbauer, elektroingeneure, mathematiker.. sonstige in oop, und viele haben vorher prozedural programmiert..
wichtig ist, die ansätze NICHT gegeneinander auszuspielen. dann machen sie von vornherein zu.
geh den weg, dass nicht jedes realweltproblem zwingend mit oop gelöst werden sollte, sondern beide 'ansätze' ihre berechtigung haben.
wichtig ist dass du ihnen das gefühl vermittelst, sie ERWEITERN ihr wissen, und nicht, sie haben bisher 'altertümliches'gemacht (habe ich öfters erlebt..)
ach, ich könnte hier ewig weiterschreiben, was wichtig ist.

aber es reicht, ich denke, du weißt, was ich meine. nur wer sich nicht angegriffen fühlt, kann das 'neue' denken lernen, ohne es permanent mit dem 'alten' zu vergleichen. denn der vergleich blockiert, das wirst du merken.

[HumeSikkins]

volkard schrieb:

willst du behaupten, der der mensch nicht in begriffen denkt?

Nö. Ich wollte nur vor der Behauptung warnen, dass OOP irgendwie näher an einer "natürlichen" Denkweise ist als andere Paradigmen.

volkard schrieb:

HumeSikkins schrieb:

Ich würde da mit so Grundgedanken wie Dependency Inversion o.Ä. kommen.

was ist das denn?

Das was z.B. Robert Martin hier so schön beschreibt.

Erst kommt "inversion of control" um Frameworks überhaupt möglich zu machen und dann kommt DI um in den Bereichen Wiederverwendbarkeit, Testbarkeit usw. punkten zu können.

und warum ist das was wesentliches der oop? gibt es statistiken, die das belegen?

Keine Ahnung, aber es gibt Case Studies die belegen, dass diese Form von OO-Design für die Qualität von Frameworks förderlich ist.

nein. also hast du unrecht

Ok.

oder wie war das?

Keine Ahnung. Kann ich nicht beurteilen.

[volkard]

HumeSikkins schrieb:

volkard schrieb:

willst du behaupten, der der mensch nicht in begriffen denkt?

Nö. Ich wollte nur vor der Behauptung warnen, dass OOP irgendwie näher an einer "natürlichen" Denkweise ist als andere Paradigmen.

ich glaube daran, daß sie näher ist. das heißt trotzdem nicht, daß man alles mit OOP angehen sollte. einen symbolischen rechner baut man wohl in lisp und geht sofort mit anderen sprachen tot. und das hello-world-programm ist in basic sehr schön (print "hello world"). optimal ist, wenn man eine sprache hat, die mehrere paradigmen einigermaßen unterstützt, denn dann kann man von problem zu problem das geeignetste paradigma wählen, und mit vielen problemlösungen zum schluß ein programm bauen, ohne immer die sprache wechseln zu müssen. oop hat uns auf jeden fall viel weiter gebracht, was die komplexität der software angeht, die noch von menschen gebaut werden kann. mir reichen da die rein technischen begründungen nicht aus. irgendwas magisches ist an einem guten stück oo-software, was dazu führt, daß man es einfach lesen kann und kapiert.
und ich weiß auch was. wenn es um ne verkehrsimulation geht, und da steht class Auto und class Omnibus, dann braucht der maschinenbauer gar nicht lange ins handbuch gucken, wie die methoden heißen. anfangs, um den stil sich anzugewöhnen. und den programmumfang zu sehen. aber nachher nicht mehr, er kann auß seinem weltwissen sehr gut ableiten, was da los ist. und zusammenhänge wie "ein Auto hat einen Motor" und "ein Omnibus ist ein Auto" und "ein Auto kann von A nach B fahren" und "ein Auto hat einen Kennzeichen mit sinnvollem Inhalt" kann man einfach so in den code schreiben. also für simulationen ist die OOP wirklich dich am "natürlichen" denken.
naja, bei containerklassen auch. und dann langsam nicht mehr so.

sorry für meinen ton im letzten posting. irgendwie hatte ich das gefühl, du wölltest mir ganz ohne argument nur um des widersprechens willen widersprechen.

ich nehme als "begriff" das an, was unter http://www.st.cs.uni-sb.de/~lindig/papers/dissertation/html/web002.html beschreiben ist. das ding ist so tierisch dicht an c++-klassen, daß ich da keinen zufall wähne.

Das was z.B. Robert Martin hier so schön beschreibt.

und wieder 12 seiten ausgedruckt, die, nachdem ich sie gelesen hab, in meinen großen order interessanter texte wandert.

nein. also hast du unrecht

Ok.

nur, weil ich ohne argumente was sagte? siehe meine sig.

[Marc++us]

Thomas++ schrieb:

Aber die verstehen den Zusammenhang mit dem Programm nicht. (Maschis halt. )

Würde mich wundern. Ich habe mehrjährige Erfahrung gerade im Zusammenhang mit Maschinenbauern und Programmierung, und stelle immer wieder fest, daß gerade Maschinenbauer das Prinzip der OO besonders gut verstehen. Es ist einfacher einen Maschinenbauer von OO zu überzeugen, als einen gestandenen C-Programmierer oder SPS-Programmierer. Die verstehen zwar Software, aber begreifen nicht warum OO gut sein soll.

Im Maschinenbau sind alle modernen Tools bereits objektorientiert aufgebaut, die ganzen 3D-Modeller, Zeichentools, auch die Stücklisten im SAP funktionieren so.

Wenn Du es richtig erklärst, wirst Du zu dem Punkt kommen, daß Dich die Maschinenbauer irgendwann fragen: "ach, Ihr könnt Software jetzt so entwickeln wie wir seit 100 Jahren die Maschinen? Gut für Euch."

Hauptproblem ist bei diesen anderen Denkwelten meistens, daß der Lehrer die Tools der Lernenden und deren Arbeitsweise nicht kennt, daher kann er nicht mit Beispielen aus deren Erfahrungsbereich argumentieren. Und stößt damit natürlich auf wenig Verständnis. Besonders problematisch ist es, wenn der Lehrer sein Fachgebiet für überlegen hält.

[HumeSikkins]

volkard schrieb:

optimal ist, wenn man eine sprache hat, die mehrere paradigmen einigermaßen unterstützt, denn dann kann man von problem zu problem das geeignetste paradigma wählen, und mit vielen problemlösungen zum schluß ein programm bauen, ohne immer die sprache wechseln zu müssen.

Da bin ich ganz deiner Meinung.

volkard schrieb:

oop hat uns auf jeden fall viel weiter gebracht, was die komplexität der software angeht, die noch von menschen gebaut werden kann. mir reichen da die rein technischen begründungen nicht aus. irgendwas magisches ist an einem guten stück oo-software, was dazu führt, daß man es einfach lesen kann und kapiert.

Die Tatsache, dass uns OOP weitergebracht hat ist unstrittig. Ich bin mir nur nicht ganz sicher, was der Grund dafür ist, was als das magische Element ist.

Du schreibst:

volkard schrieb:

und ich weiß auch was. wenn es um ne verkehrsimulation geht, und da steht class Auto und class Omnibus, dann braucht der maschinenbauer gar nicht lange ins handbuch gucken, wie die methoden heißen. anfangs, um den stil sich anzugewöhnen. und den programmumfang zu sehen. aber nachher nicht mehr, er kann auß seinem weltwissen sehr gut ableiten, was da los ist. und zusammenhänge wie "ein Auto hat einen Motor" und "ein Omnibus ist ein Auto" und "ein Auto kann von A nach B fahren" und "ein Auto hat einen Kennzeichen mit sinnvollem Inhalt" kann man einfach so in den code schreiben. also für simulationen ist die OOP wirklich dich am "natürlichen" denken.

Das ist imo prinzipiell ja alles richtig. Mein Problem ist nur, dass manche Denken (dich meine ich damit nicht) Begriffe seien eine Erfindung der OOP.
Man hat aber ja auch schon vorher Autos modelliert. Z.B. über Module bzw. ADTs. Die OOP hat dann vorhandene Konzepte konsequent weiterentwickelt und Dinge wie ADTs um sinnvolle Standardoperationen (Z.B. Erzeugung, Zerstörung) und mögliche Beziehungen erweitert (Vererbung -> Klassifizierung in Hierarchien).

Zwei Dinge sind dazu imo noch ganz Wichtig: a) Die Form der Dekomposition und b) der neue Kontrollfluss.

Die Kombination von Daten und Verhalten macht die Abhängigkeiten zwischen diesen klarer Sichtbar und damit einfacher Handhabbar. In der funktionalen Dekomposition früherer Tage hingegen wusste man häufig nicht, welche Funktionen durch die Änderung von Daten betroffen sind und wie sich solche Änderungen demzufolge Auswirken.

Hinzu kommt, als imo entscheidener Aspekt, die Dezentralität in der OOP. Im Gegensatz zu strukturierten Ansätzen geht es in der OOP weniger um einen zentralen Kontrollmechanismus oder einen sequentiellen Ablauf. Vielmehr kommunizieren hier viele kleine (und hoffentlich nur eine Aufgabe erfüllende) Objekte in einer dezentralen Art und Weise. Diese Eigenschaft ist es imo, die dazu führt, dass OOP als "schwer" oder "anders" empfunden wird. Sie sorgt imo dafür, dass OOP-Implementationen Probleme manchmal verkomplizieren und häufig einfacher lösbar machen.

Für kleine Probleme ist ein zentraler Kontrollfluss häufig einfacher. main() ist der zentrale Punkt. Dort werden drei Funktionen aufgerufen Eingabe(), Verarbeitung(), Ausgabe(). Ich kann mir die Hierarchie der Funktionen aufmalen und Schritt für Schritt durch das Programm durchgehen. Fertig.

Irgendwann stößt der zentrale Ansatz aber an seine Grenze. Der Knoten wo alle Fäden zusammen laufen wird zum gordischen Knoten. Spätestens hier
hilft die dezentrale Natur der OOP. Die Komplexität wird auf viele kleine kollaborierenden Objekte aufgeteilt. Als Mensch kann man sich dann auf einzelne Objekte bzw. auf Objektverbunde und ihre Nachrichten konzentrieren und so Ausschnitte des Systems besser verstehen.

Der Trick bei der OOP ist es dann wohl sinnvolle kollaborierenden Objekte zu bauen, die jeweils eine bestimmte Aufgabe erfüllen

Zusammengefasst: neben dem was du mit den Begriffen meinst würde ich also noch die Kombination von Daten und Verhalten sowie die Dezentralität des Ablaufs zu den entscheidenen OOP-Dingen packen.

[volkard]

[quote="HumeSikkins"]Mein Problem ist nur, dass manche Denken (dich meine ich damit nicht) Begriffe seien eine Erfindung der OOP.[/qoute]
lol. wie kommt man denn darauf?
"Brehm's Thierleben" http://gutenberg.spiegel.de/brehm/tierleb1/index.htm mit ner wahnsinnig tiefen begriffshierarchie und das ist widerlegt.

Hinzu kommt, als imo entscheidener Aspekt, die Dezentralität in der OOP. Im Gegensatz zu strukturierten Ansätzen geht es in der OOP weniger um einen zentralen Kontrollmechanismus oder einen sequentiellen Ablauf. Vielmehr kommunizieren hier viele kleine (und hoffentlich nur eine Aufgabe erfüllende) Objekte in einer dezentralen Art und Weise.

ich weiß nicht. auch in c war es ein design-ziel, eine funktion für einen zweck zu bauen.
file lesen ohne konstruktor und destruktor.

int readfile(char* filename){
   FILE* file=fopen(filename);
   int rc=readfilesub(file);
   fclose(file);
   return rc;
}

und voila, ist die readfilesub vom aufräumen genauso befreit, wie sie in c++ mit dem destruktor ist. allein, es sprach die performance dagegen. mabn mußte also performance gegen sauberkeit abwägen, das brauchen wir in c++ fast nicht mehr.
ich kann nicht unterschreiben, daß man in c++ und oo dezentraler programmiere kann als in c und prozedural. es ist so, daß man es in c++ tut, aber das liegt vielleicht gar nicht an der oo, sondern an nur und ganz allein an inline.

Der Trick bei der OOP ist es dann wohl sinnvolle kollaborierenden Objekte zu bauen, die jeweils eine bestimmte Aufgabe erfüllen

naja. vielleicht haben wir hier an sich den gleichen gedanken. ich denke mit sonnvoller kollaboration aber auch ganz wichtig an "eine klasse hat einen zweck". und damit an kleine klassen, und damit an einfache und wartbare. und, für mich ganz wesentlich, an klassen, die der dokumentation gar nicht bedürfen.

[HumeSikkins]

volkard schrieb:

HumeSikkins schrieb:

Der Trick bei der OOP ist es dann wohl sinnvolle kollaborierenden Objekte zu bauen, die jeweils eine bestimmte Aufgabe erfüllen

naja. vielleicht haben wir hier an sich den gleichen gedanken. ich denke mit sonnvoller kollaboration aber auch ganz wichtig an "eine klasse hat einen zweck". und damit an kleine klassen, und damit an einfache und wartbare. und, für mich ganz wesentlich, an klassen, die der dokumentation gar nicht bedürfen.

Was meinst du wie oft ich schon trotz all dieser Tipps & Tricks und unzähligen Heuristiken bei so"abscheulichen" Designs à la Figure 11-1 angekommen bin.

Irgendwas ist an OOP zweifelsfrei "magisch" gleichzeitig ist irgendwas an OOP (oder besser OOD) aber auch unglaublich schwierig. Ob dieses irgendwas beides das Gleiche ist...?

[volkard]

HumeSikkins schrieb:

Irgendwas ist an OOP zweifelsfrei "magisch" gleichzeitig ist irgendwas an OOP (oder besser OOD) aber auch unglaublich schwierig. Ob dieses irgendwas beides das Gleiche ist...?

glaub ich nicht. oop finde ich klasse. aber alles, was den namen ood trug, fand ich schrecklich.
unglaublich schwierig zum beispiel immer der versuch, eine sache zu modellieren, ohne die sache zu kennen. daß das nix wird, ist klar.