Einführung in OOP

Hi ich bin auf der Suche nach einem Buch was einem das OOP ordentlich versteht.
Ich hab mir schon mehrere Online Texte durchgelesen. Immer wieder diese Beispiele von wegen das Auto is die Klasse und Gas geben is eine Methode und die Farbe ein Attribut etc. smile.gif
Nur irgendwie hab ich in meinem Kopf ne blockade um das programmiertechnisch logisch umzusetzen biggrin.gif
Für welche Sprache das Buch/Tut wäre is mir relativ egal (C# wär aber gut) will halt einfach mal GENAU verstehen was OOP is
mfg skelle

Hallo skelle,

das ist leider oft nicht so einfach wie Du es Dir vorstellst. Ich habe auch ziemlich lange gebraucht um zu verstehen worum es bei der OOP nun wirklich geht.

Meiner Erfahrung nach hilft da kein "richtiges" Buch. Es nützt auch manchmal gar nichts sich von erfahrenen Entwicklern schulen zu lassen. (Ich habe Java und C# geschult und selbst nach zwei Monaten konnten die wenigsten von sich sagen Sie hätten es verstanden.)

Egal mit wem Du redest, wenn er/sei ehrlich ist, wird er/sie Dir sagen, dass es einfach irgendwann "Klick" gemacht hat und dann war das Verständnis da.

Dir bleibt nur eine Sache übrig: Nimm Dir ein Buch (oder Onlinebuch) Deiner Wahl, und dann mache Aufgaben, versuche zu entwickeln, vergleiche die Musterlösungen, versuche zu verstehen warum dieses oder jenes so gemacht wird wie es gemacht wird.

Übung macht halt den Meister, sonst nüscht.

Viele Grüße
🙂 Torsten
PS: OOP for Dummies soll ganz gut sein.

Ja das mag sein, aber ma sone grobe Übersicht was eine Klasse und so überhaupt ist, wann man eine neue erstellt etc.
Ich weiss das hört sich erstma bissle blöde an, aber wie gesagt da blick ich noch nich so durch.
Das was wir in der Schule in INFO machen is ja stupides Befehle schreiben die nacheinander abgearbietet werden, mit eventuell ma einer Schleife drinn aber blos keine neuen prozeduren.
Aber wie gesagt da mir Programmieren schon interessiert wollte ich OOP halt ma ordentlich erklärt bekommen.
Ich hoffe es meldet sich noch wer der dafür vllt n Buch kennt, was dies wirklich von 0 erklärt
mfg skelle

Hallo skelle,

ich kann mich the_lmich nur voll und uneingeschränkt anschließen.

Ich habe jedenfalls nicht ein Buch gelesen und es dann verstanden, sondern verschiedene Bücher und Artikel und überhaupt alles, was ich über OOP in die Finger bekommen konnte.

herbivore

Das man an Quelltextbeispielen am meisten lernt, sehe ich ja auch ein =)
Kennt ihr vllt ein paar Adressen wo man ein paar kleine Programme findet an denen das Prinzip von OOP kurz erklärt wird?
Weil wenn ich mir hier im Forum QT's ansehe, dann sind die schon n grad zu kompliziert 😁
mfg skelle

Hallo skelle,

Das man an Quelltextbeispielen am meisten lernt, sehe ich ja auch ein

das haben wir aber gar nicht behauptet 🙂 Ich denke sogar, dass man dadurch OOP relativ schlecht lernt. Zur Unterstützung sind sie natürlich notwendig. Aber es kommt bei OOP mehr auf die Konzepte an. Der Vorschlag war daher Bücher zu lesen (und in diesem Zuge auch die Übungsaufgaben zu erledigen). Denn nicht das Lesen, sondern das Durcharbeiten von Büchern bringt den Gewinn.

Weil wenn ich mir hier im Forum QT's ansehe, dann sind die schon n grad zu kompliziert

OOP Beispiele müssen in der Regel größer sein, weil OOP nicht auf der Ebene von Funktionen (wie bei prozeduraler Programmierung) sondern auf Ebene von Klassen oder sogar erst im Zusammenspiel von Klassen funktioniert.

Davon abgesehen findest du auf mycsharp.de alle Programmierstile. Es gibt also keine Garantie, dass die Codebeispiele hier besonders objektorientiert sind.

herbivore

Ohne Eigenwerbung machen zu wollen 😉 ...

http://www.mycsharp.de/guide/guide/guide11.html
http://www.mycsharp.de/guide/guide/guide12.html
http://www.mycsharp.de/guide/guide/guide13.html

Wird derzeit auch endlich mal überarbeitet, aber für den Anfang dürfte es vielleicht das sein, was Du haben wolltest ...

Original von Golo Haas
Ohne Eigenwerbung machen zu wollen 😉 ...

>

>

>

Wird derzeit auch endlich mal überarbeitet, aber für den Anfang dürfte es vielleicht das sein, was Du haben wolltest ...

Sehr schön genau nach sowas hab ich gesucht 🙂
Wo grunsätzlich ma so alles erklärt wird.
Jetz bin ich mit meinem Grundverständnis zur OOP auch schon ein ganzen Stückchen weiter
mfg skelle

Hi,
Im September erscheint dieses Buch zu Deinem Thema. Eine Übersetzung kommt dann hoffentlich auch noch. So wie ich die Head First Buchreihe kenne wird das sicher sehr interessant.
Pat

Original von skelle
Jetz bin ich mit meinem Grundverständnis zur OOP auch schon ein ganzen Stückchen weiter

Und jetzt wird es dir wahrscheinlich so gehen wie es mir am anfang ging: "Ich weiss wie´s geht, aber warum brauche ich das jetzt? Imperative Programmierung funktioniert wunderbar."

Hallo zusammen,

die Phase hat wohl jeder durchgemacht, der von der imperativen Programmierung her kommt. Jedenfalls ging es mir genauso. Hat auch bestimmt ein halbes Jahr angehalten. Aber wenn man am Ball bleibt, kommt man auch über diese Phase hinweg zum Verständnis.

herbivore

Hallo zusammen,

warum denkt jeder bei OOP zuerst an Klassen? Klar ist das ein Bestandteil davon, aber doch nicht DER Knackpunkt, oder sehe ich das falsch?

Ich kenne auch Programmierer, die jeglichen Code in Klassen gepackt haben, aber das Resultat war kein Grad OO.

OO ist weitaus tiefgründiger, und geht meines Erachtens auch weiter als das reine Programmieren. Es ist eine Philosophie oder eine bestimmte Denkweise.

Ich habe auch an Praxisbeispielen immer wieder gelernt (müssen), und das ist der einzige Weg OO zu verstehen. Es bringt einem nichts, wenn man nur einen fremden Code sieht, man sollte verstanden haben, warum das so gemacht ist, und nicht anders. Vor allem geht es bei OO auch um solche Dinge wie Wartbarkeit und Skalierbarkeit, und das kann man im ersten Blick nicht erkennen (wenn man noch kein Verständnis für OO hat).

Also die Devise lautet Schaue, mach selber, lerne daraus, lerne daraus, lerne daraus...

Gruß
Norman-Timo

dieses buch ist zwar didaktisch grauenhaft, zeigt aber viele konzepte auf verschiedenen ebenen... (oo analyse, klassendesign, hierarchien.......)

http://www.amazon.de/exec/obidos/ASIN/3486579266/qid=1149062742/sr=8-2/ref=pd_ka_2/028-7384424-5750122

und natürlich der klassiker:

http://www.amazon.de/exec/obidos/ASIN/3827321999/qid=1149063005/sr=1-2/ref=sr_1_11_2/028-7384424-5750122

Das beste Buch was ich zu dem Thema gelesen habe (und innerhalb der letzten 10 Jahre mehrfach für Ausbildungszwecke weitergegeben habe) ist **'Objektorientiertes Programmieren in C++ von Nicolai Josuttis **(Untertitel: Von der Klasse zur Klassenbibliothek).
Es setzt Programmierkenntnisse vorraus, verwendet C++, sollte aber auch von Java und C# Entwicklern zu verstehen sein.

Original von norman_timo
warum denkt jeder bei OOP zuerst an Klassen? Klar ist das ein Bestandteil davon, aber doch nicht DER Knackpunkt, oder sehe ich das falsch?

Dann erklär doch mal, was für die der "Knackpunkt" ist.

Original von DarkKiller

Original von norman_timo
warum denkt jeder bei OOP zuerst an Klassen? Klar ist das ein Bestandteil davon, aber doch nicht DER Knackpunkt, oder sehe ich das falsch?

Dann erklär doch mal, was für die der "Knackpunkt" ist.

Ich wage mal einen Schuss ins Blaue...

Ich nehme mal an, norman_timo meint, der Sinn, Anwendung und das Zusammenspiel von Klassen, Objekten und Interfaces...
...nicht nur das "Klassenkonstrukt" an sich 😉

Hallo zusammen,

Peter Bucher kam mir wohl voraus 😉

In diesen Worten würde ich es auch unterschreiben. Wie auch schon oben erwähnt sind solche Dinge wie Wartbarkeit und Skalierbarkeit weitere wichtige Punkte.

So kann ich behaupten, dass nur weil man Code in Klassen packt, dass noch lange kein Wartbares oder Modulares oder Skalierbares oder Lesbares oder OO dabei herauskommt. Klassen sind hier Mittel zum Zweck, und zweifelsfrei funktioniert OO nicht ohne, aber OO ist auf eine höhere Ebene angesiedelt.

Ein kleines kurzes (für mich cooles) Beispiel kann ich ja mal kurz geben:

Nehmen wir mal folgende Anforderung an einer Software(komponente) an:

• Es soll primär als Schreibmaschine dienen, also
• Tastatureingaben einlesen
• Eingaben am Drucker ausgeben

Einfaches Konstrukt. Da kann ich diese Anforderung in eine Klasse packen, die die Tastatureingaben überwacht, und sobald welche gedrückt werden, schickt sie diese Eingabe an den Drucker.

Ist das schon OO? Ich denke nicht.

Also besser sind da schon 3 Klassen. Eine, die einfach die Tastatureingaben einliest, eine die irgendwas ausdruckt, und eine die als "Manager" zwischen diesen beiden Klassen (Objekten) agiert.

Ist das schon OO? Ich würde behaupten Jain.

Als richtig OO würde ich ansehen, wenn man folgendes Konstrukt verwendet:

• Eine Klasse, die als "Copy" Funktion eine Eingabe und eine Ausgabe verwaltet
• Eine abstrakte Klasse "Reader", die eine definierte Bereitstellung von Daten für "Copy" (oder vielleicht noch andere?) bereitstellt
• Eine abstrakte Klasse "Writer", die eine definierte Weiterverarbeitung von Daten aus "Copy" (oder vielleicht noch andere?) bereitstellt
• Eine konkrete Klasse "TastaturInput", die mittels "Reader" die eingelesenen Daten an "Copy" schickt
• Eine Klasse "PrinterOutput", die mittels "Writer" die Daten von "Copy" an den Drucker schickt.

--> Skalierbar, weil auch andere IO Geräte definiert werden können (nur durch Erweiterung, nicht durch Modifikation)
--> Wartbar, da der Workflow in "Copy" festgehalten, der IO Zugriff nur in der jeweiligen konkreten Klasse
--> Lesbar, da ein gewisser Fokus gegeben ist (z.B. Nur Druckerausgabe)

Das würde ich als OO sehen. Dass hier Klassen verwendet wurden, das fast nebensächlich.

Gruß
Norman-Timo

Super Beispiel Norman_Timo

Ich befinde mich etwa in Stufe 2 😉

Original von norman_timo
Hallo zusammen,

Peter Bucher kam mir wohl voraus 😉

In diesen Worten würde ich es auch unterschreiben. Wie auch schon oben erwähnt sind solche Dinge wie Wartbarkeit und Skalierbarkeit weitere wichtige Punkte.

So kann ich behaupten, dass nur weil man Code in Klassen packt, dass noch lange kein Wartbares oder Modulares oder Skalierbares oder Lesbares oder OO dabei herauskommt. Klassen sind hier Mittel zum Zweck, und zweifelsfrei funktioniert OO nicht ohne, aber OO ist auf eine höhere Ebene angesiedelt.

Ein kleines kurzes (für mich cooles) Beispiel kann ich ja mal kurz geben:

Nichts gegen dich, aber ich habe einfach mal das Lesen aufgehört, da ich annahm, dass sowas zur OOP gehört. Aber wenn ich das richtig verstehe, bist du der Meinung, dass der "Knackpunkt" von OOP in Klassen sind, die in "richtig OO" geschrieben sind.

Hallo DarkKiller,

Nichts gegen dich, aber ich habe einfach mal das Lesen aufgehört, da ich annahm, dass sowas zur OOP gehört.

Eine Frage stellen und dann die Antwort nicht lesen, ist aber wirklich nicht die feine Englische. Das dann auch noch zu schreiben, überschreitet die Grenze zur Unhöflichkeit. Zumal es eine gute Antwort war.

herbivore

Hallo DarkKiller,

Nichts gegen dich, aber ich habe einfach mal das Lesen aufgehört, da ich annahm, dass sowas zur OOP gehört.

ich bin nicht empfindlich, wenn man meine Ausführungen nicht liest. Jedoch würde ich Dich hier bitten, mein Beispiel zu lesen. Ich habe mir hier etwas Mühe gemacht, das so in der Art zu verfassen. Also bevor Du irgendwelche konkreten Fragen hast, lies doch bitte zuerst alles.

Außerdem verstehe ich Deine Aussage nicht so ganz:

Aber wenn ich das richtig verstehe, bist du der Meinung, dass der "Knackpunkt" von OOP in Klassen sind, die in "richtig OO" geschrieben sind.

Eventuell verwirrt mich das "OOP in Klassen", da OOP so wie ich es bechrieben habe höher angesiedelt ist, und zwangsläufig nicht "in" den Klassen sein kann.

Gruß
Norman-Timo

Hallo

Ich habe auch an Praxisbeispielen immer wieder gelernt (müssen), und das ist der einzige Weg OO zu verstehen.

Das Problem für mich ist nur wann merke ich (als autodidakt) wann und wie ich auf dem Holzweg bin?
Wie lernt man überhaupt die OOP?
Ist das etwas für Programmierprofis und Konzerne?

In den Büchern ist immer alles so schön erklärt:

Klasse Auto

Eigenschaften:
Farbe
Form

Methoden:

Bremsen
Gasgebn

Also, macht man ein Konsolen Programm übt so die OOP .

Grundklasse Fahrzeug
vererbt auf Auto, Lastwagen ...

So sitzt man tagelang am PC und übt. Irgendwann möchte man ja auch ein kleines Programm schreiben.
z.B ein Rechner.
Form erstellen, Button rauf, Felder rauf und los mit dem programmieren.

Aber wo sind jetzt hier die Objekte? Bremsen tuts nicht, hupen auch nicht und eine Farbe hat es auch nicht.

Also geh ich ins Netz und suche etwas aehnliches das mir zeigt wie es aussehen könnte. 8)

