問題タブ [single-responsibility-principle]

階層関係を持つシステムを設計する際に、多態的な動作を必要とする問題に遭遇することがよくありますが、この多態的な実装の恩恵を受ける作業の種類は複数あります。

たとえば、抽象構文ツリーを使用してコンパイル用に解析されたソースを編成するコンパイラを考えてみましょう。複数のタイプの ValueProvider があり、それぞれが操作スタックに値をロードするための異なるコードの発行を担当する場合があるため、ロジックを多態的に編成すると便利です。問題は、AST で静的分析を実行したい場合があることです。この場合、ツリーでまったく異なる作業を行いたいのですが、それでも分析対象のノードのタイプに依存する動作が発生する可能性があります。つまり、ポリモーフィックな動作が必要ですが、分析コードをコンパイル コードと混ぜ合わせたくはありません。

私が現在これに取り組んでいる方法は、単にツリーを提供する責任を持つオブジェクト モデルを使用してデータを格納することです。次に、ツリーの各コンシューマー (コンパイラーや静的アナライザーなど) は、実行時の型情報を使用して、そのロジックの条件付き分岐を実行します。これは必然的に、ノードのタイプに基づいて、多くの「if/else if」または「switch」コーディングにつながります。ポリモーフィズムが対処するように設計されているのは、この種の厄介な分岐だけですが、並列でバラバラな責任にはそれが必要なようです。

これを構造化するより良い方法はありますか？

誰かが単一責任の原則の例を教えてもらえますか? 私はおそらく毎日この規則を破るのではないかと恐れているので、実際には、クラスが単一の責任を持つことが何を意味するのかを理解しようとしています。

「教えて、聞かないで」が「単一責任」の原則と矛盾しているように見える場合があります。私はこのテーマに関する他の議論を見てきましたが、この状況に最も適切なオブジェクト指向のアプローチをまだ理解することができませんでした。

さまざまなソースからのデータのコレクションを読み取って操作するプログラムがあります。データを保持および操作するためのクラス（「DataSet」クラス）を作成しました。これには、2つのデータセットを比較して違いを含む新しいデータセットを生成したり、データセットをファイルに書き込んだりするなど、データセットに対してさまざまな操作を実行するためのメソッドが含まれています。

データセットに対して分析を実行し、結果をレポートに出力したいと思います。これをコーディングする最初の試みは、データセットに問い合わせてそこから情報を抽出し、レポートを作成しますが、これは「教えて、聞かないでください」という原則に反しているようです。したがって、分析メソッドをDataSetクラス内に配置し、データセットにそれ自体を分析してレポートを生成するように指示する必要がありますか？これは単一責任の原則に違反しますか？将来、他のタイプの分析を実行したい場合はどうなりますか？DataSetクラスによって、そのコア目的とは関係のない多くの異なる分析ルーチンで非常に肥大化する可能性があります。

誰かがここで最良のアプローチを提案できますか？この問題に対処する特定のデザインパターンはありますか？

EntityFrameworkを利用するWebアプリケーションを構築しています。複数のコンシューマーによって使用されるため、エンティティモデルと生成されたクラスを別のプロジェクトに移動しました。

しかし、アプリケーションを実行しようとすると、EntityFrameworkから次のように通知されます。

この問題を解決するには、すべての消費プロジェクトにEntityFramework接続文字列を追加する必要があります。もちろん、これは厄介なことです。何人かの消費者がいるからです。また、ソフトウェアをさまざまなプロジェクトに分割することで解消したいと思っていた緊密な結合が導入されています。

では、すべての消費プロジェクトではなく、1か所だけで接続文字列を定義することは可能ですか？

注：私はデータベースファーストのアプローチに従っています。

どのクラスが特定の情報を保持する必要があるかについてのガイダンスが欲しいです。「宇宙物体」内を動き回る「移動物体」がある場合、その移動物体は宇宙物体内のどこにあるか、どれだけ速く動いているか、どの方向に移動しているかを本当に気にしますか?

「場所」のモバイル オブジェクトにプロパティを割り当てると確かに便利に思えますが、実際には気にする必要はないと思います。だから私は思いついた：

少し性急に書いてしまいましたが…私の言いたいことが伝わってれば幸いです。要約すると、モバイルは場所を保持する必要がありますか、それともスペースを保持する必要がありますか? 誰が動きを制御する必要がありますか?

高い凝集度は単一責任原則の同義語ですか？そうでない場合、それらはどのように異なりますか？

私は大規模なプロジェクトに取り組んでおり、その一部は既存のサーバー スタックを置き換えるものです。非常に正規化された大規模なデータベースでは、多くの複合オブジェクトを構築する必要があることは明らかでした。私のクエリの例は次のとおりです: 私の複合オブジェクト定義:

そして、私のサービスでの私のデータベースクエリ:

これで、私の複合オブジェクトの定義から、それにはデータのみが含まれ、ビジネス ルールは含まれず、ビジネス構造、データ構造、またはその他の永続性や公開は含まれていないことが明らかです。

