OOP Literatur: Wie anfangen? [Archiv]

Monger

2013-07-16, 14:20:24

Mal so oberflächlich wurde die selbe Frage hier ja schon unzählige Male gestellt, aber nicht von mir ^^ .

Auf Arbeit kommen immer mehr Kollegen auf mich zu, die sich gerne in VB.NET bzw. C# einarbeiten würden. Allerdings: nach dem einwöchigen Kurs hier wissen sie zugleich alles und nichts. Bücher wie die "Von Kopf bis Fuß" Reihe sind zwar ein netter Einstieg um mal mit einem konkreten Anwendungsbeispiel durchzusteigen, und die Bücher von Galileo Computing sind als Referenzhandbücher ganz nützlich...

Aber ich merke, dass da der theoretische Unterbau fehlt. Im Prinzip das, was man im Studium vermittelt kriegt. Die Leute kommen aus solchen Aktionen mit vollen Köpfen raus, setzen sich an ihre Entwicklungsumgebung dran, und scheitern spätestens an der fünften Codezeile, weil ihnen halt der Blick fürs große Ganze fehlt, und wie man Probleme abstrahiert. Dass man nicht mit zwei Büchern drei, vier Jahre Studium ersetzen kann ist mir klar. Aber irgendwo muss man ja mal anfangen.

Deshalb: was ich suche, wäre ein Buch was mal tatsächlich auf die Theorie eingeht: was sind Klassen, was Objekte? Wann lädt die Runtime was? Was ist der Unterschied zwischen Methoden, Properties und Feldern, und wann benutzt man welche? Was sind Iteratoren, was ist lazy Evaluation? Was sind Value und Reference Types, und wann nimmt man welche? Was heißt Call-By-Value in .NET?
Noch besser wären methodische Fragen, also z.B. wie nähere ich mich einer großen Implementierung Stück für Stück an? Sozusagen TDD für Dummies. Wie komme ich an Informationen ran die mir fehlen?

Klar kann man sich das auch alles aus der MSDN zusammenstückeln, aber es ist für einen Anfänger kaum bewältigbar, weil ohne Erfahrung weiß man ja gar nicht wo man suchen soll, und nach was. Kennt zufällig jemand von euch geeignete Literatur? Im Zweifel auch gerne von anderen modernen Hochsprachen, also z.B. Java, Python etc. , damit ich mal vergleichen kann.
Wenn es was taugt, darf es auch durchaus Geld kosten, hier geht es nunmal nicht um Freizeitaktivitäten.

PatkIllA

2013-07-16, 18:00:48

Deshalb: was ich suche, wäre ein Buch was mal tatsächlich auf die Theorie eingeht: was sind Klassen, was Objekte? Wann lädt die Runtime was? Was ist der Unterschied zwischen Methoden, Properties und Feldern, und wann benutzt man welche? Was sind Iteratoren, was ist lazy Evaluation? Was sind Value und Reference Types, und wann nimmt man welche? Was heißt Call-By-Value in .NET?
Davon habe ich genau gar nichts im Studium gelernt. Das ist auch sehr Sprach- bzw. Runtime bezogen.
Aber ich merke, dass da der theoretische Unterbau fehlt. Im Prinzip das, was man im Studium vermittelt kriegt. Die Leute kommen aus solchen Aktionen mit vollen Köpfen raus, setzen sich an ihre Entwicklungsumgebung dran, und scheitern spätestens an der fünften Codezeile, weil ihnen halt der Blick fürs große Ganze fehlt, und wie man Probleme abstrahiert.
Was ist denn in der einen Woche Kurs enthalten und welche Vorkenntnisse enthalten.
Wir haben in der Firma auch Umschulungen von anderen Sprachen auf unser .NET Produkt in einer Woche, aber IMO ist das zu wenig und die haben alle schon jahrelang programmiert.

Monger

2013-07-16, 19:16:05

Was ist denn in der einen Woche Kurs enthalten und welche Vorkenntnisse enthalten.

Mal kurz zusammengefasst: fängt an bei Variablendeklarationen und Schleifen, streift dann mal kurz über Windows Forms und WPF, geht mal "kurz" in nem halben Tag auf Vererbung ein, dann über DataSets und andere Datenadapter und streift dann mal am letzten Tag XML.

Vorkenntnisse sind relativ bunt gemischt. Gibt einige Entwickler drin die vor allem ihren Lebenslauf mit den Zertifikaten füllen wollen, und dann vorallem viele Tester die im wesentlichen Konsolenskripte für automatische Tests geschrieben haben.

Ich mein, wenn ich an einen ordentlichen Anbieter für Schulungen rankommen könnte, wäre das vielleicht auch was. Aber wie du schon sagst: ist halt die Frage was ne Woche bringt.

PatkIllA

2013-07-16, 19:30:12

Eine Woche kann ich dir problemlos alleine mit den besseren Basics von WPF füllen.

