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

アジャイルなソフトウェア開発とすべての原則（SRP、OCPなど）を考えるとき、ロギングをどのように扱うかを自問します。 実装の隣のロギングはSRP違反ですか？ yes実装はロギングなしで実行することもできるはずだからです。それでは、より良い方法でロギングを実装するにはどうすればよいですか？いくつかのパターンを確認し、ユーザー定義の方法で原則に違反するのではなく、原則に違反することが知られているパターンを使用する最良の方法は、デコレータパターンを使用することであるという結論に達しました。 SRP違反のない完全に多数のコンポーネントがあり、ロギングを追加するとします。 コンポーネントA コンポーネントBはAを使用します Aのロギングが必要なので、Aで装飾された別のコンポーネントDを作成し、両方ともインターフェースIを実装します。 インターフェースI コンポーネントL（システムのロギングコンポーネント） コンポーネントAはIを実装します コンポーネントDはIを実装し、Aを装飾/使用し、ロギングにLを使用します コンポーネントBはIを使用します 利点：-ロギングなしでAを使用できます-Aをテストすると、ロギングモックが不要になります-テストが簡単になります 欠点：-より多くのコンポーネントとより多くのテスト これはもう1つの公開討論の質問のように思えますが、デコレータやSRP違反よりも優れたログ戦略を誰かが使用しているかどうかを実際に知りたいです。デフォルトのNullLoggerであり、syslogロギングが必要な場合、実行時に実装オブジェクトを変更する静的シングルトンロガーはどうでしょうか。

19 design-patterns  logging  single-responsibility  decorator 

2つの異なるクラスから継承するクラスがある場合、これはサブクラスが（少なくとも）2つのことを自動的に行うことを意味しないのですか？各スーパークラスから1つですか？ 複数のインターフェイス継承がある場合、違いはないと思います。 編集：明確にするために、複数のクラスをサブクラス化するとSRPに違反する場合、複数の（マーカーまたは基本インターフェイス（Comparableなど））インターフェイスの実装もSRPに違反すると考えています。

18 object-oriented  object-oriented-design  single-responsibility  multiple-inheritance 

ロバートC.マーティンによると、SRPは次のよ​​うに述べています。 クラスが変更される理由は1つだけです。 ただし、彼の本Clean Code、第3章：関数では、次のコードブロックを示しています。 public Money calculatePay(Employee e) throws InvalidEmployeeType { switch (e.type) { case COMMISSIONED: return calculateCommissionedPay(e); case HOURLY: return calculateHourlyPay(e); case SALARIED: return calculateSalariedPay(e); default: throw new InvalidEmployeeType(e.type); } } そして次のように述べます： この機能にはいくつかの問題があります。まず、それは大きく、新しい従業員タイプが追加されると成長します。第二に、非常に明確に複数のことを行います。第三に、変更する理由は複数あるため、単一責任原則（SRP）に違反しています。[強調鉱山] まず、SRPはクラスに対して定義されていると思いましたが、関数にも適用できることがわかりました。第二に、この関数には複数の変更理由がありますか？従業員の変更が原因で変更が確認できます。

17 design-patterns  single-responsibility 

「ユーザーにとって魅力的な」デザインをデザインしたい2人のUIデザイナーを考えてみましょう。「ユーザーの魅力」は、客観的ではなく、デザイナーの心の中にのみ存在する概念です。したがって、デザイナーAはたとえば赤を選択し、デザイナーBは青を選択できます。デザイナーAは、デザイナーBとはまったく異なるレイアウトを作成します。 SRP（Single Responsibility Principle）について読みましたが、私が理解したのは、OOデザイナーから別のOOデザイナーまでさまざまな主観的な分析または責任の内訳です。私は正しいですか？言い換えれば、SRPプリンシパルに基づいて1つのシステムに対して2つの異なる設計を思いつく2つの優れたオブジェクト指向アナライザーとデザイナーを使用することは可能ですか？

17 object-oriented  object-oriented-design  single-responsibility  ooda 

