Wie gestalten Sie objektorientierte Projekte? [geschlossen]

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

Ich habe vor ein paar Semestern einen OOD-Kurs besucht und viel daraus gelernt. B. das Schreiben von UML und das Übersetzen von Anforderungsdokumenten in Objekte und Klassen. Wir haben auch Sequenzdiagramme gelernt, aber irgendwie habe ich die Vorlesung verpasst oder so, sie sind nicht wirklich bei mir geblieben.

Bei früheren Projekten habe ich versucht, Methoden zu verwenden, die ich aus dem Kurs gelernt habe, aber normalerweise habe ich Code, der, sobald ich sagen kann: "Ja, das sieht ungefähr so ​​aus, wie ich es mir vorgestellt habe", ich habe keine Lust, mich durch den Dreck zu graben, um etwas hinzuzufügen Neue Eigenschaften.

Ich habe eine Kopie von Steve McConnells Code Complete, von der ich immer wieder höre, dass sie hier und anderswo erstaunlich ist. Ich habe das Kapitel über Design gelesen und schien nicht die Informationen zu finden, nach denen ich suche. Ich weiß, dass er sagt, dass es kein geschnittener und getrockneter Prozess ist, sondern hauptsächlich auf Heuristiken basiert, aber ich kann nicht alle seine Informationen auf meine Projekte übertragen.

Also , was sind Dinge , die Sie während der hohen Designphase zu tun (vor der Programmierung beginnen) , um zu bestimmen , was sind die Klassen , die Sie brauchen (vor allem diejenigen , die nicht auf irgendwelchen ‚Objekte der realen Welt‘) und wie sie miteinander interagieren ?

Insbesondere interessiert mich, welche Methoden Sie verwenden? Welchem ​​Prozess folgen Sie normalerweise, um ein gutes, sauberes Design zu erhalten, das das Endprodukt genau repräsentiert?

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 berücksichtigen Sie die Anwendungsfälle, um zu definieren, welche Funktionen die Software haben soll.

2. Verfassen Sie eine Darstellung der einzelnen Anwendungsfälle.

3. Gehen Sie die Erzählung durch und markieren Sie Substantive (Person, Ort, Sache) als Kandidatenklassen und Verben (Aktionen) als Methoden / Verhaltensweisen.

4. Verwerfen Sie doppelte Substantive und berücksichtigen Sie die allgemeinen Funktionen.

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

6. Wenden Sie OOD-Prinzipien an, um Ihre Klassen zu organisieren (allgemeine Funktionen herausrechnen, Hierarchien erstellen usw.)

Hinzu kommt, was Scott Davies zu sagen hatte:

1. Stellen Sie unbedingt sicher, dass Sie wissen, worum es in Ihrem Programm geht, bevor Sie beginnen. Was ist dein Programm? Was wird es nicht tun? Welches Problem versucht es zu lösen?

2. Ihre ersten Anwendungsfälle sollten keine Wäscheliste mit allem sein, was das Programm letztendlich tun wird. Beginnen Sie mit den kleinsten Anwendungsfällen, die Sie entwickeln können und die immer noch die Essenz Ihres Programms erfassen. Bei dieser Website können die Hauptanwendungsfälle beispielsweise das Anmelden , das Stellen einer Frage , das Beantworten einer Frage sowie das Anzeigen von Fragen und Antworten sein . Nichts über Reputation, Abstimmung oder das Community-Wiki, nur die rohe Essenz dessen, wonach Sie fotografieren.

3. Denken Sie bei der Entwicklung potenzieller Klassen nicht nur daran, welches Substantiv sie repräsentieren, sondern welche Verantwortlichkeiten sie haben. Ich habe festgestellt, dass dies die größte Hilfe ist, um herauszufinden, wie Klassen während der Programmausführung miteinander in Beziehung stehen. Es ist einfach, Beziehungen wie "ein Hund ist ein Tier" oder "ein Welpe hat eine Mutter" zu finden. Es ist normalerweise schwieriger, Beziehungen zu finden, die Laufzeitinteraktionen zwischen Objekten beschreiben. Die Algorithmen Ihres Programms sind mindestens so wichtig wie Ihre Objekte, und sie sind viel einfacher zu entwerfen, wenn Sie die Aufgaben der einzelnen Klassen dargelegt haben.

