[OOP] Hilfen zum Umdenken?

[BF1942 Freak]

nabend

ich programmiere hauptsächlich in php. bis vor einiger zeit immer nur prozedural. zur einiger zeit hab ich mir dann mal OOP angeschaut.
mein problem ist: ich "beherrsche" OOP, aber ich kann nicht "OOP-denken".
will heißen: ich weiß, wie man klassen definiert. das methoden sind, wie man sie erstellt. was es mit vererbung auf sich hat, wie das in PHP funktioniert. kurz: theoretisch kenne ich mich mit OOP in PHP aus, aber mir fällt es einfach total schwer umzudenken.


ich kann eine problemstellung einfach schlecht "objektorientieren". ein programm schlecht in klassen aufteilen. ich komme einfach nicht vom prozeduralen los.

habt ihr da vielleicht tipps oder vielleicht tutorials, die einem den umstieg erleichtern?
ich meine jetzt keine, in denen man gesagt bekommt, mit welchen schlüsselwörtern man was erzeugt und auch keine, in denen erklärt wird was methoden, was objekte, was klassen, was eigenschaften, was vererbung usw. ist. wie gesagt, die theorie kann ich - das denken nicht.

irgendein tutorial, wo man lernt probleme zu "objektorientieren", in klassen aufzuteilen. das muss ja noch nicht mal was speziell mit php zu tun haben.

irgendwelche tipps?

 

[Crescender]

so direkt erstmal keine. ich kann dir nur sagen, dass objektorientiertes arbeiten nicht nur dir schwer fällt. da sind schon andere vor dir dran gescheitert - da kann ich geschichten aus meinem informatikkurs berichten.

nundenn, es hilft wohl nichts, du musst einfach programmieren. dann kommt das objektorientierte denken irgendwann von ganz allein. ich selbst hab auch mal so angefangen, zusammen mit nem kumpel programmiert der da einiges von verstand, und irgendwann fängt man an einfach so zu denken.

da dein problem das aufteilen in verschiedene abschnitte zu sein scheint, würde ich dir dies nochmals ans herz legen. fang einfach mal an, mit irgendwem, der was davon versteht ein kleines projekt zu programmieren, meinetwegen einen bmi- oder debroka-berechner. irgendwann kommt man dann so langsam dahinter.

so long and greetz

 

[DaPsylo]

Moin moin,
also eins vorweg. Ich habe in der Uni 2 Semester Java gehabt aber ich habe da auch noch ein paar kleine Probleme, also mach dir nix draus. Am meisten hat mir eigentlich der Kurs Software Engineering geholfen.
Ziel ist es dort gewesen, eine Software von Anfang an zu Planen, also Pflichtenheft, Klassendiagramm usw.
Nun zu dir.
Schau mal, ob du irgendwie an folgendes Buch kommst: Head First Object-Oriented Analysis and Design.
Ein Komolitone, der recht gut in Software- Entwicklung ist, meinte es sei sehr gut.
Es hat jedoch die deutsche Übersetzung gelesen was aber eigentlich keinen Unterschied machen sollte. Ich persönlich kenne nur das Buch "Head First Design Pattern" vom gleichen Verlag und muss sagen, dass die alles eigentlich recht "Idioten"sicher erklären und es sogar in english sehr verständlich ist.
Ansonsten kenne ich selber keine Tuts oder so und schließe mich xXstrikerXx an.

MfG Psylo

 

[7H3 N4C3R]

Ich kann mich xXstrikerXx nicht so ganz anschließen. Durch Learning By Doing lernt man keine OOP. Dadurch gießt du vielleicht deine Funktionen in Klassen, aber das war es. Gerade das Zusammenspiel und Design von Klassen ist enorm wichtig. Das lernt man üblicherweise nicht im Selbstversuch sondern gewöhnt sich eher sehr grausigen Stil an. OOA und OOD (OO Analys&Design) sind sicherlich wichtigige Punkte, mit denen du dich beschäftigen kannst, allerdings wird es da sehr schnell zu allgemein und auch viel zu weitläufig.

Entwurfsmuster (z.B. Observer/Beobater (um ein bekanntes, aber sehr schwer beherrschbares zu nennen), Iteratoren, Fabrikfunktionen) sind ebenfalls ein sehr wichtiger Punkt. Dabei sollte man aber immer darauf achten, dass man solche Entwurfsmuster zu verwenden, die auch zur Sprache passen. Verschiedene Sprachen (bzw. deren Mittel) eigenen sich für verschiedene Entwurfsmuster mehr oder weniger gut. "Man kann auch mit C++ Java programmieren, aber mit Java geht's einfacher", mal salopp formuliert.

