問題タブ [design-principles]

コードレビュー中に次のコードを見つけました。

私の直感は、これが適切な OOP に従っていないことを示しています。

LoadObject メソッドは、渡されたオブジェクトを変更するのではなく、新しい SomeObject オブジェクトを返す必要があると考えています。なぜこれが優れているのかについての適切な説明を実際に見つけることはできませんが。

私のソリューションはより良いですか？もしそうなら、なぜですか？具体的には、特定のコード例で破られている OOP の原則または標準は何ですか (ある場合)。

アプリケーションが持つことができるアクティビティの数に関する設計ガイドラインはありますか? 制限がある場合、Android アプリケーションにバンドルできるアクティビティの理想的な数はいくつですか。

階層的に編成された XML ファイルのクラス表現を自動的に生成するツールを使用しています。XML ファイルは、アプリがアクセスできるようにする必要がある設定ファイルです (読み取り専用)。

1 つまたは複数の設定にアクセスする必要があるクラスに最上位ノード (例: AppSettings) を渡すと、簡単に次のようなコードになる可能性があります。

これはデメテルの法則に対する深刻な違反のようですが、気にする必要があるかどうか疑問に思っています。各クラスに必要な正確な設定のみを渡すために多大な労力を費やすことができましたが、この場合、これらの複数のドットがどのように私を傷つけるのかを理解するのに苦労しています.

自分のコードを自分の XML ファイル形式に密結合すると、将来メンテナンスの問題やその他の問題が発生する可能性がありますか? それとも、これは宗教的に OOP 設計原則に従わないことが理にかなっている例ですか?

オブジェクト指向プログラミングにおける「依存関係逆転の原則」とはどういう意味ですか? それは何をするためのものか？

使用する

• Visual Studio 2010
• .Net Framework 4
• C＃
• エンティティへのLinq

問題

DRYやSOLIDなどのオブジェクト指向の原則をいくつかのLinqプロジェクションに適用できるようにしたいと思います。コンパイルされたクエリまたは渡されたパラメーターを使用して、これまでのところ、予測ではなく、Linqの残りの部分にこれらを正常に適用できます。

これが不可能な場合はお知らせください。可能な場合は、代替ソリューション（以下で説明）のいずれかを選択する必要があります。可能であれば、または何かが不足していて、目標を満たす別の代替実装がある場合。

詳細

大まかに言えば、標準のLinqクエリまたはCompiledQueryのいずれかを使用して、Linqプロジェクションで使用される型を動的に制御できるようにしたいと考えています。例と実際のコードではLinqtoEntitiesを使用していますが、この問題はコアLinqに当てはまるはずです。

以下は、動的ではなく、問題を解決しない単純な例です。タイプごとに常にFooUserを使用するように修正されています。私ができるようにしたいのは、プロジェクションで作成されたユーザーのタイプを動的に制御することです。これらはすべて、共通のIUserインターフェイスに基づいています。これは、クエリがフィルタリングするタイプを制御する方法と似ているか、似ている可能性があります。

代替ソリューション

私はDRY、SOLIDに準拠しようとしています。また、典型的なコードの臭いである列挙型を使用して対処することを避けようとしています。しかし、私のすべての試みと研究において、私は次の解決策の1つに陥らなければならないようです。

1. フィルタするタイプとプロジェクションで使用されるタイプを除いて、すべて同じタイプのクエリを実装します。これはDRYとOCPに違反しますが、これを1つのクラス内にカプセル化して、準拠したクエリとして互いに近づけることができます。これには、新しいタイプを追加した場合、またはデータのクエリ方法が変更された場合に、クラスを変更する必要があります。

2. タイプを持つ列挙型を実装し、そのタイプをプロパティとして持つ、より一般化されたUserクラスを使用します。ただし、これにより、いくつかの場所で列挙型を使用し、それらを処理するために長いケースステートメントを導入する必要があります。これは避けたいと思います。

さまざまな悪から選択する必要がなく、すべてのSOLIDの原則とDRYに準拠できる実装が必要です。しかし、私がしなければならない場合、私はそれの最初またはバージョンで終わると思います。

例

標準の単純なLinqクエリ

上記のクエリのコンパイル済みバージョン

Subversion リポジトリをめぐる戦いが予想されます。現在、3 つのメイン プロジェクトと 2 つのレポート プロジェクトとしてチェックインされた単一の Web アプリケーションがあり (6 か月前に開始したとき)、現在は最大 7 つのプロジェクトであり、さらに成長することが期待されています。 .

バージョン管理システムを合理的に使用したい場合、コンパイルされた実行可能ファイルがバージョン管理の境界を越えることができないということは、私には明らかです。1 つの機能に対して 1 つのチェックインを行うことは不可能であり、それは私にとって不可欠なことのように思えます。

しかし、これを説明しようとすると、手を振っているような気がします。Subversion または一般的に、この原則を説明し、その背後に何らかの権威がある参考文献を持っている人はいますか? 私はいくつかの検索を行いましたが、必要なものが思い浮かびません。

C や MATLAB などの手続き型言語でさえ、オブジェクト指向言語に変えることは原理的に可能であることを私は知っています。この質問は、こことここでかなりよく議論されています。

これらの議論とその中の参考文献から欠けていることがわかったのは、そのような原則を適用すべきかどうかについての説明でした. そうすることで具体的に得られるものはありますか？明らかに可能ですが、そうすることをお勧めしますか? この実践が明確な利点につながったオープンソース プロジェクトの例はありますか?

