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

休業。この質問には詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善してみませんか？詳細を追加し、この投稿を編集して問題を明確にしてください。 6年前休業。 私はプロジェクトに取り組み始めたばかりであり、ドメイン駆動設計（Eric Evansが定義するDomain-Driven Design：Tackling Complexity in the Heart of Software）を使用しています。私たちのプロジェクトは確かにこの設計の候補だと思いますエヴァンスが彼の本でそれを説明するパターン。 私は絶えずリファクタリングするという考えに苦労しています。 私は、どのプロジェクトでもリファクタリングが必要であり、ソフトウェアの変更に伴って必然的に起こることを知っています。ただし、私の経験では、リファクタリングは、ドメイン変更の理解としてではなく、開発チームのニーズが変化したときに発生します（Evansが言うように、「より深い洞察へのリファクタリング」）。私は、ドメインモデルの理解におけるブレークスルーに最も関心があります。小さな変更を加えることは理解していますが、モデルに大きな変更が必要な場合はどうなりますか？ より明確なドメインモデルを取得した後、リファクタリングする必要がある自分（および他の人）を説得する効果的な方法は何ですか？結局のところ、コードの編成またはパフォーマンスを改善するためのリファクタリングは、ユビキタス言語コードの観点から表現力を高めることとはまったく別のものである可能性があります。時々、リファクタリングするのに十分な時間がないように思えます。 幸いにも、SCRUMはそれをリファクタリングに役立てます。SCRUMの反復的な性質により、小さなピースを作成し、それを変更することが容易になります。しかし、時間の経過とともにそのピースは大きくなり、そのピースが大きくなりすぎて変更が困難になるとしたらどうでしょうか。 ドメイン駆動設計を採用するプロジェクトに取り組んだ人はいますか？もしそうなら、これについていくつかの洞察を得ることは素晴らしいでしょう。DDDを正しく理解するのは非常に難しいため、私は特にいくつかの成功事例を聞きたいと思います。 ありがとう！

10 design-patterns  architecture  object-oriented  scrum  domain-driven-design 

多くの場合、ユーザーに表示されるもの（Webページなど）は、部分的にセキュリティチェックに基づいています。私は通常、ユーザーレベルのACLセキュリティをシステムのビジネスロジックの一部と見なしています。ビューがセキュリティを明示的にチェックして条件付きでUI要素を表示する場合、ビジネスロジックを含むことでMVCに違反していますか？

10 web-development  design-patterns  security  mvc 