4. Sobald Sie diese minimale Anzahl von Anwendungsfällen und Objekten haben, beginnen Sie mit der Codierung. Holen Sie sich etwas, das tatsächlich so schnell wie möglich läuft, obwohl es nicht viel bringt und wahrscheinlich wie Mist aussieht. Dies ist ein Ausgangspunkt und zwingt Sie, Fragen zu beantworten, die Sie möglicherweise auf Papier beschönigen.

5. Gehen Sie jetzt zurück und wählen Sie weitere Anwendungsfälle aus, schreiben Sie auf, wie sie funktionieren, ändern Sie Ihr Klassenmodell und schreiben Sie mehr Code. Nehmen Sie genau wie bei Ihrem ersten Schnitt so wenig Zeit wie möglich auf, während Sie dennoch etwas Sinnvolles hinzufügen. Spülen und wiederholen.

Nur meine zwei Cent. Hoffentlich ist es nützlich.

Wenn ich die Chance hatte, verwende ich normalerweise die sogenannte "Drei-Iterationen-Regel".

In der ersten Iteration (oder beim Start) entwerfe ich das allgemeine Layout der Anwendung anhand der Modellobjekte, der Algorithmen und der erwarteten ( wirklich erwarteten, vielleicht nichterwartete) zukünftige Richtungen. Ich schreibe keine Konstruktionsdokumente, aber wenn ich mehrere Personen koordinieren muss, ist natürlich eine grobe Skizze des Verfahrens sowie eine Analyse der Abhängigkeiten und eine Schätzung der benötigten Zeit erforderlich. Versuchen Sie, diese Phase auf ein Minimum zu beschränken, wenn Sie wie ich eine agilere Methode bevorzugen. Es gibt Fälle, in denen eine starke Entwurfsphase erforderlich ist, insbesondere wenn alles über die Logik Ihres Programms bekannt und wahr ist und wenn Sie vorhaben, viele Interaktionen zwischen Funktionen in Ihrem Code durchzuführen. In diesem Fall sind Anwendungsfälle oder User Stories eine gute Idee auf hoher Ebene, insbesondere für GUI-Apps. Versuchen Sie für Befehlszeilen-Apps und insbesondere für Bibliotheken, "Programmgeschichten" zu schreiben, in denen Sie Code für die Bibliothek erstellen, die Sie entwickeln müssen, und überprüfen Sie, wie sie aussieht.

Nach dieser ersten Iteration haben Sie ein besseres Verständnis für die Interaktion der Dinge, haben die Details und die rauen Stellen herausgefunden und Probleme mit einem geklebten Klebeband-Patch gelöst. Sie können diese Erfahrung nutzen, um zu große Teile zu verbessern, zu reinigen, zu polieren, zu teilen, zu fragmentieren, Entwurfsmuster zu definieren und zu verwenden, Leistungsengpässe und nicht triviale Sicherheitsprobleme zu analysieren. Im Allgemeinen haben all diese Änderungen enorme Auswirkungen auf die von Ihnen geschriebenen Komponententests, nicht jedoch auf die Funktionstests.

Wenn Sie diese zweite Iteration abschließen, erhalten Sie ein kleines Juwel, das gut getestet, gut dokumentiert und gut gestaltet ist. Jetzt haben Sie sowohl die Erfahrung als auch den Code, um die dritte Iteration durchzuführen. Sie werden neue Funktionen und Anwendungsfälle hinzufügen, um Ihre Anwendung zu verbessern. Sie werden raue Stellen finden und schließlich eine vierte Iteration eingeben, die der zweiten analog ist. Spülen und wiederholen.