しかし、私のチーム メイトは、これはドメイン モデルにしか存在できず、この明確に定義されたオブジェクトから DTO にデータを移動するサイクルを費やす必要があると述べています。それだけでなく、a) すべての DTO の名前に DTO が含まれている必要があり、b) ネットワークを介して移動する目的でのみ存在する必要があります。したがって、クライアント コードを開発するときは、a) 各オブジェクト プロパティのプロパティを作成し、b) DTO からビュー モデル プロパティに移動する必要があります。

これはDTOを極限まで進めていると感じます。これは、これらがデータ転送オブジェクトである複合オブジェクトの定義に基づいています。また、このオブジェクトをクライアントに保存し、クライアントでこのオブジェクトに直接バインディングを行うことにまったく問題はありません。私がしているのは、複合オブジェクトで定義されたすべてのプロパティを取得してDTOにコピーすることだけなので、オブジェクトを作成して別のオブジェクトにコピーしてからもう一度内部にコピーするのは、時間とサイクルの膨大な無駄のようですクライアントのプロパティ。

これに関する他の意見に興味があります。私は、関心の分離や単一責任の原則などの OOP ルールに違反していないと感じています...少なくとも、これらについて極端に肛門にならない限り. ご意見????

前文

SRP を念頭に置いてアプリを構築しようとするのはこれが初めてであり、データ アーキテクチャ (ActiveRecord) から始めてそれに合わせてアプリを構築するのではなく、実際にテストを使用してサイトのコードを駆動しようとしています。

しかし、私は問題に直面しています。私は Destroy All Software のスクリーンキャストをたくさん購読して見てきました。理論的には彼の説教は好きですが、実際には機能させるのに苦労しています。

当面の問題

私のアプリの主な機能は、場所に基づいてプロファイルを検索することです。そこで、そのための簡単な Cucumber 機能を作成します (目前のタスクを簡素化するために、当面は意図的にルート/コントローラーなどを除外します)。

検索機能:

search_steps.rb:

問題ありません。仕様に進みます。

profile_search_spec.rb:

profile_search.rb:

私が ProfileSearch クラスを使用した理由はいくつかあります。

1. できるだけ多くのビジネス ロジックを ActiveRecord の外に移動することは正しいことのように思えます (単一責任の原則)。
2. PORO はテストを高速化します (Rails をロードしません)。
3. 近い将来、ElasticSearch または Solr を使用する予定であり、インターフェイスを同じままにしたいと考えています。

次に何をすべきかよくわかりません。ProfileSearch明らかにProfileモデルによって異なりますが、これは ActiveRecord になると確信しています。

問題は、仕様を作成してビルドProfileを開始し、テストでRailsのロードを開始するだけですか? これは最も簡単なオプションのように思えますが、何かが間違っているようです。アプリがまだ具体的に要求していない動作を設計および構築するように感じます。フィールド、リレーション、ストレージなどについて考える必要がありますが、これらは現在、私のアプリが気にする必要はありません。

Profileまたは、仕様内のすべての呼び出しにスタブ/モックを使用ProfileSearchし、正しいメソッドが呼び出されていることを確認する必要がありますか? そのときは動作を実際にテストしていないため、これも間違っているようです。同じ動作が予想される場合でも、Solr または ElasticSearch に切り替えるときにテストを書き直す必要があります。

それとも、当分の間 ActiveRecord を使用しないが、Bob おじさんが wiki のものを構築するときに示したように、すべての適切なメソッドに正しく応答する、実際に機能する Profile モデルを実際に作成する必要がありますか? これは理論的には最良のアプローチのように思えますが、将来的に ActiveRecord を使用することを考えると、かなり冗長に思えます。

または...それをファックして、ActiveRecordモデルのすべてをスローします:\

頭の中に浮かんでいるパターン、原則、ベスト プラクティスが多すぎて、どうすればよいかわかりません。

あなたならどうしますか？

私はSOLIDを学び、RailsアプリにSRPを導入しようとしています。基本認証を使用した次のユーザーモデルがあります。

すべての認証ロジックを次のようなモジュールに移動したいと思います。

そして、私のユーザーモデルは次のようになります。

そして今、エラーが始まります：

Authentication：Moduleの未定義のメソッド `attr_accessible'

このエラーを修正するにはどうすればよいですか？これが私のRailsアプリにSRPを導入するための最良のスタートであると確信しています。

ありがとう

いくつかの古いレガシーコードをリファクタリングしている間、私は可能な限り単一責任の原則を適用しようとしたので、1つの目的だけを持つ多くのクラスに行き着きました。それは問題ありませんが、これらの新しいクラスの単体テストを作成しようとすると問題が発生します。一部のクラスは、テストの設定が難しいため、テストが非常に困難です。単一のテストケースを作成するには、4〜5個のモック/スタブを作成する必要があります。すべてのコードをカバーしたい場合は、複数のテストケースを作成する必要があるため、お尻が痛くなります。

テストをセットアップするのが難しい（他の多くのクラスに依存しているため）コードの臭いはありますか？これをどのように解決しますか？