Wie kann ich eine bessere objektorientierte Programmierung üben? [geschlossen]

Ich programmiere seit Jahren in objektorientierten Sprachen, aber insgeheim schaue ich mir einige Dinge an, die meine Kollegen mit Neid tun. Viele von ihnen scheinen einen inneren OO-Instinkt zu haben, den ich nicht habe - egal wie sehr ich es versuche. Ich habe all die guten Bücher über OO gelesen, kann sie aber immer noch nicht knacken. Ich fühle mich wie der Typ, der 110% gegeben hat, um ein Profifußballer zu sein, aber einfach nicht das natürliche Talent hatte, es zu schaffen. Ich bin ratlos und denke darüber nach, meine Karriere zu wechseln - was soll ich tun?

Ich würde sagen, konzentrieren Sie sich weniger auf die OO-Programmierung und mehr auf das OO- Design . Nehmen Sie ein Papier und einen Bleistift (oder vielleicht ein UML-Modellierungswerkzeug) und entfernen Sie sich vom Bildschirm.

Wenn Sie üben, wie man ein System entwirft, bekommen Sie ein natürliches Gefühl für Objektbeziehungen. Code ist nur ein Nebenprodukt des Designs. Zeichnen Sie Diagramme und modellieren Sie Ihre Anwendung in einer rein nicht codierten Form. Wie sind die Beziehungen? Wie interagieren Ihre Modelle? Denken Sie nicht einmal an den Code.

Sobald Sie Zeit mit dem Entwerfen verbracht haben, übersetzen Sie es in Code. Sie werden überrascht sein, wie schnell der Code aus einem guten OO-Design geschrieben werden kann.

Nach viel Entwurfspraxis werden Sie gemeinsame Bereiche sehen, die modularisiert oder abstrahiert werden können, und Sie werden eine Verbesserung sowohl Ihrer Entwürfe als auch Ihres Codes feststellen.

Der einfachste Weg ist, Konzepte wie SOLID, DRY, FIT, DDD, TDD, MVC usw. zu lernen. Wenn Sie diese Akronyme nachschlagen, werden Sie durch viele andere Kaninchenlöcher geführt, und wenn Sie mit dem Lesen fertig sind, sollten Sie eine haben gutes Verständnis dafür, was eine bessere objektorientierte Programmierung ist!

SOLID-Podcasts: http://www.hanselminutes.com/default.aspx?showID=168 , http://www.hanselminutes.com/default.aspx?showID=163

FESTE Aufschlüsselung: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

TROCKEN: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

FIT: http://www.netwellness.org/question.cfm/38221.htm

DDD: http://dddcommunity.org/

DDD muss gelesen werden: http://www.infoq.com/minibooks/domain-driven-design-quickly

TDD: http://en.wikipedia.org/wiki/Test-driven_development

MVC: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Und ja, es ist immer eine gute Idee, die Ärmel hochzukrempeln und zu codieren. Machen Sie ein kleines Projekt nach besten Kräften. Dann lesen Sie einen Artikel von oben. Überarbeiten Sie dann Ihren Code, um die Anforderungen des gerade gelesenen Codes zu erfüllen. Wiederholen Sie diesen Vorgang, bis Sie Ihren Code verdammt noch mal überarbeitet haben. Am Ende sollten Sie nicht nur wissen, worum es bei OO geht, sondern auch erklären können, warum es wichtig ist und wie Sie sie zum ersten Mal erhalten. Das Refactor-Lernen ist auch ein Schlüssel zu gutem Code. Was jetzt ist, ist morgen nicht richtig.

Zu viele Leute denken daran, zuerst zu codieren, Objekte, zuletzt.

Sie können alle Bücher lesen, die Sie möchten, aber das bringt Ihnen nicht bei, wie man objektorientiert denkt - das erfordert Übung und eine bestimmte Methodik.