Ich glaube fast programmieren ist so etwas wie Lastwagen fahren.
Gerade aus und breite Strassen kann jeder. Aber enge Bergstrassen rückwärts zu fahren oder ein Anhänger korrekt an eine Rampe parkieren, können nur noch wenige. Obwohl jeder meint er kann es. 😉

Bin halt momentan ein wenig frustriert, weil ich seit Tagen brobiere mit Bleistift und Zettel so etwas aehnliches wie OO für mein Progrämmchen zu erstellen. 😁

Gruss Lothi, der Bastler

Hallo Lothi,

Das Problem für mich ist nur wann merke ich (als autodidakt) wann und wie ich auf dem Holzweg bin?

Hm, eigentlich gar nicht. Vermutlich im Nachhinein, wenn du OOP verstanden hast.

Wie lernt man überhaupt die OOP?

Das ist Thema des Threads und dazu gibt es schon verschiedene Beiträge.

Ist das etwas für Programmierprofis und Konzerne?

Nein, auch für Hobby-Programmierer, weil es in einer (rein) objektorierentierten Programmiersprache wie C# und mit der (natürlich) objektoriertierten .NET-Klassenbibliothek einfach passender und schöner ist, auch objektorientiert zu arbeiten.

Form erstellen, Button rauf, Felder rauf und los mit dem programmieren. Aber wo sind jetzt hier die Objekte? Bremsen tuts nicht, hupen auch nicht und eine Farbe hat es auch nicht.

