タグ付けされた質問 「design-patterns」

現在、デザインパターンについて学習しています。 ほとんどの人はこれらのパターンが優れたツールであることに同意するだろうと思いますが、すべての答えとしてではなく、適度に使用する必要があります。これらを使いすぎると、アプリケーションが過度に複雑になり、ほとんどメリットがありません。パターンは、それらが最良のソリューションになるか、優れたソリューションの作成に役立つ場合にのみ使用する必要があります（同意しますか？）。 これを考慮して： 私が読んでいる本（Head First Design Patterns）は、疎結合の重要性を強調しています。この疎結合は、「実装ではなくインターフェイスへのプログラム」や「変化するものをカプセル化する」などの原則に従って達成されます。 基本的に、これまでに学んだほとんどのパターンは、デザインを疎結合にして、より柔軟にするために存在します。 疎結合の重要性と利点を理解しています。 しかし、私の質問は、疎結合で柔軟な設計を作成するために実際にどれだけの労力を費やすべきかということです。 設計パターンに反対する人々は、これらのパターンを使用するコストが利益を上回ることが多いと言います。いくつかのパターンを使用して疎結合設計を作成することに多くの時間を費やしますが、実際には、疎結合、「実装ではなくインターフェイスへのプログラミング」、およびこれらの原則のすべては、実際にはそれほど重要ではない可能性があります。 私が知りたいのは、抽象化とデザインの追加レベルを作成するために実際にどのくらいの努力を払うべきかということです。これは、アプリケーションが疎結合、インターフェイスへのプログラム機能などのオブジェクト指向の原則に従うことを許可するためだけです。それは本当に価値がありますかそれ？これにはどのくらいの努力が必要ですか？

10 design-patterns  object-oriented 

プログラム内のいくつかのイベントをログに記録する必要がありますが、プログラムの実際の機能に関するものではないため、ログコードをプログラムの外部に置いた方がよいでしょう。それで、コードから完全に除外し、オブザーバーとリスナーのみを使用してイベントをログに記録する必要があるかどうかを教えてもらえますか？または、何かをログに記録する必要がある場合はいつでも、次のようなコード行を追加できます。 MyGloriousLogger.getXXXLogger().Log(LogPlace, new LogObject(z1, z2, z3, z4, ..., z99)); Observer設計パターンを使用するのは間違いですか？別のデザインパターンが必要ですか？または私はデザインパターンについて考えるのをやめるべきですか？ PS1。リスナーとオブザーバーのみを使用してログを記録したい場合は、プログラムのオブザーバーとリスナーを追加して改善する必要があります。 PS2。Javaにログインするためのさまざまなライブラリがあり、java.utils.loggingを使用していることは確かですが、特別なオブジェクトをログに記録するためのラッパーが必要です。

10 java  design-patterns  logging  observer-pattern 

