問題タブ [single-responsibility-principle]

仲間の開発者と私は (軽く言えば) オブジェクトのプロパティの遅延読み込みについて話し合っています。

• 彼は、オブジェクトのオブジェクトの解決と遅延ロードに静的 IoC ルックアップ呼び出しを使用すると述べています。
• それは SRP に違反し、所有する Service を使用してそのオブジェクトを解決すると言います。

では、IoC と SRP に続く遅延読み込みをどのように処理しますか?

その遅延ロードされたプロパティを単体テストすることはできません。彼は、「あなたはすでに UserStatsService の単体テストを持っています。あなたのコード カバレッジがあります」と反論しています。有効なポイントですが、プロパティは「完全な」カバレッジのためにテストされていません。

セットアップ / コード パターン:

• プロジェクトは、厳密な依存性注入ルールを使用しています (すべてのサービス、リポジトリなどの ctor に注入されます)。
• プロジェクトはキャッスル経由で IoC を使用しています (ただし、Unity など、何でもかまいません)。

以下に例を示します。

上記は、オブジェクトの遅延ロードの例を示しています。これを使用しないで、そのオブジェクトが必要な場所ならどこでも UI レイヤーから UserStatsService にアクセスするように言います。

編集：以下の1つの答えは、遅延読み込みに対するNHibernateのトリックを思い出させました。これは、プロパティを仮想化し、NHibernateが遅延読み込み自体の過負荷を作成できるようにすることです。はい、スリックですが、NHibernate は使用していません。

遅延読み込みの問題に実際に取り組んでいる人は誰もいません。いくつかの良い記事と SO の質問が近づいています。

• 多くの依存関係を持つクラスに依存性注入フレームワークを使用する
• http://blog.vuscode.com/malovicn/archive/2009/10/16/inversion-of-control-single-responsibility-principle-and-nikola-s-laws-of-dependency-injection.aspx

遅延読み込みの利点は確かにあります。誤解しないでください。忍者の DI 方法に切り替えるまで、複雑な型とそのサブタイプを遅延読み込みするだけでした。利点は、ユーザーの統計情報が表示される UI レイヤーにあります。たとえば、100 行のリストです。しかし DI では、数行のコードを参照してユーザーの統計情報を取得する必要があり (SRP に違反したり、デメテルの法則に違反したりしないようにするため)、この長い検索パスを 100 回以上実行する必要があります。

はい、キャッシュを追加し、UserStatsService がシングルトン パターンとして使用されるようにコード化されていることを確認すると、パフォーマンス コストが大幅に削減されます。

しかし、IoC と DI のルールに完全には従わず、回避策を正当化するための有効なパフォーマンス/コーディング ポイントを持っている [頑固な] 開発者が他にいるかどうか疑問に思っています。

私は単一責任の原則をよりよく守ろうとしていますが、データベースと通信するための一般的なクラス設計をどのように構成するかを理解するのに問題があります。簡略化されたバージョンでは、基本的に次のものを含むデータベースがあります。

メーカー<==プローブ<==>ProbeSettings

プローブにはメーカーがあります。プローブには1セットの設定があります。関連するオブジェクトはアプリケーション全体でアクセスされ、率直に言って、現在の実装は混乱しています。

現在、通信とオブジェクトがどのように実装されているかについての一般的な見方は次のとおりです。

ここには多くの問題があります。

1. Databaseやりすぎです。
2. これらのオブジェクトは、実際に読み取ったときに不変である可能性があります。唯一の問題は挿入後です。割り当てられたIDがわかりません。また、挿入されたオブジェクトは廃止されました。
3. クラスがから情報を取得する必要があるときはいつでも、Database特定のクエリを処理するために別のGetメソッドを追加する必要があります。

私はここで正しい実装がどうなるかについて本当に途方に暮れています。改善のための私の唯一の本当のアイデアは、データベースオブジェクトのある種の基本インターフェースですが、それは挿入にしか役立たないかもしれません...

