Wie kann man am besten die Begriffe der OOP lernen/verstehen?

Moin,

hmmm ich hab ein Problem, ich hab mir das GuidetoCSharp nu komplett durchgeballert aber weiter hinten wo es dann mit OOP anfängt versteh ich immer weniger. Die Begriffe

-> Konstruktoren
-> This.Zeiger
-> Vererbung
-> Klassenkonzept
-> Indexer
-> Delegates
-> Events....

sind mir irgendwie schleierhaft... Vielleicht bin ich auch einfach nur zu blööööd. 😦 Jemand ne Idee wie ich mir diese Begriffe näher bringen könnte ? Praktisch ? Sollte ich mich ohne diese Kentnisse schon an Windows Forms wagen ? I need Help 😉 !!

Gruß
Totwart

Ohne diese Begriffe solltest du dich gar nicht ans Programmieren wagen....

Ich schlage vor, du nimmst dir ein paar Stunden Zeit und arbeitest alles nochmal durch.

hmmm naja unverstädnlich für mich wird es ca. ab "Klassen" bei dem Guide .... das könnte ich nochmal durchackern aber ich zweifle so langsam an mir das ich für das programmieren gemacht bin 😉

Naja, so früh würde ich nicht aufstecken. Die OO-Konzepte sind für Noobs oft nicht ganz einfach zu verstehen. Vielleicht fragst du nicht gleich nach einer Liste von Begriffen, sondern versuchst mal konkret einen Begriff zu klären.

Dabei wäre es aber hilfreich, wenn du nicht nur schreibst "verstehe nur Bahnhof", sondern genau erklärst was du schon verstanden hast und wo es dann aussetzt. Zumal so der Eindruck vermieden wird, dass das Forum nur als interaktives Lernbuch genutzt wird. 🙂

Das Konzept von "Klassen" ist auf jeden Fall das Erste was du begreifen solltest. Das schließt sofort Vererbung mit ein.

Außerdem wäre es natürlich hilfreich, wenn du sagen würdest, ob C# deine allererste Programmiersprache ist, oder ob du schon anderweitig Programmiererfahrung gesammelt hast.

Ich werde mir das Kapitel "Klassen" und den Rest der da dran anschließt (beinhaltet auch alle anderen begriffe die ich aufgezählt hab) nochmal anschauen und durcharbeiten. Mal sehen wie es nach dem 2. oder 3. mal durchackern ausschaut. Ich bin eigentlich mehr der Typ der jemanden dabei haben müsste der dat schon kann und mir auch mal praktisch hin und wieder was zeigen könnte. 😉 Nunja, mal sehen...

C# ist meine erste Programmierprache, vorher noch nichts anderes gemacht.

Tja, bei Klassen handelt es sich eben primär um ein Konzept, das verstehst du nur mit Unmengen an Code nicht. Diffentialgleichungen lernt man ja auch nicht, indem man sich Berechnungen ansieht.

Die Fragen, die du dir beantworten solltest (oder das Buch):

* Wozu gibt es überhaupt Klassen?
* Unterschied bzw. Zusammenhang zwischen Klasse und Objekt
* Sinn und Zweck von Vererbung

Das Thema Konstruktor fällt nebenbei ab.

Hallo Totwart,

auch ich würde zur Geduld raten. Meiner Erfahrung nach brauchen (ausgebildete) Programmierer, die bisher in einer Sprache wie Pascal oder C (also prozedural/imparativ) gearbeitet haben, ca. 1/2 Jahr um die Konzepte der OOP grob zu begreifen und ca. 2 Jahre bis sie sattelfest damit sind.

herbivore

Original von herbivore
und ca. 2 Jahre bis sie sattelfest damit sind.

....und andere werden's nie verstehen....

Zu allererst musst Du wissen was der Unterschied zwischen Klasse und Objekt (manchmal auch als Instanz bezeichnet) ist. Dann wird auch klar, für was Konstruktor (denk an Konstruktion, etwas neues nach einem Bauplan erzeugen) und Destruktor (denk an Arnold Schwarzenegger in Terminator) benötigt werden.

Außerdem: Kauf Dir ein gutes Buch!

Das Problem ist natürlich auch, dass Konzepte wie Klassen ja bereits eine Art Lösungsmuster darstellen. Der Sinn solcher Muster erschließt sich aber oft nur einem erfahrenen Programmierer.

