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

オブジェクト指向設計について考えるとき、SOLIDの原則は非常に有用であることがわかりました。 関数型プログラミング向けに調整された、言語に依存しない原則の類似/同等のセットはありますか？

36 design-patterns  functional-programming  solid 

私は常に、DALでキャッシングが行われるプロジェクトに取り組んできました。基本的には、データベースへの呼び出しを行うときに、キャッシュにデータが既に存在するかどうかをチェックし、存在する場合は呼び出しを行いません。代わりにそのデータを返します。 私は最近ビジネス層でのキャッシュについて読んだので、基本的にビジネスオブジェクト全体をキャッシュします。すぐにわかる利点の1つは、応答時間の短縮です。 どちらを優先するかはいつですか？およびビジネス層でのキャッシングは一般的な慣行ですか？

36 c#  design  design-patterns  caching 

私は最近、iOS開発の学習を開始することを決めました。そのために、iOSプログラミング：The Big Nerd Ranch Guideを読みました。本の中で著者はMVCS-Model-View-Controller-Storeのデザインパターンについて説明しています。基本的な考え方は、多くのアプリケーションがデータの複数の外部ソースを利用するため、コントローラーのリクエストロジックを維持するのが非常に面倒になる可能性があるということです。すべての要求ロジックをコントローラーから別のオブジェクトに移動することを提案します。 要するに本を引用する Model-View-Controller-Storeは要求ロジックを別のオブジェクトに入れ、このオブジェクトをストアと呼びます（図28.4）。ストアオブジェクトを使用すると、冗長なコードが最小限に抑えられ、データをフェッチして保存するコードが簡素化されます。最も重要なことは、外部ソースを処理するためのロジックを、明確で焦点の合った目標を持つ整然としたクラスに移動することです。これにより、コードが理解しやすくなり、保守とデバッグが容易になり、チームの他のプログラマーと共有できます。 そして 非同期ストアの優れた点は、多くのオブジェクトが要求を処理するために多くの作業を行っているにもかかわらず、要求とその応答のフローがコントローラーの1か所にあることです。これにより、読みやすく変更しやすいコードの利点が得られます。 私はこのパターンについてもっと知り、他の人がそれについて何を言わなければならないかを見たいと思っていましたが、オンラインで検索している間、私が見つけることができる唯一の参照はその同じ本に関するものでした（パターンはおそらく他の名前で知られていますか？）。 私にとって著者の論理は理にかなっているようで、通常のMVCパターンの論理的な拡張のように思えますが、おそらく実際にはMVCパターンの経験があまりないためです（iOS開発への進出を除いて）ソートで使用MVVのBACKBONE.JS（、であるあなたがそれMVC検討している場合））。 おそらく、より多くの経験を積んだ人が、MVCSパターンに明らかな欠陥や問題がないかどうかを明らかにすることを望んでいました。

35 design-patterns  mvc  ios 