Die meisten deiner Beispiele gehören schon direkt in die Schulung selbst mit rein. Der theoretische Hintergrund, dass hinter einem Iterator eine vom Compiler erzeugte Statemachine hängt bringt einen Anwender IMO auch nicht wirklich weiter.

Marscel

2013-07-16, 20:00:27

Aber ich merke, dass da der theoretische Unterbau fehlt. Im Prinzip das, was man im Studium vermittelt kriegt. Die Leute kommen aus solchen Aktionen mit vollen Köpfen raus, setzen sich an ihre Entwicklungsumgebung dran, und scheitern spätestens an der fünften Codezeile, weil ihnen halt der Blick fürs große Ganze fehlt, und wie man Probleme abstrahiert. Dass man nicht mit zwei Büchern drei, vier Jahre Studium ersetzen kann ist mir klar. Aber irgendwo muss man ja mal anfangen.

Deshalb: was ich suche, wäre ein Buch was mal tatsächlich auf die Theorie eingeht: was sind Klassen, was Objekte? Wann lädt die Runtime was? Was ist der Unterschied zwischen Methoden, Properties und Feldern, und wann benutzt man welche? Was sind Iteratoren, was ist lazy Evaluation? Was sind Value und Reference Types, und wann nimmt man welche? Was heißt Call-By-Value in .NET?
Noch besser wären methodische Fragen, also z.B. wie nähere ich mich einer großen Implementierung Stück für Stück an? Sozusagen TDD für Dummies. Wie komme ich an Informationen ran die mir fehlen?

Was uns im Studium beigebracht unter "Objektorientierter Programmierung" wurde, war, wie man in C++ und Java den größtmöglichen syntaktischen Brainfuck hinlegt. Was fast GAR NICHT vermittelt wurde: Die Philospohie dahinter. Auch in sprachenbezogenen Lehr- und Fachbüchern siehts oft nicht besser aus. Der Ansatz kann stark daneben gehen, evtl. kann man dann die kopfschmerzenerregendsten Konstrukte bauen, fliegt damit aber in Engineering-Sicht auf die Nase (oder kriegts, je nach dem).

In der Ruby-Szene existieren etliche Guides, Videocasts und Bücher, die einem in Sachen vorzeigbare Hierarchien und Interfaces einiges vermitteln. In der Firma hatte mein Chef immer wieder Bücher verteilt, die dann einer oder mehrere lesen sollten, sodass man mal einen Vormittag dafür verwendet hat, bestehenden Code nach nahegelegten Mustern zu refactoren. Da gibts einiges Kern-Messages, aber leider hab ich die Büchernamen nicht mehr im Kopf.

Etwas mehr echte Theorie hinter Objektorientierung heißt erstmal: vergiß mal die Sprache. Da gibts im wissenschaftlichen Bereich etliche Papers, viele davon sind aber wenig erleuchtend, wenn man nicht schon drin steckt. Da guckt man sich mal Javascript oder Haskell genauer an und sieht die Umsetzung dann auf eine etwas andere Art und Weise.

Dein 2. Absatz verwirrt mich daher: .NET & Co, technische Hintergründe, OOP und methodisches Vorgehen an eine größere Softwarelösung sind komplett verschiedene Paar Schuhe. Entsprechend solltest du dich auch jeweils unabhängig damit befassen.

Für .NET und so reicht die MSDN eigentlich ziemlich aus, es gibt allerdings noch wissenschaftliche Artikel darüber für bestimmte Aspekte darin (IL, GC, Debugging, ...). Oft genug gehört das Lesen von Quellcode dazu (vllt. einen Blick in Mono oder offene .NET-Libs von Microsoft werfen). Bei den anderen Dingen kann ich leider nicht so nennen, wir sind unsere Arbeit einfach immer wieder durchgegangen, bis jeder halbwegs der Ansicht war, Methoden und Pattern verinnerlicht zu haben.

RattuS

2013-07-16, 20:21:41

Ohne mich als Troll darstellen zu wollen, aber: Ohne methodisches Vorgehen und ein Mindestmaß an Talent für analytisches Denken, hilft auch kein Buch der Welt weiter. Wenn man dies hingegen mitbringt, arbeitet man sich in die theoretischen Grundlagen mit der Zeit von selbst ein. Fachlektüre, besonders philosophischerer Natur, hilft IMO nur beim Vertiefen bzw. Differenzieren von Perspektiven. Das Problem ist, das Bücher immer nur an der Oberfläche kratzen, denn sie fassen bewusst riesige Themenkomplexe "verständlich" zusammen. Und genau diese Komprimierung ruiniert gleichzeitig den Wert dieser.

Meiner Erfahrung nach braucht es einfach etwas Zeit und einen fähigen Menschen, der wissensdurstig und engagiert ist. Einwöchige Schulungen und der x. Best-Practise-Guide, ob Print oder Webcast, wärmen nur Gedanken auf.