1. Hier sind einige Methoden, die mir geholfen haben: Wenn Sie nicht arbeiten und aufgeschlossen sind, können Sie üben, indem Sie alles als Objekt betrachten . Schauen Sie sich diese Objekte nicht an und fragen Sie sich, wie Sie sie programmieren, sondern nur als Eigenschaften und Funktionen betrachten und wie sie sich aufeinander beziehen oder voneinander erben. Wenn Sie beispielsweise eine Person sehen, ist diese ein Objekt und würde daher eine Klasse darstellen. Sie haben Eigenschaften wie Haarfarbe, Hautton, Körpergröße usw. Sie erfüllen auch bestimmte Funktionen. Sie gehen, sprechen, schlafen usw. Einige der Funktionen, die diese Personen ausführen, liefern Ergebnisse. Zum Beispiel gibt ihre Arbeitsfunktion einen Dollarbetrag zurück. Sie können dies mit allem tun, was Sie sehen, weil alles ein Objekt ist. Fahrrad, Auto, Stern usw.

2. Entwerfen Sie ein Projekt vor dem Codieren mithilfe von Haftnotizen und einer Trockenlöschkarte. Dies wird eine gute Übung sein, bis Sie den Dreh raus haben. Denken Sie an Ihr spezifisches Objekt / Ihre spezifische Funktion / Eigenschaft. Jeder dieser Artikel hat eine eigene Haftnotiz. Platzieren Sie sie als Hierarchie auf dem Trockenlöschbrett. In dieser Hinsicht werden Funktion / Eigenschaften unter dem Objekt platziert. Wenn Sie ein anderes Objekt haben, machen Sie dasselbe für dieses. Dann fragen Sie sich, ob diese Post-It-Notizen (Objekte / Funktionen / Eigenschaften) miteinander in Beziehung stehen. Wenn zwei Objekte dieselbe Funktion verwenden, erstellen Sie ein übergeordnetes Objekt (Haftnotiz) und setzen Sie es mit der wiederverwendbaren Funktion unter der neuen Notiz über die anderen. Zeichnen Sie eine Linie mit dem Trockenlöschmarker von den beiden untergeordneten Objekten zum übergeordneten Objekt.

3. Wenn dies alles erledigt ist, machen Sie sich Sorgen über die Interna, wie die Klasse funktioniert.

Mein Vorschlag wäre, etwas anderes zu lernen.

Lernen Sie funktionale Programmierung und wenden Sie das, was Sie daraus lernen, auf OOP an. Wenn Sie C ++ kennen, spielen Sie mit der generischen Programmierung.

Lerne nicht objektorientierte Sprachen.

Nicht nur, weil Sie all diese Dinge auch verwenden sollten (Sie sollten) oder weil sie OOP vollständig ersetzen sollten (sie sollten es wahrscheinlich nicht), sondern weil Sie Lehren daraus auch auf OOP anwenden können.

Das Geheimnis von OOP ist, dass es nicht immer Sinn macht, es zu verwenden . Nicht alles ist eine Klasse. Nicht jede Beziehung oder jedes Verhalten sollte als Klasse modelliert werden.

Der blinde Versuch, OOP anzuwenden, oder das Bestreben, den bestmöglichen OOP-Code zu schreiben, führt tendenziell zu großen, überentwickelten Problemen mit viel zu vielen Abstraktions- und Indirektionsebenen und sehr wenig Flexibilität.

Versuchen Sie nicht, guten OOP-Code zu schreiben. Versuchen Sie, guten Code zu schreiben. Und verwenden Sie OOP, wenn es zu diesem Ziel beiträgt.

In vielen Bereichen gibt es einen "Eureka" -Moment, in dem alles zusammenkommt.

