最初にGUIクラスを書き始めますか、それとも逆ですか？

最初のJavaプログラム（電話帳など）を書きたいのですが、最初に何をしたらいいのでしょうか。私の質問は、最初にGUIクラスを作成するか、最初にutilクラスを作成するべきですか？私はデータベース開発者であり、プログラム構築のベストプラクティスを知りたいです。

理論的には、少なくとも5つの可能なアプローチがあります。

トップダウン：

UIモックショットまたは紙のプロトタイプから始めます。それらを実際のダイアログに変換し、ボタンハンドラーやその他のコントロールからロジックを経由してデータベースに至るまで、さまざまな方法で作業できます。

一気飲み：

データ構造（おそらくデータベーススキーマ）から始めます。次にロジックを追加します（実際のプロセスをモデル化します）。最後に、UIはロジックをトリガーして結果を表示するための単なるインターフェースです。

最初のロジック：

プログラムロジックから始め、必要に応じてデータアクセスと基本的なUIを実装します。次に、データ構造を形式化して強化し、最後にUIを適切に具体化します。

真ん中に会う：

データベーススキーマとUIから始め、同時にそれらが出会うポイントに向かって作業します。このアプローチでは、ロジックが最後になります。

水平拡張：

何か面白いことをする機能の絶対最小量を特定することから始め、この部分のスタック全体（データ構造、ロジック、UI）を実装します。これは、1つのエンティティーに対する単純な編集ダイアログを備えた基本的なCRUDサイクルにすぎません。次に、機能を追加して、各機能のスタック全体を実装します（したがって、「水平」）。

これらにはそれぞれ長所と短所があります。

トップダウンを使用すると、プロセスの早い段階で何かが表示され、機能設計を関係者と確認できます。モックショットは、フローチャートやテキストの壁よりもデザインについてユーザーに多くのことを伝えます。

ボトムアップでは、何かをコミットする前に、堅固なデータベーススキーマを設計する機会が与えられます。データベーススキーマはリリース後は変更が難しいことで悪名高いため、この部分を正しく理解する必要があります。UIの変更による影響ははるかに小さく、バグの発生は少なくなります。

ロジックファーストとは、データベースとプレゼンテーションに真剣に時間をかける前にロジックをテストできることを意味します。これは、ロジックが本当に複雑になる場合に特に興味深いものです。

ミドルインミドルはボトムアップとトップダウンの利点を組み合わせたものですが、2つのタスク間を行き来する必要があり、2つの目的のため、必要以上に複雑なロジックになってしまうリスクがあります。自然に会わないでください。

水平展開は、反復ワークフローにうまく適合します。優先順位を付ければ、いつでもアプリケーションが機能し、期限を守らないと、完全なデータベースはあるがUIがまったくないバージョンとは対照的に、機能は少なくなりますが、完全に機能します。

どちらを選択するかは、個人のスタイルや状況によって異なります。

データベース開発者であれば、データモデルから始めて、適切な抽象化レイヤーを作成して、ユーザーインターフェイス（GUIかどうかに関係なく）を簡単に定義できるようにする必要があると思います。

個人的には、ユーザーの懸念を分析してそこから行きます。理想的には、最も多くの作業を必要とするアプリケーションの側面を最初に開始する必要があります。

このシナリオでは、主な焦点としてUIモックに焦点を当てます。顧客は、さまざまなエンドユーザーグループ、特に視覚障害のあるエンドユーザーグループをサポートし、システムを文化の境界を越えて配布することに懸念を表明しています。したがって、機能的で安定したシステムを持つことは重要ですが、ユーザーが作業を簡単に実行できるようにするインターフェイスを持つことの重要性が優先されます。

このシナリオでは、ドメインロジックに焦点を当てます。顧客が複雑なビジネス対話を備えたシステムを要求しました。複雑なデータ構造を大量に保存します。したがって、データソースストレージを使用してビジネスロジックを検出および実装する最初の作業は、プロジェクトの成功につながります。

システムが個人的なプロジェクトである場合は、プロジェクトから学びたいことに焦点を当てます。新しいテクノロジーを試す場合は、小さなスパイクに焦点を当て、テクノロジー自体を分離して、それがどのように機能するかをよりよく理解できるようにします。ただし、すべての段階を経た個人的なプロジェクトには、「実際の」プロジェクトに備える準備が整うという利点があります。その場合、いくつかの主要な目標を概説し、それらを足がかりとして使用します。この電話帳アプリがあなたの個人的なプロジェクトである場合、最初にUIを使用することをお勧めします。データベース開発者として、私はあなたがデータベースをドメインロジックに接続する方法、および大まかにドメインロジックを書く方法を知っていると想定していますが、UIテクノロジについてはあまり詳しくありません。したがって、UIでの作業は、データソースやドメインロジックから開始するよりも学習に役立つはずです。

プロジェクトの最も興味深い部分から始めます。気に入らない部分から始めると、次の段階に進む前に辞めるかもしれません。どこから始めるかは基本的に好みの問題なので、最もやりたいことを選択することもできます。

ドメインまたは「ユーティリティクラス」と呼ぶものから始めます。UI実装とは別にテストします。そうすれば、最終的に使用する予定のUIフレームワーク、MVCなどに関係なく、アプリケーションがどのように動作する（または動作する必要がある）か、ロジックがどのように機能するか、ツール、スタイルをよりよく理解できます。

自分を特定のUI実装にバインドすることは、通常、悪い考えです。前もって考えてはいけないと言っているのではありません。私はあなたのアプリケーションがそれに依存すべきではないと言っています。UIはプロジェクトの過程でA LOTを変更する傾向があり、ドメインがそれに関連付けられている場合は、ドメインも大幅に変更されます。

ほとんどの人は、自分のスタイルに合った別の方法で開発することになります。たとえば、基盤となるアーキテクチャとデータストレージを定義していれば、GUIを設計する方が簡単な場合があります。ただし、別の人は、GUIをいじって初期ドラフトを取得すると、ストレージシステムをより適切に整理し、プログラムをより整理された方法でコーディングできることに気付く場合があります。あなたの前のタスクは、どの方法（またはおそらく2つのハイブリッド）が最適かを見つけることです。私にとって、私はGUIがどのように見えるかを最初にモックアップしてから、アプリケーションの基本的な作業を開始することを好みます。それが終わったら、通常、戻って必要に応じてGUIに変更を加えます。

これはかなり簡単なプロジェクトで、それほど重要ではないと私は言います。ただし、多くのプロジェクトでは、GUIの外観と操作方法がすぐに明確になるわけではありません。作成すると、誰かに変更を求められる場合があります。GUIの簡単なモックアップを作成して、担当者または担当者がそれがどのように見えるかを具体的に決定できるようにすると、追跡するために必要なデータの一部を確認するのに役立ちます。データ設計を始めたのに気付かなかったかもしれません。

さらに重要なことは、データ設計でユーザーインターフェイスを操作したくないということです。相対的に言えば、貧弱なGUI実装を修正する方が、貧弱なデータ実装を修正するよりもはるかに簡単だと思います。だから私は間違いなくGUIから始めることに投票します。

そして、私は自分自身がデータベースの人です。