タグ付けされた質問 「single-responsibility」

この例を考えてみましょう： ウェブサイトを持っています。これにより、ユーザーは投稿（何でも可能）を作成し、投稿を説明するタグを追加できます。コードには、投稿とタグを表す2つのクラスがあります。これらのクラスをPostおよびと呼びましょうTag。 Post投稿の作成、投稿の削除、投稿の更新など Tagを処理します。タグの作成、タグの削除、タグの更新などを処理します。 欠落している操作が1つあります。タグと投稿のリンク。私は誰がこの手術をすべきかと格闘しています。どちらのクラスにも等しく適合する可能性があります。 一方では、PostクラスにTagaをパラメーターとして受け取り、タグのリストに格納する関数を含めることができます。一方、Tagクラスが取る関数可能性がありPost、パラメータとして及びリンクTagにしますPost。 上記は私の問題の一例です。私は実際には、すべて類似した複数のクラスでこれに直面しています。それは両方に等しく適合する可能性があります。実際に両方のクラスに機能を配置するのではなく、この問題を解決するのに役立つ規則やデザインスタイルが存在します。私は1つを選ぶだけでは足りないものがあるはずだと思いますか？ たぶん両方のクラスに入れるのが正しい答えでしょうか？

11 design  design-patterns  coding-style  single-responsibility 

クラスが単一責任の原則に違反しているかどうかを確認するために人々が使用する実用的なテクニックは何ですか？ クラスには変更する理由が1つだけあるべきだと知っていますが、その文は実際にそれを実装する実用的な方法に少し欠けています。 私が見つけた唯一の方法は、「それは…………それ自体……」という文を使うことです。ここで、最初のスペースはクラス名で、後はメソッド（責任）名です。 ただし、責任が本当にSRPに違反しているかどうかを判断するのが難しい場合があります。 SRPを確認する方法は他にありますか？ 注意： 問題は、SRPの意味ではなく、SRPを確認して実装するための実際的な方法論または一連の手順です。 更新 SRPに明らかに違反するサンプルクラスを追加しました。単一の責任の原則にどのように取り組むかを説明するための例として、人々がそれを使用できれば素晴らしいと思います。 例はここからです。

11 design  design-patterns  object-oriented  refactoring  single-responsibility 

