design länge - Wie gestalten Sie objektorientierte Projekte?




für meta (20)

Lernen Sie Designmuster . Es war meine persönliche Revolution in den letzten zwei Jahren in Bezug auf OOP. Holen Sie sich ein Buch. Ich würde dir dieses hier empfehlen:

Leiter der ersten Entwurfsmuster

Es ist in Java, aber es kann für jede Sprache erweiterbar sein.

Ich arbeite an einem großen Projekt (für mich), das viele Klassen haben wird und erweiterbar sein muss, aber ich bin mir nicht sicher, wie ich mein Programm planen soll und wie die Klassen interagieren müssen.

Ich habe einige Semester lang einen OOD-Kurs besucht und viel davon gelernt; wie das Schreiben von UML und das Übersetzen von Anforderungsdokumenten in Objekte und Klassen. Wir lernten auch Sequenzdiagramme, aber irgendwie vermisste ich den Vortrag oder so, sie blieben nicht wirklich bei mir.

Bei früheren Projekten habe ich versucht, Methoden zu verwenden, die ich vom Kurs gelernt habe, aber normalerweise mit Code enden, sobald ich sagen kann "Ja, das sieht so aus, als ob ich daran gedacht hätte", habe ich keine Lust, durch den Dreck zu graben Neue Eigenschaften.

Ich habe eine Kopie von Steve McConnells Code Complete, die ich hier und anderswo immer wieder hören kann. Ich las das Kapitel über Design und schien nicht die Informationen zu bekommen, die ich suchte. Ich weiß, dass er sagt, dass es kein ausgetrockneter Prozess ist, dass es hauptsächlich auf Heuristiken basiert, aber ich kann nicht alle seine Informationen aufnehmen und auf meine Projekte anwenden.

Was also tust du während der High-Level-Design-Phase (bevor du mit der Programmierung beginnst), um zu bestimmen, welche Klassen du benötigst (insbesondere solche, die nicht auf realen Objekten basieren) und wie sie miteinander interagieren ?

Speziell interessiert mich, welche Methoden Sie verwenden? Was ist der Prozess, dem Sie folgen, der normalerweise ein gutes, sauberes Design ergibt, das das Endprodukt genau darstellt?


Wenn Sie über Fachwissen zu dem Projekt verfügen, an dem Sie arbeiten werden, wie zum Beispiel Banking. Es ist einfach, Ihre Objekte zu strukturieren und Sie wissen, wie diese Verbesserungen jeden Tag kommen.

Wenn Sie diese Expertise nicht haben, arbeiten Sie mit jemandem zusammen, der diese Expertise besitzt, und wandeln Sie diese Ideen in technische Details um.

Wenn Sie nicht wissen, wie Sie Ihr Projektdesign strukturieren sollten. Folgen Sie blindlings dem Buch "pragmatischer Programmierer". Ich war vorher in derselben Situation, versuche ein Kapitel aus diesem Buch zu lesen. Sie werden den Unterschied sehen, es wird Ihre Denkweise als Softwareentwickler verändern.


Zuallererst - Design sollte von deiner Seele kommen. Sie müssen es an jeder Faser spüren. Normalerweise laufe ich zwei oder drei Monate hinunter, bevor ich anfange, irgendetwas zu tun. Ich laufe einfach durch die Straßen (wirklich). Und denken. Gehen ist eine gute Meditation, weißt du? So können Sie sich gut konzentrieren.

Zweitens - Verwenden Sie OOP und Klassen nur dort, wo eine natürliche Objekthierarchie existiert. Verschleudern Sie es nicht künstlich. Wenn keine strenge Hierarchie existiert (wie in den meisten Geschäftsanwendungen), wählen Sie prozedural / funktional oder verwenden Sie zumindest Objekte nur als Datencontainer mit isolierten Zugriffsmethoden.

Und das letzte - versuchen Sie es zu lesen: Der Algorithmus des kreativen Denkens


Ich denke, die Antwort hier sollte sehr unterschiedlich sein, abhängig von der realen Erfahrung des Kerls.