Die Forms, Buttons und Eingabefelder sind die Objekte. Das Bremsen ist z.B. das Setzen des Focus und Farbe haben Controls sehr wohl und auch weitere Eigenschaften wie den (angezeigten) Text, die Größe usw.

Bin halt momentan ein wenig frustriert, weil ich seit Tagen brobiere mit Bleistift und Zettel so etwas aehnliches wie OO für mein Progrämmchen zu erstellen. 😄

Wie gesagt, Objektorientierung zu verstehen, dauert einfach lange. Geduldig und hartnäckig sein hilft. Das Verstehen von Objektorientierung ist nicht gerade ein Thema, das schnelle Erfolge verspricht. Diese muss man sich woanderes holen, z.B. mit kleinen, funktionsfähigen Programmen - egal, ob diese nun schon der Weisheit letzter Schluss in Sachen Objektorienierung sind oder nicht.

herbivore

Grunsätzlich kann ich Lothi schon verstehen. Die Übungsbeispiele orientieren sich immer schön an Real-World-Objekten und scheinen daher auch immer nachvollziehbar. Dann steht man vor der Aufgabe ein Log-File parsen und in eine Db schreiben. Hmmm. Wat nu?

Es ist richtig: Bei kleinen Aufgaben ist die Softwarestruktur tendenziell eher prozedural. Insbesondere gilt diese für Applikationen der klassischen Art "Eingabe-Verarbeitung-Ausgabe". Man arbeitet zwar irgendwie in und mit Klassen, aber eine richtige OO-Modellierung gibt es da scheinbar nicht.

