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

Open Closed Principle（OCP）とDependency Inversion Princible（DIP）の違いを理解しようとしていました。 これまでにインターネットで行った調査に基づいて、「DIPはOCPを達成するための1つのオプション」という結論に達しました。 これでいいの？ DIPではなくOCPに従っている例を教えてください。

12 design-patterns  object-oriented  object-oriented-design  solid 

依存性注入は初めてなので、アプリケーションでどのスタイルを使用すべきかについていくつか質問があります。Martin FowlerによるInversion of Control ContainersとDependency Injectionパターンを読んだばかりですが、コンストラクター、セッター、インターフェースインジェクションの実際の違いを理解することはできません。 どちらか一方を使用する理由は、コードのクリーニングおよび/または明快さの問題だけであるように思えます。違いはなんですか？あるものを他のものよりも使用することの強力な長所または短所はありますか、それとも前に述べたとおりですか？ 私の意見では、コンストラクター注入はすべての中で最も直感的であり、インターフェース注入は最も少ないです。一方、セッターインジェクションは中期ですが、最初にインジェクトした依存関係オブジェクトのインスタンスを変更できるはずですか？このスタイルの注入は、依存関係を必要とするオブジェクトが常に注入されることを保証しますか？私はそうは思わないが、私が間違っているなら私を修正してください。

12 design-patterns  dependency-injection  inversion-of-control 

私はHTTP APIの設計を進めており、できればできるだけRESTfulにするようにしています。 機能がいくつかのリソースに広がるアクションがいくつかあり、いつか元に戻す必要があります。 これはコマンドパターンのように思えますが、どのようにリソースにモデル化できますか？ DepositActionのようなXXActionという名前の新しいリソースを紹介します。 POST /card/{card-id}/account/{account-id}/Deposit AmountToDeposit=100, different parameters... これにより、実際に新しいDepositActionが作成され、そのDo / Executeメソッドがアクティブになります。この場合、201 Created HTTPステータスを返すことは、アクションが正常に実行されたことを意味します。 後でクライアントができるアクションの詳細を確認したい場合 GET /action/{action-id} Update / PUTはここでは関係ないため、ブロックする必要があります。 そして、アクションを元に戻すために、私は DELETE /action/{action-id} 実際に関連オブジェクトのUndoメソッドを呼び出し、そのステータスを変更します。 やり直しが1回だけで満足だとしましょう。やり直す必要はありません。 このアプローチは大丈夫ですか？ 落とし穴、それを使用しない理由はありますか？ これはクライアントのPOVから理解されていますか？

12 design-patterns  api  rest  api-design  http 

最近、シングルトンに対する何らかの革命がありましたが、それらがステートレスである場合、シングルトンに何か問題がありますか？ 私は酷使の話とすべてを知っています...これはシングルトンだけでなくすべてに適用されます。

12 design-patterns  object-oriented  singleton  immutability 