明確化

おそらく、例が適切です。

機械学習アルゴリズムを実装する MATLAB コードをいくつか継承しました。building_model基本的に、渡されるフラグに応じて、モデルをトレーニングするか、それを使用して将来の値を予測する単一の関数があります。

と

モデル自体は、 内の MATLAB 永続変数で実装されますbuilding_model。

building_modelトレーニング用と予測用の 2 つの関数に分割しました。永続変数として実装されていたモデルは、いわば外部化されています。

これは、大まかに言えば、MATLAB で OOP のいくつかの機能をエミュレートできる範囲です。私の構築モデル モジュールは、コンストラクターと 2 つのメソッドmodel_trainとmodel_predict. 私はある程度のカプセル化を達成しました (ただし、呼び出し元が の内部をいじるのを妨げるものは何もありませんmodel)。原則として、ポリモーフィズムにも対応できます。追加のボーナスとして、コマンド/クエリの分離をほぼ無料で取得できmodel_predictます。modelmodel

(賢明な読者は、MATLAB には既にオブジェクト指向システムがあることを指摘するでしょう。パフォーマンスや古いバージョンとの互換性など、さまざまな理由から、私はそれを使用できません。)

データ構造を設計し、最初の引数がそのデータ構造のインスタンスになる関数を作成する C の同様のメカニズムを想像できます。

私が知りたいのは、このプログラミング方法をどこまでプッシュできるかということです。これは一般的に受け入れられているパターンですか (私はその言葉を言いました)? 注意すべきパフォーマンスの問題はありますか?

ご存知のように、「インターフェイスへのプログラム」の設計原則は、具体的な型や実装ではなく、スーパータイプを広く好みます。

Javaプログラムでinstanceofを使用してスーパータイプから具象型を導出するという原則と一致していますか?

私のアプリケーションでは、Storehouse は、いくつかのプライベート変数とパブリックの getter および setter を持つ抽象スーパータイプ クラスです。

ConcreteStorehouseA は Storehouse を継承し、多くの具体的なメソッドと変数を持っています。ConcreteStorehouseB は似ていますが異なります。

私のアプリケーションは倉庫を受け取ります。ただし、Storehouse は操作するのに便利なタイプではありません。本当に有用なメソッドだけが具体的な型に含まれているため、次のように instanceof を使用します。

instanceof の使用は原則と互換性がありますか?

編集：

本質的に、このアプリケーションは、テーブル トップ RPG、Shadowrun のサイコロ シミュレーターです。具体的なタイプは、成功テスト、反対テスト、拡張テストなどのさまざまなテスト タイプであり、成功する操作の要因とパラメータはすべて非常に異なります。スーパータイプには基本的にダイス プールが含まれています。

少し前に、自分が作成しているアプリケーションのクラス図を投稿しました。いくつかの役立つヒントを得て、仕事に行きました。確かにデザインするのは難しいです！とにかく、私はバージョン2.0を作成しましたが、他のことに遭遇しました。たぶん誰かが私のクラス図に関するポインタ、コメント、またはアドバイスを与えることができます:-)

最初に、 Sprite抽象クラスの一部としてSomeInterfaceに「Speed」がありました。検討の結果、これは「スピード」を置くのに最適な場所ではないと思いました。あまり良くないことは、インターフェイスに適切な名前を付けることができなかったことと、プロパティであるため、属性または操作コンパートメントのどこに「速度」を配置するかがわからなかったことです...

各オブジェクト（弾丸、侵入者、船）は独自の速度で移動するため、「速度」をインターフェイスに配置します。すべてのオブジェクトはスーパークラスSpriteを継承し、Update（）メソッドのみをオーバーライドします。Bullet抽象クラスは、Spriteから取得したUpdateメソッドでは何もしません。そこから取得したことを示すためだけにあります。これが正しい方法であるかどうか、またはそれを省略して、それをオーバーライドするクラスでのみ表示する必要があるかどうかはわかりません。

対処方法がわからないもう1つの問題は、侵入者によって行われるアニメーションです。次のプロパティを取得しました：SheetSize、FrameSize、およびCurrentFrame。シートにはエイリアンの写真（パラパラマンガなど）が含まれ、FrameSizeはシート上のフレームだけを選択するためのものであり、CurrentFrame...は現在のフレームを保持します。ShipとBulletはアニメートしないため、これらのプロパティは役に立ちません。それらをどこに置くか？

最後に、IBulletBehaviorを実装する場所がありませんでした。最初に、各弾丸の動作にIBulletBehaviorを実装させましたが、抽象Bulletクラスに実装させるように切り替えました。どちらを取るかを決めるルールはありますか？

私が取り組んでいる多くのプロジェクトでは、読み取り専用のコレクションを返す必要があるときはいつでも、IEnumerable<T>インターフェイスを使用して、次のようにタイプ固有にします。

ほとんどの場合、私はリストを返しますが、一部の関数と読み取り専用プロパティでは、拡張メソッドのおかげで目的を果たしてくれる配列を返します。

私の質問は、特定のタイプ（例：、、、またはs）の代わりにsを返すことによって、設計原則に違反しているIEnumerable<T>List<T>HashSet<T>Stack<T>Arrayのでしょうか？