Wenn Sie nur ein oder zwei Jahre Berufserfahrung haben, dann müssen Sie zu dem Punkt gehen, der ist: Wie kommen Sie zu dem Punkt, an dem Sie wirklich Ihre Daten kennen und genau verstehen, was Sie zu tun versuchen?

Ja, wenn Sie in der realen Welt über 5 Jahre gearbeitet haben, dann würden Sie sich für eines der vielen Software-Entwicklungsprozesse, Modelle oder Techniken entscheiden.

Aber du bekommst keine Erfahrung, wenn du nur Bücher liest. Sie sollten lernen, indem Sie in einer guten Gruppe unter einer guten Führung arbeiten.

Wenn das nicht möglich ist, solltest du es einfach selbst machen. Beginnen Sie mit der Iteration, indem Sie ein wahrscheinlich sehr unangenehmes Stück Code schreiben, Ihre Fehler lernen, alles verschenken, ein besseres programmieren und so weiter.

Sie werden viel über Ihre Codebasis lernen. Die Werkzeuge sind Werkzeuge, sie werden dir nichts beibringen.


Ich würde dir empfehlen, BlueJ und auch ActiveWriter zu benutzen, um zu lernen und auch ein gutes Verständnis für Objekte zu entwickeln. Das empfohlene Buch ist auch eine nette Quelle.

Aus Wikipedia :

BlueJ ist eine integrierte Entwicklungsumgebung für die Programmiersprache Java, die hauptsächlich für Bildungszwecke entwickelt wurde, aber auch für die Entwicklung kleiner Software geeignet ist.

Außerdem verwendet es UML und für mich war es eine gute Ressource, um einige Dinge über das Modellieren von Objekten zu verstehen.

alt text http://www.ryanknu.com/ryan/bluej.png

ActiveWriter ist ein Werkzeug zum Modellieren von Entitäten und Beziehungen, es erzeugt auch Code und ist leicht zu ändern. Es spart Ihnen Zeit und für agile Entwicklung ist sehr gut geeignet.

Alt Text http://altinoren.com/activewriter/Images/Introduction_1.png


Zitieren nur http://www.fysh.org/~katie/computing/methodologies.txt

Und im Kern von RUP ist ein kleiner Bereich, in dem Sie OO-Design-Talente einsetzen müssen. Wenn Sie sie nicht haben, ist es, als ob Sie eine Methodik für das Laufen der 100m haben.

"Schritt 1: Schreibe, dass du wirklich schnell rennst. Schritt 2: Geh und zeichne einen Plan der Rennstrecke. Schritt 3: Geh und kaufe wirklich enge Lycra-Shorts. Schritt 4: Lauf wirklich, wirklich, sehr schnell. Schritt 5: zuerst die Linie kreuzen "

Es ist der vierte Schritt, der schwer ist. Aber wenn Sie viel Gewicht auf 1,2,3 und 5 legen, ist es möglich, dass es niemand merkt und dann könnten Sie wahrscheinlich viel Geld verdienen, indem Sie die Methode verkaufen, um Athleten zu finden, die denken, dass es ein "Geheimnis" ist, 100m zu sein Läufer vorbei



Designmuster

Gestaltungsmuster

Singleton - Stellen Sie sicher, dass nur eine Instanz einer Klasse erstellt wird, und geben Sie einen globalen Zugriffspunkt für das Objekt an.

Factory (Vereinfachte Version der Factory-Methode) - Erstellt Objekte, ohne die Instanziierungslogik dem Client auszusetzen, und verweist auf das neu erstellte Objekt über eine gemeinsame Schnittstelle.

Factory-Methode - Definiert eine Schnittstelle zum Erstellen von Objekten, lässt jedoch Unterklassen entscheiden, welche Klasse instanziiert werden soll und verweist auf das neu erstellte Objekt über eine gemeinsame Schnittstelle.

Abstrakte Factory - Bietet die Schnittstelle zum Erstellen einer Familie verwandter Objekte, ohne deren Klassen explizit anzugeben.

