ユーザーインターフェイスからクラスを分離する

ユーザーインターフェイスについて知る必要があるかもしれないクラスを作成する場合のベストプラクティスは何ですか。自分自身を描画する方法を知っているクラスは、ユーザーインターフェイス（コンソール、GUIなど）に依存するため、いくつかのベストプラクティスを破らないでしょうか。

多くのプログラミングの本で、継承を示す「形状」の例を見つけました。基本クラスのシェイプには、円や正方形などの各シェイプがオーバーライドするdraw（）メソッドがあります。これにより、ポリモーフィズムが可能になります。しかし、draw（）メソッドは、ユーザーインターフェースに大きく依存していませんか？たとえば、Win Forms用にこのクラスを記述した場合、コンソールアプリまたはWebアプリに再利用することはできません。これは正しいです？

質問の理由は、クラスが最も役立つようにクラスを一般化する方法に常に固執し、ハングアップしていることに気付くからです。これは実際に私に対して働いており、私は「一生懸命やっている」のだろうかと思っています。

ユーザーインターフェイスについて知る必要があるかもしれないクラスを作成する場合のベストプラクティスは何ですか。自分自身を描画する方法を知っているクラスは、ユーザーインターフェイス（コンソール、GUIなど）に依存するため、いくつかのベストプラクティスを破らないでしょうか。

それはクラスとユースケースに依存します。自分自身を描く方法を知っている視覚要素は、必ずしも単一の責任原則に違反しているわけではありません。

多くのプログラミングの本で、継承を示す「形状」の例を見つけました。基本クラスのシェイプには、円や正方形などの各シェイプがオーバーライドするdraw（）メソッドがあります。これにより、ポリモーフィズムが可能になります。しかし、draw（）メソッドは、ユーザーインターフェースに大きく依存していませんか？

繰り返しますが、必ずしもそうではありません。インターフェイス（drawPoint、drawLine、set Colorなど）を作成できる場合は、図形に何かを描画するためのコンテキスト（図形のコンストラクター内など）をほとんど渡すことができます。これにより、コンソールまたは指定されたキャンバスに図形を描画できます。

たとえば、Win Forms用にこのクラスを記述した場合、コンソールアプリまたはWebアプリに再利用することはできません。これは正しいです？

まあ、それは本当です。Windowsフォーム用のUserControl（一般的なクラスではない）を記述する場合、コンソールで使用することはできません。しかし、それは問題ではありません。WindowsフォームのUserControlがどのような種類のプレゼンテーションでも機能するのはなぜですか？UserControlは1つのことを実行し、適切に実行する必要があります。定義により、特定の形式のプレゼンテーションにバインドされています。最終的に、ユーザーは抽象化ではなく具体的​​なものを必要とします。これは、フレームワークでは部分的にしか当てはまらないかもしれませんが、エンドユーザーアプリケーションではそうです。

ただし、その背後にあるロジックは分離する必要があるため、他のプレゼンテーションテクノロジで再度使用できます。必要に応じてインターフェースを導入して、アプリケーションの直交性を維持します。一般的なルールは次のとおりです。具体的なものは他の具体的なものと交換可能でなければなりません。

質問の理由は、クラスが最も役立つようにクラスを一般化する方法に常に固執し、ハングアップしていることに気付くからです。これは実際に私に対して働いており、私は「一生懸命やっている」のだろうかと思っています。

極端なプログラマーはYAGNIの姿勢が好きです。すべてを一般的に記述しようとしないでください。また、すべてを汎用的にしようと一生懸命しようとしないでください。これはオーバーエンジニアリングと呼ばれ、最終的には完全に複雑なコードになります。各コンポーネントにタスクを1つだけ与え、それが適切に機能することを確認します。必要に応じて、変化が予想される場所に抽象化を追加します（上記のようなコンテキストを描画するためのインターフェイスなど）。

一般に、ビジネスアプリケーションを作成するときは、常に分離するようにしてください。MVCおよびMVVMは、ロジックをプレゼンテーションから切り離すのに最適であるため、Webプレゼンテーションまたはコンソールアプリケーションに再利用できます。最後に、いくつかのことを具体的にする必要があることに留意してください。ユーザーは抽象化を使用できません。具体的なものが必要です。抽象化は、コードの拡張性と保守性を維持するためのプログラマーであるあなたにとっての助けにすぎません。コードを柔軟にするために必要な場所について考える必要があります。最終的にすべての抽象化は、具体的な何かを生む必要があります。

