Objektorientierung erlernen

[DennisXX]

Hallo !

Ich bin noch recht neu in der Programmierung und möchte es möglichst von Anfang an richtig und sinnvoll erlernen. Dazu gehört für mich vor allem die Objektorientierung. Ohne diese werde ich wohl kaum gute Software, die nicht nur funktioniert, sondern auch schnell erweiterbar und wartbar ist.

Ich habe mir mal das Buch "Objektorientierte Analyse von Kopf bis Fuß" gekauft und fnde das Buch nicht schlecht. Ich möchte einfach mal eure Meinung hören:

Ich habe das Gefühl, dass ich die Objektoriertung nur sehr langsam verstehe. Wie genau ist das bei euch gelaufen? Hattet ihr am Anfang auch ein bißchen das Problem "abstarkt in Objekten" zu denken, wenn ihr eure Architektur entworfen und umgesetzt habt. F*** ich will das vernünftig lernen, aber es ist sehr mühselig und hart.

 

[Alex126]

Naja nar klar gibt es einfachere Sachen als OOP, aber wenn man es einmal kann und verstanden hat, wird es um ein vieles leichter.

Ja ich hab mir am Anfang auch sehr schwer getan weil ich von Delphi auf Java umgestiegen bin und in Delphi nur statisch programmiert habe. Doch so nach 1-2 Wochen mit Java hab ich mir dann mit OOP ziemlich leicht getan.

Ich kann dir dieses Youtube Tutorial empfehlen dort wird OOP ziemlich gut erklärt und noch vieles mehr solltest du dir vllt mal anschauen wenn du dir schwer tust(mir hat es sehr geholfen). In welchem teil OOP explizit behandelt wird weiß ich leider gerade nicht.

YouTube - Java Tutorial - Vom Noob zum SCJP! Teil 1: Setup
PS. Beachte seinen Desktop Hintergrund nicht den siehst du nur im ersten Teil...xD

 

[slawaweis]

Ich bin noch recht neu in der Programmierung und möchte es möglichst von Anfang an richtig und sinnvoll erlernen. Dazu gehört für mich vor allem die Objektorientierung. Ohne diese werde ich wohl kaum gute Software, die nicht nur funktioniert, sondern auch schnell erweiterbar und wartbar ist.

dazu solltest Du eher ein paar Bücher über Softwareprojektplanung, -organisation, -durchführung, -management und -wartung lesen. Objektorientierung ist nur ein Werkzeug, es entscheidet nicht über gute oder schlechte Software.

Ich habe das Gefühl, dass ich die Objektoriertung nur sehr langsam verstehe. Wie genau ist das bei euch gelaufen? Hattet ihr am Anfang auch ein bißchen das Problem "abstarkt in Objekten" zu denken, wenn ihr eure Architektur entworfen und umgesetzt habt. F*** ich will das vernünftig lernen, aber es ist sehr mühselig und hart.

ich habe mindestens 4 Jahre gebraucht, bis ich um die 80% der OOP-Techniken verstand und sicher anwenden konnte. Bis Heute lerne ich immer wieder neue Sachen dazu. Es geht dabei nicht nur darum, die Bücher zu lesen und die Sachen darin wiederzugeben. Vor allem muss man es üben und anwenden, immer wieder üben und anwenden. Erst durch Erfahrung und viele viele Fehlschläge lernt man es wirklich zu begreifen, deshalb dauert es auch so lange. Dazu sollte man sich angewöhnen viel fremden, aber guten, Code zu lesen, auch wenn man am Anfang 90% davon nicht versteht. Die Beispiele in den Büchern sind leider immer sehr kurz und oft theoretischer Natur. Am besten man überlegt sich ein eigenes Projekt, eine Softwarelösung für ein bestimmtes reales Problem/Wunsch das man hat (CD-Verwaltung, Lieblingsbrettspiel als Computerspiel, automatische Bilderverarbeitung, ...) und versucht es umzusetzen.

Noch eine wichtige Sache. OOP ist nur ein Tropfen im Glas der Softwareentwicklung. Um eine konkrete Software zu erstellen, braucht man mehr Wissen, wie Betriebssystemverhalten, Dateisysteme, Softwareweitergabe, automatische Build-Prozesse, wie eine IDE einem helfen kann, Projektplanung, Softwarearchitektur, Datenbanken, Dokumentation, Versionsverwaltung, viele viele Bibliotheken und einiges mehr. So ist da noch viel zu lernen. Man muss auch nicht alles verstehen, manches versteht man sowieso erst nach Jahren. Am Ende zählt nur, ob man eine Software erstellt hat, die den Anforderungen entspricht, ohne grobe Fehler läuft und gut wartbar ist. Wie es entsteht, ist relativ. Kann auch komplett ohne OOP passieren.