Ich erinnere mich, dass ich mich in der Geometrie der High School frustriert fühlte. Ich wusste nicht, welchen Satz ich auf jeden Schritt des Beweises anwenden sollte. Aber ich blieb dran. Ich habe jeden Satz im Detail gelernt und untersucht, wie sie in verschiedenen Beispielbeweisen angewendet wurden. Da ich nicht nur die Definition jedes Satzes, sondern auch dessen Verwendung verstand, baute ich eine "Toolbox" bekannter Techniken auf, die ich nach Bedarf herausziehen konnte.

Ich denke, dass es beim Programmieren genauso ist. Deshalb werden Algorithmen, Datenstrukturen und Entwurfsmuster untersucht und analysiert. Es reicht nicht aus, ein Buch zu lesen und die abstrakte Definition einer Technik zu erhalten. Man muss es auch in Aktion sehen.

So versucht , mehr Code zu lesen , zusätzlich zu praktizieren es selbst zu schreiben. Das ist eine Schönheit von Open Source. Sie können viel Code herunterladen, um ihn zu studieren. Nicht der gesamte Code ist gut, aber das Studium von schlechtem Code kann genauso lehrreich sein wie das Studium von gutem Code.

Lerne eine andere Sprache! Die meisten Entwickler, die nur Java verwenden (nur als Beispiel), haben nur ein begrenztes Verständnis von OO, da sie Sprachfunktionen und -konzepte nicht trennen können. Wenn Sie es noch nicht wissen, schauen Sie sich Python an. Wenn Sie Python kennen, lernen Sie Ruby. Oder wählen Sie eine der Funktionssprachen.

Die Antwort ist in deiner Frage;)

Üben, üben, üben.

Überprüfen Sie Ihren eigenen Code und lernen Sie aus den Fehlern.

TDD hat mir am meisten dabei geholfen, meine allgemeinen Fähigkeiten einschließlich OOP zu verbessern.

Je mehr Code Sie schreiben, desto mehr werden Sie die Fallstricke bestimmter Programmierpraktiken bemerken. Nach genügend Zeit und genügend Code können Sie die Warnzeichen dieser Fallstricke identifizieren und vermeiden. Manchmal, wenn ich Code schreibe, bekomme ich diesen Juckreiz im Hinterkopf und sage mir, dass es einen besseren Weg gibt, dies zu tun, obwohl es das tut, was ich brauche. Eine meiner größten Programmierschwächen ist die "Überanalyse" von Dingen, die die Entwicklungszeit dramatisch verlangsamen. Ich versuche, diesen "Juckreiz" zu verhindern, indem ich etwas mehr Zeit für das Design aufbringe, was normalerweise dazu führt, dass viel weniger Zeit für das Schreiben von Code benötigt wird.

... insgeheim schaue ich mir einige Dinge an, die meine Kollegen mit Neid tun. Viele von ihnen scheinen einen inneren OO-Instinkt zu haben, den ich nicht habe - egal wie sehr ich es versuche ...

Ich denke, Sie haben hier Ihre eigene Frage beantwortet. Das Lesen von gutem Code ist ein guter Anfang, und das Verstehen von gutem Code ist noch besser, aber das Verstehen der Schritte, um zu diesem guten Code zu gelangen, ist das Beste. Wenn Sie einen Code sehen, auf den Sie neidisch sind, können Sie den Autor vielleicht fragen, wie er zu dieser Lösung gekommen ist. Dies hängt ganz von Ihrer Arbeitsumgebung sowie den Beziehungen zu Ihren Kollegen ab. Auf jeden Fall zögere ich nicht, es ihnen zu sagen, wenn mich jemand nach dem Gedankenprozess hinter einem von mir geschriebenen Code fragt, weil ich weiß, dass ich möchte, dass sie dasselbe für mich tun.

Sprachdesigner haben "Objektorientierte Programmierung" unterschiedlich interpretiert. Sehen Sie zum Beispiel, wie Alan Kay, der Mann, der den Begriff OOP zum ersten Mal verwendete, ihn definierte:

OOP bedeutet für mich nur Messaging, lokale Aufbewahrung und Schutz sowie das Verbergen von Staatsprozessen und die extreme Spätbindung aller Dinge. Dies kann in Smalltalk und in LISP erfolgen. Es gibt möglicherweise andere Systeme, in denen dies möglich ist, aber ich bin mir ihrer nicht bewusst.

(Zitiert von http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en ).

Es mag seltsam erscheinen, dass er Java- und C ++ - OOP-Sprachen nicht berücksichtigt! Aber als Designer einer der ersten und besten OOP-Sprachen (Smalltalk) hat er seine eigenen gültigen Gründe dafür. Warum betrachtete Alan Kay Lisp als objektorientierte Sprache, aber nicht als Java? Diese Frage erfordert ernsthafte Überlegungen von jedem, der behauptet, OOP zu verstehen.

Erlang hat eine völlig andere Implementierung von OOP, Schema hat eine andere. Es lohnt sich, all diese alternativen Ansichten in Betracht zu ziehen. Wenn möglich, lerne all diese Sprachen! Das gibt Ihnen einen breiteren Ausblick, nimmt einige neue und leistungsstarke Tools in die Hand und macht Sie zu einem besseren Programmierer.

Ich habe meine Experimente mit der Implementierung einer OOP-Sprache zusammengefasst, basierend auf Ideen, die in diesem Artikel von Smalltalk, Scheme und Erlang entlehnt wurden .

       public void MasteryOfOOP() 
    { 
       while(true)

        /* My suggestion is: */
     DO: find a lot of well-written object oriented code and read it.  Then 
try to use the insights from it on your own coding.  Then do it again.  Then 
have a colleague who is a good OOP look at it and comment. Maybe post a chunk 
of your code on SO and ask for how it could be improved.

        Then read some more of those books.  Maybe they make a little more 
sense now...?

        Now go back to the top of this post, and do it again. 

        Repeat Forever.

        }
    }

Wenn Sie nicht wissen, wie Sie objektorientierte Systeme entwerfen sollen, beginnen Sie mit den Daten. Finden Sie heraus, welche Dinge Sie benötigen, um den Überblick zu behalten, und welche Informationen natürlich zusammenpassen (zum Beispiel alle Spezifikationen eines Modells einer Autogruppe gut zusammen).

Jede dieser Arten von Dingen, die Sie verfolgen möchten, wird zu einer Klasse.

Wenn Sie dann in der Lage sein müssen, bestimmte Aktionen auszuführen (z. B. ein Automodell als stillgelegt zu markieren) oder bestimmte Fragen zu stellen (z. B. zu fragen, wie viele eines bestimmten Automodells in einem bestimmten Jahr verkauft wurden), laden Sie diese Funktionalität auf die Klasse, mit der es am stärksten interagiert.

Im Allgemeinen sollte es immer einen ziemlich natürlichen Ort für ein bestimmtes Stück Code geben, um in Ihrer Klassenstruktur zu leben. Wenn dies nicht der Fall ist, signalisiert dies, dass es einen Ort gibt, an dem die Struktur ausgebaut werden muss.

Es gibt zu viele Informationen über Objekte. Das Wichtigste ist, die Grundlagen zu beherrschen, und alles passt leichter zusammen.

Hier ist eine Möglichkeit, über Objekte nachzudenken. Denken Sie an Datenstrukturen in prozeduralen Sprachen. Sie sind eine Gruppe von Feldern ohne Verhalten. Denken Sie an Funktionen, die Zeiger auf diese Datenstrukturen erhalten, und bearbeiten Sie diese. Definieren Sie nun die Funktionen innerhalb der Definition der Strukturen, anstatt sie getrennt zu haben, und nehmen Sie an, dass die Funktionen normalerweise einen Zeiger auf die zu manipulierende Datenstruktur erhalten. Dieser Zeiger heißt so. Stellen Sie sich Objekte in der Summe als die Kombination von Status (Daten) und Verhalten (Methoden - der ausgefallene Name für Funktionen in OOP) vor.