Ansonsten, um nicht komplett das Thema zu verfehlen, schlage ich einfach mal Uncle Bob's "Clean Code (http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)" vor. Damit hat man zumindest ein gewisses Maß an Selbstverständlichkeit unter den Kollegen.

FlashBFE

2013-07-16, 20:37:25

Was uns im Studium beigebracht unter "Objektorientierter Programmierung" wurde, war, wie man in C++ und Java den größtmöglichen syntaktischen Brainfuck hinlegt. Was fast GAR NICHT vermittelt wurde: Die Philospohie dahinter
Das wurde bei uns besser gemacht, die ganze Theorie erst mal sprachunabhängig, aber natürlich trotzdem alles noch mal (leider) in C++ in einem uralten Visual Studio "eingeprügelt".

Aber in der Praxis fällt auf, wie wenig man von der ursprünglichen reinen Lehre heute noch braucht oder andererseits selbstverständlich ist. Die Vererbung oder abstrakte Klassen brauche ich quasi nie. Dafür brauche ich heute Lambda-Prozeduren, Interfaces und parallele Programmierung ständig, was es damals entweder noch nicht gab oder mit keinem Wort erwähnt wurde.

Lange Rede, kurzer Sinn: Bring dir das Zeug mit der Zeit lieber selbst bei, wie du es gerade brauchst und bleibe flexibel. Das Wissen in dem Bereich ist eh nicht lange von Bestand.

Ein Buch für .NET 2.0 zum Beispiel ist heute fast nutzlos, außer man will mit den absoluten Grundlagen anfangen. Die MSDN-Hilfe und vor allem die How-To finde ich aber zum Lernen schon brauchbar, außerdem bietet MS viele viele Videos an, die echt gut sind. Das neue Async-Await-Prinzip habe ich mir z.B. fast nur durch ein Video-Tutorial beigebracht.

][immy

2013-07-16, 21:38:59

Ein Buch für .NET 2.0 zum Beispiel ist heute fast nutzlos, außer man will mit den absoluten Grundlagen anfangen. Die MSDN-Hilfe und vor allem die How-To finde ich aber zum Lernen schon brauchbar, außerdem bietet MS viele viele Videos an, die echt gut sind. Das neue Async-Await-Prinzip habe ich mir z.B. fast nur durch ein Video-Tutorial beigebracht.

nunja, das würde ich jetzt mal überhaupt nicht behaupten. Die Möglichkeiten von .net 2.0 sind schon sehr vielfältig und alles was dort geht ist auch in .net 4.5 noch enthalten. zudem sollte man Anfänger eventuell nicht direkt überfordern mit der neusten Technologie und mit Features überfrachten.
Einige Basics lernt man nur durch "begrenzte" Möglichkeiten, denn wenn man immer die Dinge nutzt die bereits vorhanden sind, fängt man nie an diese auch wirklich zu verstehen und verwendet sie am ende eventuell noch falsch.
Man muss zwar nicht immer alles wissen, aber Grundlagen gehören nun mal dazu und da ist eine Sprache, die noch nicht all zu viel von Anfang an anbietet eigentlich optimal.

Für OOP sollte man sich einfach an die Basics halten, aber es auf eine Woche einzudampfen ... da kommt es stark auf den Wissensstand an.
Bei den meisten ist eher das Problem alte Gewohnheiten loslassen zu können. Zu häufig habe ich es inzwischen gesehen, das man zwar mit Objekt-Orientierung startet, am ende aber doch nur gescripted und Methoden-orientiert gearbeitet wird. Diesen misst wieder los zu werden erfordert viel Zeit und Arbeit.

Von daher finde ich für den Einstieg eigentlich immer etwas ältere Sprachen, wo man sich halt mehr um Sachen kümmern muss, besser für den Einstieg, denn so muss man sich Zwangsweise mit dem Thema beschäftigen und ist automatisch gefordert mehr Grips rein zu stecken. Hinterher kann man es sich dann mit Java/.net noch immer das Leben leichter machen :)

Literatur ist da doch ein ziemlicher Knackpunkt, in den meisten Sachen stehen zwar vereinzelt gute Anleitungen und Tipps drin, aber insgesamt ist es halt überfrachtet oder geht in eine andere Richtung als man sich diese vorstellt.
Ein gutes Buch zu dem Thema (das für Anfänger taugt und die Sache gut erklärt, so das man es auch dauerhaft versteht) würde mich aber auch mal interessieren.

Frucht-Tiger

2013-07-17, 00:02:52

Mit Büchern alleine kommt man meiner Meinung nach nicht so weit.

Am besten lernt/versteht man ein Sprachkonzept, wenn man mal vor einem Problem steht und sich die Vorgehensweise anbietet es zu lösen. Gar nicht so verkehrt finde ich, wenn man den auf diesem Gebiet unerfahrene Kollegen mal eine Lösung machen lässt, wie es demjenigen auf Grund seines Erfahrungsstandes in den Sinn kommt. Anschließend kann man sich ja zusammen hinsetzen und die Sache gemeinsam refactorn, um zu zeigen, dass man so besser/einfacher ans Ziel kommt.