これを実際に実装するための良い方法は何ですか？

私は実際の責任とは何かを理解しようとしているので、現在取り組んでいることの例を使用したいと思います。あるシステムから別のシステムに製品情報をインポートするアプリがあります。アプリのユーザーは、一方のシステムの製品フィールドでもう一方のシステムで使用するさまざまな設定を選択できます。

だから私にはProductImporterというクラスがあり、その責任は製品をインポートすることです。このクラスは大きいですが、おそらく大きすぎます。

このクラスのメソッドは複雑で、たとえばgetDescriptionになります。この方法は、単に他のシステムから説明を取得するのではなく、ユーザーが設定したさまざまな設定に基づいて製品の説明を設定します。説明を取得するための設定と新しい方法を追加すると、このクラスが変更される可能性があります。

それで、それは2つの責任ですか？製品を輸入するものと説明を得るものはありますか？私が持っているほとんどすべてのメソッドはそれ自身のクラスにあり、それはやり過ぎのように思えます。

完全に理解するのは難しいので、この原則をよく説明する必要があります。不必要な複雑さは望んでいません。

この目的のために、xml ファイルで特定のノードを検索し、見つかった場合は削除する必要があります。検索機能を独自のメソッドに引き出し、機能を削除して独自のメソッドにする必要がありますか? xmlファイルを一度検索して存在するかどうかを確認し、再度検索して削除するため、この方法ではより費用がかかるようです。これら 2 つの機能を 1 つのメソッドに組み合わせると、見つけたらすぐに削除できます。ここで SRP を正しく理解していますか?

SRPでは、「責任」は通常「変更する理由」として説明されるため、各クラス（またはオブジェクト？）には、誰かがそこに行って変更する必要がある理由が1つだけある必要があります。

しかし、これを非常にきめ細かくすると、2つの数値を足し合わせたオブジェクトは責任であり、変更する可能性のある理由であると言えます。したがって、オブジェクトには他のロジックが含まれていてはなりません。これは、変更の別の理由を生み出すためです。

少し客観的ではない単一責任の原則である「スコーピング」の戦略を持っている人がいるのではないかと思います。

定義されたインターフェイス GraphStructure に準拠する機能的な AdjacencyListGraph クラスがあります。これに対する制限 (たとえば、非循環、非 null、一意の頂点データなど) を階層化するために、それぞれ GraphStructure インターフェイスを使用する 2 つの可能なルートを確認できます。

1. 考えられるさまざまな制限を指定する一連のビットフラグを持つ単一のクラス (「ControlledGraph」) を作成します。このクラスのすべての制限を処理します。新しい制限要件が明らかになった場合は、クラスを更新してください。

2. デコレーター パターン (基本的には DI) を使用して、クライアント クラスが使用したい個々の制限ごとに個別のクラス実装を作成します。ここでの利点は、単一責任の原則を順守していることです。

私は後者の方に傾きますが、Jove! によると、私はデコレータ パターンが嫌いです。それはクラッターの縮図、IMOです。正直なところ、最悪の場合に適用される可能性のあるデコレータの数によって異なります。これまでの私の場合、カウントは 7 です (この段階で認識した個別の制限の数)。デコレーターのもう 1 つの問題は、すべての... 1 つの... デコレーター クラスでインターフェイス メソッドのラッピングを行う必要があることです。ああ。

どちらかだとしたら、どちらに行きますか？または、よりエレガントなソリューションを提案できる場合は、それを歓迎します。

編集: 提案された ControlledGraph クラスを戦略パターンで使用すると、ここで役立つ可能性があると思います...さまざまなグラフ標準インターフェイスメソッドで個別のビットを個別のコントロールに適用する、ある種のテンプレートメソッド/ファンクターのセットアップ。それとも私はプロットを失っていますか？