編集：ベストプラクティスを提供できるアーキテクチャと設計手法について詳しく知りたい場合は、@ Catchopsの回答を読み、ウィキペディアでSOLIDの実践について読むことをお勧めします。

また、初心者には常に次の本をお勧めします：Head First Design Patterns。GoFブックよりも抽象化テクニック/ OOPデザインプラクティスを理解するのに役立ちます（GoFブックよりも優れていますが、初心者には向いていません）。

あなたは間違いなく正しい。そして、あなたは「うまくやっている」:)

単一責任の原則について読む

クラスの内部作業と、この情報をユーザーに提示する方法には2つの責任があります。

クラスを分離することを恐れないでください。まれに、問題があまりにも多くの抽象化と分離である:)

非常に関連性の高い2つのパターンは、Webアプリケーションのモデルビューコントローラーと、Silverlight / WPFのモデルビューViewModelです。

私はMVVMを頻繁に使用しますが、私の意見では、ビジネスオブジェクトクラスはユーザーインターフェイスについて何も知る必要はありません。確かに彼らが知っておく必要があるかもしれませんSelectedItem、またはIsChecked、またはIsVisible、などしかし、これらの値は、特定のUIに結びつける必要はありませんし、クラスの一般的な特性をすることができます。

フォーカスの設定、アニメーションの実行、ホットキーの処理など、コードビハインドでインターフェイスに何かを行う必要がある場合、コードはビジネスロジッククラスではなく、UIのコードビハインドの一部である必要があります。

したがって、UIとクラスを分割しようとするのをやめないでください。分離されているほど、保守とテストが容易になります。

あなたが話していることを正確に扱うために、長年にわたって開発されてきた多くの試行された真の設計パターンがあります。あなたの質問に対する他の答えは、単一の責任原則 -絶対に有効です-とあなたの質問を推進しているように思われるものに言及しています。この原則は、クラスが1つのことを行う必要があると単純に述べています。言い換えれば、Cohesionを上げ、Couplingを下げることは、優れたオブジェクト指向設計のすべてです-クラスは1つのことをうまく行い、他のクラスにあまり依存しません。

まあ...あなたは、あなたがiPhoneで円を描きたいなら、それは窓を走らせているPCでそれを描くこととは異なることを観察することで正しい。この場合、iPhoneでうまく描画する具象クラスと、PCでうまく描画する別のクラスが必要です。これは、これらのすべての形状の例が分解する基本的なオブジェクト指向の継承の概念です。継承だけではできません。

それがインターフェイスの出番です-Gang of Fourの本が述べているように（必読）-常に継承よりも実装を優先します。つまり、インターフェイスを使用して、ハードコードされた依存関係に依存せずにさまざまな機能をさまざまな方法で実行できるアーキテクチャをつなぎ合わせます。

私は、SOLID原則を参照しています。それらは素晴らしいです。「S」は単一の責任原則です。しかし、「D」は依存性反転の略です。ここでは、Inversion of Controlパターン（Dependency Injection）を使用できます。これは非常に強力であり、iPhoneとPCの両方に円を描くことができるシステムを設計する方法の質問に答えるために使用できます。

一般的なビジネスルールとデータアクセスを含むが、これらの構造を使用してユーザーインターフェイスのさまざまな実装を持つアーキテクチャを作成することができます。しかし、実際にそれを実装したチームにいて、実際にそれを理解するために実際にそれを見ることは本当に助けになります。

これは、より詳細な回答に値する質問に対する簡単な高レベルの回答です。これらのパターンをさらに検討することをお勧めします。これらのパターンのより具体的な実装は、MVCおよびMVVMの既知の名前として見つけることができます。

がんばろう！

ユーザーインターフェイスについて知る必要があるかもしれないクラスを作成する場合のベストプラクティスは何ですか。

自分自身を描画する方法を知っているクラスは、ユーザーインターフェイス（コンソール、GUIなど）に依存するため、いくつかのベストプラクティスを破らないでしょうか。

この場合でも、MVC / MVVMを使用し、共通のインターフェイスを使用してさまざまなUI実装を挿入できます。