Dies ist mein allgemeiner Ansatz für das Software-Design. Es ähnelt dem Spiraldesign mit kurzen Iterationen von drei Monaten und Elementen der agilen Entwicklung, mit denen Sie die Probleme kennenlernen und Ihre Software und ihren Anwendungsbereich kennenlernen können. Natürlich ist es eine Frage der Skalierbarkeit. Wenn die Anwendung so groß ist, dass Hunderte von Entwicklern daran beteiligt sind, sind die Dinge etwas komplexer, aber am Ende denke ich, dass die Idee immer dieselbe ist, dividiere et impera .

Also zusammenfassend:

1. In der ersten Iteration bekommen Sie einen Vorgeschmack darauf und lernen
2. In Iteration zwei bereinigen Sie Ihr Produkt und bereiten es für die Zukunft vor
3. In Iteration drei fügen Sie neue Funktionen hinzu und erfahren mehr
4. gehe zu 2

Die interessanteste Quelle, die ich dazu kenne, ist Teil D der objektorientierten Softwarekonstruktion, 2. Auflage von Bertrand Meyer.

Teil D: Objektorientierte Methodik: Anwendung der Methode gut

19: Zur Methodik, 20: Entwurfsmuster: Interaktive Systeme mit mehreren Panels, 21: Fallstudie zur Vererbung: "Rückgängig machen" in einem interaktiven System, 22: So finden Sie die Klassen , 23: Prinzipien des Klassendesigns, 24: Vererbung gut nutzen , 25: Nützliche Techniken, 26: Sinn für Stil, 27: Objektorientierte Analyse, 28: Der Software-Konstruktionsprozess, 29: Vermittlung der Methode

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

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

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

Wenn Sie ein mentales Modell haben, das das Verhalten und die Lebensdauer der Daten gut beschreibt, können Sie Ihre Klassen problemlos auslegen.

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

Versuchen Sie es mit verhaltensorientierter 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 für diese Entwurfsphase zu detailliert.