Wenn ich gar nicht um die Bedeutung von Modularisierung und Kapselung weiss, wie soll man dann den Sinn von Klassen verstehen?

Ich würde daher immer dazu raten, die ersten Schritte prozedural zu machen. Das dumme ist nur, dass .NET als Basis bereits objektorientiert ist. D.h. um selbst prozedurale Programme zu schreiben muss man bereits auf Objekt-Konzepte zurückgreifen.

Die logische Konsequenz wäre, erstmal eine Programmiersprache zu wählen, die komplett auf OO verzichtet..... so zumindest meine Meinung. Aber das ist eine rein theoretische Überlegung. Ich code schon so lange, dass ich mich nicht wirklich in einen Anfänger hineinversetzen kann.

wenn du noch nie programmiert hast, rate ich dir, zuerst etwas in einer sprache ohne oo zu programmieren. (z.b c)

dort lernst du vieles grundlegendes (variablendeklaration, funktionen usw) die du in oo zwingend brauchst. gehe schrittweise vor, und erschlag dich nicht mit einer tonne von informationen 😉

mein tipp, resp. so habe ich es gemacht

Es gibt aber auch so Personen wie mich, die ich nicht direkt benennen kann, aber die auch versuchen müssen irgendwie klar zu kommen. Teilweise kann ich die Argumentionen nicht ganz verstehen - vielleicht gerade weil ich anders?! - bin. Ich jedenfalls kann mir nicht einfach ein Buch kaufen und was lesen, denn ich verstehe es nicht, warum? Keine Ahnung - evtl. weil zuviel Informationsfluss aufeinmal kommt. Deswegen habe ich mir meine eigenen Lernstrukturen beigebracht.

Ich male mir zum Beispiel oft Zeichnungen wie ich mein Problem löse anhand der gelernten Struktogramme (der Schule sei dank). Damals habe ich nicht verstehen wollen, warum man sowas macht, aber jetzt benutze ich das Zeug um mir was verständlich zu machen und um es mir zu merken. Und um sich was zu merken, muss man es bzw. ich es verstehen. Nur dann bleibt es im Kopf und man kann davon weitere Lösungen abwandeln.

Apropos abwandeln: Kommen wir zum Thema OOP:
Ich kann heute teilweise noch keine klaren Antworten auf meine Probleme geben, gerade weil ich noch nicht alles verstanden habe. Ich für mich habe aber gemerkt, dass ich wesentlich einfacher lerne, wenn ich praktisch etwas Step by Step umsetzen kann. Beispiel die Objekte, etc...
Manchmal sagt Code mehr als 1000 Worte. Vielleicht hilft es Andren auch keine Ahnung. Mir jedenfalls hilft diese Kombination von Referenz (SDK, Buch), Planung anhand Diagramme und Schrittprogrammierung oft, um komplexe Probleme zu lösen.

An dieser Stelle möchte ich mich nochmals bei allen bedanken die mich soweit gebracht haben (herbivore, Programmierhans und und und) und hoffentlich auch in Zukunft so Hilfsbereit sein werden 🙂

Oft sehr hilfreich kann auch ein Prototype sein.....

Mal schnell ein paar Textboxen auf ein Form und alles Quick und Dirty miteinander verbinden.... Denn oft sieht man diverses erst bei der Realisierung.....

Will sagen: Lieber Zeit und Geld in einem kleinen Prototype versenken als ein sauberes OO aufzubauen welches nachher die Anforderungen nicht abdeckt.... Denn der Aufwand für ein sauberes OO ist in der Regel grösser als für einen Quick und Dirty Prototype..... und lieber nen Prototype wegschmeissen als ein fertiges OO-Gerüst... oder noch schlimmer auf einem verkorksten OO-Gerüst weitermachen weil schon zu viel investiert wurde.

Mit den Jahren lernt man dann den Prototype (wenn es denn einen braucht) von Anfang an so zu schreiben, dass gewisse Teile des Prototypes in das endgültige OO - Design übernommen werden können.

So kann z.B: für ein Programm welches Daten rumschickt (Socket oder was auch immer) ein Prototype erstellt werden welcher einen vererbten TcpClient verwendet welcher die Daten serialisiert (aus String Byte[] macht usw...) wenn sich die Machbarkeit bestätigt hat, dann wird der vererbte TcpClient nur noch erweitert (Designer-Unterstützung / Parametriesierte Constructor / Properties statt public Variablen / Methoden)....