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

pimplの問題の1つは、それを使用するとパフォーマンスが低下することです（追加のメモリ割り当て、不連続なデータメンバー、追加の間接参照など）。pimplのすべての利点が得られないという犠牲を払ってこれらのパフォーマンスのペナルティを回避する、pimplイディオムのバリエーションを提案したいと思います。アイデアは、クラス自体にすべてのプライベートデータメンバーを残し、プライベートメソッドのみをpimplクラスに移動することです。基本的なpimplと比較した場合の利点は、メモリが連続している（追加の間接参照がない）ことです。pimplをまったく使用しない場合と比較した場合の利点は次のとおりです。 プライベート関数を非表示にします。 これらのすべての関数が内部リンケージを持ち、コンパイラーがより積極的に最適化できるように構造化できます。 したがって、私の考えは、pimplをクラス自体から継承させることです（私は少し奇妙に聞こえますが、我慢してください）。次のようになります。 Ahファイル： class A { A(); void DoSomething(); protected: //All private stuff have to be protected now int mData1; int mData2; //Not even a mention of a PImpl in the header file :) }; A.cppファイル： #define PCALL (static_cast<PImpl*>(this)) namespace //anonymous - guarantees internal linkage { struct PImpl …

9 design-patterns  performance  optimization  c++11 

これは、別の質問に対するこの回答が動機です。 ビルダーパターン）、特に、オプションの初期化パラメータとの複合体の初期化を簡略化するために使用されます。しかし、相互に排他的な構成を適切に管理する方法がわかりません。 ここにImageクラスがあります。 Imageファイルまたはサイズから初期化できますが、両方から初期化することはできません。コンストラクタを使用してこの相互排除を強制することは、クラスが十分に単純な場合に明らかです。 public class Image { public Image(Size size, Thing stuff, int range) { // ... initialize empty with size } public Image(string filename, Thing stuff, int range) { // ... initialize from file } } Imageビルダーパターンが役立つように実際に十分に構成可能であると想定すると、突然これが可能になる可能性があります。 Image image = new ImageBuilder() .setStuff(stuff) .setRange(range) .setSize(size) // <---------- NOT …

9 design-patterns  object-oriented  builder-pattern 

私は自分のアプリケーションで常にリポジトリー・パターンを使用してきました。しかし、多くの人が命名規則にリポジトリではなくファサードを使用しているのを見てきましたが、操作は同じだと思います。なぜこの違いがあるのですか？それらの間には本当の違いがありますか？

9 design-patterns  repository 

一度だけインスタンス化されるクラスを作成するのは悪いコーディングの実践/設計ですか？ 私はいくつかの変数と関数をクラスの下でグループ化して「見栄え」を良くするために（より良い説明がないため）いくつかの変数と関数を持っていますが、それらは単にグローバル変数とグローバル関数にすることができます。 （ところで、私はJavaScript、AngularJS、Express、MongoDBを使用しています。）

9 design  design-patterns 

PHP Codeigniter MVCデザインパターンを使用しています そして私はある種の特定のビジネスプロセスを備えたこのプロジェクトを持っていました 私のアプリケーションでは、2つの既存のREST APIを扱います。 グーグル トレロ ビジネスロジックレイヤー（BBL）として機能するREST APIを作成するというアイデアを思いつきました 次に、モデルに直接アクセスして、ビジネスルールを作成するために必要なデータをフェッチします。 RESTクライアントを使用してBLLと通信するコントローラー、 パフォーマンスの悪いアプローチですか？ データアクセスレイヤー（DAL）とビジネスロジックレイヤー（BLL）の2つのモデルのレイヤーを作成する方が良いですか？

9 php  design-patterns  mvc  rest  codeigniter 

のclass XFactoryオブジェクトを作成するファクトリがありますclass X。のインスタンスXは非常に大きいため、ファクトリの主な目的は、クライアントコードに対してできるだけ透過的にインスタンスをキャッシュすることです。のオブジェクトclass Xは不変であるため、次のコードは妥当なようです。 # module xfactory.py import x class XFactory: _registry = {} def get_x(self, arg1, arg2, use_cache = True): if use_cache: hash_id = hash((arg1, arg2)) if hash_id in _registry: return _registry[hash_id] obj = x.X(arg1, arg2) _registry[hash_id] = obj return obj # module x.py class X: # ... それは良いパターンですか？（実際のファクトリーパターンではないことはわかっています。）変更すべき点はありますか？ …

9 design  design-patterns  python  caching  persistence 

私はおもちゃのプロジェクトとして小さなツールに取り組んでおり、2つのディレクトリの違いを示し、どのファイル/ディレクトリが追加、削除、変更されたかなどを示しています。 私はこれらの変更を、それがファイルであるかディレクトリであるかを区別せずに、単に「ChangeItem」オブジェクトとして表現しようとしていました。しかし、それらをツリーに表示する方法、子供の親が誰であるかを知る方法など、多くの問題が発生しました。また、非常に直感的ではありませんでした。 次に、ディレクトリの変更とファイルの変更の間で変更を分割します。これにより、コーディングが非常に簡単になり、何が起こっているのかを理解することが容易になりました。これで、ディレクトリ内のすべてのファイルを選択するなど、はるかに簡単になりました。 私の質問は、抽象化を使用するか、コードでより具体的にするかをどのようにして知ることができるかです。抽象化が多すぎるか少なすぎるかをどのように判断できますか？

9 self-improvement  design-patterns  architecture  code-quality  abstraction 

単純なASP.NET Webフォームアプリケーションを作成しています。抽象化を実現し、管理性と理解性を向上させる設計パターンを実装することにより、コードを改善したいと考えています。 どのパターンが推奨されますか？サンプルアプリケーションへのリンクも提供してください。

9 design-patterns  asp.net 

私と友達の間で議論を解決してください。 現在、製品APIを設計しています。製品エンティティは次のようになります { "Id": "", "ProductName": "", "StockQuantity": 0 } 製品の販売はサードパーティが処理し、StockQuantityフィールドを減らすことができるように購入数量を通知する義務があります。 私のアプローチ： PUT /api/Product/{Id}/ --data { "StockQuantity": "{NewStockQuantity}" } サードパーティは、製品のクエリ、現在のStockQuantity購入数量に基づく計算、およびPUT新しい値でのリクエストの送信を担当します。 私の友人はサードパーティに計算を望まない。彼のアプローチ PUT /api/Product/{Id}/DecreaseStock --data { "PurchasedQuantity": "{PurchasedQuantity}" } したがって、計算を行って、 StockQuantity 私は関数ベースのエンドポイントを作成したくありません、そして彼は計算を行うためにサードパーティを信頼したくありません。 この問題に取り組むための正しい方法は何でしょうか？

8 design  design-patterns  rest  api-design  rpc 

相互に作用する小さな（> 50）小さなWebComponentsがたくさんあるWebアプリがあります。 すべてを切り離しておくために、原則として、どのコンポーネントも別のコンポーネントを直接参照できないようにしています。代わりに、コンポーネントはイベントを発生させ、（「メイン」アプリ内で）配線されて、別のコンポーネントのメソッドを呼び出します。 時間が経つにつれ、追加されるコンポーネントが増え、「メイン」のアプリファイルには次のようなコードチャンクが散らばっています。 buttonsToolbar.addEventListener('request-toggle-contact-form-modal', () => { contactForm.toggle() }) buttonsToolbar.addEventListener('request-toggle-bug-reporter-modal', () => { bugReporter.toggle() }) // ... etc これを改善するために、同様の機能をグループ化し、にClass関連性のある名前を付け、インスタンス化するときに参加要素を渡し、内の「配線」を次のClassように処理します。 class Contact { constructor(contactForm, bugReporter, buttonsToolbar) { this.contactForm = contactForm this.bugReporterForm = bugReporterForm this.buttonsToolbar = buttonsToolbar this.buttonsToolbar .addEventListener('request-toggle-contact-form-modal', () => { this.toggleContactForm() }) this.buttonsToolbar .addEventListener('request-toggle-bug-reporter-modal', () => { this.toggleBugReporterForm() }) …

8 design  design-patterns  object-oriented  javascript  object-oriented-design 

シングルトンパターンとそれがどのように「悪い」のかについては、クラスをテストするのが難しくなるので避けてきました。シングルトンを依存性注入に置き換える方法を説明した記事をいくつか読んだことがありますが、それは不必要に複雑に思えます。 これがもう少し詳しく私の問題です。私はReact Nativeを使用してモバイルアプリを構築しています。サーバーと通信し、データを取得し、データを投稿し、ログインを処理するRESTクライアントを作成します（ログイントークンを保存し、ログイン後にリクエストごとに送信します）。 私の最初の計画は、アプリが最初にログインに使用し、必要に応じて資格情報の送信を要求するシングルトンオブジェクト（RESTClient）を作成することでした。DIのアプローチは本当に複雑に思えます（おそらくDIを使用したことがないためです）が、このプロジェクトを最大限に活用して、ここで最善を尽くしたいと思います。提案やコメントは大歓迎です。 編集：私は今、自分の質問の言葉遣いが不十分であることに気づきました。RNでシングルトンパターンを回避する方法についてのガイダンスが必要でした。幸運にも、サミュエルは私が望んでいたような答えをくれました。私の問題は、シングルトンパターンを避けてDIを使用したかったのですが、React Nativeで実装するのは本当に複雑に思えました。さらに調査を行い、Reactsコンテキストシステムを使用して実装しました。 ここに興味のある人のために、私はそれをしました。私が言ったように、私はプロップのようなものであるRNのコンテキストを使用しましたが、それはすべてのコンポーネントに伝搬されます。 ルートコンポーネントでは、次のような必要な依存関係を提供します。 export default class Root extends Component { getChildContext() { restClient: new MyRestClient(); } render() {...} } Root.childContextTypes = {restClient: PropTypes.object}; これで、restClientは、ルートの下のすべてのコンポーネントで使用できます。このようにアクセスできます。 export default class Child extends Component { useRestClient() { this.context.restClient.getData(...); } render() {...} } Child.contextTypes = {restClient: PropTypes.object} これにより、オブジェクトの作成がロジックから効果的に離れ、RESTクライアントの実装がコンポーネントから切り離されます。

8 design-patterns  architecture  dependency-injection  singleton  react 

概要：密接に相互依存する値間での情報の重複を減らすための優れた設計パターンはありますか？ 私の仕事では、他の数量を知っている場合に数量の1つを導出できるような数量間の関係があることはかなり一般的です。理想的なガスの法則がその例です。 Pv = RT 理想的なガスの状態を表すクラスを作成することを想像できます。クラスは当然、3つの特性を有するであろうPressure、TemperatureとSpecificVolume適切な種類のそれぞれ。 このクラスのオブジェクトのユーザーのために、あなたが両方の値を設定している場合ことを期待するのが自然と思われるPressureとTemperature、あなたはその後の値を読み出すことができSpecificVolume、オブジェクトがあなたのためのことを計算していることを期待しています。 同様に、との両方に値を設定するPressureとSpecificVolume、を読み取ることができますTemperature。 ただし、このクラスを実際に実装するには、情報の重複が必要です。方程式のすべてのバリエーションを明示的にプログラムし、それぞれの場合に異なる変数を従属変数として扱う必要があります。 T = P * v / R P = R * T / v v = R * T / P これはDRYの原則に違反しているようです。それぞれが同じ関係を表していますが、これらのケースには独立したコーディングとテストが必要です。 実際のケースでは、私が考えているロジックはこの例よりも複雑ですが、同じ基本的な問題を示しています。したがって、ロジックを1回だけ、または少なくともより少ない回数で表現できれば、真の価値があります。 このようなクラスは、値が読み取られる前に適切に初期化されていることも確認する必要があることに注意してください。ただし、これは2番目の考慮事項です。 数学的例を挙げましたが、問題はデータ間の数学的関係だけに限定されません。これは、ポイントを説明するための簡単な例のように思われました。

8 design-patterns 

私は最近、以下のクラスに関して別の開発者との議論に入りました： 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＃アプリであり、戦略パターンとテンプレートパターンの間で議論していますが、フォルダー構造と命名規則の考慮事項もあります。各州の個別のプロジェクトはすぐに管理できなくなるようです（たとえば、5つのコアサービスX 50州のカスタムプロジェクト）= 250プロジェクト!!）おそらく、サービスごとに1つのカスタムプロジェクトが、州ごとにサブフォルダーに編成された専門化を処理していますか？

8 c#  design-patterns  architecture  architectural-patterns 

多くの場合、（Javaでの）ビルダーパターンの実装は次のようになります。 public class Foo { private Foo(FooBuilder builder) { // get alle the parameters from the builder and apply them to this instance } public static class FooBuilder { // ... public Foo build() { return new Foo(this); // <- this part is what irritates me } } } ここにも例： …

8 design-patterns  builder-pattern