Aber eben nur scheinbar. Bleiben wir mal beim obigen Beispiel. Der Anfänger wäre geneigt zu glauben, man bräuche jetzt eine Klasse "LogFile" und "DB". Aber hier muss man sich jetzt an Tätigkeiten orientieren, also z.B. eine Klasse "Parser". Dann will man vielleicht auch ein paar Einträge rausfiltern, also wäre ein Klasse "Filter" vielleicht ganz brauchbar. Und vielleicht ein Klasse "Exporter". Dann kommt man auf die Idee die Software modular zu halten und will vielleicht auch mal andere Format parsen. Schon ist man bei Interfaces und vielleicht sogar bei PlugIns. Bump.

Die Frage nach dem Holzweg ist schwierig zu beantworten. Als erfahrener Entwickler kennt man ein paar No-Gos (seien mal zyklische Referenzen als Beispiel genannt). Und wenn du dein Modell peu a peu verfeinerst und mit Leben füllst, stellst du meist fest, dass es an ein paar Stellen "unschön" (im englischen "code smells") anfühlt, d.h. du No-Gos verwenden musst um dein Modell zu halten. Spätestens das ist der Moment wo man weiss, dass das Modell nix taugt und verändert werden muss. EIn gutes Modell bildet eben alle Anforderungen ab, ohne dass man es "vergewaltigen" muss.