public interface IAgnosticChartDrawing
{
   public void Draw(ChartProperties chartProperties);
   event EventHandler ChartPanned;
}

public class GuiChartDrawer : UserControl, IAgnosticChartDrawing
{
    public void Draw(ChartProperties chartProperties)
    {
        //GDI, GTK or something else...
    }

    //Implement event based on mouse actions
}

public class ConsoleChartDrawer : IAgnosticChartDrawing
{
    public void Draw(ChartProperties chartProperties)
    {
        //'Draw' using characters and symbols...
    }

    //Implement event based on keyboard actions
}

IAgnosticChartDrawing guiView = new GuiChartDrawer();
IAgnosticChartDrawing conView = new ConsoleChartDrawer();

Model model = new FinancialModel();

SampleController controllerGUI = new SampleController(model, guiView);
SampleController controllerConsole = new SampleController(model, conView);

これにより、新しいタイプのGUIを追加しながら、コントローラーおよびモデルロジックを再利用できます。

それを行うためのさまざまなパターンがあります：MVP、MVC、MVVMなど...

読むべきMartin Fowler（ビッグネーム）からの素晴らしい記事はGUIアーキテクチャです：http : //www.martinfowler.com/eaaDev/uiArchs.html

MVPはまだ言及されていませんが、引用するに値するものです。それを見てください。

これは、Google Web Toolkitの開発者が使用することを提案したパターンで、本当にすてきです。

実際のコード、実際の例、およびこのアプローチが有用である理由の根拠をここで見つけることができます。

http://code.google.com/webtoolkit/articles/mvp-architecture.html

http://code.google.com/webtoolkit/articles/mvp-architecture-2.html

ここで十分に強調されていないこのアプローチまたは類似のアプローチに従う利点の1つは、テスト容易性です！多くの場合、それが主な利点です。

これは、OOP が抽象化でうまく機能しない場所の1つです。OOPポリモーフィズムは、単一の変数（「this」）に対する動的ディスパッチを使用します。多態性がShapeに根ざしている場合、レンダラー（コンソール、GUIなど）で多態的にディスパッチすることはできません。

2つ以上の変数をディスパッチできるプログラミングシステムを考えます。

poly_draw(Shape s, Renderer r)

また、システムが、ShapeタイプとRendererタイプのさまざまな組み合わせに対してpoly_drawを表現する方法を提供できると仮定します。そうすれば、シェイプとレンダラーの分類を簡単に思い付くでしょうか？型チェッカーは、実装に失敗した可能性のある形状とレンダラーの組み合わせがあることを理解するのに役立ちます。

ほとんどのOOP言語は上記のようなものをサポートしていません（いくつかはサポートしていますが、主流ではありません）。回避策として、訪問者パターンをご覧になることをお勧めします。

... draw（）メソッドは、ユーザーインターフェースに大きく依存していませんか？たとえば、Win Forms用にこのクラスを記述した場合、コンソールアプリまたはWebアプリに再利用することはできません。これは正しいです？

上記の音は私にとって正しい。私の理解では、MVCデザインパターンの観点から、コントローラーとビューの間の比較的緊密な結合を意味すると言うことができます。これはまた、desktop-console-webappを切り替えるには、コントローラーとビューの両方をペアとして切り替える必要があることを意味します。モデルのみが変更されないままです。

...私は常に行き詰まって、クラスを一般化する方法にこだわって、それらが最も役立つようにします。

私の現在の上記の見解は、私たちが話しているこのView-Controllerカップリングは大丈夫であり、さらにモダンなデザインではかなりトレンディだということです。

しかし、1、2年前にも私はそれについて不安を感じていました。Sunフォーラムでパターンとオブジェクト指向設計に関する議論を学んだ後、気が変わりました。

興味のある方は、このフォーラムを自分で試してみてください-Oracleに移行しました（リンク）。そこに着いたら、Saishに pingを送ってみてください-当時、これらのトリッキーな問題に関する彼の説明は、私にとって最も役に立ちました。彼がまだ参加しているかどうかはわかりません-私自身はしばらくそこにいません

しかし、draw（）メソッドは、ユーザーインターフェースに大きく依存していませんか？