私はオブジェクト指向プログラミングに不慣れで、メインの目的が何なのかわかりません。 はい、私はそれがプログラムの「入り口」であると読みましたが、私が理解していないことは、メインに何があるべきかです。そして、その責任は何ですか？ メインで記述された何かが別のオブジェクトにカプセル化される可能性がありますが、このアプローチをどの程度使用する必要がありますか？ これが私がJavaで書いた最初のメインです。非常にシンプルですが、私の疑問をよりよく理解してくれるかもしれません。「Cat」と「Dog」によって拡張された抽象クラスAnimalがあります。メインを使用してオブジェクトを作成し、ユーザーとの「インターフェース」としても使用しました。実際に、条件付きの指示を使用して、ユーザーが何をしたいかを「ユーザーに尋ねる」ことができます。 私の質問は、インターフェイスが別のオブジェクトにカプセル化され、メインにその責任を与えないという事実から生じました。 public static void main(String[] args) { Scanner input = new Scanner(System.in); System.out.println("What type of animal do you want to create? \n dog cat"); String type = input.nextLine(); if ( Objects.equals(type, "dog")){ System.out.println("Enter the animal's age: "); int age = input.nextInt(); // Scans the next token …

10 java  object-oriented  programming-practices  single-responsibility  entry-point 

私には2つの基本クラスがOperationありTriggerます。それぞれに、特定のタイプの操作またはトリガーに特化したいくつかのサブクラスがあります。Aは、Trigger特定のトリガすることができますOperation。一方、Operation特定のによってトリガーできますTrigger。 特定のものOperationを特定のものにTrigger（またはその逆に）マップするコードを記述する必要がありますが、どこに配置するかわかりません。 この場合、コードは1つのクラスまたは他のクラスに明確に属していません。したがって、単一責任の原則に関しては、コードがどこに属すべきかわかりません。 私はすべてうまくいく3つのオプションを見ることができます。1と2は単なるセマンティクスの選択であるように見えますが、3は完全に異なるアプローチを表しています。 トリガー時、例えばbool Triggers(Operation o)。 操作について、例えばbool TriggeredBy(Trigger t)。 マッピングを管理するまったく新しいクラス、たとえばbool MappingExists(Trigger t, Operation o)。 単一の責任の原則に関して、共有マッピングコードを配置する場所をどのように決定すればよいですか？ 責任が共有されているときに単一の責任を管理するにはどうすればよいですか？ 編集1。 したがって、実際のコードは次のようになります。すべてのプロパティは、どちらかであるstring、Guid、collection<string>、またはenum。それらは基本的に小さなデータの一部を表すだけです。 編集2。 ブール型の戻り値の理由。別のクラスがのコレクションTriggerとのコレクションを使用しOperationます。との間のマッピングがどこにあるかを知る必要がTriggerありOperationます。その情報を使用してレポートを作成します。

10 object-oriented  single-responsibility 

私は最近、クリーンコードやSOLIDに関するさまざまなオンライン記事を読んでいますが、それについて読むほど、何も知らないように感じます。 ASP.NET MVC 3を使用してWebアプリケーションを構築しているUsersControllerとしましょう。たとえば、次のCreateようなアクションがあるとします。 public class UsersController : Controller { public ActionResult Create(CreateUserViewModel viewModel) { } } そのアクションメソッドでは、入力したデータが有効な場合、ユーザーをデータベースに保存します。 さて、単一の責任の原則に従って、オブジェクトは単一の責任を持つべきであり、その責任はクラスによって完全にカプセル化されるべきです。そのすべてのサービスは、その責任と厳密に一致している必要があります。検証とデータベースへの保存は2つの別々の責任であるため、次のようにそれらを処理するために別々のクラスを作成する必要があると思います。 public class UsersController : Controller { private ICreateUserValidator validator; private IUserService service; public UsersController(ICreateUserValidator validator, IUserService service) { this.validator = validator; this.service= service; } public ActionResult Create(CreateUserViewModel viewModel) { ValidationResult result …

10 object-oriented-design  solid  single-responsibility 

過去数か月、私はここSEや他のサイトの人々に、私のコードに関して建設的な批判をしてくれるように頼みました。ほぼ毎回飛び出し続けていることが1つあります。それでも、その推奨事項には同意しません。：P私はそれについてここで議論したいと思います、そして多分物事は私にとってより明確になるでしょう。 それは単一責任原則（SRP）に関するものです。基本的に、私はデータクラスを持っています。これは、データFontを操作するための関数だけでなく、データをロードするための関数も保持しています。ロードファンクションはファクトリクラス内に配置する必要があると、2つは分離する必要があると言われています。これはSRPの誤解だと思います... 私のフォントクラスの一部 class Font { public: bool isLoaded() const; void loadFromFile(const std::string& file); void loadFromMemory(const void* buffer, std::size_t size); void free(); void some(); void another(); }; 提案されたデザイン class Font { public: void some(); void another(); }; class FontFactory { public: virtual std::unique_ptr<Font> createFromFile(...) = 0; virtual std::unique_ptr<Font> createFromMemory(...) = …

10 design  c++  single-responsibility 

よりエレガントで、プロセッサをCommandProcessorDispatcherクラスに注入する方法を見つけたいです。または、別のソリューションにすることもできます（目標は、各コマンド処理ロジックを独立したクラスに分離することです）。たぶん、ここでいくつかのデザインパターンが役立ちます。 public interface ICommand { } public class StartCommand : ICommand { } public class StopCommand : ICommand { } public interface ICommandProcessor<in T> where T : ICommand { void Process(T command); } public class StartCommandProcessor : ICommandProcessor<StartCommand> { public void Process(StartCommand command) { } } public class StopCommandProcessor : …

10 design-patterns  object-oriented  .net  single-responsibility 

私は3つの基本的な手順を含む多くのコードを記述しています。 どこかからデータを取得します。 そのデータを変換します。 そのデータをどこかに置きます。 私は通常、それぞれの設計パターンに触発された3種類のクラスを使用します。 ファクトリー-あるリソースからオブジェクトを構築します。 メディエーター-ファクトリーを使用するには、変換を実行してから、司令官を使用します。 司令官-そのデータを別の場所に配置します。 私のクラスは非常に小さく、多くの場合単一の（パブリック）メソッドです。たとえば、データの取得、データの変換、作業の実行、データの保存などです。これはクラスの急増につながりますが、一般的にはうまく機能します。 私がテストに来るときに苦労しているのは、結局は密結合テストになります。例えば; 工場-ディスクからファイルを読み取ります。 Commander-ファイルをディスクに書き込みます。 もう1つがないとテストできません。ディスクの読み取り/書き込みを行うための追加の「テスト」コードを作成することもできますが、それから繰り返します。 .Netを見ると、Fileクラスは別のアプローチをとっており、（私の）ファクトリーとコマンダーの責任を組み合わせています。Create、Delete、Exists、Readの機能がすべて1か所にあります。 .Netの例をたどって、特に外部リソースを扱う場合は、クラスを一緒に結合する必要がありますか？結合されたコードですが、意図的です。テストではなく、元の実装で発生します。 ここでの問題は、単一責任の原則をやや熱心に適用したことですか？読み取りと書き込みを担当する個別のクラスがあります。特定のリソース（システムディスクなど）の処理を担当する結合クラスがある場合。

9 design  clean-code  single-responsibility 

このような： Campaign: type: object properties: id: type: string description: "A GUID identifier" referenceId: type: string description: "A consumers identifier they have used to map their own systems logic to this object." name: type: string description: "'Great Campaign 2017' as an example" referenceIdが心配です。 システムドメインは、さまざまな形式（xml、excel）のデータのエクスポートおよびインポートを通じて、サードパーティと多くの方法で統合されるプラットフォームです。サードパーティがAPIを介してシステムと統合できるように十分に成熟しており、このAPIの設計がこの疑問を引き起こします。 リソースを識別して取得するために使用できるIDを持つオブジェクト、キャンペーンがあります。APIの利用者は、ドメイン内のキャンペーンと見なすものへの独自の参照コードを持っている場合があります。 私たちのシステムには、このようなサードパーティの参照フィールドを持つ他のオブジェクトがあり、既存のコンシューマーから期待されています。ただし、マッピングの負担がかかり、このreferenceIdが何であるか（数値、テキスト、json？）がわからないため、新しいコンシューマー向けの混乱するプロパティがAPIに追加されます。 APIのパブリックオブジェクト定義でサードパーティの参照IDフィールドを許可することは、不適切な手法または不適切な設計と見なされますか？

9 rest  api  domain-driven-design  api-design  single-responsibility 

私は自分のインターフェース設計を見ていて、がアクセスしたいuserとを与えられた場合に、ロールベースのアクセス制御を実装するための最も「正しい」方法を決定するのに苦労しています。subjectuser 私が見る限り、3つのコアオプションがあります（4番目は最初の3つの粗野化、5番目は4番目の微調整です）。 がsubject持つ権限のリストを使用してをクエリしuserます-subject.allowAccess(user.getPermissionSet) に必要なuser権限のリストを使用してをクエリしsubjectます-user.hasPermissionTo(subject.getRequiredPermissions()) サードパーティにクエリを実行して、権限の共通部分を見つけます- accessController.doPermissionSetsIntersect(subject.permissionSet, user.getPermissionSet()) subject/のいずれかを照会しuser、「決定」をサードパーティのクラスに委任する 持ってuserアクセスしようとするとsubjectアクセスが許可されていない場合は、エラーをスローします 私はオプション4に傾いています- フィールドに操作を委託するための呼び出しをsubject含めるaccessControllerフィールドがありますsubject.userMayAccess(User user)。 class Subject { public function display(user) { if(!accessController.doPermissionSetsIntersect(this.permissionSet, user.getPermissionSet())) { display403(); //Or other.. eg, throw an error.. } } } ..しかし、これはさらに質問を引き起こします： accessControllerフィールド対静的クラスである必要があります。 必要がありますsubject 知っている必要とされるどのような権限は、それを表示することができますか？ 召喚に関して、知識の最小の原則はここでsubject.display()どこに作用しますか？呼び出し元はsubject.display()、アクセス制御が有効であることを知っている必要がありますか？（subject.display()最終的な「テンプレートメソッド」はどこにあるか） subject.display()アクセス制御を管理し、ユーザーが必要な権限を持っていない場合に例外をスローしますか？ この状況で何が「ベストプラクティス」と見なされますか？チェックを実行する責任は実際にどこで発生しますか？ これはどちらかと言えば実装に進む学術的な演習であるため、設計パターンへの参照をいただければ幸いです。

9 design  single-responsibility  access-control 

基本的に「必要なものだけを尋ねる」というインターフェースの設計と消費の原則を使用するようになりました。 たとえば、削除できるタイプがたくさんある場合は、Deletableインターフェイスを作成します。 interface Deletable { void delete(); } 次に、ジェネリッククラスを記述できます。 class Deleter<T extends Deletable> { void delete(T t) { t.delete(); } } コードの他の場所では、クライアントコードのニーズを満たすために可能な限り小さな責任を常に求めます。したがって、を削除するだけでよい場合Fileでも、Deletableではなくを要求しますFile。 この原則は常識であり、すでに受け入れられている名前ですか？物議を醸していますか？それは教科書で議論されていますか？

9 object-oriented  interfaces  solid  single-responsibility 

私はすっきりしたコードが大好きで、コードを可能な限り最善の方法でコーディングしたいと思っています。しかし、常に1つありましたが、本当に理解できませんでした。 メソッドに関する「懸念の分離」が多すぎるのはいつですか？ 次のメソッドがあるとします。 def get_last_appearance_of_keyword(file, keyword): with open(file, 'r') as file: line_number = 0 for line in file: if keyword in line: line_number = line return line_number この方法はそのままでも問題ないと思います。それはシンプルで読みやすく、そしてその名前が言うように、それは明らかにそうです。しかし、それは「ただ1つのこと」を実際に行っているのではありません。実際にファイルを開き、それを見つけます。それは私がそれをさらに分割できることを意味します（「単一の責任の原則」も考慮する）： バリエーションB（まあ、これは何となく理にかなっています。このようにして、テキスト内のキーワードの最後の出現を見つけるアルゴリズムを簡単に再利用できますが、「多すぎる」ように見えます。理由は説明できませんが、「感じる」 「それはそのように）： def get_last_appearance_of_keyword(file, keyword): with open(file, 'r') as text_from_file: line_number = find_last_appearance_of_keyword(text_from_file, keyword) return line_number def find_last_appearance_of_keyword(text, keyword): line_number = 0 …

9 single-responsibility  encapsulation  separation-of-concerns 

そのため、プログラミングコードインタビューに関するビデオシリーズを見て、単一の真の情報源という用語を見つけました。 私が理解したことから、それは真実の単一のソースが複数回使用される可能性のあるあらゆるタイプの操作/ロジックのカプセル化であることを意味しました。 SRPは、何度も使用される可能性のある特定の操作やロジックをカプセル化するという意味でほぼ同じものです。 ここで私が見逃している非常に微妙なものはありますか？ いつもありがとうございました。

9 single-responsibility  design-principles 

私は最近、以下のクラスに関して別の開発者との議論に入りました： public class GroupBillingPayment { public void Save(IGroupBillingPayment model) { if (model == null || UserInfo.UserID == 0) { throw new Exception("GroupBillingPayment object or Current User Id is NULL , Please Contact Administrator."); } Data.GroupBillingPayment groupBillingPayment = RepositoryManager.GroupBillingPaymentRepository.GetById(model.GroupBillingPaymentID); Mapper.Map(model, groupBillingPayment); ServiceManager.GroupBilling.IsBillAlreadyCancelled(groupBillingPayment.GroupBillingID, THROW_ERROR); groupBillingPayment.UpdatedBy = UserInfo.UserID; groupBillingPayment.UpdatedOn = DateTime.Now; RepositoryManager.GroupBillingPaymentRepository.Update(groupBillingPayment, false); …

8 design  design-patterns  object-oriented-design  single-responsibility 

C ++で物理シミュレーションプログラムを書いています。私はOOPとC ++の初心者です。 私のプログラムでは、入力ファイルのデータに基づいていくつかのオブジェクトを初期化する必要があります。 たとえば、架空の入力ファイル： # Wind turbine input file: number_of_blades = 2 hub_height = 120 # Airfoil data: airfoil1 = { chord = 2, shape = naca0012} airfoil2 = { chord = 3, shape = naca0016} この例では、TurbineクラスとAirfoilクラスがあるとします。翼オブジェクトは翼弦と形状を知る必要があり、タービンオブジェクトは翼の高さと数を知る必要があります。 各オブジェクトが入力ファイルから自分自身を構築できるように、これを行う必要がありますか？ 例えば： class Turbine { public: Turbine(File input_file); // reads input file …

8 design  object-oriented  c++  architecture  single-responsibility