単一責任原則は、「クラスには変更の理由が1つあるべきだ」と述べています。 MVCパターンでは、コントローラーの仕事は、ビューとモデルの間を仲介することです。GUIでユーザーが行ったアクションをレポートするためのビューのインターフェースを提供し（ビューの呼び出しを許可するcontroller.specificButtonPressed()など）、データを操作したり操作を呼び出すためにモデルの適切なメソッドを呼び出すことができます（例model.doSomething()） 。 この意味は： ビューにユーザーアクションを報告するための適切なインターフェイスを提供するために、コントローラーはGUIについて知る必要があります。 また、モデルの適切なメソッドを呼び出すことができるように、モデルのロジックについて知る必要があります。 つまり、GUIの変更とビジネスロジックの変更という2つの理由があります。 GUIが変更された場合（新しいボタンが追加された場合など）、コントローラーは、ユーザーがこのボタンを押したことをビューが報告できるように新しいメソッドを追加する必要がある場合があります。 また、モデルのビジネスロジックが変更された場合、モデルの正しいメソッドを呼び出すためにコントローラーを変更する必要があります。 そのため、Controllerには2つの変更可能な理由があります。SRPを壊しますか？

16 design  object-oriented  mvc  single-responsibility 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 約100行にわたる関数を作成しました。それを聞いて、あなたはおそらく私に単一の責任について教えて、私にリファクタリングを促すように誘惑されるでしょう。これは私の本能でもありますが、問題は次のとおりです。関数は 1つのことを行います。複雑な文字列操作を実行し、関数の本体は主に1つの冗長な正規表現で構成され、文書化された多くの行に分割されます。正規表現を複数の関数に分割すると、実際に言語を切り替えているため、実際に読みやすさが失われ、正規表現が提供する一部の機能を利用できなくなるためです。ここに私の質問があります： 正規表現を使用した文字列操作に関しては、大きな関数本体は依然としてアンチパターンですか？名前付きキャプチャグループは、機能と非常に似た目的を果たしているようです。ところで、正規表現を通るすべてのフローのテストがあります。

15 programming-practices  refactoring  anti-patterns  regular-expressions  single-responsibility 

たとえば、コンソールとの間のあらゆる種類の入出力メソッドを備えたコンソールゲームプログラムがあるとします。でしょうが、すべてのシングルでそれらを保つためにスマートにinputOutputクラスなど、より具体的なクラスにそれらを打破startMenuIO、inGameIO、playerIO、gameBoardIO各クラスが1-5程度のメソッドを持っていることなど、？ また、同じメモで、それらを分解する方が良い場合は、IO名前空間に配置して、呼び出しをもう少し冗長にするのが賢明でしょうIO.inGameか？

14 design-patterns  object-oriented  class-design  solid  single-responsibility 

2500行のCharacterクラスがあります。 ゲーム内のキャラクターの内部状態を追跡します。 その状態をロードして永続化します。 〜30個の着信コマンドを処理します（通常=に転送しますGameが、一部の読み取り専用コマンドはすぐに応答します）。 Game実行中のアクションと他のユーザーの関連アクションに関する〜80の呼び出しを受け取ります。 私にCharacterは、単一の責任があるように思われます。キャラクターの状態を管理し、受信コマンドとゲームを仲介することです。 既に分割されている他のいくつかの責任があります。 CharacterOutgoingクライアントアプリケーションの発信更新を生成するために呼び出すがあります。 Characterは、Timer次に何ができるかを追跡するを持っています。着信コマンドはこれに対して検証されます。 だから私の質問は、SRPや同様の原則の下でこのような大規模なクラスを持つことは容認できますか？煩雑さを軽減するためのベストプラクティスはありますか（メソッドを個別のファイルに分割するなど）。それとも、私は何かを見逃していますか？それを分割する本当に良い方法はありますか？これは非常に主観的なものであり、他の人からのフィードバックが欲しいと思います。 サンプルを次に示します。 class Character(object): def __init__(self): self.game = None self.health = 1000 self.successful_attacks = 0 self.points = 0 self.timer = Timer() self.outgoing = Outgoing(self) def load(self, db, id): self.health, self.successful_attacks, self.points = db.load_character_data(id) def save(self, db, id): db.save_character_data(self, health, self.successful_attacks, self.points) …

13 object-oriented  class-design  single-responsibility 

SOLIDの調査を始めたばかりで、ファイルの読み取りとファイルへの書き込みが同じ責任であるかどうかはわかりません。 ターゲットは同じファイルタイプです。アプリケーションで.pdfを読み書きしたい。 それが違いを生む場合、アプリケーションはPythonです。