Muss man dazu ein Profi sein? Sicher nicht. Ist es leicht zu lernen? Ganz bestimmt nicht. Die Tatsache, dass die Beschäftigung mit Computern lange Zeit Hobby-Charakter hatte, läßt viele vermuten, dass es leicht sei zu programmieren. Das ist es keineswegs. Es ist noch nie so kompliziert gewesen SW zu entwickeln. Zugleich war es aber noch nie so einfach komplexe SW zu entwickeln. Das ist kein Widerspruch!

Ich wills mal so vergleichen: Angenommen du hast ein CAD-Programm mit dem man Häuser entwerfen kann. Ist deswegen jeder in der Lage Häuser zu bauen? Sicher nicht. Man muss Ahnung von Statik haben, von Materialien, Bautechnologien, usw.!

Wenn ich mir heute Code aus meiner Anfangszeit angucke, wird mir wirklich schlecht. Die läuft zwar immer noch beim Kunden, aber SO würde ich es garantiert nicht machen. Erfahrung bekommt man, indem man etwas erfährt. Das heisst man muss manche "Schmerzen" einfach mal am eignen Leib erleben (wie z.B. schlecht wartbare SW wo jeder Bugfix zu drei neuen Fehlern führt) um zu erkennen, wo es lohnt Dinge anders und besser zu machen.

Senior Entwickler wird man also nur, indem man selbst zum "Senior" wird. Ich denke, man muss mehrere tausend Stunden entwicklen um sich als halbwegs erfahren bezeichnen zu können.

@Lothi:

Du hast mein Problem so ziemlich genau auf den Punkt gebracht!
Ich hatte in letzter Zeit nich grosartig Zeit um mich ums programmieren zu kümmern aber mal sehen villeicht habe ich in der nächsten Zeit mal wieder öfter die Möglichkeit
mfg skelle

Meiner Ansicht nach geht es bei der OOP haupsächlich um die Abstraktion.
Basisobjekte sollten immer einen möglichst abstrakten Charakter haben, um Sie vielseitig nutzen zu können. Wenn Du die Realität in Objekte packen mußt, vergleiche die Gemeinsamkeiten der Objekte und richte Deine Klassen und Interfaces danach.

Oje, klingt das jetzt philosophisch... war gar nicht so gemeint.