Dies ist die absolute Basis. Es gibt drei weitere Konzepte, die Sie unbedingt beherrschen müssen:

Vererbung - Hier geht es um die Wiederverwendung von Code.

Kapselung - Hier geht es darum, die Implementierung vor der Schnittstelle zu verbergen. Einfach ausgedrückt, sollte alles privat sein, bis das Gegenteil bewiesen ist.

Polymorphismus - Es spielt keine Rolle, welchen Typ die Referenzvariable hat, sondern welchen Typ die tatsächliche Instanz hat, um zu wissen, welches Verhalten (Methode) aufgerufen wird. Java macht es nicht einfach, dieses Konzept sehr gut sichtbar zu machen, da per Definition alles polymorph ist. .Net erleichtert das Verständnis, wenn Sie entscheiden, was polymorph ist und was nicht, und bemerkt so den Unterschied im Verhalten. Dies wird durch die Kombination von virtuell und Override erreicht.

Wenn diese Konzepte sehr gut verstanden werden, wird es Ihnen gut gehen.

Ein letzter letzter Tipp: Sie erwähnen die besten Bücher. Haben Sie " Thinking in Java " von Bruce Eckel gelesen ? Ich empfehle dieses Buch sogar Leuten, die mit .Net beginnen, da die OOP-Konzepte klar umrissen sind.

Werden Sie agiler, lernen Sie Junit-Tests und lernen Sie Domain Driven Design kennen. Ich schlage das Buch Domain-Driven Design vor: Bewältigung der Komplexität im Herzen von Software, obwohl es an einigen Stellen etwas schwierig ist.

OOP-Fähigkeiten kommen mit der Zeit. Das Lesen von 1, 2 ... 10 Büchern schneidet nicht. Übe das Schreiben von Code. Wenn Sie in einer Programmierumgebung arbeiten, kann dies hilfreich sein. Wenn nicht, versuchen Sie es. Bieten Sie an, einige Anwendungen kostenlos zu entwickeln. Sie müssen sich die Hände schmutzig machen. Denken Sie daran ... keine Anwendung ist von Grund auf perfekt. Deshalb gibt es ein Re-Factoring.

Auch ... lassen Sie sich nicht zu sehr von der OOP mitreißen ... es passiert mit der Zeit. Sorgen Sie sich um die Entwicklung voll funktionsfähiger Anwendungen.

Versuchen Sie etwas in Self zu programmieren , einer der reinsten OO-Sprachen. In der Tat so rein, dass es nicht einmal Klassen gibt, sondern nur Objekte. Es gibt auch keine Variablen, Felder, Statiken, Attribute, nur Methoden. Interessant ist auch die Tatsache, dass jedes Objekt im System auch ein Objekt auf dem Bildschirm ist und umgekehrt.

Einige der interessanten Artikel zu Self sind prototypbasierte Anwendungskonstruktionen mit SELF 4.0 (das Self-Tutorial), Self: Die Kraft der Einfachheit und das Organisieren von Programmen ohne Klassen . Auch Self: Das Video (Randall B. Smith; Dave Ungar) ist großartig, da zwei der Designer der Sprache die Ideen von Self erklären.

Das funktioniert für so ziemlich jedes Konzept, zumindest für mich: Finden Sie die Sprache, die das Konzept, das Sie lernen möchten, am reinsten verkörpert, und verwenden Sie es einfach.

OO hat endlich für mich geklickt, nachdem ich versucht hatte, ein bankähnliches Programm zu programmieren, das Transaktionen abwickelte, Zinsen berechnete und alles im Auge behielt. Ich habe es getan, während ich Java gelernt habe. Ich würde vorschlagen, es einfach zu versuchen, es zu vervollständigen und dann, wenn Sie fertig sind, eine gute Lösung anzusehen und zu sehen, was Sie besser hätten tun können.