Ist ja auch so in vielen anderen Lebensbereichen, wenn da jemand kommt und das eigene Vorgehen "kritisiert" mit dem Argument: "Das macht man halt so" hat das keine große Überzeugungskraft. Nur weil es mal jemand in irgendein Buch geschrieben hat, ist es auch nicht der Weisheit letzter Schluss.

Als ich angefangen habe zu programmieren, war es z.B. Mode fast alle Klassen ein Interface zu verpassen, weil "dann kann man später nochmal die Implementierung austauschen blablabla", das hat dazu geführt das der ganze Code mit Interfaces zugeballert war und man fast mehr damit beschäftigt war seine neue Funktionalität korrekt durch die ganzen Schichten zu ziehen, als den eigentlichen Business-Code zu schreiben. Heute bin ich für mich zur Erkenntnis gekommen, dass sowas Mist ist für eine "API" die eh nur von einer Stelle aus genutzt wird. Wenn ich es brauche habe ich es dank Refactoring-Tools innerhalb einer Sekunde generiert und fertig. Mit modernen Mocking-Frameworks kann ich auch alles testen wie ich das will, da brauch man kein Interface für. Die Vorgehensweise wurde aber in allen Java/Spring Büchern dieser Zeit rauf und runter gebetet.

Mein Rat: Die Leute einfach mal auf ein Problem loslassen, danach gemeinsam versuchen eine bessere Lösung zu finden. Das hat auch für den erfahreneren Kollegen den Effekt, dass er seine "bessere" Vorgehensweise belegen muss, vllt. lernt der auch was dazu. Ich will ja einen Programmiere dazu erziehen mitzudenken und kreativ zu sein, nicht einfach nur altes Wissen aus einem Buch nachzuäffen.

Monger

2013-07-17, 08:19:43

Was fast GAR NICHT vermittelt wurde: Die Philospohie dahinter.

Da hatte ich mehr Glück, lag aber wohl auch am Dozenten. Eröffnet hat er die Vorlesung mit dem Gödelschen Unvollständigkeitssatz "Jedes hinreichend komplexe System ist unvollständig". Es gibt keine Programmiersprache die sich selbst vollständig beschreiben kann. Dann haben wir buchstäblich bei Platon angefangen, also: existiert die Idee eines Gegenstands zuerst und dann das Objekt, oder formt sich erst aus dem konkreten Objekt durch Abstraktion die Idee? Darauf haben verschiedene Programmiersprachen ja durchaus unterschiedliche Antworten gefunden.

Ich fand das ziemlich erfrischend, weil man verliert sich so schnell in der Praxis im Detail. Es ist anschließend unglaublich schwer sich mal aus dem technischen Sumpf hervor zu heben, und mal den theoretischen Unterbau zu betrachten.

Dein 2. Absatz verwirrt mich daher: .NET & Co, technische Hintergründe, OOP und methodisches Vorgehen an eine größere Softwarelösung sind komplett verschiedene Paar Schuhe. Entsprechend solltest du dich auch jeweils unabhängig damit befassen.

Deshalb habe ich ja bewusst die auch in zwei Absätze gefasst! ;)
Aber wahrscheinlich wäre letzteres wichtiger. Hast schon recht: ersteres altert auch ziemlich schnell, und ist so spezifisch für die jeweilige Situation, dass man jedem eigentlich was anderes erzählen muss.

Ohne mich als Troll darstellen zu wollen, aber: Ohne methodisches Vorgehen und ein Mindestmaß an Talent für analytisches Denken, hilft auch kein Buch der Welt weiter.
Da klingt jetzt so ein bisschen die Ansicht durch, dass man zum Programmierer geboren sein muss.
Natürlich tun sich manche Menschen leichter, und manche schwerer, aber Abstraktionsvermögen kann man erlernen. Bei mir ist der Knoten auch erst im fünften Semester geplatzt, ich weiß daher dass diese Einstiegshürde, also die Schwelle zwischen wo man nur bestehendes Wissen abkupfert, und wo man versteht wie man seine Probleme kategorisieren muss und wie man Informationen dazu sucht, ist ziemlich hoch. Bis dahin ist man am Schwimmen, danach ist es ein Selbstläufer.

Aber danke für den Buchtipp.

Gar nicht so verkehrt finde ich, wenn man den auf diesem Gebiet unerfahrene Kollegen mal eine Lösung machen lässt, wie es demjenigen auf Grund seines Erfahrungsstandes in den Sinn kommt. Anschließend kann man sich ja zusammen hinsetzen und die Sache gemeinsam refactorn, um zu zeigen, dass man so besser/einfacher ans Ziel kommt.