私は産業環境でバルブを開閉するために使用されるアプリを開発しており、このような単純なことを考えていました：- public static void ValveController { public static void OpenValve(string valveName) { // Implementation to open the valve } public static void CloseValve(string valveName) { // Implementation to close the valve } } （実装は、バルブを制御するためにシリアルポートに数バイトのデータを書き込みます-バルブ名から派生した「アドレス」、およびバルブを開閉する「1」または「0」）。 別の開発者は、代わりに物理的なバルブごとに個別のクラスを作成するかどうかを尋ねました。のようなコードを書く方が良いと思いますPlasmaValve.Open()がValveController.OpenValve("plasma")、これはやり過ぎですか？ また、私はいくつかの仮説的な将来の要件を念頭に置いて設計に取り組む最善の方法を疑問に思っていました： バルブの開閉に異なる値を必要とする新しいタイプのバルブ（0と1ではありません）をサポートするよう求められています。 単に「開く」または「閉じる」のではなく、0〜100の任意の位置に設定できるバルブをサポートする必要があります。 通常、この種のことには継承を使用しますが、最近、「継承を超える構成」に頭を悩まし始め、構成を使用するスリッカーソリューションがあるのではないかと考え始めました。

12 design  design-patterns  object-oriented 

ここで何が求められているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 7年前に閉鎖されました。 ここでプログラマーに、この質問への答えを見ました：動的で弱く型付けされた言語で、設計パターンとOOPプラクティスに関する考え方はどのように変わりますか？そこで、率直なタイトルの記事へのリンクを見つけました：デザインパターンには言語機能がありません。しかし、私にとって非常にキャッチーであると思われるスニペットを見つけた場合、それはおそらく次のようなインセンティブがあるので、経験に対して検証することができます： PaulGraham氏は、「Peter Norvigは、Design Patternsの23パターンのうち16パターンがLispで「見えない、または単純である」ことを発見しました。」 JavaScriptでクラスをシミュレートしようとしている人に最近見たものを確認する別の文： もちろん、ほとんどの言語が「機能」パターン、「クラス」パターン、または他の多くのことを当たり前だと言っていることはありません。ほとんどの言語が組み込み機能として提供しているからです。OTOH、純粋にPrototypeOrientedLanguageのプログラマーですか？プロトタイプを使用してクラスをシミュレートすると便利かもしれません... また、デザインパターンが通信ツールであることも考慮しています。アプリケーションの構築に参加した経験が限られている場合でも、たとえばアンチパターン（非効率的および/または逆効果）として見ることができるため、小規模のPHPチームに中小規模のイントラネットアプリのGoFパターンを学習させる必要があります。規模、範囲、目的が何が効果的および/または生産的であるかを決定できることは承知していますが、それでも技術的な概要を見つけることができませんでした。 OOPと機能が混在し、なおかつ保守可能である小さな商用アプリケーションを見ました。シングルトンを記述するために、たとえばPythonで多くの人が必要かどうかはわかりませんが、私にとっては単純なモジュールでも同じことができます。 設計パターン対回避策対それを行う簡単な方法、または言語機能による置換を考慮した研究、網羅的な記事、または他の形式の説明はありますか？

12 programming-languages  design-patterns 

永続性無知は、単一の責任原則のアプリケーションです。実際には、ドメインオブジェクト（DO）に永続性に関連するコードを含めるべきではなく、ドメインロジックのみを含める必要があります。 a）これは、下位層（つまり、永続層）に接続するコードが、ビジネスロジック層の他のクラス（OC）のドメインモデルの外側にあることを意味すると思いますか？ b）の下で、私の仮定した場合）正しいこと、そしてDOたとえば、Customer、決してなどの方法が含まれていませんGetCustomersかGetCustomerByID？ c）a）およびb）の下での私の仮定が正しく、Customerドメインオブジェクトがそのプロパティの一部に遅延読み込みを使用すると仮定すると、ある時点でCustomer内部ロジックがOCに連絡し、次にOCが遅延データを取得する必要があります。しかし、遅延データを受け取るためにOCCustomerに連絡する必要がある場合、ドメインオブジェクトに永続性に関連するロジックが含まれていないことを主張することはできません。 ありがとうございました jkohlheppへの返信 1）クラスはビジネスロジック層に含まれているOrderProviderと思いCustomerProviderますか？ 2）b）の下での私の仮定が正しいというあなたの返事から集めますか？ 3） ...いくつかの非公開注文フィールドが入力されているか、それがヌルであるかを確認します。nullの場合... しかし、私が知る限り、ドメインコードがプライベートorderフィールドに入力されているかどうかを確認する必要があるとすぐに、もしそうでない場合はOrderProviderに問い合わせると、すでにPIの原則に違反していますか？！

12 design-patterns  domain-driven-design  domain-model  persistence 

データオブジェクトにカスタムフィールドを追加する機能を持つオブジェクトを設計するための、またはオブジェクトの独自のカスタム定義を作成するための一般的な戦略または設計パターンはありますか。たとえば、独自の種類の情報を持つことができるSalesForceなどの製品、Expression Engineなどのフレームワーク、およびチャネルとチャネルフィールドグループの処理方法（例）、またはwordpressのようなCMSの機能カスタム投稿タイプにフィールドを追加します。

12 design-patterns  database-design 

ウィキペディアによると 「ソフトウェアエンティティ（クラス、モジュール、関数など）は拡張のために開かれている必要がありますが、変更のために閉じられている必要があります」 関数という言葉が目を引きましたが、メソッドのオーバーロードを作成することは、オープン/クローズの原則の一例とみなすことができると思いますか？ 例を説明しましょう。サービスレイヤーにメソッドがあり、ほぼ1000か所で使用されていることを考慮してください。メソッドはuserIdを取得し、ユーザーが管理者であるかどうかを判断します。 bool IsAdmin(userId) ここで、userIdではなくユーザー名に基づいて、ユーザーが管理者であるかどうかを判断する必要があると考えてください。上記のメソッドのシグネチャを変更すると、1000箇所でコードが破損します（関数は修正のために閉じる必要があります）。したがって、ユーザー名を取得するオーバーロードを作成し、ユーザー名に基づいてuserIdを見つけ、元のメソッドを見つけることができます。 public bool IsAdmin(string username) { int userId = UserManager.GetUser(username).Id; return IsAdmin(userId); } このように、オーバーロードを作成して機能を拡張しました（機能は拡張に対して開かれている必要があります）。 それはオープン/クローズド原則の例ですか？

12 solid  design-patterns  open-close 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 私は告白します：読んだ本や聞いたデザインパターンなどに基づいてそれを作ろうとすると、そのような熱意-から来る熱意が私に与えられるので、ほとんどの場合、「シンプルで短く保つ」という問題がありますその感覚は、私がありそうな完璧さへの正しい道にいます。 一方で、はい、それは時々締め切りを提供するという点で私に余分なストレスをかけます... しかし、私が自分自身に言うときはいつでも、「次回は単純にしてください、あなたは愚かです！」次回になったときに「シンプル」にするのは静かだと思いますが、それは奇妙に感じ始め、ある時点で不快に感じるからです。 それから、私は「シンプル」の私の理解を判断し始めます... SIMPLEは短すぎて機能しませんが、維持および拡張が難しいということですか？ SIMPLEは、OOPの原則の多くを破ることを意味しますか？ SIMPLEは不正行為を意味しますか？ SIMPLEとは、締め切りなしに期限を守ることを意味しますか？等 実際、それは何ですか？ 質問は次のとおりです。KISSの原則に関して、SIMPLEの正確な定義を記述できますか。-もしあれば。 ありがとう！

12 design-patterns 

これまで、私はWebアプリケーションを開発するためのMVCパターンの大ファンでした。Webの場合、私は主にPHP（KohanaおよびCodeIgniterフレームワークを使用）およびRuby（RoR）で開発しました。 私のアプリケーションがAjax側で重くなると（単一ページのアプリなど）、MVCの非常に基本的な概念を裏切るしかないわけではないことに気付きました。Javascriptはほとんどの作業を行っています。ビューまたはその他のjs / jsonコードを要求するためだけにコントローラーを呼び出すことは間違っているようです。 すべてのルーティングジョブをコントローラーに保持するように努めた後、基本的にそれらを（つまり、フレームワークのPoV、ビューの一部から）Javascriptに分割しました。JSONを求める場合にはMVCの転覆は、より明白になります要求をしているJSコードがあるコントローラ。フレームワークのコントローラーは、単にモデルのデータのプロキシとして機能しているだけです-私が実際に求めているのは。 だから、私は何を調べるべきですか？ バックボーンとしてbackbone.jsとドキュメントベースのjson-spittingデータベース（couchDB）を使用するなど、純粋なjavascriptアプリケーションを考えていましたが、リレーショナルデータベースが大好きです。 別のオプションは次のとおりです。PHP/ ruby​​ / go / whatnotで「ルーティングモデル」を作成するだけです。それらはリクエストを分析し、dbを呼び出し、jsonを返します。 このアプローチは私には興味深いように見えますが、実質的な文書や学術的な分析がないため、飛躍を少し恐れています。 アイデア？

12 javascript  design-patterns  mvc  ajax 

大規模なプログラムの作成中に何度も、コピーまたは貼り付けの回数を関数またはメソッドにコードを入れるのが理にかなっていて、良い経験則は何かを疑問視しています。私は4行以上の経験則を使用しており、2回以上表示され、そのコードを含む単純な関数/メソッドを作成します。より良いプラクティスを考えたり、何か指針を提供できますか？これは、言語固有の質問というよりも、一般的なデザインパターンの質問です。

12 design-patterns  language-agnostic 

2007年に、Joshua Blochsが「ビルダーパターン」を採用し、コンストラクターとセッターの過剰使用を改善するためにどのように変更できるかについての記事を読みました。このデザインパターンの簡単な概要は、こちらで説明されています。 私はこのアイデアが好きで、それ以来ずっと使っています。それに伴う問題は、クライアントの観点からは非常にクリーンで使いやすいものですが、それを実装するのは苦痛になる可能性があります！オブジェクトには単一のプロパティが参照される非常に多くの異なる場所があるため、オブジェクトを作成し、新しいプロパティを追加するには時間がかかります。 だから...私は考えていました。まず、Joshua Blochスタイルのオブジェクトの例： ジョシュブロッホスタイル： public class OptionsJoshBlochStyle { private final String option1; private final int option2; // ...other options here <<<< public String getOption1() { return option1; } public int getOption2() { return option2; } public static class Builder { private String option1; private int option2; // other …

12 java  design-patterns 

この既存のコードには、クラスとそのクラスの初期化メソッドがあります。クラスのオブジェクトが作成されたら、そのオブジェクトでinitializeを呼び出す必要があります。 初期化メソッドが存在する理由 オブジェクトは、グローバルスコープを持つように早期に作成され、その後、依存するDLLを読み込んだ後に初期化メソッドが呼び出されます。 初期化 の問題クラスには現在、このbool isInitializedがあります。初期化されていない場合、処理を続行してエラーを返す前にすべてのメソッドでチェックする必要があります。簡単に言えば、それは大きな痛みです。 考えられる解決策の1つ は、コンストラクターで初期化することです。グローバルスコープ内のオブジェクトへのポインターのみがあります。dllがロードされた後、実際のオブジェクトを作成します。 上記のソリューションの問題 このクラスのオブジェクトを作成する人は誰でも、dllがロードされた後にのみ作成される必要があることを知る必要があります。さもないと、失敗します。 これは受け入れられますか？

12 c++  design  design-patterns 

新しいRESTful Webサービスを設定していますが、役割ベースのアクセス制御モデルを提供する必要があります。ユーザーがユーザー名とパスワードを入力してサービスにアクセスできるようにするアーキテクチャを作成し、役割に基づいてサービスの使用方法（使用できるサービス、読み取りvs読み取り/書き込みなど）を制限する必要がありますそのユーザーに割り当てられます。 私は他の質問を見て回り、欲しいものを見つけました。たとえば、資格情報をRESTサービスのrestful-authenticationに渡す方法、ベストプラクティスを扱う方法については、いくつかの素晴らしい議論があります。また、プログラマーがWebサイトを作成するときに知っておくべきこと（すべての開発者が公開Webサイトを構築する前に知っておくべきこと）についての優れた指針もあります。 しかし、これらのソリューションを実装するソフトウェアアーキテクチャのベストプラクティスとパターンに関する優れた投稿、記事、書籍を見つけることができませんでした。 具体的には： ユーザーの詳細とアクセス権はどのように保存する必要がありますか？（データモデル、場所、形式） サーバーでこれらを表現および追跡するための優れた設計パターンは何ですか？（メモリ内のセッション、毎回のデータベース検索など） コードベースでこれらの権利を安全な方法でサービスにマッピングするための良いパターンは何ですか？ システムをより安全で信頼性の高いものに保つのに役立つアーキテクチャの選択肢は何ですか？ トレンチから学んだことは何ですか？ 特定の技術以外のソフトウェアアーキテクチャの設計パターンと推奨事項を探しています。 （テクノロジーが重要な場合は、python、twisted、およびpostgresqlデータベースを使用してこれを実装する予定です）

12 web-development  design-patterns  security  web-services  rest