Wie erklärt man Ahnungslosen die Objektorientierung?

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.