人々（このサイトでも）が日常的に関数型プログラミングのパラダイムを称賛していることを読んで聞いています。特に、C＃、Java、C ++などの従来の命令型オブジェクト指向言語でも、プログラマーにこれを強制するHaskellのような純粋に関数型の言語だけでなく、このアプローチを提案します。 変異性と副作用が便利だと思うので、理解するのは難しいと思います。しかし、人々が現在副作用を非難し、可能な限りそれらを取り除くことが良い習慣であると考えると、私が有能なプログラマーになりたいなら、私はパラダイムのいくつかのより良い理解に向けて私の夢を始めなければならないと信じています...したがって、私のQ. 機能的パラダイムで問題を見つけたときの1つの場所は、オブジェクトが複数の場所から自然に参照されるときです。2つの例で説明します。 最初の例は、私が暇なときに作ろうとしているC＃ゲームです。これはターンベースのWebゲームで、両方のプレイヤーに4つのモンスターのチームがあり、チームからモンスターを戦場に送ることができます。戦場では、相手のプレイヤーが送ったモンスターと対戦します。プレイヤーは戦場からモンスターを呼び戻し、それらを自分のチームの別のモンスターに置き換えることができます（ポケモンと同様に）。 この設定では、単一のモンスターを少なくとも2か所から自然に参照できます。プレイヤーのチームと2つの「アクティブな」モンスターを参照する戦場です。 ここで、1つのモンスターがヒットし、ヘルスポイントが20失われる状況を考えてみましょう。命令パラダイムの括弧内で、このモンスターのhealthフィールドを変更して、この変更を反映させます。これが私が現在行っていることです。ただし、これによりMonsterクラスが変更可能になり、関連する関数（メソッド）が不純になります。これは、現時点では悪い習慣と考えられています。 私は自分にこのゲームのコードを理想的な状態ではない状態にして、実際に将来のある時点でそれを完成させるという希望を持たせる許可を与えましたが、それがどのようにあるべきかを知り、理解したいと思います適切に書かれた。したがって、これが設計上の欠陥である場合、どのように修正すればよいですか？ 機能的なスタイルでは、私が理解しているように、代わりにこのMonsterオブジェクトのコピーを作成し、この1つのフィールドを除いて古いオブジェクトと同じにします。suffer_hitこのメソッドは、古いオブジェクトを変更する代わりに、この新しいオブジェクトを返します。次に、同様にBattlefieldオブジェクトをコピーし、このモンスター以外のすべてのフィールドを同じに保ちます。 これには少なくとも2つの困難が伴います。 階層は、この単純化された単なるBattlefield->の例よりもはるかに深くすることができますMonster。1つを除くすべてのフィールドをこのようにコピーし、新しいオブジェクトをこの階層全体で返す必要があります。これはボイラープレートのコードです。関数型プログラミングはボイラープレートを減らすことになっているので、私は特に迷惑です。 ただし、さらに深刻な問題は、データが同期されなくなることです。フィールドのアクティブなモンスターは、体力が低下します。ただし、この同じモンスターは、その制御プレイヤーから参照されTeam、そうではありません。代わりに命令型のスタイルを採用した場合、データのすべての変更はコードの他のすべての場所から即座に表示され、このような場合には非常に便利ですが、これを実現する方法はまさに人々が言うことです命令型スタイルとは間違っています！ これでTeam、各攻撃の後に旅をすることで、この問題に対処できるようになります。これは余分な作業です。しかし、後でさらに多くの場所からモンスターが突然参照される可能性がある場合はどうなりますか？たとえば、モンスターがフィールド上にある必要のない別のモンスターに集中できるようにする能力が付いている場合はどうなりますか（実際にそのような能力を検討しています）。私はウィル確かに immediatellyそれぞれの攻撃の後にも焦点を当てたモンスターへの旅を取ることを覚えていますか？これは時限爆弾のようで、コードが複雑になると爆発するため、解決策はないと思います。 より良い解決策のアイデアは、同じ問題にぶつかったときの2番目の例から生まれます。学界では、Haskellで独自のデザインの言語の通訳を書くように言われました。（これは私がFPとは何かを理解し始めることを余儀なくされた方法でもあります）。クロージャーを実装しているときに問題が発生しました。もう一度同じスコープは現在、複数の場所から参照することができます。この範囲を保持する変数を通じおよびネストされたスコープの親スコープとして！明らかに、それを指している参照のいずれかを介してこのスコープに変更が加えられた場合、この変更は他のすべての参照からも見える必要があります。 私が付いた解決策は、各スコープにIDを割り当て、Stateモナド内のすべてのスコープの中央辞書を保持することでした。これで、変数はスコープ自体ではなく、バインドされたスコープのIDのみを保持し、ネストされたスコープは親スコープのIDも保持するようになります。 私のモンスターバトルゲームでも同じアプローチが試みられると思います...フィールドとチームはモンスターを参照していません。代わりに、中央のモンスターディクショナリに保存されているモンスターのIDを保持しています。 ただし、問題の解決策として躊躇せずにそれを受け入れることができないというこのアプローチの問題をもう一度見ることができます。 これもまた、ボイラープレートコードのソースです。これにより、1行が必ず3行になります。以前は単一フィールドの1行のインプレース変更でしたが、現在は（a）中央ディクショナリからオブジェクトを取得する（b）変更を加える（c）新しいオブジェクトを保存する中央の辞書に。また、参照の代わりにオブジェクトと中央の辞書のIDを保持すると、複雑さが増します。FPは複雑さと定型コードを減らすために宣伝されているので、これは私が間違っていることを示唆しています。 さらに深刻な2番目の問題についても書きました。このアプローチではメモリリークが発生します。到達できないオブジェクトは、通常、ガベージコレクションされます。ただし、到達可能なオブジェクトがこの特定のIDを参照していない場合でも、中央の辞書に保持されているオブジェクトをガベージコレクションすることはできません。また、理論的に注意深いプログラミングによりメモリリークを回避できます（各オブジェクトが不要になったら、手動で中央ディクショナリから削除することもできます）が、これはエラーが発生しやすく、FPはプログラムの正確さを高めるようにアドバタイズされます。正しい方法ではありません。 しかし、解決された問題であるように思われました。WeakHashMapこの問題の解決に使用できるJavaが提供しています。C＃も同様の機能を提供します。ConditionalWeakTableただし、ドキュメントによると、コンパイラによる使用を目的としています。そしてHaskellにはSystem.Mem.Weakがあります。 そのような辞書を保存することは、この問題の正しい機能的な解決策ですか、それとも私が見落としているより単純なものがありますか？そのような辞書の数は簡単に増えてひどくなります。したがって、これらのディクショナリも不変であると想定されている場合、これは多くのパラメータを渡すことを意味します。または、それをサポートする言語では、モナド計算が行われます。これは、ディクショナリがモナドで保持されるためです（ただし、私は純粋に関数でそれを読んでいます）このディクショナリソリューションはほとんどすべてのコードをStateモナド内に配置しますが、これは正しいソリューションであるかどうかを疑います。 いくつか検討した後、もう1つ質問を追加します。このような辞書を作成することで何が得られるのでしょうか。多くの専門家によると、命令型プログラミングの問題点は、一部のオブジェクトの変更が他のコードに伝播することです。この問題を解決するために、オブジェクトは不変であると想定されています-このため、私が正しく理解していれば、オブジェクトに加えられた変更は他の場所には表示されないはずです。しかし、今は古くなったデータで動作する他のコードが気になるので、中央の辞書を発明して...もう一度、いくつかのコードの変更が他のコードに伝播するようにします！したがって、想定されるすべての欠点を伴う命令型のスタイルに戻りませんか？