Builder - Definiert eine Instanz zum Erstellen eines Objekts, lässt aber Subklassen entscheiden, welche Klasse instanziiert werden soll und ermöglicht eine feinere Kontrolle über den Konstruktionsprozess.

Prototyp - Geben Sie die Arten von Objekten an, die mithilfe einer prototypischen Instanz erstellt werden sollen, und erstellen Sie neue Objekte, indem Sie diesen Prototyp kopieren.

Verhaltensmuster

Chain of Responsibility - Es vermeidet, den Absender einer Anfrage an seinen Empfänger anzuhängen, so dass andere Objekte die Möglichkeit haben, die Anfrage zu bearbeiten. - Die Objekte werden Teile einer Kette und die Anfrage wird von einem Objekt zu einem anderen über die Kette gesendet, bis eines der Objekte damit umgehen wird.

Befehl - Verkapselt eine Anforderung in einem Objekt, Erlaubt die Parametrisierung von Clients mit unterschiedlichen Anforderungen und ermöglicht das Speichern der Anforderungen in einer Warteschlange.

Interpreter - Bei einer gegebenen Sprache definieren Sie eine Repräsentation für ihre Grammatik zusammen mit einem Interpreter, der die Repräsentation verwendet, um Sätze in der Sprache zu interpretieren / Eine Domäne einer Sprache, die Sprache einer Grammatik und die Grammatik einem hierarchischen objektorientierten Design zuzuordnen

Iterator - Bietet eine Möglichkeit, sequentiell auf die Elemente eines Aggregatobjekts zuzugreifen, ohne die darunter liegende Darstellung anzuzeigen.

Mediator - Definieren Sie ein Objekt, das die Interaktion einer Gruppe von Objekten kapselt. Mediator fördert lose Kopplung, indem er Objekte davon abhält, sich explizit aufeinander zu beziehen, und Sie können ihre Interaktion unabhängig voneinander variieren.

Beobachter - Definieren Sie eine Eins-zu-Viele-Abhängigkeit zwischen Objekten, so dass, wenn ein Objekt seinen Status ändert, alle seine Abhängigen automatisch benachrichtigt und aktualisiert werden.

Strategie - Definieren Sie eine Familie von Algorithmen, kapseln Sie sie ein und machen Sie sie austauschbar. Strategie lässt den Algorithmus unabhängig von Clients variieren, die ihn verwenden.

Template-Methode - Definiere das Grundgerüst eines Algorithmus in einer Operation und verschiebe einige Schritte auf Unterklassen. / Template-Methode lässt Unterklassen bestimmte Schritte eines Algorithmus neu definieren, ohne dass sie die Struktur des Algorithmus ändern müssen.

Besucher - Stellt eine Operation dar, die an den Elementen einer Objektstruktur / Besucher ausgeführt werden soll. Sie können eine neue Operation definieren, ohne die Klassen der Elemente zu ändern, auf denen sie ausgeführt wird.

Null-Objekt - Stellt ein Objekt als Ersatz für das Fehlen eines Objekts eines bestimmten Typs bereit. / Das Null-Objektmuster bietet intelligentes Verhalten, das nichts tut, und versteckt die Details von seinen Mitbearbeitern.

Strukturelle Entwurfsmuster

Adapter - Konvertieren Sie die Schnittstelle einer Klasse in eine andere Schnittstelle, die Clients erwarten. / Adapter ermöglicht die Zusammenarbeit von Klassen, die aufgrund inkompatibler Schnittstellen nicht möglich wären.

Bridge - Verfasst Objekte in Baumstrukturen, um Teil-Ganzes-Hierarchien darzustellen. Mit / Composite können Clients einzelne Objekte und Kompositionen von Objekten einheitlich behandeln.

Composite - Verfasst Objekte in Baumstrukturen, um Teil-Ganzes-Hierarchien darzustellen. Mit / Composite können Clients einzelne Objekte und Kompositionen von Objekten einheitlich behandeln.