Da dir die Theorie aber soweit nicht helfen wird - ein grundlegender (weder vollständig, noch universell) Ansatz ist folgender:

Überlege dir, welche Dinge deiner Anwendung du mit Substantiven beschreiben kannst. Beispiel: Wir programmieren eine Autoverwaltung. Also z.B. "Auto". Aus Substantiven machst du Klassen.
Dann überlegst du dir, wie du diese Substantive mit Adjektiven beschreiben kannst bzw. was es "hat". Z.B. das Auto ist rot, schnell oder langsam, hat das Licht ein- oder ausgeschaltet. Daraus machst du Attribute/Eigenschaften der Klasse, für die du Getter und Setter bereitstellst.
Danach kommt, was das Auto alles kann. sprich was du mit Verben beschreiben kannst. Z.B. fahren, anhalten, explodieren Daraus machst du Methoden der Klasse. Da eine Klasse aber nicht alleine "lebt" (was hätten wir von einem nackten Auto), arbeitet die Klasse mit anderen zusammen - die Methoden der Klasse haben mit anderen Klassen zu tun. D.h. sie nehmen als Parameter Objetke entgegen oder gegen welche zurück und die Klasse werden von anderen Klassen verwendet.

Gerade der letzte Punkt ist schwierig und macht ein gutes OOD aus, da hiermit die Zusammenarbeit der Klassen beschrieben wird. Hierfür kannst du dir als Lern-/Orientierungshilfe bestehenden Code anschauen.

Vererbung ist ein schwieriges Thema, hier solltest du mit Vorsicht rangehen. All zu oft wird Vererbung falsch und missbräuchlich verwendet (das beliebte "Wir leiten Quadrat von Rechteck ab" - wenn du das in einem Tutorial findest, leg es ganz schnell weg).
(Laufzeit-) Polymorphie bedingt Vererbung und ist für den ersten Einstieg noch nicht unbedingt ratsam. Aber da kann man sich hinarbeiten.

Ein gutes Buch, Bekannte die gute Erfahrung mit OOP haben und auch guter bestehender Quellcode können gut weiterhelfen, ein Verständnis dafür zu entwickeln. Das ganze ist leider etwas zu umfangreich, um es mal so oder in einem Post zu erschlagen. Aber bei Rückfragen, einfach rückfragen.


Btw: Das von DaPsylo vorgeschlagene Buch hat ziemlich erschreckende Kundenrezensionen. Würde da zur Vorsicht raten, evtl. erstmal irgendwo ausleihen.

 

[ghorst]

ich kann mich da 7H3 N4C3R nur anschließen: learning-by-doing funktioniert bei oop nicht wirklich. ich habe es am anfang auf dem weg probiert und wenn ich mir meinen code von damals heute angucke, kann ich nur sagen: objekte ja, oop nein.
man sollte sich aus meiner sicht an den design pattern orientieren. die sind mit sicherheit nicht alleinselig machend, aber sie funktionieren (aber wie 7H3 N4C3R schon sagte, nur wenn sie zur sprache passen.) und sorgen in den meisten fällen tatsächlich dafür, dass man oop programmiert und nicht nur ein paar objekte erzeugt.

der klassiker zum thema entwurfsmuster:
Entwurfsmuster
muss man sich allerdings genau überlegen, ob das nicht lieber auf englisch liest.

 

[DaPsylo]

Btw: Das von DaPsylo vorgeschlagene Buch hat ziemlich erschreckende Kundenrezensionen. Würde da zur Vorsicht raten, evtl. erstmal irgendwo ausleihen.

Moin,
wie gesagt, ich habe es mir nur sagen lassen
Ich finde die Idee mit den Substantiven, Adjektiven und Verben echt genial, werde ich beim nächsten Entwurf auchmal so machen und schauen, ob es dann schneller geht

Als Design-Pattern (Entwurfsmuster) Buch empfehle ich das Head First Design Pattern
. Die englische Variante gibt es neu oder gebraucht recht günstig, k.A. warum die deutsche so teuer ist.

MfG Psylo

 

[7H3 N4C3R]

@DaPsylo: Klar, es kommt ja auch immer auf den Leser an und jeder muss für sich rausfinden, ob ihm das Buch gefällt. Ich hatte es nur gesehen und dachte ich erwähne es mal.

Zum Buch, dass ghorst empfohlen hat - das ist wirklich klasse, allerdings ist es auch eher eine Art Referenz und eher "wissenschaftlich" geschrieben und setzt idealer Weise Grundkenntnisse in SmallTalk oder C++ voraus. Wenn Englisch kein Problem darstellt, würde ich definitiv die englische Variante empfehlen, da die deutsche Übersetzung ein wenig "unglücklich" ist und sogar die Quelltexte eingedeutscht wurden.