10 design-patterns  pure-function 

アプリの無料版と有料版があるとしましょう。有料版は、ユーザーが利用できる機能に関する無料版のスーパーセットです。つまり、有料版は無料アプリのすべての機能に加えて追加機能を備えています。 起動時にロードされるフラグ（無料/有料など）に基づいて機能の可用性を切り替えるパターンはありますか？ どこにでも以下のコードブロックを用意するのは好きではありません。 if(isFreeVersion){ // ... } else { // ... } すべてのバージョンのために2つの別々のgitのブランチを持つことは、それは2を維持（またはそれ以上）のコードのソースを意味しますので、オプションではありません、一般的には非現実的と思われる、よりここで議論されています。バージョン管理で同じコードベースから二つの個別のソフトウェアバージョンを維持します。 これを行う方法はありますか？それでも、単一のコードベースがあり、無料/有料フラグをチェックする条件ステートメントでコードを散らかしていませんか？ これは以前に何度も議論されたと確信しており、この問題に取り組むためのいくつかのパターンがあると確信していますが、それを見つけることができません。 Android / Javaを使用しています。

10 design  design-patterns  programming-practices 

整数を入力として受け取り、その入力に基づいて異なるクラスの静的メソッドを呼び出すアプリケーションがあります。新しい番号が追加されるたびに、別のケースを追加して、異なるクラスの異なる静的メソッドを呼び出す必要があります。現在、スイッチには50のケースがあり、別のケースを追加する必要があるたびに、震えます。これを行うより良い方法はありますか？ 私はいくつか考えて、このアイデアを思いつきました。私は戦略パターンを使います。スイッチケースを持つ代わりに、キーが入力整数である戦略オブジェクトのマップがあります。メソッドが呼び出されると、オブジェクトが検索され、オブジェクトのジェネリックメソッドが呼び出されます。このようにして、switch case構文の使用を回避できます。 どう思いますか？

10 design-patterns  object-oriented-design 

組み込みデバイスの状態パターンでコーディングしています。Stateと呼ばれる基本/抽象クラスがあり、各離散（コンクリート）状態クラスが抽象状態クラスを実装します。 Stateクラスには、いくつかの抽象メソッドがあります。ディスクリート（コンクリート）クラスに抽象メソッドを実装しない場合、Visual Studioは次のようなエラーを出します。 ...エラー1 'myConcreteState'は継承された抽象メンバー 'myAbstractState'を実装していません さて、StateNameというStateごとにStringプロパティを作成しようとしています。新しい具象クラスを作成するときはいつでも、StateNameを定義する必要があります。使用しない場合はVSでエラーをスローする必要があります。これを行う簡単な方法はありますか？ 私は抽象/基本クラスでこれを試しました： public abstract string StateName { get; set; } ただし、各状態にGetメソッドとSetメソッドを実装する必要はありません。 改訂された質問：理想的な状況では、各Stateクラスは、StateNameを定義して抽象基本クラスから継承する必要があります。 StateName = "MyState1"; //or whatever the state's name is そのステートメントがない場合、Visual Studioは上記のエラーを生成します。これは可能ですか？可能な場合、どのようにですか？

10 c#  design-patterns  visual-studio  abstract-class 

私はDelphiパスカルプログラマーで、最新のEmbarcadero delphi XEを使用しています。モデルビューコントローラーやモデルビュービューモデルなどのデザインパターンを利用したいと思います。 ただし、これをPascalで行うためのベストプラクティスについては、Webに多くはないようです。私が見つけることができるほとんどの例はC＃にあり、一部の言語機能はPascalに存在しません。つまり、これらの機能を実装する方法を見つける必要があるかもしれません。 この記事のコードをここで適応させようとしています 私が直面している問題をリストします null許容型 PascalにはC＃のようにnull許容型がないため、独自に作成しました。 TNullable<T> = record strict private fHasValue : boolean; fValue : T; function GetValue:T; procedure SetValue(newValue : T); public property HasValue : boolean read fHasValue; property Value : T read GetValue write SetValue; procedure SetToNull; end; 実装セクション function TNullable<T>.GetValue:T; begin if fHasValue then …

10 design-patterns  mvc  mvvm  delphi  pascal 

ドメインドリブンデザインについて初めて知ったとき、データベースに対する穴居人のようなSQLクエリを投げたクールな子供たちにとって、かつては一流であるように思われるリポジトリと作業単位パターンも紹介されました。EFやNHibernateのようなORMは、作業単位とリポジトリの両方を1つのAPI（セッションまたはコンテキストと呼ばれる）に実装するため、そのトピックを深く掘り下げれば読むほど、それらは必要なくなったように見えます。 今、私は何をすべきかわかりません。リポジトリするかしないか。このようなリークの多い抽象化は複雑すぎてデータアクセスを簡略化するものは一切追加しないという主張を本当に理解していますが、アプリケーションのあらゆる側面をEntity Frameworkなどに結合するのは適切ではないと感じます。通常、私はいくつかの簡単なガイドラインに従います： ドメイン層は、エンティティ、サービス、リポジトリを含むシステムの中心です... インフラストラクチャ層は、ファイル、データベース、プロトコルなどのインフラストラクチャ関連のドメインインターフェイスの実装を提供します。 アプリケーション層は、物事を結び付け、すべてをオーケストレーションするコンポジションルートをホストします。 私の解決策は通常次のようになります： Domain.Module1 Domain.Module2 IModule2Repo IModule2Service Module2 Infrastructure.Persistence Repositories EntityFrameworkRepositoryBase MyApp Boostrapper -> inject EntityFrameworkRepositoryBase into IRepository etc. 私は、IRepository<'T>データへのアクセス方法を教えてくれる他のものに依存しないドメインの問題でもあるを使用して、ドメインレイヤーをクリーンに保ちます。IModule2Serviceデータアクセスを必要とする具体的な実装を行うときは、注入DbContextし、これによってインフラストラクチャレイヤーに直接結合する必要があります。（Visual Studioプロジェクトに入ると、循環依存関係のために、これは本当にトリッキーになる可能性があります！） さらに、作品の保管庫やファックトンの代わりになるものは何ですか？CQRS？純粋なインフラストラクチャフレームワークを抽象化するにはどうすればよいですか？

10 design-patterns  database  domain-driven-design  dependency-injection  repository 

でヘッドファーストデザインパターンでは教えて戦略パターンをダックの異なるサブクラスは、実行時に特定の動作を割り当てることができダックの例を使用して。私の理解では、戦略パターンの目的は実行時に単一のオブジェクトの動作を変更することですが、Duckの継承を使用してさまざまなタイプのDuckの動作を変更しています。 関連性？ Duckのコンテキスト継承は戦略パターンと無関係であるか、またはDuckのタイプを変更し、それらの動作も変更することは、戦略パターンを採用する正当な理由ですか？両方を変化させる必要がある状況は、戦略パターンを使用する正当な理由になりますか？なぜこれを戦略パターンの例として含めるのですか？ より簡単な例 Duckクラス（派生クラスなし）だけでこの例をさらに簡略化できますか？次に、1つのduckオブジェクトを実装するときに、独自のオブジェクトタイプに依存しない特定の状況に基づいて、異なる動作を割り当てることができます。例：FlyBehaviorは天気に基づいて変化し、QuackBehaviorは時刻またはアヒルの空腹度に基づいて変化します。これは本の問題とは異なる問題を解決することになると思いますが、私が探しているのは、頼りになる適切な戦略パターンの例です。 上記の私の例も戦略パターンを構成しますか？ 編集： 私は、コンテキストを継承しない単なる戦略パターンであるHunter.javaとsolver.pyに厳密に準拠する2つの単純な戦略パターンの例を見つけることに成功しました。

10 design  design-patterns  strategy  behavior 

Itemクラスの階層があるとしましょう：Rectangle, Circle, Triangle。それらを描画できるようにしたいので、私の最初の可能性はDraw()それぞれに仮想メソッドを追加することです： class Item { public: virtual ~Item(); virtual void Draw() =0; }; ただし、コアライブラリには基本的な表現しか含まれていないのに、描画機能を別のDrawライブラリに分割したいと思います。私が考えることができるいくつかの可能性があります： 1-のDrawManagerリストを受け取り、何をすべきかを計算Itemするdynamic_cast<>ために使用する必要がある： class DrawManager { void draw(ItemList& items) { FOREACH(Item* item, items) { if (dynamic_cast<Rectangle*>(item)) { drawRectangle(); } else if (dynamic_cast<Circle*>(item)) { drawCircle(); } .... } } }; これはRTTIに依存し、1つのクラスが階層内のすべての項目を認識するように強制するため、理想的ではありません。 2-もう1つのアプローチは、描画の責任をItemDrawer階層に任せることです（RectangleDrawerなど）。 class Item { virtual Drawer* GetDrawer() …

10 c++  design-patterns  polymorphism 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 4年前休業。 私は「パターンへのリファクタリング」という本を読んでいて、パターンをリファクタリングして使用する新しい方法を意図的に練習しなければスキルが上がらないので、どうしたらスキルを練習できるのかと考えていました。 しかし、事務処理では、各タスクをできるだけ早く完了する必要があります。ほとんどの場合、プロジェクトのデザインとアーキテクチャは私が管理しているのではなく、既存のコードと同様のスタイルに従うしかありません。悪いデザインのプロジェクトがあることもありますが、デザインスキルが私よりも優れている別の開発者もいて、彼はプロジェクト全体をリファクタリングする計画をすでに持っているので、私は彼の計画に従っています。練習する機会を得るにはどうすればよいですか？

10 self-improvement  design-patterns  refactoring 

私はいくつかの回答を見て、Googleで検索しましたが、役立つ情報は見つかりませんでした（つまり、厄介な副作用はありません）。 私の問題は、要約すると、オブジェクトがあり、それに対して長い一連の操作を実行する必要があることです。自動車をつくるような組み立てラインのようなものだと思います。 これらのオブジェクトはメソッドオブジェクトと呼ばれると思います。 したがって、この例では、ある時点でCarWithoutUpholsteryがあり、その上でinstallBackSeat、installFrontSeat、installWoodenInsertsを実行する必要があります（操作は相互に干渉せず、並列で実行されることもあります）。これらの操作はCarWithoutUpholstery.worker（）によって実行され、CarWithUpholsteryとなる新しいオブジェクトを生成します。このオブジェクト上で、おそらくcleanInsides（）、verifyNoUpholsteryDefects（）などを実行します。 単一フェーズでの操作は既に独立しています。つまり、私はすでに、それらのサブセットを任意の順序で実行できるように取り組んでいます（前部座席と後部座席は任意の順序でインストールできます）。 私のロジックは現在、実装を簡単にするためにリフレクションを使用しています。 つまり、CarWithoutUpholsteryを取得すると、オブジェクトは、performSomething（）と呼ばれるメソッドについてそれ自体を検査します。その時点で、これらのメソッドをすべて実行します。 myObject.perform001SomeOperation(); myObject.perform002SomeOtherOperation(); ... エラーやものをチェックしながら。操作の順序は重要ではありませんが、結局、何らかの順序が重要であることがわかった場合に備えて、辞書式順序を割り当てました。これはYAGNIと矛盾しますが、コストはごくわずか（単純なsort（））で、大規模なメソッドの名前変更（またはメソッドの配列など、テストを実行する他のメソッドを導入すること）を節約できます。 別の例 車を製造する代わりに、誰かに関する秘密警察の報告書を編集し、それを私の悪の支配者に提出しなければならないとしましょう。最後のオブジェクトはReadyReportです。それを構築するために、基本的な情報（名前、姓、配偶者...）を収集することから始めます。これは私のフェーズAです。配偶者の有無に応じて、フェーズB1またはB2に進み、1人または2人の性別データを収集する必要があります。これは、ナイトライフ、ストリートカム、セックスショップの売上レシートなどを制御するさまざまなEvil Minionsに対するいくつかの異なるクエリで構成されています。などなど。 被害者が家族を持たない場合、私はGetInformationAboutFamilyフェーズに入ることさえしませんが、そうする場合、私が最初に父親、母親、または兄弟（もしあれば）をターゲットにするかどうかは関係ありません。しかし、FamilyStatusCheckを実行していない場合はそれを行うことができません。したがって、これは以前のフェーズに属します。 すべてうまくいきます... 追加の操作が必要な場合は、プライベートメソッドを追加するだけです。 操作がいくつかのフェーズに共通している場合、スーパークラスから継承させることができます。 操作はシンプルで自己完結型です。ある操作の値が他の操作で必要になることはありません（実行する操作は別のフェーズで実行されます）。 作成者オブジェクトがそもそもこれらの条件を検証していなかった場合、それらは存在することさえできなかったため、将来のオブジェクトは多くのテストを実行する必要はありません。つまり、ダッシュボードにインサートを配置し、ダッシュボードをクリーニングし、ダッシュボードを確認するときに、ダッシュボードが実際にそこにあることを確認する必要はありません。 簡単にテストできます。私は簡単に部分オブジェクトをモックして、その上で任意のメソッドを実行でき、すべての操作は確定的なブラックボックスです。 ...だが... 問題は、メソッドオブジェクトの1 つに最後の操作を1つ追加したときに発生しました。これにより、モジュール全体が必須の複雑度インデックス（「N未満のプライベートメソッド」）を超えました。 私はすでにこの問題を2階で取り上げており、この場合、豊富なプライベートメソッドは災害の兆候ではないことを示唆しています。複雑さはあるが、しかし操作はので、それがありますされ、複雑な、そして実際に、それはすべてが複雑ではない-それだけだ長いです。 Evil Overlordの例を使用すると、私の問題は、Evil Overlord（別名拒否されるべきではない彼）がすべての食事情報を要求したことです。所有者など、そして悪（サブ）オーバーロード- 否定されるべきではない彼としてよく知られている-は、GetDietaryInformationフェーズで実行するクエリが多すぎると不平を言っています。 注：私はいくつかの観点からこれがまったく問題ではないことを認識しています（考えられるパフォーマンスの問題などを無視します）。起こっていることは、特定の測定基準が不幸であるということだけであり、それには正当化の余地があります。 何だと思い、私が行うことができます 最初のものを除いて、これらのオプションはすべて実行可能であり、防御可能だと思います。 私はこっそりできることを確認し、メソッドの半分を宣言しますprotected。しかし、私はテスト手順の弱点を利用しているので、捕まったときに自分自身を正当化することは別として、私はこれが好きではありません。また、それは応急措置です。必要な操作の数が2倍になった場合はどうなりますか？可能性は低いですが、それではどうでしょうか。 このフェーズを任意にAnnealedObjectAlpha、AnnealedObjectBravo、AnnealedObjectCharlieに分割し、各ステージで3分の1の操作を実行できます。これは実際には複雑さを増す（N-1クラス増える）という印象の下にあり、テストに合格する以外に利点はありません。もちろん、CarWithFrontSeatsInstalledとCarWithAllSeatsInstalledは論理的に連続したステージであると私は考えることができます。後でAlphaがBravoメソッドを必要とするリスクは小さく、うまく使えばさらに小さくなります。それでも。 リモートで類似したさまざまな操作を1つの操作にまとめることができます。performAllSeatsInstallation()。これはあくまで暫定的な措置であり、単一操作の複雑さが増します。操作AとBを異なる順序で実行する必要があり、E =（A + C）とF（B + D）内にそれらをパックした場合、EとFをアンバンドルしてコードをシャッフルする必要があります。 ラムダ関数の配列を使用して、チェックを完全に回避できますが、それは不格好です。ただし、これはこれまでのところ最良の代替手段です。それは反射を取り除くでしょう。私が抱えている2つの問題は、仮説だけでなく、すべてのメソッドオブジェクトを書き換えるように求められることです。これはCarWithEngineInstalled非常に優れたジョブセキュリティですが、それほど魅力的ではありません。また、コードカバレッジチェッカーにはラムダに関する問題があります（これは解決可能ですが、まだ問題です）。 そう... あなたは、どちらが私の最良の選択肢だと思いますか？ 私が考慮していないより良い方法はありますか？（たぶん、私はきれいに来て、それが何であるかを直接尋ねた方がいいですか？） この設計にはどうしようもない欠陥があり、私は敗北と溝掘りを認めるべきです-このアーキテクチャは完全にそうですか？私のキャリアには良くありませんが、長期的には、設計が不適切なコードを書く方が良いでしょうか？ 私の現在の選択は実際にはOne True Wayであり、より良い品質のメトリック（および/またはインストルメンテーション）をインストールするために戦う必要がありますか？この最後のオプションについては、参照が必要です...つぶやいているときに@PHBで手を振るだけでは、これらは探しているメトリックではありません。いくらでもやりたい

10 design-patterns  refactoring  complexity 

私は現在、AngularJS / JavaScript環境にいます。 現在、ポーリング方式を使用しているアプリケーション（つまり、一定の秒数でサーバーから新しいデータを取得する）。 これはかなりの負担であり、最新の結果をすぐに取得することはできません。サーバーがWebサービス機能にASMXを使用していると仮定します。可能であれば、大幅なオーバーホールを行わずに、アプリケーションの効率を向上させるにはどうすればよいですか？ 編集1： 課税とは、サーバーがさまざまなSQLテーブルと関連データなどを取得する必要があることを意味します。つまり、多数の同時ユーザーがいる場合、将来サーバーのパフォーマンスに問題が発生する可能性があるのではないかと心配しています。 現在、アプリケーションは要求/応答httpsタイプの呼び出しを使用しているため、最新のデータは取得されません。 モバイルアプリケーション側でさらに改善できますが、サーバー側ではサーバーのWebサービスファイルを除いて多くを変更することはできません。

10 design-patterns  javascript  angularjs  polling 

2つの間の類似点と相違点： テンプレートメソッド 継承に依存します。 アルゴリズムのステップを定義し、それらを実装するタスクをサブクラスに任せます。 ファクトリーメソッド 継承に依存します。 スーパークラスは、オブジェクトを作成するためのインターフェースを定義します。サブクラスは、インスタンス化する具象クラスを決定します。 2つ並べて： 「ファクトリーメソッドはテンプレートメソッドの特殊化」というフレーズの意味がわかりません（Head First Design Patternsブックにあります）。ではBeverage、私たちの方法持ってprepareいるfinalと一連の手順を定義します。にPizzaStoreあるメソッドがありabstract、サブクラスがそれを再定義します。後者は前者を特化したものですか？

10 design-patterns  object-oriented-design  factory-method  template-method 

よりエレガントで、プロセッサをCommandProcessorDispatcherクラスに注入する方法を見つけたいです。または、別のソリューションにすることもできます（目標は、各コマンド処理ロジックを独立したクラスに分離することです）。たぶん、ここでいくつかのデザインパターンが役立ちます。 public interface ICommand { } public class StartCommand : ICommand { } public class StopCommand : ICommand { } public interface ICommandProcessor<in T> where T : ICommand { void Process(T command); } public class StartCommandProcessor : ICommandProcessor<StartCommand> { public void Process(StartCommand command) { } } public class StopCommandProcessor : …

10 design-patterns  object-oriented  .net  single-responsibility