Das ist de facto meine tägliche Arbeit. Aber ich kann nicht überall gleichzeitig sein, das sind ein gutes Dutzend Kollegen die ich auf die Weise betreue. Ich hab schon angefangen die gruppenweise zu Schulungsmeetings einzuberufen, damit ich wenigstens nicht jedem wieder einzeln alles erzählen muss, aber es ist trotzdem ein brutaler Zeitaufwand. Wie gesagt, die haben ja alle Grundkenntnisse, aber es fehlt eben dieses Gesamtverständnis.

Colin MacLaren

2013-07-17, 08:55:47

PatkIllA

2013-07-17, 09:14:34

Da klingt jetzt so ein bisschen die Ansicht durch, dass man zum Programmierer geboren sein muss.
Ein bisschen schon. Einige kriegen das auch nach Jahren, mehrfachen Erklärungen nicht hin. Da besteht dann meist auch kein Interesse sich in die Grundlagen einzuarbeiten und es werden sämtliche Probleme mit dem vorhandenen Wissen gelöst, obwohl ein Blinder mit Krückstock merken muss, dass das Pfusch ist.

Watson007

2013-07-17, 09:22:45

Das sind eigentlich alles Dinge, die im Galileo Referenzwerk in den ersten Kapiteln erläutert werden.

na nun komm. Solange programmierst du auch noch nicht ;) nicht von oben herab blicken

Ein Buch für .NET 2.0 zum Beispiel ist heute fast nutzlos, außer man will mit den absoluten Grundlagen anfangen. Die MSDN-Hilfe und vor allem die How-To finde ich aber zum Lernen schon brauchbar, außerdem bietet MS viele viele Videos an, die echt gut sind. Das neue Async-Await-Prinzip habe ich mir z.B. fast nur durch ein Video-Tutorial beigebracht.

ich habe auch schon Fehler in den MSDN-Videos gefunden, und von sinnvoller (inhaltlicher) Strukturierung kann man häufig auch nicht reden... aber für umme sind die schon ganz gut. Aber nicht jeder Programmierer ist zum Lehrer geboren, das merkt man bei diesen Videos ganz klar (fehlende Didaktik, könnte ich aber auch bei manchen unserer Dozenten bemängeln). Von deutlicher Aussprache ganz zu reden... aber als Inspiration sind die auf jeden Fall gut.

mir hat z. B. geholfen eine verteilte Anwendung zu programmieren, um das OOP-Prinzip zu verinnerlichen. Mit MVC- und Observer-Pattern, Verwaltung der Formular/Dialog-Objekte in Listen wie in Oracles MVC-Artikel erläutert, Datenspeicherung im Server über einen Persistenzlayer... also einen eigenen Anwendungsserver und -client zu programmieren, für eine Datenbankanwendung.

was mich eher stört ist dass sich selbst etwas beibringen im Prinzip von Unternehmen nicht anerkannt wird, dort zählt nur was man auf Papier hat was für Autodidakten natürlich nicht gut ist.

Watson007

2013-07-17, 09:43:56

bei dem Thema darf natürlich das Stichwort "Design Patterns" nicht fehlen, fast schon eine Glaubensfrage unter Programmierern :D
wobei das Thema selbst im Studium bei uns nur angerissen wurde, richtig vermittelt hatten die MVC nicht, hatte eher den Eindruck die Praktikumsbetreuer hatten MVC selbst nicht hundertprozentig verstanden. Das Observer-Pattern z. B. kam gar nicht vor.

Ich habe zum Thema Design Patterns auch noch das Buch "Entwurfsmuster von Kopf bis Fuß" hier rumliegen, auch wenn ich zu meiner Schande gestehen muss bislang kaum einen Blick hineingeworfen zu haben seitdem ich mit dem Studium angefangen habe.

Gast

2013-07-17, 12:17:04

Deshalb: was ich suche, wäre ein Buch was mal tatsächlich auf die Theorie eingeht: was sind Klassen, was Objekte? Wann lädt die Runtime was? Was ist der Unterschied zwischen Methoden, Properties und Feldern, und wann benutzt man welche? Was sind Iteratoren, was ist lazy Evaluation? Was sind Value und Reference Types, und wann nimmt man welche? Was heißt Call-By-Value in .NET?bei deiner Liste von Fragen muss man allerdings zurückfragen, welche Theorie genau denn "die Theorie" eigentlich sein soll?

Deine erste Frage, was Klassen und Objekte sind, betrifft die allgemeine Theorie der OOP. In der aber hat deine zweite Frage, wann die Runtime was lädt, rein gar nichts verloren, da in der allgemeinen Theorie der OOP überhaupt keine Runtime vorkommt, geschweige denn eine Regel, wann die irgendetwas laden soll. Die dritte Frage passt dann schon eher wieder, allerdings kennt die allgemeine Theorie der OOP nur Methoden und Felder, keine Properties. Ebenso sieht sie keine Iteratoren und keine Wert- und Referenztypen vor.