私は、MVCでの最初の本当のクラックで、業界標準とベストプラクティスに従っていることを確認したいと思います。この場合、C＃を使用したASP.NET MVCです。 モデルにEntity Framework 4.1を使用し、コードファーストオブジェクト（データベースが既に存在する）を使用するため、データベースからデータを取得するためのDBContextオブジェクトが存在します。 asp.net Webサイトで行ったデモでは、コントローラーにデータアクセスコードが含まれています。これは、特にDRY（自分自身を繰り返さないでください）プラクティスに従う場合、私には正しくないようです。 たとえば、公共図書館で使用するWebアプリケーションを作成しており、カタログ内の書籍を作成、更新、削除するためのコントローラーがあるとします。 アクションのいくつかはISBNを取得し、「Book」オブジェクトを返す必要がある場合があります（これはおそらく100％有効なコードではないことに注意してください）。 public class BookController : Controller { LibraryDBContext _db = new LibraryDBContext(); public ActionResult Details(String ISBNtoGet) { Book currentBook = _db.Books.Single(b => b.ISBN == ISBNtoGet); return View(currentBook); } public ActionResult Edit(String ISBNtoGet) { Book currentBook = _db.Books.Single(b => b.ISBN == ISBNtoGet); return …

35 c#  design-patterns  asp.net-mvc  industry-standard 

どちらが優れていると考えられますか： サービスと直接やり取りするディレクティブを持つ または コントローラが動作をバインドする特定のフックを公開するディレクティブを持っていますか？

35 design-patterns  patterns-and-practices  angularjs 

割引モデルを実装するための既知の設計パターンはありますか？ 割引モデルとは、次のことを意味します。 顧客が製品X、製品Y、および製品Zを購入すると、10％または100ドルの割引を受けます。 顧客が製品Xを100単位購入すると、15％または$ 500の割引を受ける 顧客が昨年に10万ドル以上持ち込んだ場合、20％の割引が適用されます 顧客が製品Xを2ユニット購入した場合、製品X（または製品Y）を1ユニット無料で入手できます。 ... 上記のすべてのシナリオを処理するために適用できる一般的なパターンはありますか？私はいくつかのモデルを考えていますが、一般的なモデルに出くわすことはできません。

35 design  design-patterns  financial 

Joshua BlochのEffective Javaの本（第2版）に大きな影響を受けました。おそらく私が読んだどのプログラミングの本よりもそうでしょう。特に、彼のビルダーパターン（項目2）が最大の効果をもたらしました。 Blochのビルダーは、過去10年間のプログラミングよりも数か月ではるかに遠くまで私を導いてくれましたが、私は今でも同じ壁にぶつかっています。 --especiallyジェネリックが遊びに来たときに、そして特にと自己参照ジェネリック医薬品（などComparable<T extends Comparable<T>>）。 私には2つの主要なニーズがありますが、この質問で焦点を当てたいのは2番目だけです。 最初の問題は、「...単...クラスごとに再実装することなく、自己復帰メソッドチェーンを共有する方法」です。好奇心may盛な方のために、この回答記事の最後でこの部分について説明しましたが、ここで焦点を当てたいものではありません。 私がコメントを求めている2番目の問題は、「他の多くのクラスによって拡張されることを意図したクラスにビルダーを実装するにはどうすればよいですか」です。ビルダーを使用してクラスを拡張するのは、当然、ビルダーを使用せずに拡張するよりも困難です。を実装Needableするビルダーを持つクラスを拡張することは、そのため、それに関連付けられた重要なジェネリックを持ち、扱いにくいです。 それが私の質問です：Bloch Builder（私が呼ぶもの）をどのように改善できますか？そのクラスが「ベースクラス」であることを意図している場合でも、自由にビルダーを任意のクラスに添付できますビルダー（およびその潜在的なジェネリック）が彼らに課す余分な荷物のために、私の未来やライブラリのユーザーを落胆させることなく、何度も何度も拡張およびサブ拡張されましたか？ 補遺 私の質問は上記のパート2に焦点を当てていますが、対処方法など、問題1について少し詳しく説明したいと思いました。 最初の問題は、「...単...クラスごとに再実装することなく、自己復帰メソッドチェーンを共有する方法」です。これは、拡張クラスがこれらのチェーンを再実装する必要があることを防ぐためではなく、もちろん、これらのメソッドチェーンを利用したい非サブクラスを防ぐ方法を再実装する必要があります- ユーザーがそれらを利用できるように、すべての自己復帰機能を実装しますか？このために、ここでインターフェースのスケルトンを印刷し、今のところはそのままにしておく必要がある必要性の高いデザインを考え出しました。私にとってはうまくいきました（この設計は長年の開発でした...最も困難な部分は循環依存を回避することでした）： public interface Chainable { Chainable chainID(boolean b_setStatic, Object o_id); Object getChainID(); Object getStaticChainID(); } public interface Needable<O,R extends Needer> extends Chainable { boolean isAvailableToNeeder(); Needable<O,R> startConfigReturnNeedable(R n_eeder); R getActiveNeeder(); boolean isNeededUsable(); R endCfg(); } …

34 java  design  design-patterns  object-oriented 

UIとモデルの間の適切なデカップリングを実装する方法を十分に理解しようとしていますが、行を分割する場所を正確に把握するのに苦労しています。 私はModel-View-Presenterを見てきましたが、それをどのように実装するのか正確にはわかりません。たとえば、私のビューには複数のダイアログがあります。 各ダイアログのインスタンスを持つViewクラスが必要ですか？その場合、ダイアログはプレゼンターとどのように対話する必要がありますか？すなわち。個々のダイアログがプレゼンターを介してモデルからデータを要求する必要がある場合、ダイアログはプレゼンターへの参照をどのように取得する必要がありますか？建設中に与えられたビューへの参照を介して？ 私は多分ビューが静的なクラスであるべきだと思っていましたか？次に、GetViewダイアログとそこからプレゼンターを取得します... ビューとモデルの所有権を持つプレゼンターをセットアップすることを考えていました（ビューを持つプレゼンターとプレゼンターがモデルを持つのとは対照的に）、プレゼンターはビューのイベントのコールバックを登録しますが、それは多くのように見えますより結合された（または少なくとも言語に依存） 私がしようとしている： これを可能な限り分離する 理想的には、プレゼンター/モデルを他の言語のビューと結合することを可能にします（言語間で大量のことをやったことはありませんが、可能な限り、特にvoid(void)私ができる限り、少なくともC＃アプリでC ++ライブラリ... コードを簡潔かつシンプルに保つ だから..相互作用をどのように処理すべきか提案はありますか？

34 design-patterns  ui  interfaces 

たとえば、プレーヤーの能力を高めるためのいくつかのツールを備えたゲームがあります。 Tool.h class Tool{ public: std::string name; }; そしていくつかのツール： Sword.h class Sword : public Tool{ public: Sword(){ this->name="Sword"; } int attack; }; Shield.h class Shield : public Tool{ public: Shield(){ this->name="Shield"; } int defense; }; MagicCloth.h class MagicCloth : public Tool{ public: MagicCloth(){ this->name="MagicCloth"; } int attack; int defense; }; …

34 design-patterns  c++  generics 

単一責任の原則は、高い結束の原則に基づいています。この2つの違いは、SRPに準拠するクラスの責任は1つだけであるのに対し、非常に凝集性の高いクラスには密接に関連する一連の責任があることです。 しかし、特定のクラスに一連の責任があり、したがって非常に凝集性があるのか​​、それとも1つの責任しか持たず、したがってSRPに準拠するのかをどのように判断するのでしょうか。言い換えれば、クラスが非常にきめ細かいと考える人もいるかもしれません（クラスがSRPに準拠していると考える人もいるかもしれませんが）

34 design-patterns  single-responsibility  cohesion 

ディスラプターパターンがどのように機能するかを簡単な方法で説明していただければ幸いです。この概念は、知っているように私にはとらえどころのないです。 おそらくあなたの助けがあれば理解できます。

33 java  design-patterns  multithreading  real-time 

理解する限りでは、アダプターパターンは、目的の実際のオブジェクトのラッパーオブジェクトを作成しています。これは、もう1つのレベルの間接化であり、柔軟性を提供します。柔軟性は、実際のオブジェクトのインターフェイスが変更された場合、実際のオブジェクトを指すラッパーインターフェイスを変更し、クライアント側の公開インターフェイスを変更しないという点です。 Proxyパターンは、すべてのプロキシラッパーは実際のオブジェクトの機能の唯一のコヒーレントサブセットを提供していることの違いで、同じです。「1つの目的のために1つのクラス」を作成しようとするとき、なぜこれが役立つのかは私にはわかりません。 これを正しく入手しましたか？

33 design-patterns 

パンをスライスして以来、デザインパターンが最高のものであると主張したと聞いています。また、デザインパターンは「セカンドシステムシンドローム」を悪化させる傾向があり、非常に使い古されており、ユーザーに実際よりも優れたデザイナーだと思わせると主張していると聞きました。 私は以前のキャンプに近づく傾向がありますが、最近では、ほぼすべての相互作用がオブザーバー関係に置き換えられ、すべてがシングルトンであるデザインを見てきました。 それでは、利点と問題を考慮して、設計パターンは一般に良いか悪いか、そしてその理由は何ですか？

33 design  design-patterns 

ボストンで開催されたAn Event Apartというカンファレンスから戻ってきました。 スピーカーの間で本当に人気のあるテーマは、プログレッシブエンハンスメントのアイデアでした。サイトのコンテンツはHTMLに入れ、JavaScriptは動作を強化するためだけに使用する必要があります。 スピーカーがプログレッシブエンハンスメントに対して行った議論は非常に説得力がありました。古いブラウザや低帯域幅のネットワーク上のデバイスをサポートするための堅実なパターンであるだけでなく、HTMLはJavaScriptよりもはるかに優雅に失敗します（つまり、サポートされていないマークアップは無視されますが、ブラウザが実行中に例外をスローした場合スクリプト-あなたはうんざりしています）。 ジェレミー・キースはこれについて特に洞察力に富んだ講演を行いました。 しかし、BackboneやAngularなどの単一ページのWebアプリはどうでしょうか。これらのフレームワークの背後にある設計全体が、開発者をコンテンツをHTMLからJSON APIのようなものに移行させるように思われます。 プログレッシブエンハンスメントとシングルページWebアプリの2つのデザインパターンを融合させることはできません。一方が他方より優れている場合はありますか？それとも、敵対的な技術でさえないのか、ここに私の精神モデルで何かが欠けていますか？

33 design-patterns  programming-practices  html  angularjs 

私はかなり大きなコードベースに取り組んでいます。数百のクラス、大量の異なるファイル、多くの機能が、新しいコピーの取得などに15分以上かかります。 このような大きなコードベースの大きな問題は、かなりの数のユーティリティメソッドがあり、同じことを行うか、可能な場合にこれらのユーティリティメソッドを使用しないコードがあることです。また、ユーティリティメソッドは、すべてが1つのクラスに含まれているわけではありません（巨大な混乱のせいだからです）。 私はコードベースにはかなり慣れていませんが、何年もこのコードに取り組んでいるチームリーダーも同じ問題を抱えているようです。それは多くのコードと作業の重複につながり、そのため、何かが壊れると、通常は基本的に同じコードの4つのコピーで壊れます このパターンをどのように抑制できますか？ほとんどの大規模プロジェクトと同様に、すべてのコードが文書化されているわけではありません（一部は文書化されています）。しかし、基本的には、この点で品質の改善に取り組み、将来コードの重複を減らし、ユーティリティ関数のようなものを見つけやすくすることができれば、本当に素晴らしいことです。 また、ユーティリティ関数は通常、いくつかの静的ヘルパークラス、単一のオブジェクトで動作する非静的ヘルパークラス、または主に「ヘルプ」を行うクラスの静的メソッドのいずれかにあります。 拡張メソッドとしてユーティリティ関数を追加する1つの実験がありました（クラスの内部は不要であり、非常に特定のシナリオでのみ必要でした）。これには、プライマリクラスなどが乱雑になるのを防ぐ効果がありましたが、すでにそれを知っていない限り、実際には発見できません

33 design-patterns  refactoring  clean-code