Decorator - Fügt einem Objekt dynamisch zusätzliche Verantwortlichkeiten hinzu.

Flyweight - Use Sharing, um eine große Anzahl von Objekten zu unterstützen, die einen Teil ihres internen Zustands gemeinsam haben, während der andere Teil des Zustands variieren kann.

Memento - erfasst den internen Zustand eines Objekts, ohne die Kapselung zu verletzen und bietet somit einen Mittelwert für die Wiederherstellung des Objekts in den Anfangszustand bei Bedarf.

Proxy - Stellen Sie einen "Platzhalter" für ein Objekt bereit, um Referenzen darauf zu steuern.


Es ist oft wiederholt, aber völlig richtig - verstehen Sie Ihre Daten.

Für OOP sollten Ihre Klassen herausragende Informationen und deren Interaktion beschreiben.

Wenn Sie ein mentales Modell haben, das das Verhalten und die Lebensdauer der Daten gut beschreibt, haben Sie eine einfache Möglichkeit, Ihren Unterricht zu planen.

Dies ist nur eine Erweiterung von: Wissen Sie genau, was Sie zu tun versuchen.


Die Schritte, die ich für das anfängliche Design verwende (um zu einem Klassendiagramm zu gelangen), sind:

  1. Erfassung von Anforderungen. Sprechen Sie mit dem Kunden und räumen Sie die Anwendungsfälle aus, um zu definieren, welche Funktionalität die Software haben soll.

  2. Verfassen Sie eine Erzählung der einzelnen Anwendungsfälle.

  3. Gehe durch die Erzählung und markiere Substantive (Person, Ort, Ding) als Kandidaten-Klassen und Verben (Aktionen) als Methoden / Verhaltensweisen.

  4. Verwerfen Sie doppelte Substantive und eliminieren Sie die allgemeine Funktionalität.

  5. Erstellen Sie ein Klassendiagramm. Wenn Sie Java-Entwickler sind, verfügt NetBeans 6.7 von Sun über ein UML-Modul, das sowohl Diagramm- als auch Round-Trip-Engineering ermöglicht und KOSTENLOS ist. Eclipse (eine Open-Source-Java-IDE), hat auch ein Modellierungs-Framework, aber ich habe keine Erfahrung damit. Sie können auch ArgoUML ausprobieren, ein Open-Source-Tool.

  6. Wenden Sie die OOD-Prinzipien an, um Ihre Klassen zu organisieren (schließen Sie allgemeine Funktionen aus, erstellen Sie Hierarchien usw.)


Die Technik, die ich in realen Projekten mit angemessenem Erfolg verwendet habe, ist Responsibility Driven Design, inspiriert von Wirfs-Brocks Buch.

Beginnen Sie mit den User Stories auf höchster Ebene und skizzieren Sie mit Kollegen auf einem Whiteboard die High-Level-Interaktionen, die sie beinhalten. Dies gibt Ihnen die erste Idee, was die großen Module sind; und eine Iteration oder zwei von CRC-Karten mit hohem Level wie Spielen, sollten Sie eine Liste von Hauptkomponenten stabilisiert haben, was sie tun und wie sie interagieren.

Wenn eine der Verantwortlichkeiten groß oder komplex ist, verfeinern Sie diese Module so lange, bis Sie über Objekte verfügen, die klein und einfach genug sind, indem Sie die Interaktionen innerhalb des Moduls für jede der von den übergeordneten Interaktionen identifizierten Hauptoperationen ausspielen .

Zu wissen, wann man aufhören soll, ist eine Frage des Urteilsvermögens (das nur mit Erfahrung einhergeht).


Versuchen Sie die verhaltensorientierte Entwicklung. Es wird schwer sein, Ihre alten Gewohnheiten zu brechen, aber ich habe festgestellt, dass BDD wirklich die beste Wahl ist, wenn es darum geht, sich in der realen Welt zu entwickeln.

http://behaviour-driven.org/