Nimmt man an, dass du stattdessen die Theorie des .NET-Frameworks meintest, so passen zumindest die Fragen ab der dritten. Die zweite Frage passt aber auch dann nicht: die Theorie des .NET-Frameworks sieht zwar die Existenz einer Runtime vor, legt aber nicht fest, wann die irgendetwas lädt.

Monger

2013-07-17, 14:42:05

Deine erste Frage, was Klassen und Objekte sind, betrifft die allgemeine Theorie der OOP. In der aber hat deine zweite Frage, wann die Runtime was lädt, rein gar nichts verloren, da in der allgemeinen Theorie der OOP überhaupt keine Runtime vorkommt, geschweige denn eine Regel, wann die irgendetwas laden soll. Die dritte Frage passt dann schon eher wieder, allerdings kennt die allgemeine Theorie der OOP nur Methoden und Felder, keine Properties. Ebenso sieht sie keine Iteratoren und keine Wert- und Referenztypen vor.
Ich finde es ehrlich gesagt schwierig, überhaupt über OOP sprachneutral zu reden. Wenn man den kleinsten gemeinsamen Nenner aller OO Sprachen nimmt, bleibt im Kern fast nichts übrig. Einige Sprachen kennen noch Mehrfachvererbung, andere nicht. Manche kennen Generics, andere nicht. Manche erlauben sehr weitgehende Ko- und Kontravarianzen, manche nicht. Die Liste lässt sich wahllos weiterführen: nicht alle Sprachen kennen Zeiger, nicht alle behandeln elementare Datentypen als Objekte, nicht alle kennen Reflections, nicht alle kennen dynamische Typen, und nicht alle gehen mit virtuellen Überladungen gleichermaßen um.
Wo also die Grenze ziehen?

Ich bezieh mich hier schon explizit auf .NET. Den Horizont auf andere Sprachen zu erweitern ist natürlich grundsätzlich nicht uninteressant, aber ich wäre schon froh wenn es innerhalb von .NET hier einigermaßen rund laufen würde.

Gast

2013-07-17, 17:29:00

Ich finde es ehrlich gesagt schwierig, überhaupt über OOP sprachneutral zu reden. Wenn man den kleinsten gemeinsamen Nenner aller OO Sprachen nimmt, bleibt im Kern fast nichts übrig. Einige Sprachen kennen noch Mehrfachvererbung, andere nicht. Manche kennen Generics, andere nicht. Manche erlauben sehr weitgehende Ko- und Kontravarianzen, manche nicht. Die Liste lässt sich wahllos weiterführen: nicht alle Sprachen kennen Zeiger, nicht alle behandeln elementare Datentypen als Objekte, nicht alle kennen Reflections, nicht alle kennen dynamische Typen, und nicht alle gehen mit virtuellen Überladungen gleichermaßen um.
Wo also die Grenze ziehen?der gemeinsame Nenner ist leicht zu finden, er ist einfach das sprachunabhängige OO-Paradigma, und das ist keineswegs "im Kern fast nichts". Das OO-Paradigma definiert:
- Klassen und Objekte
- Felder und Methoden, wobei beides sowohl statisch als auch instanzenbasiert sein kann
- Vererbung, und zwar erstmal als Einfachvererbung, wobei Mehrfachvererbung nicht ausgeschlossen wird
- Abstraktheit von Klassen
- virtuelle Methoden
- Information hiding, d.h. Felder sollen privat sein

