Wie erklärt man Ahnungslosen die Objektorientierung?

[Artchi]

Hem, was sollst du denn vorstellen? Die Technik die dahinter steckt oder den fachlichen Hintergrund?

Wenn es sozusagen die Endanwender sind, würde ich von Technik nichts erzählen. Höchstens nur sagen, das das Ding in C++ programmiert wurde und wenn noch ne Datenbank dahinter steckt, welche. Fertig.

Falls du wirklich OO erklären willst: viel Spaß!

[User---]

Wenn es Programmierer sind, würde ich denen OOP für Dummies in die Hände drücken.

Wenn du es selbst erklären willst, willst du nur das Konzept an sich erklären, oder auch wie man es korrekt anwendet?

[volkard]

Thomas++ schrieb:

Hi,
ich werde demnächst ein größeres Softwareprojekt vorstellen und dabei hauptsächlich mit Leuten zu tun haben, die keine Ahnung von OO haben (neue Situation für mich).

wieviele halswirbel hat eine giraffe mit 10 meter langem hals? 7! weil alle säugetiere 7 halswirbel haben. klasse sache das. dadurch, daß der mensch schubladisiert, braucht er viel weniger zu wissen. die schubladen heißen übrigens begriffe. und begriffe können oberbegriffe haben, wie Giraffe->Säugetier. nichmal zum üben: wieviele räder, die bis zum boden reichen, hat mein auto? obwohl du gar nicht mein auto kennst, weißt doch, daß es zum begriff auto paßt und da gibts 4 räder.

der mensch denkt in begriffen. es wäre toll, wenn die programmierspachen auch begriffe abbilden könnten, dann wäre der mensch besser in der lage, das, was er denkt, im programm abzubilden. naja, das hat man in den 70-ern viel gemacht. netzwerke im rechner voller begriffe und die können auch noch tolle beziehungen untereinander haben. und da haben die so geforscht und gespielt und es hat sich immer recht deutlich abezeichnet, daß zwei arten der beziehungen ganz dominierend sind. die Ist-Ein-beziehung (wie bei die kuh ist ein säugetier) und die Hat-Ein-beziehung (wie das auto hat ein lenkrad). die anderen beziehungen sind sozusagen spliterparteien, von denen es zar ganz viele gibt, aber ekine schafft die 5%-hürde.

naja, und kluge leute kamen drauf, daß man die programmiererei eoin wenig aufmotzen sollte. vormals gab es nur daten (fachausdruck: dinge) und funktionen (auch prozeduren sind damit gemeint). und jetzt gibt es daten, funktionen und beziehungen. und zwar Ist-Ein und Hat-Ein.

und so weiter und so fort...

Wo liegen die am besten nachvollziehbaren Vorteile der OO-Programmierung gegenüber der bei Anfängern noch am ehesten bekannten funktionalen Programmierung?

meinste die den anfängern bekannte prozedurale programmierung?

na, der mensch denkt in begriffen, deswegen kann er saukomplexe software auch mit begriffen besser hinschreiben als mit ohne so sachen. das ist auch schon der ganze trick.

die schreibe v.push_back(5) ist nur syntaktischer zucker. bereits in lisp haben wir konsequent das subjekt von den anderen objekten unterschieden, indem es IMMER die erste stelle in der argumentenliste erhielt.
(push_back v 5). das subjekt ist nämlich auch nur ein objekt, aber das wichtigste irgendwie. das aktive. der funktionsname ist das verb.
und da ich vom deutschen oder englichen gewohnt bin, subjekt-verb-objekt zu schreiben, mag ich auch die c++-syntax mit i.goTo(school);.

viel spaß beim vortrag. wenn du sowas öfters machst, lernste unheimlich viel übers programmieren, weil du dir auch filosofische fragen im programmier-kontext stellst, auf die man sonst gar nicht kommt.

[Thomas++]

Artchi schrieb:

Hem, was sollst du denn vorstellen? Die Technik die dahinter steckt oder den fachlichen Hintergrund?