13 object-oriented-design  solid  single-responsibility 

エンティティの単一の責任（変更する理由）は、それ自体を一意に識別することである必要があります。言い換えると、その責任を見つけられるようにすることです。 エリックエヴァンのDDDの本、ページ。93： エンティティの最も基本的な責任は、動作が明確で予測可能なように継続性を確立することです。彼らは予備にされている場合、彼らはこれを最善にします。属性や動作に焦点を当てるのではなく、Entityオブジェクトの定義を最も本質的な特性、特にそれを識別する、またはそれを検索または一致させるために一般的に使用される特性まで取り除きます。その動作に必要な概念と属性に不可欠な動作のみを追加します。 それを超えて、コアエンティティに関連付けられた他のオブジェクトへの動作と属性を削除することを検討してください。 1。 ... ENTITYオブジェクトの定義を最も本質的な特性、特にそれを識別する、またはそれを検索または一致させるために一般的に使用される特性まで取り除きます。コンセプトに不可欠な動作のみを追加します... いったんエンティティが割り当てられている固有のIDを、そのアイデンティティが確立され、私はそのような実体がするいかなる行動を必要としないと仮定しますので、そのアイデンティティを維持したりするために、それは自分自身を識別するのに役立ちます。したがって、著者が「概念に不可欠な振る舞い」findとはどのような振る舞いを参照しているのか理解できません（およびmatch 操作以外）。 2。 ... ENTITYオブジェクトの定義を最も本質的な特性、特にそれを識別する、またはそれを検索または一致させるために一般的に使用される特性まで取り除きます。...さらに、動作と属性を削除して、コアENTITYに関連付けられている他のオブジェクトを探します。 そのため、エンティティを特定するのに役立たないが、そのエンティティの固有の特性として行動を特徴付けます（つまり、characterえは犬に固有、飛行は飛行機に固有、産卵は鳥に固有です。） 。）、そのエンティティに関連付けられている他のオブジェクトに配置する必要があります（例：犬のエンティティに関連付けられているオブジェクトにbarえる動作を配置する必要があります）？ 3。 それを超えて、コアENTITYに関連付けられた他のオブジェクトの動作と属性を削除してください。 a）MyEntity責任A_respをおよびにそれぞれ委任B_respします。ab ほとんどのにもかかわらずA_respとB_resp仕事をすることによって行われa、およびbインスタンス、クライアントはまだ提供されているA_respとB_resp通じMyEntityクライアントの観点から二つの責任はに属していることを意味しています、MyEntity。したがって、それはMyEntityまたA_resp、B_resp責任と責任を持っていることを意味していないので、SRPに違反していますか？ B）私たちがいることを前提としていてもA_respとB_respに属していないMyEntity、MyEntityまだ責任があるAB_respオブジェクトの動作を調整するにaしてb。そうしないMyEntity違反SRPを最低でも、それは持っているので、2つの責任を一意に自身を識別し、またして- AB_resp？ class MyEntity { private A a = ... private B b = ... public A GetA() { ... } public B GetB() { ... } /* coordinates operations of objects …

13 domain-driven-design  single-responsibility 

いくつかのベースポイント： Pythonのメソッド呼び出しは、その解釈された性質により「高価」です。理論的には、コードが十分に単純な場合、Pythonコードの分解は、読みやすさと再利用に加えてマイナスの影響を及ぼします（これは、ユーザーにとってはそれほどではなく、開発者にとって大きな利益です）。 単一責任原則（SRP）は、コードを読み取り可能に保ち、テストと保守が容易です。 プロジェクトには、読み取り可能なコード、テスト、および時間パフォーマンスが必要な特別な種類の背景があります。 たとえば、いくつかのメソッド（x4）を呼び出すこのようなコードは、次のメソッド（1つ）よりも低速です。 from operator import add class Vector: def __init__(self,list_of_3): self.coordinates = list_of_3 def move(self,movement): self.coordinates = list( map(add, self.coordinates, movement)) return self.coordinates def revert(self): self.coordinates = self.coordinates[::-1] return self.coordinates def get_coordinates(self): return self.coordinates ## Operation with one vector vec3 = Vector([1,2,3]) vec3.move([1,1,1]) vec3.revert() vec3.get_coordinates() これと比較して： from …

12 python  performance  single-responsibility  methods 

例 データベースからデータをロードし、HTMLマークアップを表示し、ルーター/コントローラー/アクションとして機能する「すべて」を行うモノリシックコードに出会いました。データベースコードを独自のファイルに移動するSRPを適用し始め、物事の命名を改善しましたが、すべてが見栄えが良かったのですが、なぜこれを行っているのか疑問に思い始めました。 リファクタリングする理由 目的は何ですか？役に立たない？利点は何ですか？モノリシックファイルはほとんどそのままにしておきましたが、作業を行う必要がある領域に関連する小さな部分のみをリファクタリングしたことに注意してください。 元のコード： 具体的な例を挙げると、このコードスニペットに出会いました。既知の製品IDまたはユーザーが選択したバージョンIDのいずれかで製品仕様を読み込みます。 if ($verid) $sql1 = "SELECT * FROM product_spec WHERE id = " . clean_input($verid); else $sql1 = "SELECT * FROM product_spec WHERE product_id = " . clean_input($productid) ; $result1 = query($sql1); $row1 = fetch_array($result1); /* html markup follows */ リファクタリング： この特定のコード部分を変更する必要がある作業を行っているため、リポジトリパターンを使用するように変更し、オブジェクト指向のMySQL機能を使用するようにアップグレードしました。 //some implementation details …

12 php  refactoring  solid  single-responsibility 

注：コードサンプルはc＃で記述されていますが、それは問題ではありません。適切なものを見つけることができないため、c＃をタグとして配置しました。これはコード構造についてです。 Clean Codeを読んで、より良いプログラマーになろうとしています。 私はしばしば、単一の責任原則（クラスと関数は1つのことだけを行うべきです）、特に関数に従うことに苦労しています。たぶん私の問題は、「一つのこと」が明確に定義されていないことですが、それでも... 例：データベースにFluffiesのリストがあります。Fluffyが何であるかは気にしません。クラスに綿毛を回復させたい。ただし、綿毛はいくつかのロジックに従って変化する可能性があります。いくつかのロジックに応じて、このクラスはキャッシュからデータを返すか、データベースから最新のデータを取得します。毛羽立ちを管理していると言えますが、それは一つのことです。簡単にするために、ロードされたデータが1時間有効であり、それを再ロードする必要があるとしましょう。 class FluffiesManager { private Fluffies m_Cache; private DateTime m_NextReload = DateTime.MinValue; // ... public Fluffies GetFluffies() { if (NeedsReload()) LoadFluffies(); return m_Cache; } private NeedsReload() { return (m_NextReload < DateTime.Now); } private void LoadFluffies() { GetFluffiesFromDb(); UpdateNextLoad(); } private void UpdateNextLoad() { m_NextReload = DatTime.Now …

12 c#  database  object-oriented-design  caching  single-responsibility 

ビューモデルでIValidatableObjectを実装し、カスタム検証を追加できるようにするMVCの拡張ポイントが気に入っています。 このコードを唯一の検証ロジックにして、コントローラーを無駄のないものにしようとしています。 if (!ModelState.IsValid) return View(loginViewModel); たとえば、ログインビューモデルはIValidatableObjectを実装し、コンストラクターインジェクションを介してILoginValidatorオブジェクトを取得します。 public interface ILoginValidator { bool UserExists(string email); bool IsLoginValid(string userName, string password); } ビューモデルにインスタンスを注入するNinjectは、実際には一般的な慣行ではないようです。 これは良いアプローチですか？より良いものはありますか？

12 architecture  asp.net-mvc  dependency-injection  validation  single-responsibility 

私は単一責任原則（SRP）に準拠し、コードの繰り返しを省略しようとします。しかし、少なくとも意味のある名前付きメソッドへの抽出に抵抗する呼び出しのコードブロックにすぎないコードの繰り返しがある場所がしばしばあります。 DoAction1(); DoAction2(); if (value) DoAction3(); DoAction4(); そのようなコードをメソッドに抽出する最良の方法とその命名方法は何ですか？

11 refactoring  readability  single-responsibility  code-reuse