Ob dann Mehrfachvererbung zugelassen wird oder nicht, ob zwischen abstrakten Klassen und Interfaces unterschieden wird oder nicht, wie virtuelle Methoden gehandlet werden (über Pointer oder Referenzen in C++, über Verweise in Java und C#), ob Methoden per se virtuell sind (Java) oder ausdrücklich als virtuell deklariert werden müssen (C++), ob Verletzungen des Information hiding geduldet werden oder nicht, ob Klassen Referenztypen sein müssen (Java, C#) oder auch Werttypen sein dürfen (C++) - das alles ist Sache der jeweiligen Sprache.

Wenn man nur ein einzige OO-Sprache kennt, oder zwei Sprachen, die sich sehr ähneln, wie Java und C#, dann kann man das natürlich leicht übersehen.

Ich bezieh mich hier schon explizit auf .NET. Den Horizont auf andere Sprachen zu erweitern ist natürlich grundsätzlich nicht uninteressant, aber ich wäre schon froh wenn es innerhalb von .NET hier einigermaßen rund laufen würde.dann hättest du als Threadtitel wohl besser ".NET-Literatur: Wie anfangen?" wählen sollen. Wenn im Threadtitel nur "OOP" steht, ohne Nennung einer konkreten Sprache, dann erwarte ich auch, dass es um OOP im allgemeinen geht.

Yavion

2013-07-17, 19:28:37

Für Entwickler mit einem gewissen .NET-Bezug kann ich das hier wärmstens empfehlen:
http://www.amazon.de/Framework-Design-Guidelines-Conventions-Development/dp/0321545613/ref=pd_cp_b_0

Was mir an dem Buch vor allem gefällt ist, dass es gespickt ist mit den Kommentaren der Autoren, in denen sie ihre Gedanken, Erfahrungen und Lösungen erleutern. Dies geschieht häufig an praktischen Beispielen und z.T. auch kontrovers, so dass man als Leser gezwungen wird, sich selbst seine Gedanken zu machen.

Dadurch wirkt das Buch sehr viel eingängiger und persönlicher als ein normales Lehrbuch oder Referenzwerk. Das Buch wirkt streckenweise wie eine Konversation zwischen erfahrenen Software-Entwicklern und bleibt dabei sachlich und absolut unprätentiös.

Haarmann

2013-07-20, 09:54:01

Monger

Wer sich altes, ich benenne es mal prozedurales Programmieren gewohnt ist, der kommt mit den Objekten hervorragend klar, wenn er sie quasi flach ausrollt - sprich ignoriert. Seither klappts bestens.
Man kann ja auch in der alten Sichtweise solche Namen wie, Filesystem_Dateizugriff_Lesen vergeben - hindert Dich echt keiner dran.

ByVal ist ein Schreibschutz zB - denke dann ists einfach erklärt

Wie man jedoch ein komplexes Problem auseinanderbricht ist nun imo auch eine Erfahrungssache - denn was einfach zu coden ist und was nicht, das weiss der Anfänger wohl erst dann, wenn ers versucht hat.
Dieses Vorgehen lernte ich zumindest in Mathe - zerlege die Aufgabe ich kleinere Häppchen oder versuche die Aufgabe umzuwandeln, bis eine Dir bekannte Aufgabe entsteht.
Mein Lieblingsexempel, wo sich fast jeder verschätzt... lange Strings parsen. Klingt unglaublich einfach...

Ich weiss auch, dass die LEute sehr seltsam gucken, wenn man selbst keine Intention zeigt die "Segen" von Objekten zu geniessen - die "Flüche", wenn mal wieder eines ohne Dein Wissen geändert wurd, ersparst Dir aber auch gleich.

Ectoplasma

2013-07-20, 11:14:28

Ohne mich als Troll darstellen zu wollen, aber: Ohne methodisches Vorgehen und ein Mindestmaß an Talent für analytisches Denken, hilft auch kein Buch der Welt weiter.

Noch wichtiger ist aber der Wille dahinter.

PatkIllA

2013-07-20, 12:43:38

Tiamat

2013-07-20, 22:55:51

Klick dich mal durch Youtube. Da dürfte Tonnen an Videos über Objektorientierte Programmierung auf dich warten.

Monger

2013-07-21, 01:24:41

Monger

Wer sich altes, ich benenne es mal prozedurales Programmieren gewohnt ist, der kommt mit den Objekten hervorragend klar, wenn er sie quasi flach ausrollt - sprich ignoriert. Seither klappts bestens.
Also quasi so wie ein Fahrradfahrer, der auch bestens mit einem Flugzeug zurecht kommt - solange er es einfach stehen lässt.

Sorry, da bin ich zu dogmatisch. OO ist nicht einfach nur ein Weg um prozeduralen Code in Klassen aufzuteilen. Ich hab genügend Code gesehen von Leuten die genau das von dir beschriebene "Ausrollen" machen. Es gibt halt Probleme, die lassen sich ohne OO nur mit irrwitzigem Aufwand "lösen", sind aber in Folge dessen nahezu unwartbar und auch untestbar.

Ich seh auf Arbeit regelmäßig, dass es leichter ist jemandem OOP beizubringen der wirklich überhaupt keine Vorkenntnisse in Programmierung hat, als jemandem der mit prozeduralen Sprachen aufgewachsen ist - was leider bei uns aufgrund von etlichen Microcontroller Dialekten relativ häufig vorkommt.

Haarmann

2013-07-21, 06:13:24

Monger

Nicht wirklich - eher wie der Fahrradfahrer, der dem Einrad nen Stützrad anbaut ;).

Solange Du bei OO den Quellcode besitzt, kannst auch erweitern wie Du grad lustig bist - ohne wirkliche Probleme. Leider kannst mit OO auch fremden Code, dessen Quellcode Du nicht kontrollieren kannst, erweitern. Und das würde ich tunlichst vermeiden.

Flach ausrollen heisst daher - erweitere Deine Sachen direkt und ohne Hierarchie - wenns geht und lass möglichst die Finger von irgendwelchen Dingern über die Du keine Kontrolle hast.

Damit etwas Fleisch an den Knochen kommt... ein Exempel aus der Realität.

Test einer Eigenentwicklung auf einem neuen System mit neuer Version. Geht aufm Entwicklerrechner - ergibt bei mir nen Abflug mit Modul nicht gefunden. Ursache ist natürlich kein Modul... sondern ein Fehler in einem fremden Framework... meine Parameter lösten das erst aus, waren aber laut Dokumentation des Frameworkanbieters nach wie vor korrekt. Die Suche dauerte ne sehr lange Weile...