私は、管理者がフィールドを含むフォームを定義できるシステムに取り組んでいます。定義されたフォームは、システムにデータを入力するために使用されます。フォームは、GUIを介して人間が入力する場合もあれば、別のシステムから報告された値に基づいて入力される場合もあります。 各フィールドについて、管理者はフィールドに許可される値を制限する検証ルールを定義できます。検証ルールは、「フィールドに入力された値はTrueまたはFalseである必要があります」から「フィールドに入力された値はデータベースのテーブルBの列Aに存在している必要があります」まで、任意です。管理者はいつでもフィールドの検証ルールを変更できます。 このシナリオでは、各フィールドが正しく入力されていることを検証するのに最も適した場所は何だと思いますか？私は現在、主に2つのアプローチを考えています。 オプション＃1：ドメインモデルで検証する 各フィールドオブジェクトには、管理者が指定した検証ルールが含まれます。Fieldオブジェクトには、IValidatorへの参照も含まれます。フィールドの値を設定しようとすると、フィールドは指定された値と検証ルールをIValidatorに渡します。指定された値が有効でない場合、ValidationExceptionがスローされ、他のシステムへのGUI /インターフェイスで適切に処理されます。 長所： 検証ルールに違反するフィールドが誤って割り当てられたフィールドに対する強力な保護 短所： データアクセスレイヤーは、検証をバイパスし、現在の検証ルールに違反するフィールドを構築できる必要があります。管理者がフィールドの入力規則を変更しても、何年も前に入力されたフォームをレンダリングするときなど、古いデータに基づいてフィールドオブジェクトを構築できる必要があります。これは、フィールドを保存するたびに現在の検証ルールを保存することで解決できる可能性があります。 この設計では、フィールドモデルはIValidatorを介してデータアクセスレイヤー/リポジトリに間接的にリンクしています。ドメインモデルへのサービス/リポジトリの挿入は、一般的には嫌われているようです。 オプション＃2：サービスで検証する フィールドの値を設定するすべての試行が、検証ルールが確実に実行されるサービスを通過するようにしてください。検証ルールに違反している場合は、ValidationExceptionをスローします。 もちろん、以前はDBに永続化されていたFieldオブジェクトを作成する場合、データアクセス層はサービスを使用しません。 長所： 「サービス/リポジトリをドメインモデルに挿入しない」という考え方に違反していない。 フィールドを永続化するときに、現在の検証ルールを永続化する必要はありません。サービスは、フィールドの現在の検証ルールを単純に検索できます。履歴データを見ると、フィールドの値は変更されません。 短所： サービスを使用してフィールド値を設定する必要のあるすべてのロジックが実際にそうであるとは限りません。私はこれを大きな欠点だと考えています。誰かが「thisField.setValue（thatField.getValue（））」を書いているだけで、thisFieldの検証ルールに違反する可能性があります。これは、データアクセスレイヤーがフィールドを永続化しようとしているときに、フィールドの値が入力規則と一致するようにすることで軽減できる可能性があります。 私は現在、オプション＃2よりもオプション＃1を好みます。これは主にこれをビジネスロジックと見なしており、オプション＃2がシステムに不正なデータを導入するリスクが大きいと感じているためです。どちらのオプションを選択しますか、またはこのシナリオに適合する、説明した2つのオプションよりも優れた別のデザインはありますか？ 編集（検証の複雑さ） 現在のところ、検証ケースは比較的単純です。フィールド値は、数値、日付、時刻付きの日付、またはデータベース列の既存の値である必要があります。ただし、時間の経過とともに複雑さが徐々に増加すると思われます。たとえば、検証ソリューションは国際化を念頭に置いて構築する必要があります。日付などはロケール固有の構文で入力できます。 ここでは、オプション1に進むことを決定しました。ドメインモデルに多くの責任を割り当てないように注意してください。同様の状況に直面している人は、関連する質問を確認することもできます。階層化アーキテクチャでの検証と承認およびデータ入力検証-どこですか？いくら？。

10 design-patterns  architecture  domain-driven-design  validation 