Das Problem bei großen Projekten ist, dass Sie nicht alle Interaktionen zwischen Komponenten überwachen können. Es ist daher wichtig, die Komplexität des Projekts zu reduzieren. Klassen- und Sequenzdiagramme sind zu detailliert für diese Phase des Designs.

Versuchen Sie zuerst, von einer höheren Abstraktionsebene zu denken. Denken Sie an wichtige Komponenten und deren Verantwortlichkeiten (ihre Schnittstelle zu anderen Komponenten), sehen Sie sich einige architektonische Muster zur Inspiration an (nein, keine Designmuster, diese sind zu niedrig! MVC und Multi-Tier sind Beispiele für Architekturmuster). Bei relativ großen Projekten sollte eine solche Ansicht etwa 3-5 Komponenten enthalten.

Erst dann zoomt man in eine bestimmte Komponente hinein und versucht diese zu gestalten. Jetzt befinden wir uns auf der Ebene von Entwurfsmustern und Klassendiagrammen. Versuchen Sie, sich auf diesen Teil des Projekts zu konzentrieren. Wenn Sie feststellen, dass Sie eine Verantwortlichkeit zu einer der anderen Komponenten hinzufügen müssen, fügen Sie sie einfach Ihrer Dokumentations- / Aufgabenliste hinzu. Verschwenden Sie keine Zeit mit Nachdenken über die Implikationen, sie ändern sich viel zu schnell, überprüfen Sie, wann das Design stabiler ist.

Sie müssen nicht jede Komponente zu diesem Zeitpunkt vollständig entwerfen, obwohl es wahrscheinlich ratsam ist, einen Codeabschnitt zu haben, der die Schnittstelle der nicht implementierten Komponenten implementiert und einfache, aber nützliche Antworten generiert. Auf diese Weise können Sie beginnen, eine Komponente nach der anderen zu entwickeln (und zu entwickeln) und sie in einem angemessenen Maße zu testen.

Wenn neue Komponenten fertiggestellt sind, sollten Sie natürlich testen, wie (und ob) sie sich miteinander integrieren, bevor Sie fortfahren.

Ganz kurz: Nimm das OO- und Information-Hiding-Prinzip und ziehe es auf ein anderes Level!

PS: Zeichnen Sie viel beim Entwerfen, es ist wie echte Architektur!

PPS: Versuchen Sie, sich der Sache aus verschiedenen Blickwinkeln zu nähern, denken Sie über den Tellerrand hinaus (obwohl die Box der richtige Weg ist), Gespräche mit Gleichaltrigen können sehr nützlich sein ... und Sie haben etwas zu besprechen beim Mittagessen.


Während meiner Abenteuer beim Entwurf von Klassenstrukturen habe ich festgestellt, dass es sehr hilfreich ist, mit dem Schreiben von Pseudocode zu beginnen. Das heißt: Ich beginne mit dem "Schreiben" einiger allgemeiner Anwendungscode-Fragmente auf höchstem Niveau, spiele damit und entdecke die Elemente, die erscheinen - in der Tat, die Elemente, die ich - als Programmierer - verwenden möchte. Es ist ein sehr guter Ausgangspunkt für die Gestaltung der allgemeinen Struktur von Modulen und ihrer Interaktionen. Nach einigen Iterationen sieht die gesamte Struktur mehr wie ein vollständiges Klassensystem aus. Es ist eine sehr flexible Möglichkeit, Teile des Codes zu entwerfen. Sie können es als programmiererorientiertes Design bezeichnen.


Eine nützliche Technik ist, Ihre einzigartige Problembeschreibung mit etwas zu verbinden, das Sie in der realen Welt finden können. Zum Beispiel modellieren Sie ein komplexes Gesundheitssystem, das die Welt im Sturm erobern wird. Gibt es Beispiele, auf die Sie zurückgreifen können, um dies zu modellieren?

Tatsächlich. Beobachten Sie, wie die Seitenapotheke funktioniert, oder das Zimmer des Arztes.