RattuS

2013-07-21, 12:14:19

Flach ausrollen heisst daher - erweitere Deine Sachen direkt und ohne Hierarchie
Das hat den fiesen Beigeschmack, dass alles seinen eigenen Grundstein legt und somit zu der von Monger erwähnten Unwartbarkeit führt. Für kleinere Projekte mag das noch in Ordnung gehen, aber bei größeren Projekten kommst du bei solchen Strukturen vom Hundertsten ins Tausendste, wenn dann doch mal etwas umgebaut werden muss.

wenns geht und lass möglichst die Finger von irgendwelchen Dingern über die Du keine Kontrolle hast.
Das dürfte eine grundsätzliche Empfehlung sein, denn beide Stile leiden darunter.

Test einer Eigenentwicklung auf einem neuen System mit neuer Version. [...]
Inwiefern hat das mit OOP zu tun? Inwiefern wäre es kein Problem, wenn du flache Hierarchien hättest? Das externe Framework bleibt doch so oder so?

Exxtreme

2013-07-21, 12:27:21

Damit etwas Fleisch an den Knochen kommt... ein Exempel aus der Realität.

Test einer Eigenentwicklung auf einem neuen System mit neuer Version. Geht aufm Entwicklerrechner - ergibt bei mir nen Abflug mit Modul nicht gefunden. Ursache ist natürlich kein Modul... sondern ein Fehler in einem fremden Framework... meine Parameter lösten das erst aus, waren aber laut Dokumentation des Frameworkanbieters nach wie vor korrekt. Die Suche dauerte ne sehr lange Weile...

Ich glaube, in dem Falle ist es egal ob man "Flache Hierarchien" nutzt oder nicht. Sobald die Komponente etwas anders funktioniert als geplant dann halte ich es für sehr unwahrscheinlich, dass sie es nur dann tut wenn man keine "flachen Hierarchien" nutzt.

Monger

2013-07-21, 14:10:34

Solange Du bei OO den Quellcode besitzt, kannst auch erweitern wie Du grad lustig bist - ohne wirkliche Probleme. Leider kannst mit OO auch fremden Code, dessen Quellcode Du nicht kontrollieren kannst, erweitern. Und das würde ich tunlichst vermeiden.

Ich kann dir da grad nicht mehr folgen, keine Ahnung was du meinst.
Fremdkomponenten zu verwenden und zu erweitern ist für mich das, was ein Framework ausmacht. Und Softwareentwicklung lebt nun mal von der Verwendung von (eigenen und fremden) Frameworks, man will ja schließlich nicht jedes Jahr das Rad neu erfinden.

Haarmann

2013-07-31, 20:29:57

RattuS

Ich persönlich habe mehr Probleme mit einer Hierarchie noch irgendwas zu sehen...
Solange man es überblicken kann ist man imo flach einfacher dran.

Exxtreme und RattuS

Flach hätte ich nicht nach Modulen gesucht... die Fehlermeldung war verwirrend, weil völlig falsch.

War ja auch nicht mein Code...

Monger

Ich kann etwas einbinden indem ich es aufrufe - oder ich kanns erben. Ersteres gerne - letzteres nicht.

So wars angedacht.

RattuS

2013-07-31, 23:54:38

Ich persönlich habe mehr Probleme mit einer Hierarchie noch irgendwas zu sehen...
Solange man es überblicken kann ist man imo flach einfacher dran.
Na ja, ich kann dich verstehen. Es hängt letztendlich immer vom Programmierer ab. Es gibt Programmierer, die können sich auch durch Code lesen, der nicht "spricht". Viele Kollegen bevorzugen aber lieber eine bunte Welt, in der sich die Prozesslogik vorstellt, Namen trägt, beschreibt, was sie tut, Großeltern, Eltern, Geschwister und Kinder hat. Genau deswegen ist die OOP entstanden. Es ist (scheinbar) schlichtweg verständlicher eine solche Welt aufzubauen statt wie eine Maschine Zustände abzuarbeiten. Aber spätestens wenn sich ein paar Generationen Familie und Verwandtschaft aufgebaut haben, schwächelt die OOP oft. Hier rächt sich ein wackeliger Stammbaum oder schwach durchdachte Vererbungen. Die Kunst der Programmierung ist es, in solchen Momenten die Wahrheit frühzeitig zu erkennen, Entscheidungen zu überdenken und Dinge neu zu evaluieren. Das gilt aber eben nicht nur für die OOP. Also, welche der beiden Methoden lässt sich bei Bedarf hier effizienter umkrempeln?

Wenn ich objektorientierte Prozesslogik entwickle, tue ich das selten für mich selbst. Viel mehr möchte ich jetzige und auch zukünftige Kollegen dabei berücksichtigen. Es ist selbstverständlich, dass man seinen eigenen Code immer versteht. Nur die Anderen tun das vielleicht nicht? ;)