Das Head First Buch dagegen ist einfacher und recht praxisorientiert mit Beispielen. Wenn du erst einsteigst, ist ersteres Buch vielleicht etwas zu harte Kost. Evtl. mal Leseproben o.Ä. versuchen. Das Buch geht aber IIRC nicht so gut ins Detail und auf die Software-Mechaniken ein.

 

[BF1942 Freak]

vielen dank erstmal, ich werde mir die bücher mal ansehen.
englisch ist eigentlich kein großes problem, trotzdem habe ich bei solchen fachbüchern deutsche versionen lieber, da man bei sowas ja wirklich (fast) jedes wort verstehen sollte, wohingegen es bei "normalen" texten/büchern ja nicht schlimm ist, wenn man mal ein wort oder gar satz nicht versteht - der inhalt kommt trotzdem rüber. bei solchen fachbüchern sollte man wohl aber alles verstehen, oder?


ich habe da noch eine frage: ist PHP vielleicht nicht das richtige um OOP zu lernen? (weil es auch den prozeduralen ansatz erlaubt?)
ich habe ja bereits einige klassen geschrieben, die dann aber im "hauptprogramm" immer mehr oder weniger prozedural zusammengefügt...

 

[ghorst]

um es ganz offen zu sagen: für oop ist php die falsche sprache, wobei es nichts damit zu tun hat, das php auch prozeduale programmierung erlaubt. sprachen die dieses nicht tun, schießen aus meiner sicht am ziel vorbei.

ansonsten: sprachen mit strenger typisierung helfen beim lernen, auch und gerade was oop angeht.

 

[BF1942 Freak]

Warum ist php dafür die falsche sprache? mit php5 kamen doch viele neue oop-features dazu.
und z.b. pear: da ist alles objektorentiert. und auch professionellere skripts (also nicht nur so kleine besucherzähler) setzen fast immer OOP ein, wie z.b. forensoftware.
warum ist deiner meinung nach oop nichts für php?

 

[DaPsylo]

vielen dank erstmal, ich werde mir die bücher mal ansehen.
englisch ist eigentlich kein großes problem, trotzdem habe ich bei solchen fachbüchern deutsche versionen lieber, da man bei sowas ja wirklich (fast) jedes wort verstehen sollte, wohingegen es bei "normalen" texten/büchern ja nicht schlimm ist, wenn man mal ein wort oder gar satz nicht versteht - der inhalt kommt trotzdem rüber. bei solchen fachbüchern sollte man wohl aber alles verstehen, oder?

Um nochmal auf das HeadFirst DP zu kommen.
Ich persönlich habe es bis zu diesem Buch genau wie du gesehen und englishe Fachbücher strikt gemieden und bei diesem Buch habe ich auch nur die Ausnahme gemacht, da es in unserer Bibliothek nur die englische original Fassung gab.
Ich persönlich habe auch nicht jedes Wort verstanden aber meiner Meinung nach ist es so gut geschrieben bzw gemalt, dass man das auch garnicht muss.
Ich will jetzt hier aber weiter keine Werbung machen, dies soll nur mein persönliche Gefühl darstellen.

Einen Grund, warum PhP evtl nicht geeignet ist könnt sein, dass es nur eine Skriptsprache ist aber ich will mich da jetzt nicht zu weit aus dem Fenster lehnen und folgender Punkt von 'ghorst' könnte auch noch ein Grund sein:

sprachen mit strenger typisierung helfen beim lernen, auch und gerade was oop angeht.

MfG Psylo

 

[BF1942 Freak]

Ich werde mir aufgrund eurer Empfehlung und der Überwältigenden Kundenrezensionen auf Amazon (13x 5 Sterne, 1x 4 Sterne) "Head First Design Pattern" zulegen. "Head First Object-Oriented Analysis and Design" hat leider nur miserable Kritiken bekommen.
Meine Frage: 'Reicht' es (für den Anfang) ein Buch über Design Pattern zu lesen, oder sollte ich mich nach einem alternativen Buch über OOA&D zusätzlich umsehen? Oder vllt sogar mich vor Entwurfsmuster erst mit OOA&D beschäftigen?

 

[Zweipunktnull]

Also die Head First-Bücher sind eigentlich klasse und vielleicht solltest du dir doch das Buch über OOA&D aus der Head First-Reihe kaufen. Ich kenne es zwar nicht, aber mir ist etwas komisches aufgefallen, was die vernichtenden Rezensionen angeht.

Auf amazon.de gibt es zwar genau drei Rezensionen und alle drei vergeben entweder nur einen oder zwei Sterne. Guckt aber mal auf amazon.com. Dort sind nicht nur drei, sondern 26 Rezensionen und da liegt der Durchschnitt bei immerhin dreieinhalb Sternen, was eigentlich okay ist.