Ich denke auch, dass die OOP-Fähigkeiten hauptsächlich durch Übung gestärkt werden. Erwägen Sie, Ihr Unternehmen zu ändern, wenn Sie länger als 3 Jahre dort sind. Dies gilt zwar nicht für alle Jobs, aber oft gewöhnt sich ein Mann an die Projekte und Praktiken in einem Unternehmen und hört im Laufe der Zeit auf, Fortschritte zu machen.

Krempeln Sie die Ärmel hoch und codieren Sie!

Du hast die Antwort selbst gesagt: üben. Die beste Lösung hierfür ist die Entwicklung eines Spiels. Verwenden Sie die Konzepte, die Sie in den Büchern dort gelernt haben.

Haben Sie das Kapitel über OO aus der ersten Ausgabe von Scott Meyers "Effective C ++" - Buch gelesen? Es hat es nicht zu späteren Ausgaben geschafft, aber es war eine großartige Erklärung. Der Titel lautete im Grunde "Sagen Sie, was Sie meinen, was Sie sagen" über geeignete Konventionen.

Eigentlich möchten Sie vielleicht meine Antwort auf eine ähnliche Frage hier sehen .

HTH

Prost,

Planen Sie Dinge aus. Fragen Sie sich, wie sich Ihre Objekte zueinander verhalten sollen, und suchen Sie nach Möglichkeiten, wie Dinge geändert und modularisiert werden können.

Codieren Sie die Dinge so, dass Sie, wenn Sie 1 Teil des Codes ändern möchten, nur diesen 1 Teil des Codes und nicht 50 Instanzen davon ändern müssen.

OOP können Sie nicht meistern, indem Sie Tausende von Büchern lesen. Vielmehr muss man die inneren Konzepte spüren. Lesen Sie alles, aber versuchen Sie zu fühlen, was Sie lesen. Erstellen Sie ein Konzept im Hinterkopf und versuchen Sie, diese Konzepte anzupassen, wenn Sie sich einem neuen Szenario stellen. Überprüfen und aktualisieren Sie Ihre Konzepte, während Sie neue Dinge erkunden.

Viel Glück!

Bier hilft. Ernsthaft. Legen Sie sich mit einem A3-Notizblock, einem Stift und einem Bier auf eine Couch. Schließen Sie den Hund, die Katze und die Frau draußen ab. Und denken Sie entspannt über das Problem nach. Wagen Sie es nicht einmal, eine API darauf zu zeichnen!

Flussdiagramme, Responsibity-Karten (CRC) und Bier (aber nicht zu viel) reichen weit.

Der einfachste Weg, Code umzugestalten, besteht darin, dies überhaupt nicht zu tun.

http://misko.hevery.com/code-reviewers-guide/

Diese kleinen einfachen Regeln machen Sie zu einem besseren OO-Programmierer. Befolgen Sie die Regeln religiös, während Sie codieren, und Sie werden feststellen, dass Ihr Code besser ist als sonst.

Sie möchten auch die soliden Prinzipien lernen: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

So sehr diese Prinzipien und Programmiermethoden Debatten auslösen, sind sie die einzige Möglichkeit, wirklich exzellenten Code zu schreiben.

Möglicherweise schreiben Sie bereits Code auf diese Weise und wissen es nicht - wenn ja, großartig. Wenn Sie jedoch ein Ziel benötigen, das Sie anstreben möchten, sind dies die Goldstandards.

Gib auf! Warum brauchst du das OOP? Schreiben Sie einfach eine brauchbare App. Metter nicht mit OOP, prozeduralem oder funktionalem Ansatz.

Welchen Ansatz Sie auch wählen, Python-Sprache sollte zum Üben geeignet sein.

Du bist meine Zielgruppe. Schauen Sie sich Building Skills in OO Design an

Vielleicht kann das helfen.