2

ユーザーインターフェイスの部分に基づいてソースコードを構造化したことがありますか？たとえば、UIが次のもので構成されている場合：

  1. いくつかのプロパティを表示するためのGridView
  2. 3Dレンダリングパネル
  3. アクティブなツールを選択するためのパネル

次に、変数と関数に多かれ少なかれ次のように名前を付けてグループ化します。

class Application
{
  string   PropertiesPanel_dataFile;
  DataSet  PropertiesPanel_dataSet;
  string[] PropertiesPanel_dataIdColumn;
  void     PropertiesPanel_OpenXml();
  void     PropertiesPanel_UpdateGridView();

  string   ThreeDView_modelFile;
  Panel    ThreeDView_panel;
  PointF[] ThreeDView_objectLocations;
  void     ThreeDView_RenderView();

  string   ToolPanel_configurationFile;
  Button[] ToolPanel_buttons;
  void     ToolPanel_CreateButtons();
}

これについてどう思いますか？このアーキテクチャは長期的に機能しますか？

PS。このソリューションは、Front-ahead-designエイプリルフールのジョークhttp://thedailywtf.com/Articles/FrontAhead-Design.aspxを思い出させるかもしれませんが、私の質問は深刻なものです。

編集

この種のコードを半年間維持および拡張してきました。アプリケーションはメインの.csファイルで3000行を超え、約2000行がより小さなファイル（汎用ヘルパー関数とクラスを含む）に分散されています。一般化してメインファイルから取り出す必要のあるコードの部分はたくさんあり、私は常にそれに取り組んでいますが、最終的にはそれほど重要ではありません。コードの構造と細分化は非常に単純なので、ナビゲートするのは本当に簡単です。UIに含まれる主要なコンポーネントは7つ未満であるため、デザイン全体を一度に頭に収めても問題はありません。（少し休憩した後）このコードに戻って、どこから始めればよいかすぐにわかるのはいつでも楽しいことです。

私の場合、この巨大な手続き型の構造が機能する理由の1つは、c＃でのUIプログラミングのイベント型の性質にあると思います。ほとんどの場合、このコードが行うのは、このプロジェクトに本当に固有のさまざまな種類のイベントの実装です。一部のイベント関数はすぐに数ページの長さのモンスターに成長しますが、イベントハンドラー間の結合はそれほど緊密ではないため、後でリファクタリングして圧縮するのが簡単になります。そのため、他のプロジェクトがこのプロジェクトで使用するのと同じ実装部分を必要とし始めたときに、Iamは意図的に一般化とリファクタリングを残します。

PSを使用して、VisualStudioでFindNextSelection-およびFindPrevSelection-マクロを使用している3000行のコードをナビゲートできるようにします。いくつかの変数を左クリックした後、F4を押してその変数の次のインスタンスにジャンプし、F2を押して前のインスタンスにジャンプします。変数名の一部を選択して、部分的な名前の一致間をジャンプすることもできます。これらのショートカットがなければ、私はずっと前にほとんど間違いなく道に迷いました:)

4

3 に答える 3

1

これは概念的には非常に手続き的で、OOD の価値を完全にバイパスしています。賢明なアプローチは、要素ごとにオブジェクトを作成することであり、指定した値はそれらのオブジェクトのプロパティになります。

class PropertiesPanel 
{
  public string DataFile { get; set; }
  public DataSet DataSet { get; set; }
  public string[] DataIDColumn { get; set; }
  etc...

あなたはその考えを理解していると思うので、すべてをタイプするつもりはありません。これは最初の段階であり、アプリケーションを適切に構成するためにさらに作業を行う必要があるかもしれません。

OOD に関して私がこれまでに受け取った最高のアドバイスは、アプリの各論理ブランチを抽出できる最小のオブジェクトに注目することでした。おそらく、プロパティのネイティブ型があります (.NET では、Framework オブジェクトを再発明しても意味がないため、論理分岐をカプセル化するオブジェクトが得られるまで、継承、ポリモーフィズム、およびカプセル化を使用して、これらの基本クラスを拡張します。

当時、データを I2C デバイスにプッシュするアプリを作成していたので、I2C バスにビットを配置するクラスから始めました。これは、バイトをバスに配置するクラスによって継承され、バスにデータを配置するクラスによって継承されます。バス上のバイト配列、そして最後にアドレスとバイト配列を置くクラス。これはかなり極端な OOD ですが、各クラスが非常に小さく、デバッグが非常に簡単な非常にクリーンなコードを生成しました。

問題について考える前にもっと多くの作業が必要になる可能性がありますが、長い目で見れば、非常に多くの時間を節約できます。

于 2009-06-06T08:41:43.770 に答える
0

UI パーツに基づいてユーザー インターフェイス コードを構成することは問題ありませんが、プログラムの非 UI 関連ロジックは分離しておく必要があります。

しかし、UI 部分のイベントでは、すべてを 1 つのクラスに分割するだけではいけません。代わりに、UI コードをいくつかのクラスに分割して、すべてのクラスが 1 つの UI コンポーネントのみを処理し、知る必要のない他のコンポーネントを処理しないようにする必要があります。

クラス アプリケーション
{
  プロパティパネル
  三次元ビュー
  ツールパネル
}

クラスPropertiesPanel {
  文字列データファイル;
  データセット データセット;
  文字列[] dataIdColumn;
  void OpenXml();
  void UpdateGridView();
}

クラスThreeDView {
  文字列モデルファイル;
  パネルパネル;
  PointF[] objectLocations;
  void RenderView();
}

クラスツールパネル{
  文字列構成ファイル;
  ボタン[] ボタン;
  void CreateButtons();
}
于 2009-06-06T08:42:26.937 に答える
0

これについてどう思いますか？

それは混乱です。

このアーキテクチャは長期的に機能しますか?

いいえ（少なくとも汗をかかないわけではありません。）

名前は非常に冗長です。考えてみると、長い名前の接頭辞は、関連するものをグループ化するために、一種の個別の「名前空間」を作成するためにあります。この種のもののためのより良い言語構造がすでにあります – それはクラスです。しかし、主な問題は別のところにあります。

ユーザー インターフェイスは頻繁に変更されますが、概念はめったに変更されません。コード構造がユーザー インターフェイスを反映している場合、この特定のインターフェイスに縛られています。これにより、コードの再利用とリファクタリングが非常に困難になります。問題領域の基本概念に基づいてコードを構成すると、ソフトウェアの開発時に既存のコードを再利用する可能性が高くなります。設計は変更に適応します。そして、変更は常にソフトウェアで発生します。

(「問題領域からの基本概念」の部分が明確であることを願っています。たとえば、ローカル シアターのシステムを作成する場合、映画、ビジター、シートなどの概念に基づいて設計する必要があります。 MovieList、SeatMap、TheaterPlan などの周りに構造化する代わりに。)

ほとんどの場合、GUI からコア コードを可能な限り分離することをお勧めします (これはまさに、Model–View–Controllerデザイン システムのすべてです)。インターフェイスが変更される場合に必要です。GUI をコードの残りの部分から切り離す好例は、Mac OS X での GUI プログラミングで、Interface Designer、バインディングなどを使用しています。残念ながら、理解するには時間がかかります。ウェブ上のドキュメントをざっと読んで理解することはできません。

于 2009-06-06T08:55:19.687 に答える