Nun, was wird repräsentativer sein? Drei Rezensionen auf amazon.de oder 26 auf amazon.com?

Wie gesagt, ich kenne es selbst nicht, aber laut Rezensionen scheint es doch ganz ordentlich zu sein - und eigentlich kann ich mir auch nur schwer ein "Ein-Stern-Buch" in der Head First-Reihe vorstellen...

 

[privacy]

Ich finde 2 Ergebniss zu "Head First Design Pattern". Ist das zweite Ergebnis nur die deutsche Übersetzung und kann man sie empfehlen?

Gruß Denis

 

[Zweipunktnull]

Wie man leicht am Cover erkennen kann, ja.

Head First Design Patterns (englische Originalversion)
Entwurfsmuster von Kopf bis Fuß (deutsche Übersetzung)

 

[moagnus]

Das sieht jetzt sehr billig unter den ganzen andern Einträgen aus... aber bei OOP ist es wichtig, dass du dir vor der eigentlichen Implementierung Gedanken machst, wer an einem Vorgang beteiligt ist, welche Eigenschaften er hat und was er können muss.

Beispiel Getränkeautomat:

Beteiligte: Automat, Person
Eigenschaften des Automaten: ein gewisses Kontingent an Wechselgeld, einen Vorrat an Getränken
Eigenschaften der Person: Bargeld
Funktionen des Automaten: eingeworfenes Geld prüfen, Getränk je nach Tastendruck auswählen, Wechselgeld ausgeben, Getränk ausgeben
Funktionen der Person: Geld einwerfen, Taste drücken, evtl. Wechselgeld entnehmen (, Flasche entnehmen)

Ich weiß nicht, ob ich dir damit helfen kann und es ist natürlich auch nur ein billiges Beispiel, aber es sollte doch helfen, sich ein wenig besser in die Welt der Klassen und Objekte zu versetzen.

 

[BF1942 Freak]

Hm.. ich hätte da noch eine Bitte.
Ganz oft ließt man so beispiele aus der realen Welt, wie bspw. Getränkeautomat, Autovermietung und so zeugs und welche klassen man dafür braucht.
aber das ist ja nicht das problem. bei so sachen aus der realen welt wie eine autovermietung wüsst ich auch, wie ich das in klassen aufteile.

könnte nicht vllt jemand das mal für ein programm machen und nichts reales?
Z.B. für so einen ganz billigen Texteditor wie der in Windows, der wirklich fast nichts kann. das wäre doch bestimmt keine große arbeit, oder? könnte vllt einfach mal jemand dafür sagen, welche klassen man benötigen würde?

EDIT: Oder wenn jemand UML Diagramme von einfachen "echten" Programmen hat, dann kann er das ja sagen. Ich finde im internet nichts...

 

[kaepten]

Ich sage Dir, wie Du am besten OO lernst: Du verwendest eine Programmiersprache, die komplett OO ist (Java, C#) und selbst eine umfangreiche und reine OO-Bibliothekssammlung mit sich bringt. Indem Du diese Bibliotheken benutzt, wirst Du ein Gespühr kriegen, was OO ist und kannst "abgucken"!

Warum bringen so viele OO immer mit Patterns in Verbindung? Die bekannten Patterns (die ich meine) besitzen schon eine gesunde Komplexität, die man erst verstehen kann, wenn man die OO Mechanismen kennt. OO über Patterns lernen ist meiner Meinung nach ziemlich grosser Unsinn und der verkehrte Weg! Wenn man OO kann, dann sollte man sich mit Design-Patterns befassen (oder ihr versteht unter Patterns etwas anderes als ich )

Ich kann einfach für C# sprechen und Dir sagen, dass es unzählige einfach aber auch komplexe "Musteranwendungen" gibt um in die Welt von OO (und C#) zu kommen. Ganze Portale und Foren gibt es da z.B. für ASP.NET.

 

[Loopo]

Nja die Beispiele mit den Autos und so sind recht nett.

Aber um ein Beispiel zu nennen, dass ich wirklich oft verwende, ist zB in der Programmierung einer grafischen Benutzeroberfläche. Die Bibliotheken bieten da zB ein Drop-Down-Menü an. Jetzt leite ich von der Drop-Down-Klasse eine neue Klasse ab, in der ich dann zB das Menü in einem neuen Konstruktor befülle und eine Methode integriere, um den Zustand des Drop-Down-Menüs abzufragen. Im übergeordneten Bereich des GUI kann ich nun einfach eine Instanz dieser neuen Klasse einbauen und brauch mich innerhalb der GUI-Klasse nicht mehr um Drop-Down-spezifische Dinge kümmern.