Versuchen Sie zunächst, von einer höheren Abstraktionsebene aus zu denken. Denken Sie über Hauptkomponenten und ihre Verantwortlichkeiten nach (ihre Schnittstelle zu anderen Komponenten), lassen Sie sich von einigen Architekturmustern inspirieren (nein, keine Entwurfsmuster, 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 zoomen Sie in eine bestimmte Komponente und versuchen, diese zu entwerfen. Jetzt sind wir auf der Ebene der Entwurfsmuster und Klassendiagramme. Versuchen Sie, sich auf diesen Teil des Projekts zu konzentrieren. Wenn Sie feststellen, dass Sie einer der anderen Komponenten eine Verantwortung hinzufügen müssen, fügen Sie sie einfach Ihrer Dokumentations- / Aufgabenliste hinzu. Verschwenden Sie keine Zeit damit, über die Auswirkungen nachzudenken, die sich zu diesem Zeitpunkt viel zu schnell ändern. Überprüfen Sie, wann das Design solider ist.

Zu diesem Zeitpunkt müssen Sie nicht jede Komponente vollständig entwerfen, obwohl es wahrscheinlich ratsam ist, einen Code zu haben, der die nicht implementierte Komponentenschnittstelle implementiert und einfache, aber nützliche Antworten generiert. Auf diese Weise können Sie jeweils eine Komponente entwickeln (und entwerfen) und in angemessenem Umfang testen.

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

Kurz gesagt: Nehmen Sie das OO- und Informationsversteckprinzip und ziehen Sie es auf eine andere Ebene!

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

PPS: Versuchen Sie, die Angelegenheit aus verschiedenen Blickwinkeln zu betrachten, über den Tellerrand hinaus zu denken (obwohl der Tellerrand möglicherweise der richtige Weg ist). Eine Diskussion mit Kollegen kann hierfür sehr nützlich sein ... und Sie haben beim Mittagessen etwas zu besprechen.

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

Beginnen Sie mit den User Stories der obersten Ebene und skizzieren Sie mit Kollegen an einem Whiteboard die Interaktionen auf hoher Ebene, die sie implizieren. Auf diese Weise erhalten Sie eine erste Vorstellung von den großen Modulen. und ein oder zwei Iterationen von High-Level-CRC-Karten-ähnlichen Spielen sollten Sie eine Liste der Hauptkomponenten stabilisiert haben, was sie tun und wie sie interagieren.

Wenn eine der Verantwortlichkeiten groß oder komplex ist, verfeinern Sie diese Module, bis Sie Dinge haben, die klein und einfach genug sind, um Objekte zu sein, indem Sie die Interaktionen innerhalb des Moduls für jede der Hauptoperationen spielen, die durch die Interaktionen auf höherer Ebene identifiziert werden .

Zu wissen, wann aufzuhören ist eine Frage des Urteils (was nur mit Erfahrung verbunden ist).

Designmuster

Kreative Designmuster

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

Factory (vereinfachte Version der Factory-Methode) - Erstellt Objekte, ohne die Instanziierungslogik dem Client zur Verfügung zu stellen, und verweist über eine gemeinsame Schnittstelle auf das neu erstellte Objekt.

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

Abstract 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 jedoch Unterklassen entscheiden, welche Klasse instanziiert werden soll, und ermöglicht eine genauere 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.

Verhaltensentwurfsmuster

Verantwortungskette - Es wird vermieden, den Absender einer Anfrage an den Empfänger anzuhängen, sodass andere Objekte auf diese Weise auch die Möglichkeit haben, die Anfrage zu bearbeiten. - Die Objekte werden zu Teilen einer Kette und die Anforderung wird von einem Objekt zu einem anderen über die Kette gesendet, bis eines der Objekte damit umgeht.

Befehl - Kapselung einer Anforderung in ein Objekt, Ermöglicht die Parametrisierung von Clients mit unterschiedlichen Anforderungen und Ermöglicht das Speichern der Anforderungen in einer Warteschlange.

Interpreter - Definieren Sie für eine bestimmte Sprache eine Darstellung für ihre Grammatik zusammen mit einem Interpreter, der die Darstellung verwendet, um Sätze in der Sprache zu interpretieren / eine Domäne einer Sprache zuzuordnen, die Sprache einer Grammatik und die Grammatik einem hierarchischen objektorientierten Design

Iterator - Bieten Sie eine Möglichkeit, nacheinander auf die Elemente eines Aggregatobjekts zuzugreifen, ohne dessen zugrunde liegende Darstellung verfügbar zu machen.

Mediator - Definieren Sie ein Objekt, das die Interaktion einer Reihe von Objekten zusammenfasst. Mediator fördert die lose Kopplung, indem verhindert wird, dass Objekte explizit aufeinander verweisen, und Sie können ihre Interaktion unabhängig voneinander variieren.

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

Strategie - Definieren Sie eine Familie von Algorithmen, kapseln Sie jeden einzelnen und machen Sie sie austauschbar. Mit der Strategie kann der Algorithmus unabhängig von den Clients variieren, die ihn verwenden.

Vorlagenmethode - Definieren Sie das Grundgerüst eines Algorithmus in einer Operation, indem Sie einige Schritte auf Unterklassen verschieben. Mit der Vorlagenmethode können Unterklassen bestimmte Schritte eines Algorithmus neu definieren, ohne dass sie die Struktur des Algorithmus ändern können.

Besucher - Stellt eine Operation dar, die für die Elemente einer Objektstruktur ausgeführt werden soll. Mit Besucher können Sie eine neue Operation definieren, ohne die Klassen der Elemente zu ändern, für die sie ausgeführt wird.

Null-Objekt - Geben Sie ein Objekt als Ersatz für das Fehlen eines Objekts eines bestimmten Typs an. / Das Null-Objektmuster bietet intelligentes Verhalten, bei dem nichts getan wird, und verbirgt die Details vor seinen Mitarbeitern.

Strukturelle Entwurfsmuster

Adapter - Konvertieren Sie die Schnittstelle einer Klasse in eine andere Schnittstelle, die Clients erwarten. Mit / Adapter können Klassen zusammenarbeiten, was aufgrund inkompatibler Schnittstellen nicht möglich wäre.

Brücke - Verfassen Sie Objekte zu Baumstrukturen, um Teil-Ganz-Hierarchien darzustellen. Mit / Composite können Clients einzelne Objekte und Objektzusammensetzungen einheitlich behandeln.

Zusammengesetzt - Verfassen Sie Objekte zu Baumstrukturen, um Teil-Ganz-Hierarchien darzustellen. Mit / Composite können Clients einzelne Objekte und Objektzusammensetzungen einheitlich behandeln.

Dekorateur - Fügen Sie einem Objekt dynamisch zusätzliche Verantwortlichkeiten hinzu.

Fliegengewicht - Verwenden Sie die Freigabe, um eine große Anzahl von Objekten zu unterstützen, die einen Teil ihres internen Zustands gemeinsam haben, wobei der andere Teil des Zustands variieren kann.

Memento - Erfassen Sie den internen Zustand eines Objekts, ohne die Kapselung zu verletzen, und bieten Sie so ein Mittel, um das Objekt bei Bedarf in den Ausgangszustand zurückzusetzen.

Proxy - Geben Sie einen Platzhalter für ein Objekt an, um Verweise darauf zu steuern.

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

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 kleinerer Software geeignet ist.

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

Alternativtext http://www.ryanknu.com/ryan/bluej.png

ActiveWriter ist ein Tool zum Modellieren von Entitäten und Beziehungen, generiert außerdem Code und lässt sich leicht ändern. Das spart Ihnen Zeit und ist für eine agile Entwicklung sehr gut geeignet.

_{(Quelle: altinoren.com )}

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

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

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

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

Und das Herzstück von RUP ist ein kleiner Bereich, in dem Sie OO-Designtalente einsetzen müssen. Wenn Sie diese nicht haben, ist es wie eine Methode, um die 100 m zu laufen.

"Schritt 1: Schreiben Sie über das schnelle Laufen. Schritt 2: Zeichnen Sie einen Plan für die Rennstrecke. Schritt 3: Kaufen Sie wirklich enge Lycra-Shorts. Schritt 4: Laufen Sie sehr, sehr, sehr schnell. Schritt 5: Überqueren Sie zuerst die Linie ""

Es ist dieser Schritt 4, der die schwierige Frage ist. Aber wenn Sie viel Wert auf 1,2,3 und 5 legen, wird es möglicherweise niemand bemerken, und dann könnten Sie wahrscheinlich viel Geld verdienen, wenn Sie die Methode an Athleten verkaufen, die glauben, dass es ein "Geheimnis" gibt, 100 m zu sein Läufer vorbei

Sie haben eine Frage gestellt, mit der 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 empfehlen . Überprüfen Sie auch die Website dddcommunity.org .

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

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

Ja, wenn Sie mehr als 5 Jahre in der realen Welt gearbeitet haben, würden Sie zwischen einem der vielen Modelle oder Techniken für Softwareentwicklungsprozesse wählen.

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

Wenn das nicht möglich ist, sollten Sie es einfach selbst tun. Beginnen Sie mit der Iteration, indem Sie einen wahrscheinlich sehr bösen Code codieren, Ihre Fehler lernen, alles ablegen, einen besseren codieren und so weiter.

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

Wenn Sie über Domain-Know-how für das Projekt verfügen, werden Sie beispielsweise an Banking arbeiten. Es ist einfach, Ihre Objekte zu strukturieren, und Sie wissen, wie diese Verbesserungen jeden zweiten Tag erfolgen.

Wenn Sie nicht über dieses Fachwissen verfügen, arbeiten Sie mit jemandem zusammen, der über dieses Fachwissen verfügt, und wandeln Sie diese Ideen in technische Details um.

Wenn Sie sich nicht sicher sind, wie Sie Ihr Projektdesign strukturieren sollen. BLIND folgen Sie dem Buch "Pragmatischer Programmierer". Ich war vorher in der gleichen Situation, versuche ein Kapitel aus diesem Buch zu lesen. Sie werden den Unterschied sehen. Es wird Ihre Denkweise als Softwareentwickler verändern.

1. Design & Master Design Patterns.
2. Erfahren Sie als Nächstes mehr über das domänengesteuerte Design
3. Lernen Sie danach das Sammeln von Anforderungen

Ich habe vor ein paar Semestern einen OOD-Kurs besucht und viel daraus gelernt. B. das Schreiben von UML und das Übersetzen von Anforderungsdokumenten in Objekte und Klassen. Wir haben auch Sequenzdiagramme gelernt, aber irgendwie habe ich die Vorlesung verpasst oder so, sie sind nicht wirklich bei mir geblieben.

4. Sie kennen den Schritt 3. Sie müssen ihn beherrschen. Ich meine, durch viel Übung, um es zu deiner zweiten Natur zu machen. Das liegt daran, dass die Methode, die Sie lernen, einfach gegen die Art und Weise ist, wie wir sie früher hatten. Sie müssen es also wirklich beherrschen. Andernfalls werden Sie immer wieder zu Ihrer ursprünglichen Vorgehensweise zurückkehren. Dies ist irgendwie wie bei 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 Belastung für sie

5. Schreiben Sie Anwendungsfälle, insbesondere für alternative Kurse. Alternativer Kurs nimmt mehr als 50% unserer Entwicklungszeit ein. Wenn Ihr PM Ihnen eine Aufgabe zuweist, z. B. ein Anmeldesystem erstellt, wird er normalerweise denken, dass dies unkompliziert ist. Sie können sich 1 Tag Zeit nehmen, um diese Aufgabe abzuschließen. Er berücksichtigt jedoch niemals, dass Sie Folgendes berücksichtigen müssen: 1. Was passiert, wenn der Benutzer ein falsches Kennwort eingibt? 2. Was passiert, wenn der Benutzer dreimal ein falsches Kennwort eingibt? 3. Was passiert, wenn der Benutzer keinen Benutzernamen eingibt? Usw. Sie müssen sie auflisten und Ihrem PM zeigen. Bitten Sie ihn, die Frist zu verschieben.

Ich befürchte, dass dies keine Antwort ist, die die Leute gerne hören . Wie auch immer, lassen Sie mich meine Meinung sagen.

OOP sollte als eines der Paradigmen angesehen werden, nicht als das überlegene Paradigma. OOP eignet sich gut zum Lösen bestimmter Probleme, z. B. zum Entwickeln einer GUI-Bibliothek. Es passt auch in den Stil der Softwareentwicklung, dem normalerweise große Softwareunternehmen folgen - ein Elite-Team von Designern oder Architekten legt das Software-Design in UML-Diagrammen oder einem ähnlichen Medium fest und ein weniger aufgeklärtes EntwicklerteamÜbersetzen Sie dieses Design in Quellcode. OOP bietet wenig Nutzen, wenn Sie alleine oder mit einem kleinen Team hochtalentierter Programmierer arbeiten. Dann ist es besser, eine Sprache zu verwenden, die mehrere Paradigmen unterstützt und Ihnen hilft, schnell einen Prototyp zu entwickeln. Python, Ruby, Lisp / Scheme usw. sind eine gute Wahl. Der Prototyp ist Ihr Design. Dann verbessern Sie das. Verwenden Sie das Paradigma, das am besten zur Lösung des vorliegenden Problems geeignet ist. Optimieren Sie bei Bedarf Hotspots mit Erweiterungen, die in C oder einer anderen Systemsprache geschrieben sind. Wenn Sie eine dieser Sprachen verwenden, erhalten Sie auch Erweiterbarkeitkostenlos, nicht nur auf Programmiererebene, sondern auch auf Benutzerebene. Sprachen wie Lisp können dynamisch Code generieren und ausführen, was bedeutet, dass Ihre Benutzer die Anwendung durch Schreiben kleiner Codefragmente in der Sprache erweitern können, in der die Software selbst codiert ist! Wenn Sie das Programm in C oder C ++ schreiben möchten, sollten Sie einen Interpreter für eine kleine Sprache wie Lua einbetten. Stellen Sie Funktionen als Plugins bereit, die in dieser Sprache geschrieben sind.

Ich denke, dass OOP und OOD die meiste Zeit Software erstellen, die Opfer von Überdesign sind.

Zusammenfassend ist meine bevorzugte Art, Software zu schreiben ,:

1. Verwenden Sie eine dynamische Sprache.
2. Schreiben Sie das Design (Prototyp) in dieser Sprache.
3. Optimieren Sie bei Bedarf bestimmte Bereiche mit C / C ++.
4. Stellen Sie die Erweiterbarkeit über den Interpreter der Implementierungssprache selbst bereit.

Mit der letzten Funktion kann sich die Software problemlos an bestimmte Benutzeranforderungen (einschließlich meiner selbst!) Anpassen.

Ich verwende Test-Driven Design (TDD). Wenn Sie den Test zuerst schreiben, erhalten Sie ein sauberes und korrektes Design. Siehe http://en.wikipedia.org/wiki/Test-driven_development .

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 Ihnen dieses empfehlen:

Head First Design Patterns

Es ist in Java, kann aber auf jede Sprache erweitert werden.

Ehrlich gesagt wäre ein guter Schritt, zurück zu gehen und sich Flussdiagramme und Sequenzdiagramme anzuschauen. Es gibt eine Menge guter Websites, die Ihnen zeigen, wie es geht. Ich finde es von unschätzbarem Wert, wenn ich mir anschaue, wie ich ein Programm in Klassen aufteilen möchte, da ich genau weiß, was das Programm eingeben, berechnen und ausgeben muss und jeder Schritt in einen Teil des Programms unterteilt werden kann.

Wie unter Was ist der Workflow, dem Sie folgen, um die Software zu entwerfen, die Sie schreiben möchten?

Eine nützliche Technik besteht darin, Ihre eindeutige Problembeschreibung mit etwas in Beziehung zu setzen, das Sie in der realen Welt finden können. Sie modellieren beispielsweise ein komplexes Gesundheitssystem, das die Welt im Sturm erobern wird. Gibt es Beispiele, auf die Sie sich gerne berufen können, um dies zu modellieren?

Tatsächlich. Beobachten Sie, wie die Seitenapotheke oder das Zimmer des Arztes funktionieren würde.

Bringen Sie Ihr Domain-Problem auf etwas, das für Sie verständlich ist. etwas, auf das Sie sich beziehen können.

Sobald die "Spieler" innerhalb der Domain offensichtlich erscheinen und Sie mit der Modellierung Ihres Codes beginnen, entscheiden Sie sich für einen Modellierungsansatz "Anbieter-Verbraucher", dh Ihr Code ist der "Anbieter" des Modells und Sie sind der "Verbraucher" ".

Das Beziehen auf die Domäne und das Verstehen auf hoher Ebene ist ein wesentlicher Bestandteil jedes Designs.

Während meiner Abenteuer beim Entwerfen von Klassenstrukturen habe ich festgestellt, dass es sehr hilfreich ist, mit dem Schreiben von Pseudocode zu beginnen. Das heißt: Ich beginne damit, einige allgemeine Fragmente des Anwendungscodes auf höchster Ebene zu „schreiben“, spiele damit und entdecke die Elemente, die erscheinen - tatsächlich die Elemente, die ich als Programmierer verwenden möchte. Dies ist ein sehr guter Ausgangspunkt für die Gestaltung der allgemeinen Struktur von Modulen und ihrer Interaktionen. Nach wenigen Iterationen sieht die gesamte Struktur eher wie ein vollständiges Klassensystem aus. Es ist eine sehr flexible Möglichkeit, Teile des Codes zu entwerfen. Sie können es ein programmiererorientiertes Design nennen.