srp-2.1.2パッケージをダウンロードして、ubuntuでコンパイルしてみました。ただし、完全にコンパイルされるわけではありません。ubuntuでコンパイルする方法を教えてください。

エラー-

root @ ubuntu：〜/ Desktop / srp-2.1.2 / libsrp＃make

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c t_client.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c t_conf.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c t_conv.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c t_getpass.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c t_sha.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c t_math.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c t_misc.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c t_pw.c t_pw.c：関数't_changepw'内：

t_pw.c：468：警告：属性warn_unused_resultで宣言された「link」の戻り値を無視します

t_pw.c：470：警告：属性warn_unused_resultで宣言された「link」の戻り値を無視します

t_pw.c：関数't_deletepw'：

t_pw.c：540：警告：属性warn_unused_resultで宣言された「link」の戻り値を無視します

t_pw.c：542：警告：属性warn_unused_resultで宣言された「link」の戻り値を無視します

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c t_read.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c t_server.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c t_truerand.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c cstr.c

cstr.c：24：警告：互換性のないポインタ型からの初期化

cstr.c：24：警告：互換性のないポインタ型からの初期化

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c srp.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c rfc2945_client.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c rfc2945_server.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c srp6_client.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c srp6_server.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c yp_misc.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c yp_tpasswd.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c yp_tconf.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c nsw_tpasswd.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c nsw_tconf.c

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c nsswitch.c

rm -f libsrp.a

ar cru libsrp.a t_client.o t_conf.o t_conv.o t_getpass.o t_sha.o t_math.o t_misc.o t_pw.o

t_read.o t_server.o t_truerand.o cstr.o srp.o rfc2945_client.o rfc2945_server.o

srp6_client.o srp6_server.o yp_misc.o yp_tpasswd.o yp_tconf.o nsw_tpasswd.o nsw_tconf.o

nsswitch.o

ranlib libsrp.a

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c tconf.c

tconf.c：関数'main'内：

tconf.c：188：警告：属性warn_unused_resultで宣言された「fgets」の戻り値を無視します

tconf.c：202：警告：属性warn_unused_resultで宣言された「fgets」の戻り値を無視します

tconf.c：230：警告：属性warn_unused_resultで宣言された「fgets」の戻り値を無視します

tconf.c：263：警告：属性warn_unused_resultで宣言された「fgets」の戻り値を無視します

gcc -fPIC -O -o tconf tconf.o libsrp.a -lcrypto -ldl -lnsl

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c clitest.c

clitest.c：関数'main'内：

clitest.c：51：警告：属性warn_unused_resultで宣言された'gets'の戻り値を無視します

clitest.c：53：警告：属性warn_unused_resultで宣言された'gets'の戻り値を無視します

clitest.c：57：警告：属性warn_unused_resultで宣言された'gets'の戻り値を無視します

clitest.c：61：警告：属性warn_unused_resultで宣言された'gets'の戻り値を無視しますclitest.c：74：警告：属性warn_unused_resultで宣言された'gets'の戻り値を無視します

clitest.c：79：警告：属性warn_unused_resultで宣言された「gets」の戻り値を無視します

gcc -fPIC -O -o clitest clitest.o libsrp.a -lcrypto -ldl -lnsl clitest.o：関数 `main'内：

clitest.c:(。text+0x56）：警告： `gets'関数は危険であるため、使用しないでください。

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c srvtest.c

srvtest.c：関数'main'内：

srvtest.c：77：警告：属性warn_unused_resultで宣言された「gets」の戻り値を無視します

srvtest.c：103：警告：属性warn_unused_resultで宣言された「gets」の戻り値を無視します

srvtest.c：109：警告：属性warn_unused_resultで宣言された'gets'の戻り値を無視しますsrvtest.c：118：警告：属性warn_unused_resultで宣言された'gets'の戻り値を無視します

gcc -fPIC -O -o srvtest srvtest.o libsrp.a -lcrypto -ldl -lnsl