実用的な観点から見ると、システム内の一部のコードはRectangle、ユーザーエンドの要件である場合のように描画する方法を知る必要があります。そして、それはある時点で、ピクセルのラスタライズやコンソールでの何かの表示のような本当に低レベルのことを行うことに要約されます。

カップリングの観点からの私への質問は、このタイプの情報に誰が/何を依存すべきか、そしてどの程度の詳細（例えば、どの程度抽象的か）ですか？

描画/レンダリング機能の抽象化

上位レベルの描画コードが非常に抽象的なものにのみ依存している場合、その抽象化は、ターゲットとするすべてのプラットフォームで（具体的な実装の置換により）動作する可能性があるためです。考案された例として、非常に抽象的なIDrawerインターフェイスをコンソールとGUIの両方のAPIで実装して、プロット形状などを実行できる場合があります（コンソール実装はコンソールをASCIIアートの80xNの「イメージ」のように扱う場合があります）。もちろん、それは不自然な例です。なぜなら、通常はコンソール出力を画像/フレームバッファーのように扱うことではないからです。通常、ほとんどのユーザーエンドは、コンソールでより多くのテキストベースの対話を要求する必要があります。

別の考慮事項は、安定した抽象化を設計するのがどれほど簡単かということです。対象とするのは、ライン、長方形、パス、テキスト、この種のもの（プリミティブの限られたセットの単純な2Dラスタライズ）のような基本的な図形描画機能を抽象化する最新のGUI APIだけであれば簡単かもしれません、さまざまなサブタイプを介して簡単に実装できる1つの抽象インターフェースを、低コストで提供します。そのような抽象化を効果的に設計し、すべてのターゲットプラットフォームに実装できる場合、シェイプやGUIコントロール、またはそのような抽象化。

しかし、プレイステーションポータブル、iPhone、XBox One、パワフルなゲームPCの間で変化する厄介な詳細を抽象化しようとしている一方で、ニーズはそれぞれに最先端のリアルタイム3Dレンダリング/シェーディングテクニックを利用することであるとします。その場合、基礎となるハードウェアの機能とAPIが非常に大きく変化するときにレンダリングの詳細を抽象化する1つの抽象インターフェイスを考え出そうとすると、設計と再設計に膨大な時間がかかり、予期せずに設計変更が繰り返される可能性が高くなります発見、同様に、基盤となるハードウェアの完全な一意性と能力を活用できない最も一般的な分母ソリューション。

安定した「簡単な」設計への依存関係の流れの作成

私の分野では、私はその最後のシナリオにいます。私たちは根本的に異なる基本的な機能とAPIを備えた多くの異なるハードウェアをターゲットにし、それらをすべて支配する1つのレンダリング/描画抽象化を考え出すことは境界線絶望です（ゲームのように効果的にそれを行うだけで世界的に有名になるかもしれません業界のチェンジャー）。ですから、私の場合、私が最後に望むことは、たとえそのドローイングを可能な限り最高レベルで最も抽象的な方法で表現しているとしても、アナロジーShapeやModel、Particle Emitter自分自身を描く方法を知っているようなものです...

...これらの抽象化は適切に設計するのが難しすぎるため、設計を修正するのが困難で、すべてがそれに依存している場合、それは最もコストのかかる中央設計変更のレシピであり、それに応じてすべてを波及させ破壊するからです。したがって、最後にしたいことは、システム内の依存関係が、修正するのが難しすぎる抽象設計に向かって流れることです（侵入的な変更なしに安定させるのが難しすぎます）。

難しいは簡単に依存しているが、簡単ではないは難しいに依存している

したがって、代わりに行うことは、依存関係を設計しやすいものに向かって流れさせることです。ポリゴンやマテリアルのようなものを保存することに焦点を合わせた抽象「モデル」を設計し、その設計を正しくするのは、図面をサービスするために効果的に実装できる抽象の「レンダラー」を設計するよりもはるかに簡単ですPCからPSPのような異種ハードウェアを均一に要求します。

そのため、設計が難しいものから依存関係を反転させます。抽象モデルに、すべてが依存する抽象レンダラーデザインに自分自身を描画する方法を知らせるのではなく（そして、その設計が変更されると実装を中断する）、代わりにシーン内のすべての抽象オブジェクトを描画する方法を知っている抽象レンダラーがあります（モデル、パーティクルエミッタなど）、などのPC用のOpenGLレンダラーサブタイプを実装できますRendererGl。別のPSP RendererPsp用、携帯電話用などに依存します。その場合、依存関係は安定した設計に向かって流れ、修正が容易で、レンダラーから、シーン内のさまざまなタイプのエンティティ（モデル、パーティクル、テクスチャなど）まで。