Bringen Sie Ihr Domain-Problem zu etwas, das für Sie verständlich ist; etwas, auf das du dich beziehen kannst.

Sobald die "Player" innerhalb der Domain offensichtlich erscheinen und Sie beginnen, Ihren Code zu modellieren, entscheiden Sie sich für einen "Provider-Consumer" -Modellierungsansatz, dh Ihr Code ist der "Provider" des Modells und Sie sind der "Consumer" ".

Die Beziehung zur Domäne und ihr Verständnis auf hohem Niveau ist ein wichtiger Bestandteil jedes Designs.


Sie haben gefragt, dass viele Autoren ein Buch schreiben. Es gibt eine Reihe von Methoden und Sie sollten eine auswählen, die Ihnen am "schönsten" erscheint.
Ich kann das Buch "Domain Driven Design" von Eric Evans weiterempfehlen. Überprüfen Sie auch die Website dddcommunity.org .


  1. Studieren & Master Design Patterns.
  2. Als Nächstes lernen Sie das Domain Driven Design kennen
  3. Danach lernen Sie die Anforderung sammeln

Ich habe einige Semester lang einen OOD-Kurs besucht und viel davon gelernt; wie das Schreiben von UML und das Übersetzen von Anforderungsdokumenten in Objekte und Klassen. Wir lernten auch Sequenzdiagramme, aber irgendwie vermisste ich den Vortrag oder so, sie blieben nicht wirklich bei mir.

  1. Sie kennen den Schritt 3. Sie müssen es meistern. Ich meine, über eine Menge Übung, um es zu Ihrer zweiten Natur zu machen. Das liegt daran, dass die Methode, die Sie lernen, einfach so ist, wie wir sie früher hatten. Also musst du es wirklich beherrschen. Sonst wirst du immer wieder zu deiner ursprünglichen Art zurückkehren, etwas zu tun. Das ist irgendwie wie Test Driven Process, wo viele Java-Entwickler es nach ein paar Versuchen aufgeben. Es sei denn, sie beherrschen es vollständig, sonst ist es nur eine Last für sie

  2. Schreiben Sie Anwendungsfälle, insbesondere für alternative Kurse. Alternative Kurse belegen mehr als 50% unserer Entwicklungszeit. Normalerweise, wenn Ihr PM Ihnen eine Aufgabe zuweist, zum Beispiel, erstellen Sie ein Login-System, er wird denken, es ist einfach, Sie können 1 Tag dauern, um es zu beenden. Aber er berücksichtigt nie, dass Sie in Betracht ziehen müssen, 1. was, wenn Benutzer falsches Kennwort eingibt, 2. was, wenn Benutzer falsches Kennwort für 3mal eingibt, 3. was, wenn Benutzer Benutzername und usw. nicht eingibt Sie müssen sie auflisten und Ihrem PM zeigen, bitten Sie ihn, die Frist zu verschieben.


Die interessanteste Quelle, die ich darüber weiß, ist Teil D der Object Oriented Software Construction, 2. Auflage von Bertrand Meyer.

Teil D: Objektorientierte Methodik: Anwendung der Methode gut

19: Zur Methodik, 20: Entwurfsmuster: Mehrfeld-interaktive Systeme, 21: Vererbungsfallstudie: "Rückgängig" in einem interaktiven System, 22: Wie finde ich die Klassen , 23: Prinzipien des Klassenentwurfs, 24: Vererbung gut nutzen , 25: Nützliche Techniken, 26: Ein Sinn für Stil, 27: Objektorientierte Analyse, 28: Der Software-Konstruktionsprozess, 29: Die Methode lehren

Interessanterweise ist das Kapitel 22. Wie man die Klassen findet, ist online verfügbar.



Persönlich mag ich diesen:

"Der Designer ist damit beschäftigt, was passiert, wenn ein Benutzer eine Taste drückt, und der Architekt ist besorgt, was passiert, wenn zehntausend Benutzer eine Taste drücken."

SCEA für Java ™ EE Study Guide von Mark Cade und Humphrey Sheil





design architecture oop class-design