Slawa

 

[Empire Phoenix]

Für mich war das Konzept eigentlich absolut logisch von anfang an, weil ich in Garrysmod angefangen habe zu programmieren/scripten, (ist ein Sourceengine mod), dort hat man bereits mit Objecten zu tun, weil alles in der WElt objectorientiert gemacht wird (bzw zumindest das lua interface so programmiert ist das es so wirkt).

Am anfang mit echten virtuellen objecten zu arbeiten(aka metallplatte) hilft die ersten abstraktions probleme zu überwinden.

Zu dem thema kann ich für den start auch mal Greenfoot empfehlen, welches eine einfache 2d engine einbinded, und somit einem hilft eineige sachen etwas weniger abstrakt zu betrachten.

 

[DrPCox]

Ich habe mich auch sehr schwer getan mit dem Thema - da ich ja selbst noch Anfänger bin - aber die Kombination dieser beiden Bücher hat mir echt geholfen und kann es eigentlich nur weiterempfehlen:

Grundkurs Programmieren in Java: Amazon.de: Dietmar Ratz, Jens Scheffler, Detlef Seese, Jan Wiesenberger: Bücher

Objektorientierte Programmierung. Das umfassende Handbuch - Das Buch von Galileo Computing

 

[Marco13]

Hmja, die grundlegenden Sachen bei der OO sind eigentlich ... sehr anschaulich. Jemand hatte das hier mal so beschrieben (ich glaube ARadauer war's) : Man schreibt sich auf, was man in dem Programm machen will. Die Substantive in dem Text sind die Klassen/Objekte, die Verben sind die Methoden, und die Adjektive sind die Fields. Wenn man ein Programm schreiben will, wo ein grünes Auto über eine Straße fährt, dann braucht man nicht zu überlegen bevor man

class Auto 
{ 
    Color farbe;
    void fahre() { ... }
}

hinschreibt. Aber das natürlich nur in erster Näherung In Wirklichkeit (also bei "komplexeren" Programmen) kann man schon SEHR viel Zeit in die (gedankliche) Modellierung inverstieren (und das sollte man auch). Oft stellt man dann fest, das bestimmte Strukturen immer ähnlich sind. Das sind dann "Design Patterns".
Viele wichtige OO-Konzepte tauchen in Swing auf. Vererbung, Polymorphie, Interfaces, und auch Muster wie die Sache mit Model-View-Controller oder allgemein Listenern.

 

[DrPCox]

Hmja, die grundlegenden Sachen bei der OO sind eigentlich ... sehr anschaulich. Jemand hatte das hier mal so beschrieben (ich glaube ARadauer war's) : Man schreibt sich auf, was man in dem Programm machen will. Die Substantive in dem Text sind die Klassen/Objekte, die Verben sind die Methoden, und die Adjektive sind die Fields. Wenn man ein Programm schreiben will, wo ein grünes Auto über eine Straße fährt, dann braucht man nicht zu überlegen bevor man

class Auto 
{ 
    Color farbe;
    void fahre() { ... }
}

[zitar verkürzt]

Ganz im Ernst: Genau solche Beschreibungen der OOP haben mir anfänglich den Einstieg total versaut, denn in meinen Augen ist es ratsam sich die zuerst die zu Grunde liegenden Prinzipien (Generealisierung, Kapselung, Vererbung und Polymorphismus) an zu schauen, bevor man anfängt mit Instanziierungen, Klassen, Konstruktoren und Instanzmethoden um sich zu werfen.

 

[Landei]

Man sollte auch nicht vergessen, dass "java-artige OO" nicht die einzige "OO" ist. Klassen sind z.B. für OO nicht nötig, und ob die Typisierung statisch oder dynamisch (wie z.B. bei Smalltalk) ist, hat auch großen Einfluss darauf, wie OO realisiert werden kann. Dann gibt es noch Einfach-, Mehrfach- und Mixin-Vererbung. Weiterhin gibt es Sprachen (z.B. Haskell), in denen man fast alle OO-Techniken nutzen kann außer Vererbung (die von allen OO-Features das problematischste ist).

OO lässt zum großen Teil auf "grundlegendere" Prinzipien zurückführen, insbesondere auf:
- Don't repeat yourself
- Single Responsibility
- Uniform Access Principle (in einem weiteren, nicht nur auf Felder beschränkten Sinne)

 

[ARadauer]

@DrPCox: Vererbung wird überbewertet ;-)

In Head First Design Patterns: Amazon.de: Eric Freeman, Elisabeth Freeman, Bert Bates, Kathy Sierra, Mike Loukides: Englische Bücher gehts zwar um Patterns, aber es hat mich im Bereich Objektorientierung extrem weitergebracht ...

 

[Marco13]

Ganz im Ernst: Genau solche Beschreibungen der OOP haben mir anfänglich den Einstieg total versaut, denn in meinen Augen ist es ratsam sich die zuerst die zu Grunde liegenden Prinzipien (Generealisierung, Kapselung, Vererbung und Polymorphismus) an zu schauen, bevor man anfängt mit Instanziierungen, Klassen, Konstruktoren und Instanzmethoden um sich zu werfen.

Wie schon gesagt bezieht sich das auf die grundlegenden Dinge - also darauf, dass es "natürlich" ist, Dinge und deren Eigenschaften und was sie tun als Objekte zu beschreiben. Generalisierung und Kapselung sind IMHO zu einem gewissen Grad Teilaspekte davon, da sie stark damit zusammenhängen, dass man versucht, bei dieser Beschreibung glechzeitig abstrakt und präzise zu sein, und die Relalität™ möglichst so abzubilden, wie sie in bezug auf das Anwendungsgebiet auch IST.

 

[DrPCox]

@DrPCox: Vererbung wird überbewertet ;-)

