Beginnen Sie zuerst oder umgekehrt mit dem Schreiben der GUI-Klasse?

Ich möchte mein erstes Java-Programm schreiben, zum Beispiel Phonebook, und ich frage mich, was ich zuerst tun soll. Meine Frage ist, ob ich zuerst GUI-Klassen schreiben oder zuerst Util-Klassen verwenden soll. Ich bin Datenbankentwickler und möchte die besten Praktiken beim Erstellen von Programmen kennen.

Theoretisch gibt es mindestens fünf mögliche Ansätze.

Von oben nach unten:

Beginnen Sie mit UI-Mock-Shots oder einem Papierprototyp. Verwandeln Sie sie in echte Dialoge und arbeiten Sie sich von den Schaltflächenhandlern und anderen Steuerelementen über die Logik bis zur Datenbank vor.

Prost:

Beginnen Sie mit den Datenstrukturen (wahrscheinlich dem Datenbankschema). Fügen Sie dann Logik hinzu (Modellierung realer Prozesse). Schließlich ist Ihre Benutzeroberfläche nur eine Schnittstelle, um die Logik auszulösen und die Ergebnisse anzuzeigen.

Logik zuerst:

Beginnen Sie mit der Programmlogik und implementieren Sie nach Bedarf den Datenzugriff und eine rudimentäre Benutzeroberfläche. Formalisieren und härten Sie dann die Datenstrukturen und verfeinern Sie die Benutzeroberfläche ordnungsgemäß.

In der Mitte treffen:

Beginnen Sie mit dem Datenbankschema und der Benutzeroberfläche und arbeiten Sie gleichzeitig an dem Punkt, an dem sie sich treffen. Bei diesem Ansatz kommt die Logik an letzter Stelle.

Horizontale Ausdehnung:

Beginnen Sie mit der Ermittlung des absoluten Mindestmaßes an Funktionalität, das etwas Interessantes bewirken würde, und implementieren Sie den gesamten Stapel (Datenstrukturen, Logik und Benutzeroberfläche) für diesen Teil. Es könnte sich nur um einen einfachen CRUD-Zyklus mit einem einfachen Bearbeitungsdialog für nur eine Entität handeln. Fügen Sie dann weitere Features hinzu und implementieren Sie den gesamten Stapel für jedes Feature (daher 'horizontal').

Jedes davon hat Vor- und Nachteile.

Mit Top-Down können Sie zu Beginn des Prozesses etwas Sichtbares erkennen und Ihr funktionales Design mit den Stakeholdern überprüfen. Mock-Shots erzählen Benutzern häufig mehr über ein Design als Flussdiagramme oder Textwände.

Mit Bottom-up können Sie ein solides Datenbankschema entwerfen, bevor Sie sich zu etwas verpflichten. Da ein Datenbankschema nach seiner Veröffentlichung notorisch schwer zu ändern ist, möchten Sie diesen Teil richtig machen - die Auswirkungen der Änderung einer Benutzeroberfläche sind viel geringer und führen zu immer weniger schwerwiegenden Fehlern.

Logic-first bedeutet, dass Sie die Logik testen können, bevor Sie sich ernsthaft mit der Datenbank und der Präsentation befassen. Dies ist besonders interessant, wenn Ihre Logik wirklich komplex sein soll.

Meet-in-the-Middle kombiniert die Vorteile von Bottom-Up und Top-Down, aber Sie müssen zwischen zwei Aufgaben hin und her springen, und Sie riskieren eine Logik, die komplexer als nötig ist, weil Ihre beiden Enden treffe dich nicht natürlich.

Die horizontale Erweiterung passt gut zu einem iterativen Workflow und hat den zusätzlichen Vorteil, dass Sie bei einer guten Priorisierung zu jedem Zeitpunkt eine funktionierende Anwendung haben. Wenn Sie also keine Frist festlegen, haben Sie eine Version mit dieser weniger Funktionen, aber immer noch voll funktionsfähig, im Gegensatz zu einer Version mit einer vollständigen Datenbank, aber überhaupt keiner Benutzeroberfläche.

Welches Sie wählen, hängt von Ihrem persönlichen Stil und den Umständen ab.

Wenn Sie ein Datenbankentwickler sind, sollten Sie mit einem Datenmodell beginnen und eine gute Abstraktionsschicht erstellen, damit Sie Ihre Benutzeroberfläche einfach definieren können (ob GUI oder nicht).

Persönlich würde ich die Bedenken der Benutzer analysieren und von dort aus fortfahren. Idealerweise sollte zuerst der Aspekt der Anwendung beginnen, der den größten Arbeitsaufwand erfordert.

In diesem Szenario würde ich mich auf UI-Mocks als primären Fokus konzentrieren. Der Kunde hat Bedenken geäußert, eine vielfältige Endbenutzergruppe, insbesondere solche mit visuellen Behinderungen, zu unterstützen und das System über kulturelle Grenzen hinweg zu verteilen. Während ein funktionsfähiges und stabiles System von entscheidender Bedeutung ist, hat die Bedeutung einer Schnittstelle, über die Benutzer ihre Arbeit problemlos ausführen können, Vorrang.

