プログラムコードとグラフィカルインターフェイスコードを異なるクラスにパッケージ化することがベストプラクティスと見なされるのはなぜですか？

だから私の先生は、プログラムコードとグラフィカルインターフェースコードを同じクラスにカプセル化しないことが非常に重要であるが、それらを完全に独立した状態に保つことが非常に重要だと教えてくれます。私は現在、グリッドを使ってiPhoneゲームを書いています。私にとっては、同じ「グリッド」クラスでグラフィカルグリッドと技術コードの両方を作成する方がはるかに理にかなっています。他のプログラマはこれに眉をひそめますか？グラフィカルインターフェイスとコードを独立させることは本当に非常に重要ですか？そうしないとどのような問題が発生しますか？

ありがとうございました！

編集：みんなありがとう！最初にプロジェクトを作成し、次にコードをコピーして懸念事項の分離設計を作成してもかまいませんか？私はこれが目的を完全に打ち負かすかもしれないことを知っていますが、練習として...だから、次回からこのデザインパターンを最初から適用できますか？

先生が言及している概念は、懸念の分離と呼ばれるものです。

コンテキストで説明するために、プログラムを完成させてからAndroidに移植する場合は、グリッドロジックを分離しておく場合よりも多くのコードを書き直す必要があります。

インターフェースコントロールは、指示された内容の描画のみを対象とし、グリッドロジックは、グリッドの描画方法ではなく、グリッド内の内容のみを対象とします。

これは役立ちますか？

コードの変更を簡単にするため。明日、グリッドではなくリストを使用したい場合はどうなりますか？GUIをロジックから分離すると、簡単に実行できます。

それに加えて、より再利用可能なコードを記述します。GUIに技術コードが含まれていない場合は、再利用することもできます。すべてのオプションを備えた派手なグリッドを一度作成すると、他のプロジェクトで使用できます。GUIと技術コードを混在させると、これができなくなります。

また、読みやすいコードを提供します。グリッドがGUI機能のみを実行している場合、コードを理解または変更する方が簡単です。

関心の分離に対するオブジェクト指向プログラミングの一般的なアプローチ。コードは論理的なタスクに分離されます。最初は、これはより多くの作業のように見えるかもしれません。しかし、プロジェクトが成長するにつれて、コードの追跡と管理が容易になります。

そのため、グリッドの表示を担当するコードと、そのグリッドに表示される可能性のあるデータを処理するコードを分離する方がよいでしょう。

懸念の分離がアプリケーション構造に適用されると、結果は多層アーキテクチャ（またはN層アーキテクチャ）http://en.wikipedia.org/wiki/Multitier_architectureになります。

他の回答に基づいて例を挙げるには、ロジック/データをグリッドに挿入するか、またはその逆を許可する必要があります。

グリッドコントロールは、Renderメソッドまたはメソッドを公開できますDataBind。

class GridControl
{
    public Render(GridData data) { ... }
}

または

class GridControl
{
    public DataBind(GridData data) { ... }
}

論理ユニットは、GridControlを取得してデータオブジェクトをバインドするか、変更が発生するたびにデータオブジェクトを使用して手動でrenderを呼び出すことができます。

GridLogicは、GridControlへの参照も持っている必要があります。これにより、発生するすべての入力/イベントにバインドできます。

データバインディングの背後にある考え方は、グリッドコントロールがデータの変更を監視してそれ自体を再レンダリングするというものです。

どちらの方法でも、ロジックとグリッドをこのように分割すると、何も壊さずに、簡単に他の1つを変更できます。また、aのような新しいコントロールをListControl作成して、すべてのロジックを書き直すことなく、グリッドではなくリストとしてデータを表示することもできます。

MVCアーキテクチャをご覧になることを強くお勧めします。

これは、あなたが言及した概念の改良版です（プログラムコードとグラフィックインターフェイスの分離）。MVCはModel-View-Controllerの略です。ここで、モデルはデータ、ビューはグラフィックインターフェイスコード、COntrollerはデータを処理するコードです。

このようにして、プログラムの3つの部分を作成しました。他の2つの部分を変更せずに、各部分を交換できます。

それは、発生が予想される将来の変更の種類によって異なります。最小限に抑えたいのは、各機能変更を正しく実装するために必要な手動コード変更の数です。

MVCが勝つのは、変更がV部分または「表示」に限定されている場合です。

私の経験では、変更は3つの部分すべてに影響する可能性が非常に高いので、それらが分離されていない方が良いです。私が意味することを示すために、私は長い間、Dynamic Dialogsと呼ばれる開発した手法を使用しました。この手法では、「テキスト：

if(deTextEdit(&sName)){
  // do XYZ
}

複数の個別の編集の代わりに、編集フィールドが存在することを指定し、その一意の識別子を作成し、モデル変数にバインドし、lost-focusイベントハンドラーにリンクします。

そのリンクにアクセスすると、より複雑な例が表示されます。

基本的には、目的を達成するために編集の回数を最小限に抑えるために、コードをドメイン固有の言語に変えるという考え方です。これを行う理由は、労力を削減するだけでなく、1つまたは複数の編集内容を忘れたり、誤ってコーディングしたりして、バグを導入する機会を減らすためです。また、ソースコードのサイズを約1桁削減します。

無料ではありません。プログラマーに1回限りの学習曲線を導入します。

グラフィカルインターフェイスはシステムに依存しますが、ゲームコアは実行するシステムから完全に独立したアルゴリズムです。1つのサブシステムの変更が他のサブシステムの動作に影響を与えないため、2つのアプリケーションを保持すると、プログラムの保守、テスト、デバッグが容易になります。移植性に関心がなくても、プログラムの堅牢性と保守性に関心があるに違いありません。