erzähl das mal bitte, bitte meinem java-prof

 

[ARadauer]

Head First Design Patterns 1. Kapitel - > "Ziehen sie Komposition der Vererbung vor."

 

[DrPCox]

Head First Design Patterns 1. Kapitel - > "Ziehen sie Komposition der Vererbung vor."

Danke..auch wenns mir wenig nützt.

 

[Wortraum]

Ich kannte zwar die Theorien der Vererbung, aber bis es klick machte und ich die vielen Klassen zu Datenströmen verstand, warum man dieses und jenes in BufferedSonstwas stecken sollte, das kam später und irgendwann von allein. Bis ich den praktischen Nutzen von Schnittstellen gegenüber abstrakten kennenlernte, dauerte es auch.

dazu solltest Du eher ein paar Bücher über Softwareprojektplanung, -organisation, -durchführung, -management und -wartung lesen. Objektorientierung ist nur ein Werkzeug, es entscheidet nicht über gute oder schlechte Software.

Hast Du schon einmal eine Bohrmaschine für ein Mikroskop gehalten und versucht, hineinzuschauen? Ja, auch Kenntnisse über das Werkzeug sind wichtig!

 

[slawaweis]

Hast Du schon einmal eine Bohrmaschine für ein Mikroskop gehalten und versucht, hineinzuschauen? Ja, auch Kenntnisse über das Werkzeug sind wichtig!

ich habe nicht gesagt, dass man sein Werkzeug nicht kennen muss. Doch die besten Kenntnisse über den besten Hammer helfen einem nichts, wenn man nicht weis, wie man damit ein Vogelhaus zusammenzimmern kann, welches man entweder für gutes Geld an einen zufriedenen Kunden verkauft oder in einer Kunstausstellung präsentiert, ohne gleich ausgelacht zu werden. Manchmal braucht man für ein Vogelhaus nicht mal einen Hammer, sondern nur guten Holzkleber, aber der glänzende Hammer verleitet dazu Dinge zu machen, deren Folgen und Probleme man erst später merkt.

Slawa

 

[alderwaran]

ich bin auch recht neu in sachen java und oo.. auch wenn ich schon einige jahre als admin und entwickler tätig bin - ich habs bisher einfach nicht gebraucht.
das problem ist imho nicht die sprache an sich oder oo, sondern die vielen frameworks und redundanten funktionen... benutze ich nun zur threaderzeugung Thread, Runnable, oder (dieses andere ding das einen threadqueue vorhält, namen vergessen :bahnhof? in perl gibts dafür exakt eine funktion: fork()

angefangen hab ich damit ein java-buch durchzuackern, die beispiele darin abzutippen, dabei auch gleich die eigenschaften einer ide kennenzulernen, fehler im buch zu entdecken und ein paar eigenheiten der sprache kennen zu lernen...
und wie ein vorposter schon schrieb: neben den aufgaben die ich momentan beruflich zu erledigen habe (xml aus einer db spulen, per jaxb in java pressen und über itext ein pdf draus machen das eingabedaten wieder zurück zur db senden kann, das ganze höchstwahrscheinlich als bean in oracle forms eingebaut) versuche ich privat weiter in java-gebieten rumzuwühlen die in meiner arbeit nicht vorkommen.
momentan wäre das einen downloadmanager zu scheiben, multithreaded, mit gui.... learning by doing