Wenn es sozusagen die Endanwender sind, würde ich von Technik nichts erzählen. Höchstens nur sagen, das das Ding in C++ programmiert wurde und wenn noch ne Datenbank dahinter steckt, welche. Fertig.

Falls du wirklich OO erklären willst: viel Spaß!

Hi,

also hauptsächlich geht es um den fachlichen Hintergrund. Da Ingenieure aber meistens auch daran interessiert sind, _wie_ etwas funktioniert ;), soll ich denen auch die Technik dahinter ein bisschen näher bringen.

Die meisten scheitern aber schon am Klassenbegriff.

Im Prinzip ist die OO ja nur ein Paradigma, um Programmaufgaben greifbarer, mit Bezug auf "anfassbare" Dinge zu modellieren.

Im Gegensatz zu einer Prozedur kann man viele verschiedene Objekte einer Klasse erzeugen, die so lange existieren, bis man sie wieder zerstört.
Die Frage ist, gibt es einen Anwendungsfall, in dem ich nur mit OO-Programmierung weiterkomme, die sich quasi mit einem prozeduralen Ansatz gar nicht lösen lassen?

Ist Parallelität vielleicht ein Thema? Prozeduren werden ja seriell abgearbeitet, das Ergebnis kommt raus und der Kontext ist weg..

Danke für eure Anregungen bisher,

Gruß, Thomas.

[volkard]

Thomas++ schrieb:

Die Frage ist, gibt es einen Anwendungsfall, in dem ich nur mit OO-Programmierung weiterkomme, die sich quasi mit einem prozeduralen Ansatz gar nicht lösen lassen?

nein. sind die beiden zu betrachtenden sprachen beide turing-vollständig, dann kannste auch alles, was in der iennen zu berechnen geht, in der anderen berechnen.

Ist Parallelität vielleicht ein Thema? Prozeduren werden ja seriell abgearbeitet, das Ergebnis kommt raus und der Kontext ist weg..

nein. alte prozeduren kennen auch daten. neu ist doch nur, daß jetzt die methoden zu den datentypen gehören, daß man ein wenig polymorphie hat (was aber nur tipp-arbeit abnimmt und daß man vererbung hat (was auch nicht in der sprache eingebaut sein muß).
es ist nämlich um genau zu sein so, daß nicht die sprachen OO sind, sondern die programme. ich kann in c wunderbar oo programme programmieren und die mehrzahl der c++-coder programmiert mit c++ programme ohne oo.
daher kannste den hörern auch nicht erzählen, was eine oo sprache ist. versuchst du es, wirste in widersprüche verwickelt.

edit: oo ist also ein programmierstil, und das versuch mal den technikern mit bits und bytes zu vermittel. geht natürlich net. vielmehr mußte ehrlich sein, und sagen, was sache ist. oo ist ein stil. man nennt manche sparcehn oo-sprachen, was aber mehr ein marketing-gag ist, denn eine sinnvolle klassifizierung. faste alle der sogenannten oo-sprachen haben irgendwelchen syntaktischen zucker eingebaut, der diese oder jene programmiertechnik, die man bei oo programmen gerne verwendet, anbietet. zum beispiel virtuelle methoden oder destruktoren.

[Thomas++]

Das sind alles alteingesessene Maschinenbauer, die höchstens mal was mit Matlab oder die älteren Semester mit Fortran zu tun hatten.

Denen ist die Art der Modellierung logisch (Ein Auto hat vier Räder, ein Rad besteht aus einer Felge und einem Reifen, ein Reifen hat einen bestimmten Durchmesser)
Aber die verstehen den Zusammenhang mit dem Programm nicht. (Maschis halt. )

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

Die Frage ist eben, ob ich denen in kurzer Zeit ein Klassendiagramm mit Vererbung und den verschiedenen Assoziationen/Aggregationen usw. erklären kann. Wohl eher nicht.

Gruß, Thomas.

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