私はクラス作りの最善の方法について常に議論しています。オブジェクトはどのように見えますか？
これは私が常にINotifyPropertyChangedとIDataErrorInfoを実装するクラスを作成しないようにして、 "if"をフォームに直接バインドできるようにするためです。 WCFでクラスを使用できるようにしたいですか？
私は明白な余分なコードとは別に、これ以上の柔軟性を持たないテストが必要なのでしょうか？
私はいつも「一度作成」して「どこでも」を使用しますが、「YAGNI」と調整しています（必要ではありません）。
私の質問には、「ビジネスクラス」というアイデアがありますが、死んだ再利用可能なものがありますか？私たちは、今のところ働く最も基本的なものを作り、必要な時にそれを構築すると言うのでしょうか？
R
私はそれはむしろ、さまざまなシナリオで使用できるオブジェクトを作成するよりも、特定のタスクの小さなセットにあなたのクラスはより集中させるために通常より良いと思います。たとえば、すべてのデータレイヤ固有の属性/ビヘイビア、すべてのプレゼンテーションレイヤの内容を含むプレゼンテーションレイヤオブジェクト、サービスレイヤオブジェクトなどを持つデータレイヤオブジェクトがあるとします。
クラスを "オールパワフル "とすると、異なるレイヤーにたくさんの依存関係が作成されてしまい、将来的に変更するのがずっと難しくなります。 Googleの「単一責任原則」の検索を行う - OOの「固い」原則の1つです。
私はUIから非常に遠い多くのクラスを作成します。毎回これらのインターフェイスを実装することは、報酬を最小限に抑えて大きな負担になります。
まず、プログラマは怠け者です。私たちの改造は退屈な作業を自動化することです。 （私は否定的ではない）私たちは一般的に、どんな種類の余分なビットが入ってくるかを示す特定の目的に役立つクラスを書く。あなたはアスペクト指向プログラミングが答えようとしている基本的な質問をしています。私のクラスはサーヴィスですか？私のクラスはデータコンテナですか？私のクラスは観察可能ですか？これらは、用途に応じてクラスがこれらすべてのものになることができる側面です。あるいは、それだけが彼らの一人かもしれません。
これを行うと、どこに線を描くのですか？あなたはいつかあなたがどこかからそれらを投げたいかもしれないので、すべてのクラスの例外を作るつもりですか？それらをすべてシリアライズ可能にするつもりですか？
あなたが考えることのもう一つの方法は、言語デザイナーがすでにその決定を下したことです。すべてのクラスは、「一般的な」オブジェクトに必要なものすべてを含むObjectから自動的に継承されます。
最後に、コードの再利用と不要なコードの書き出しを混同しないでください。一般的には、今すぐ必要なコードを書くだけで、将来は使いやすく/変更しやすいように設計する必要があります。