私は戦略パターンを理解しようとして自分自身に問いかけています。コンテキストクラスはなくてはならないのですか、それともパターンの目的を損なうことなく省略できますか？ さまざまな種類のファイルを読み取るためになんらかのスイッチが必要であるという印象を受けましたが、何かをハックして後でリファクタリングを処理したくありませんでした（もちろん、コードは常にリファクタリングされる可能性がありますが、アイデアは：設計をできるだけスマートにするために...）： ウィキメディアから撮影した画像 クライアントはストラテジーインターフェイスに直接委任できますか、それともコンテキストクラスについて理解できなかったことがありますか？ interface Reader { // read information from file and fill data list field of Client readFile(); } class ExcelReader implements Reader{ /* */ } class PdfReader implements Reader{ /* */} class Client{ // strategic choice Reader r; // data list field List<Data> data; // Client Constructor …

10 design-patterns  strategy 

「細いコントローラー、ファットモデル」の概念と、出力用のデータが必要な場合にビューがモデルを直接呼び出すことができるという一般的な受け入れを考えると、コントローラーではなくビュー内のリクエストの「取得と表示」部分の処理を検討する必要がありますか？例（コードをかなり一般的なものにしようとする）： コントローラ <?php class Invoice extends Base_Controller { /** * Get all the invoices for this month */ public function current_month() { // as there's no user input let's keep the controller very skinny, // DON'T get data from the Model here, just load the view $this->load->view('invoice/current_month'); } } 見る …

10 php  design-patterns  mvc 

フラグメントを操作するときは、フラグメントのアクションを定義する静的メソッドで構成されるクラスを使用しています。どのようなプロジェクトでもFragmentActions、次のようなメソッドを含むというクラスがあるかもしれません。 public static void showDeviceFragment(FragmentManager man){ String tag = AllDevicesFragment.getFragmentTag(); AllDevicesFragment fragment = (AllDevicesFragment)man.findFragmentByTag(tag); if(fragment == null){ fragment = new AllDevicesFragment(); } FragmentTransaction t = man.beginTransaction(); t.add(R.id.main_frame, fragment, tag); t.commit(); } 通常、アプリケーション画面ごとに1つのメソッドがあります。小さなローカルデータベース（通常はSQLite）で作業するときは、このようなことを行うので、それをフラグメントに適用しました。フラグメントには同様のワークフローがあるようです。私はそれと結婚していません。 Fragments APIとインターフェースするようにアプリケーションをどのように編成しましたか。また、どのようなデザインパターン（ある場合）を適用すると思いますか？

10 design-patterns  android 

私のコードに次のような関数がある場合： class Employee{ public string calculateTax(string name, int salary) { switch (name) { case "Chris": doSomething($salary); case "David": doSomethingDifferent($salary); case "Scott": doOtherThing($salary); } } 通常、これをリファクタリングして、ファクトリクラスと戦略パターンを使用してPloymorphismを使用します。 public string calculateTax(string name) { InameHandler nameHandler = NameHandlerFactory::getHandler(name); nameHandler->calculateTax($salary); } TDDを使用している場合は、calculateTax()リファクタリングの前にオリジナルで機能するテストをいくつか用意します。 例： calculateTax_givenChrisSalaryBelowThreshold_Expect111(){} calculateTax_givenChrisSalaryAboveThreshold_Expect111(){} calculateTax_givenDavidSalaryBelowThreshold_Expect222(){} calculateTax_givenDavidSalaryAboveThreshold_Expect222(){} calculateTax_givenScottSalaryBelowThreshold_Expect333(){} calculateTax_givenScottSalaryAboveThreshold_Expect333(){} リファクタリング後、FactoryクラスNameHandlerFactoryと少なくとも3つのの実装ができInameHandlerます。 テストをリファクタリングするにはどうすればよいですか？の単体テストを削除して、実装ごとにTestクラスを作成する必要claculateTax()がEmployeeTestsありますInameHandlerか？ Factoryクラスもテストする必要がありますか？

10 design  design-patterns  unit-testing  tdd  refactoring 

ほとんどの場合、特定の関数呼び出しの応答を処理するコードを書いているとき、次のコード構造が得られます。 例：これはログインシステムの認証を処理する関数です class Authentication{ function login(){ //This function is called from my Controller $result=$this->authenticate($username,$password); if($result=='wrong password'){ //increase the login trials counter //send mail to admin //store visitor ip }else if($result=='wrong username'){ //increase the login trials counter //do other stuff }else if($result=='login trials exceeded') //do some stuff }else if($result=='banned ip'){ //do …

10 design  php  design-patterns  object-oriented  clean-code 

私はデザインパターンについて調べていましたが、プロトタイプのデザインパターンでは、過度のサブクラス化をなくすことができました。 サブクラス化が悪いのはなぜですか？プロトタイプを使用すると、サブクラス化に対してどのような利点がありますか？

10 design-patterns  inheritance 

私は最近、文芸的プログラミングの概念を見つけました。そして、私はそれがかなり興味深いと感じました。それでも、プログラムを構成するのは悪い方法であるという主張には遭遇していません。多くの場所をカバーしていないようです。ここでさえこれに関する質問を見つけることができませんでした。 私の質問は、その欠陥やドキュメントの処理方法についてではありません。ドキュメンテーションは、文芸的プログラミングの流れにとってそれが何を意味するのかという副作用だと考えています。この設計はもともと、簡単な文書化とフォワードプログラミングフローの概念を目的としたものでした。 問題を小さな文ベースの問題に分割するという概念は、本当に素晴らしいアイデアのようです。これにより、プログラムの流れの理解が容易になります。 文芸的設計法の結果として、必要な機能の数はプログラマーの想像力に制限されます。特定のタスクの関数を定義する代わりに、それをscrap文芸的メソッドとして作成することができます。これにより、個別の関数コンパイルの代わりにコードが自動的に挿入され、同等の速度を得るために手続き間コンパイルの最適化ステップが必要になります。実際、ドナルドE.クヌースの最初の試みは、この事実のために実行時間が劣っていました。私はコンパイラがこれの多くに作られることができることを知っています、しかしこれは私の心配ではありません。 それで、なぜこれが悪い/良い設計方法論であると考える必要があるのか​​についてフィードバックを得たいですか？

10 design-patterns  language-design  literate-programming 

古典的なObserverパターンインターフェイスを定義する2つの抽象クラスSubjectとObserverを作成しました。オブザーバーパターンを実装するためにそれらから派生しています。オブザーバーは次のようになります。 void MyClass::Update(Subject *subject) { if(subject == myService_) { DoSomething(); } else if(subject == myOtherService_) { DoSomethingElse(); } } これは問題なく、誰が何かを変更したかがわかります。ただし、何が変わったのかはわかりません。サブジェクトに最新のデータを照会するだけでよい場合もありますが、サブジェクトで何が変更されたかを正確に知る必要がある場合もあります。Javaでは、おそらく何が変更されたかの詳細を指定するために、notifyObservers（）メソッドとnotifyObservers（Object arg）メソッドの両方があることに気づきました。 私の場合、サブジェクトでいくつかの異なるアクションの1つが発生したかどうかを知り、それが特定のアクションである場合は、そのアクションに関連する整数を知る必要があります。 だから私の質問は： （Javaのように）汎用的な引数を渡すC ++の方法は何ですか？ オブザーバーは最高のパターンですか？多分ある種のイベントシステム？ 更新 Observerパターンのテンプレート化について説明しているこの記事を見つけました：テンプレートを使用したSubject / Observerパターンの実装。これは、あなたが議論をテンプレート化できるかどうか疑問に思いました。 引数のテンプレート化に関するこのスタックオーバーフローの質問が見つかりました：テンプレートベースのサブジェクトオブザーバーパターン-static_castまたはdynamic_castを使用する必要があります。しかし、OPには誰も答えていない問題があるようです。 もう1つの方法は、Updateメソッドを変更して、次のようにEventArgオブジェクトを取得することです。 void MyClass::Update(Subject *subject, EventArg arg) { ... 次に、特定の引数データ用にEventArgのサブクラスを作成し、それをupdateメソッド内の特定のサブクラスにキャストし直したと思います。 アップデート2 また、非同期メッセージベースのc ++フレームワークの作成に関する記事も見つかりました。何が変わったかについての詳細を被験者に伝えることを論じるパート2 Boost.Signalsの使用を真剣に検討しています。自分のオブザーバーパターンを使用することは、それが単純な場合には理にかなっていますが、型と引数のテンプレート化は複雑になり始めています。そして、Boost.Signals2のスレッドセーフが必要になる場合があります。 アップデート3 オブザーバーパターンに関する興味深い記事もいくつか見つかりました。 ハーブサッターによるオブザーバーの一般化 C ++でのオブザーバーパターンの実装-パート1 Observerデザインパターンの実装の経験（パート2） …

10 c++  design-patterns  observer-pattern 

イベントリスナーアプローチが必要であることを示すコードベースの症状は何ですか？ 他のクラスのデザインタイムセットでは定義されていない、複数で呼び出す必要があるクラスがある場合、何らかのシグナリングフレームワークが必要ですが、他にどのような状況があるのか​​聞きたいですイベントベースのモデルに変更することで改善されました。

10 architecture  design-patterns  code-smell 

（この質問は、「広すぎる」および「本当の質問ではない」ため、Stack Overflowで締めくくられたため、ここでより適切でしょうか？） この質問に触発されました。イベントは、Observerパターンの言語レベルの実装であることを知っています。C＃の言語機能として実装されている他のデザインパターンはありますか？他の言語で実装されたデザインパターンはたくさんあるので、この質問はC＃固有のままにしておきたいです。 BCLのパターン実装（多くのWCFクラスのデコレーターやのファクトリーメソッドなどWebClient）ではなく、言語レベルのパターンを探しています。 これまでのところ、オブザーバー（event）とイテレーター（foreach多くのBCLクラスおよびインターフェースとの組み合わせ）を認識しています。私が見逃している明らかなものはおそらく他にもあります。

10 c#  .net  design-patterns 

姪にデザインのパターンを説明したいのですが、いつも苦労しています。それは主に、デザインパターンを明確に理解していないためです。MVC、シングルトン、ファクトリー、リポジトリなどのパターンを、10歳の子供でも理解できるような簡単な言葉で説明するにはどうすればよいですか。 パターンの理解を助けるのに役立つ例を探しています。おもちゃ、映画、音楽などの例

10 design-patterns 

デザイン内の他のクラスを管理する集中型クラスを作成する傾向があります。それ自体はすべて保存されませんが、ほとんどのデータ要求は最初に「マネージャー」に送信されます。この質問への答えを見ていると、「神のオブジェクト」という言葉に気づきました。ウィキペディアは、それを当然のことながらアンチパターンとしてリストしています。 データとメッセージを場所から場所へと渡す正当な接着剤クラスまたはモジュールと、やり過ぎているクラスとの間の境界はどこにありますか？

10 design  design-patterns  anti-patterns