srvtest.o：関数 `main'内：

srvtest.c:(。text+0x15a）：警告： `gets'関数は危険であるため、使用しないでください。

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c getpwtest.c

gcc -fPIC -O -o getpwtest getpwtest.o libsrp.a -lcrypto -ldl -lnsl

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c srptest.c

gcc -fPIC -O -o srptest srptest.o libsrp.a -lcrypto -ldl -lnsl

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c srpbench.c

gcc -fPIC -O -o srpbench srpbench.o libsrp.a -lcrypto -ldl -lnsl

gcc-DHAVE_CONFIG_H-I。-私。-私。-fPIC -O -c srp6bench.c

srp6bench.c：関数'do_srp6preparam'：

srp6bench.c：197：警告：組み込み関数'exit'の互換性のない暗黙の宣言</p>

srp6bench.c：関数'usage'内：

srp6bench.c：214：警告：組み込み関数'exit'の互換性のない暗黙の宣言</p>

srp6bench.c：関数'main'内：

srp6bench.c：246：警告：組み込み関数'exit'の互換性のない暗黙の宣言</p>

gcc -fPIC -O -o srp6bench srp6bench.o libsrp.a -lcrypto -ldl -lnsl `

-

---

---

できるだけ早く問題がどこにあるか教えてください

ありがとう

こんにちはrobsnこの答えをありがとう。

makeを使用してlibsrpをコンパイルした後、libsrp.aを作成します。このlibsrp.aを共有ライブラリとして使用できますか？.dllimportを使用してubuntuのac＃ファイルでlibsrpを使用したいのですが。`

私はmakeを使用してubuntuでsrp-2.1.2をコンパイルしました、それはファイルlibsrp.aを作成します。libsrp.aを共有ライブラリとして使用する方法を教えてもらえますか？.dllimportを使用してubuntuのac＃ファイルでlibsrpを使用したいです。libsrp.aファイルの意味を教えてください。

ありがとう

nm -D libsrp.aを使用している場合は、

c2 @ ubuntu：〜/ Desktop / srp-2.1.2 / libsrp $ nm -D libsrp.a

t_client.o：nm：t_client.o：記号なし

すべての記号を取得する方法を教えてください。

ありがとう

CRUD (作成、読み取り、更新、および削除) 操作を行う UserServiceImpl クラスを設計しているとします。私の見解では、作成、読み取り、更新、および削除は、クラスが変更される 4 つの理由です。このクラスは単一責任の原則に違反していますか? 違反する場合はCreateUserServiceImpl、ReadUserServiceImpl、 、 UpdateUserServiceImpl、 のような 4 つのクラスが必要DeleteUserServiceImplです。授業が多いのはやり過ぎじゃない？

作成、読み取り、更新、および削除操作用にそれぞれ 4 つのインターフェースを定義し、サービス クラスが 4 つのインターフェースすべてを実装するとします。現在、実装クラスは 1 つしか持てませんが、それらのインターフェースを分離することで、アプリケーションの残りの部分に関する限り、概念を切り離しました。これは正しい方法ですか、それとも問題がありますか?

ウィキペディアでは、単一責任の原則について次のように説明しています。

単一責任の原則は、すべてのオブジェクトが単一の責任を持つべきであり、その責任はクラスによって完全にカプセル化されるべきであると述べています。そのすべてのサービスは、その責任と密接に連携する必要があります。

MVC でのコントローラーの従来の使用法は、プログラマーをこの原則に違反する方向に導くようです。シンプルなゲスト ブック コントローラーとビューを使用します。コントローラーには、1) Index() と 2) Submit() の 2 つのメソッド/アクションがある場合があります。Index() はフォームを表示します。Submit() がそれを処理します。これらの 2 つの方法は、2 つの異なる責任を表していますか? もしそうなら、単一の責任はどのように作用しますか?