• 私が理解できる限り、変化の難しさをより多く測定しているボブおじさんの求心性/遠心性カップリングメトリックとは少し異なる意味で「安定性/不安定性」を使用しています。私は「変更を必要とする確率」についてもっと話していますが、彼の安定性の指標はそこで役立ちます。「変更の確率」が「変更の容易さ」に比例する場合（例：変更を必要とする可能性が最も高いものは、最も不安定であり、ボブおじさんの測定基準からの求心性結合）、そのような可能性のある変更は、安価で邪魔にならない、中心的な設計に触れることなく実装を置き換えるだけで済みます。

コードベースの中央レベルで何かを抽象化しようとしていて、壁に頭をぶつけて、毎月/年に8,000のソースファイルを更新する必要のある変更を絶えず行うのではなく、設計が非常に難しい場合それに依存するすべてを壊す、私の一番の提案は、依存関係を反転することを検討することです。設計が非常に困難なものは、設計が他のすべてのものに依存し、設計が非常に困難なものに応じて設計が容易なものを持たないような方法でコードを記述できるかどうかを確認します。実装ではなく設計（具体的にはインターフェース設計）について話していることに注意してください。時には、設計が簡単で実装が難しい場合があります。また、時には設計が難しくても実装が簡単な場合があります。依存関係は設計に向かって流れるので、依存関係が流れる方向を決定するためにここで何かを設計することがどれだけ難しいかに焦点を当てる必要があります。

単一責任の原則

私にとって、SRPは通常はそれほど興味深いものではありません（ただし、コンテキストにもよりますが）。目的が明確で保守Shape可能なものを設計する際に綱渡りのバランスをとる行為がありますが、オブジェクトは、たとえば、自分で描く方法がわからない場合、より詳細な情報を公開する必要があり、あまり意味のあることはないかもしれません特定の使用コンテキストで形状を作成し、それを描画するよりも実行します。ほぼすべてとトレードオフがあり、特定のコンテキストでの私の経験では、このようなメンテナンスの悪夢になり得る自分自身を描く方法を意識させることができるSRPとは関係ありません。

それは、カップリングと、システム内で依存関係が流れる方向に関係しています。すべてが依存する抽象的なレンダリングインターフェイスを（自分自身で描画するために使用しているため）新しいターゲットAPI /ハードウェアに移植しようとしており、そこで効果的に機能するためにデザインを大幅に変更する必要があることに気付いた場合、それは非常にコストのかかる変更であり、自分自身を描く方法を知っているシステム内のすべての実装を置き換える必要があります。そして、それは、前もって正しく設計するのが難しすぎる抽象化に向かって流れる依存関係のボートの負荷に変換される場合、自分自身を描く方法を知っているもので遭遇する最も実用的なメンテナンスの問題です。

開発者の誇り

私の経験では、これは多くの場合、依存関係の方向を設計しやすいものに向けることの最大の障害であるため、この1つの点に言及します。開発者がここで少し野心的になり、「クロスプラットフォームレンダリングの抽象化を設計してすべてを支配し、他の開発者が何ヶ月もポーティングに費やすものを解決します。そして、それは正しく、私たちがサポートするすべてのプラットフォームで魔法のように動作し、すべてのプラットフォームで最先端のレンダリング技術を利用します。私はすでにそれを頭の中で思い描いていました。」その場合、彼らはそれを避けて依存関係の方向を反転させ、莫大な費用がかかり、繰り返し発生する中央の設計変更を単に安価でローカルな繰り返しの実装変更に変換するという現実的な解決策に抵抗します。そのような抽象的なレベルまで設計するのが難しすぎるとあきらめて、戦略全体を再考する開発者には、ある種の「白旗」の本能が必要です。そうでなければ、彼らは多くの悲しみと痛みに陥ります。このような世界を征服する野心をインターフェースの設計レベルに引き上げるよりも、そのような野心と闘志を、設計しやすいものの最先端の実装に移すことをお勧めします。