In diesem Szenario würde ich mich auf die Domänenlogik konzentrieren. Der Kunde hat ein System mit komplexen Geschäftsinteraktionen angefordert. Es werden große Mengen komplexer Datenstrukturen gespeichert. Erste Arbeiten zur Ermittlung und Implementierung der Geschäftslogik mit Datenquellenspeicher führen daher zu einem erfolgreichen Projekt.

Wenn das System ein persönliches Projekt ist, konzentrieren Sie sich auf das, was Sie aus dem Projekt lernen möchten. Wenn ich eine neue Technologie ausprobiere, versuche ich, mich auf eine kleine Spitze zu konzentrieren und die Technologie selbst zu isolieren, damit ich besser verstehen kann, wie sie funktioniert. Ein persönliches Projekt, das alle Phasen durchläuft, hat jedoch den Vorteil, dass Sie besser auf "echte" Projekte vorbereitet werden. In diesem Fall würde ich einige wichtige Ziele skizzieren und diese als Sprungbrett verwenden. Wenn diese Telefonbuch-App ein persönliches Projekt von Ihnen ist, würde ich empfehlen, zuerst die Benutzeroberfläche zu bearbeiten. Als Datenbankentwickler gehe ich davon aus, dass Sie wissen, wie man Datenbanken mit Domänenlogik verbindet und ungefähr wie man Domänenlogik schreibt, aber die UI-Technologien nicht so genau erforscht haben. Daher sollte die Arbeit an der Benutzeroberfläche Ihrem Lernen mehr nützen als von der Datenquelle oder Domänenlogik auszugehen.

Beginnen Sie mit dem Teil des Projekts, den Sie am interessantesten finden. Wenn Sie mit dem Teil beginnen, den Sie nicht mögen, können Sie ihn beenden, bevor Sie Fortschritte machen. Wo Sie anfangen, ist meistens eine Frage der Präferenz. Sie können also genauso gut auswählen, woran Sie am meisten arbeiten möchten.

Beginnen Sie mit der Domain oder dem, was Sie "util classes" nennen. Testen Sie es unabhängig von Ihrer UI-Implementierung. Auf diese Weise erhalten Sie ein besseres Verständnis dafür, wie sich Ihre Anwendung verhält (oder verhalten sollte), wie sich die Logik auswirkt, unabhängig davon, welches UI-Framework, MVC oder so weiter, Tools und Stile, die Sie am Ende verwenden möchten.

Es ist normalerweise eine schlechte Idee, sich an eine bestimmte UI-Implementierung zu binden. Ich sage nicht, dass Sie es nicht im Voraus betrachten sollten. Ich sage, dass Ihre Anwendung nicht davon abhängig sein sollte. Die Benutzeroberfläche ändert sich im Laufe eines Projekts in der Regel VIEL. Wenn Ihre Domain daran gebunden ist, ändern Sie auch Ihre Domain erheblich.

Fast jeder wird eine andere Entwicklungsmethode haben, die seinem Stil entspricht. Beispielsweise kann eine Person feststellen, dass es einfacher ist, ihre GUI zu entwerfen, wenn sie die zugrunde liegende Architektur und Datenspeicherung definiert hat. Eine andere Person kann jedoch feststellen, dass das Herumspielen mit der GUI und das Erhalten eines ersten Entwurfs ihnen helfen kann, ihr Speichersystem besser zu organisieren und ihr Programm besser zu codieren. Die Aufgabe vor Ihnen wird sein, herauszufinden, welche Methode (oder vielleicht eine Mischung aus beiden) für Sie am besten geeignet ist. Für mich ziehe ich es vor, ein erstes Modell dessen zu erstellen, wie die GUI meiner Meinung nach aussehen wird, und dann mit der Arbeit an den Schrauben und Muttern der Anwendung zu beginnen. Sobald ich das getan habe, komme ich normalerweise zurück und nehme nach Bedarf Änderungen an der GUI vor.

Dies ist ein ziemlich einfaches Projekt, bei dem ich sagen würde, dass es nicht so wichtig ist. Bei vielen Projekten wird jedoch nicht sofort klar sein, wie die GUI aussehen und funktionieren soll, und wenn Sie sie erstellt haben, werden Sie möglicherweise von jemandem gebeten, sie zu ändern. Es ist gut, schnelle Modelle der Benutzeroberfläche zu erstellen, damit Sie oder der Verantwortliche eine konkrete Entscheidung darüber treffen können, wie sie aussehen soll. Auf diese Weise können Sie einige der korrelativen Daten sehen, die Sie benötigen, um dies zu verfolgen Sie hätten es vielleicht nicht bemerkt, wenn Sie mit dem Datenentwurf begonnen hätten.

Noch wichtiger ist, dass Ihr Datendesign Ihre Benutzeroberfläche NICHT steuern soll. Relativ gesehen glaube ich, dass das Beheben schlechter GUI-Implementierungen weitaus einfacher ist als das Beheben schlechter Datenimplementierungen. Also stimme ich definitiv dafür, mit der GUI zu beginnen.

Und ich bin selbst eher ein Datenbank-Typ, nur zu Ihrer Information.