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

私はギャングオブフォーを読んでいますいくつかの問題を解決するためにて、Mediatorパターンに出くわしました。 以前使用していた 、プロジェクトでいくつかのGUIアプリケーションを作成するためにObserverを。この2つに大きな違いはないので、少し混乱しています。違いを見つけるために閲覧しましたが、私のクエリに対する適切な答えを見つけることができませんでした。 2人を明確に区別するいくつかの良い例で2人を区別するのに役立つ人がいますか？

93 oop  design-patterns  observer-pattern  mediator 

ヘルパー/ユーティリティクラスに関するこれらの簡単な質問に対する良い答えを見つけたことはありません。 静的メソッドを使用する代わりにシングルトン（ステートレス）を作成するのはなぜですか？ オブジェクトに状態がない場合、オブジェクトインスタンスが必要になるのはなぜですか？

92 java  design-patterns  singleton 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 この質問を改善する Cプロジェクトの設計中に従うことができる既知の設計原則、ベストプラクティス、および設計パターンはありますか？それとも、手続き型（命令型）プログラミング全般に役立つ設計原則ですか？ （私は「オブジェクト指向世代」の子であり、初めて大規模なCプロジェクトを設計する必要があります）

91 c  design-patterns  principles 

それに直面しよう。Singletonパターンは、非常に論争の大群プログラマーとトピックの両方フェンスの脇。シングルトンは栄光のグローバル変数に過ぎないと感じている人や、パターンで誓い、それを絶え間なく使用している人もいます。ただし、シングルトン論争が私の質問の中心にあるのは望ましくありません。 誰もが綱引きを持って戦い、私が気にかけているすべてのことで誰が勝つかを確認できます。私が言おうとしているのは、正解が1つあるとは思わないことであり、意図的に炎上党派の口論をしようとしているのではありません。私が質問するとき、私は単にシングルトンの選択肢に興味があります： GOFシングルトンパターンに代わるものはありますか？ たとえば、過去にシングルトンパターンを何度も使用したことがあるのですが、1つまたは複数の変数の状態/値を保存することに単に関心があります。ただし、変数の状態/値は、シングルトンパターンを使用する代わりに、静的変数を使用してクラスの各インスタンス化間で保持できます。 他にどんなアイデアがありますか？ 編集： 「シングルトンを正しく使用する方法」に関する別の投稿にしたくありません。繰り返しますが、それを回避する方法を探しています。楽しいですか？私はあなたの映画の予告編の声で純粋に学術的な質問をしていると思います。「シングルトンが存在しないパラレルユニバースでは、何ができるでしょうか？」

91 design-patterns  singleton 

我々は、すべての方法を知っている悪いシングルトン彼らは依存関係を非表示にするためにためている他の理由。 しかし、フレームワークでは、一度だけインスタンス化してどこからでも呼び出す必要のある多くのオブジェクト（ロガー、dbなど）が存在する可能性があります。 この問題を解決するために、サービス（ロガーなど）へのすべての参照を内部的に保存する、いわゆる「オブジェクトマネージャー」（またはsymfonyのようなサービスコンテナー）を使用するように言われました。 しかし、サービスプロバイダーが純粋なシングルトンほど悪くないのはなぜですか？ サービスプロバイダーも依存関係を隠し、最初のインスタンスの作成をラップアウトするだけです。そのため、シングルトンの代わりにサービスプロバイダーを使用する理由を理解するのに本当に苦労しています。 PS。依存関係を隠さないようにするには、DIを使用する必要があることを知っています（Miskoが述べたように） 追加 私は付け加えます：最近のシングルトンはそれほど悪ではありません、PHPUnitの作成者はここでそれを説明しました： http://sebastian-bergmann.de/archives/882-Testing-Code-That-Uses-Singletons.html DI +シングルトンは問題を解決します： <?php class Client { public function doSomething(Singleton $singleton = NULL){ if ($singleton === NULL) { $singleton = Singleton::getInstance(); } // ... } } ?> これですべての問題が解決されなくても、それはかなりスマートです。 DIとService Container以外に、このヘルパーオブジェクトにアクセスするための適切なソリューションはありますか？

91 php  oop  design-patterns  frameworks 

現在のところ、この質問はQ＆A形式には適していません。私たちは回答が事実、参考文献、または専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張された議論を誘います。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 私は特に、ファットモデルと細いコントローラーのアプローチを支持する多くのブログを読んでいます。Railsキャンプ。その結果、ルーターは基本的に、どのコントローラーでどのメソッドを呼び出すかを理解しているだけであり、すべてのコントローラーメソッドは、モデルの対応するメソッドを呼び出してビューを表示します。だから私はここで私が理解できない2つの懸念を持っています： コントローラーとルーターは、ルートに基づいて神のようなモデルでメソッドを呼び出す以外に、実際にはそれほど異なるタスクを実行していません。 モデルがやりすぎです。電子メールの送信、関係の作成、他のモデルの削除と変更、タスクのキューイングなど。基本的に、データのモデリングと処理に関係するかどうかに関係なく、すべてを実行することになっている神のようなオブジェクトがあります。 どこに線を引くのですか？これは単に神のパターンに該当するのではないですか？

91 model-view-controller  design-patterns  architecture  god-object 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 6年前休業。 この質問を改善する Springフレームワークで使用されている設計パターンは何ですか？

90 design-patterns  spring 

Mapを返すメソッドを書いているとしましょう。例えば： public Map<String, Integer> foo() { return new HashMap<String, Integer>(); } しばらく考えた結果、このマップが作成された後で変更する理由はないと判断しました。したがって、私はImmutableMapを返したいと思います。 public Map<String, Integer> foo() { return ImmutableMap.of(); } 戻り値の型を汎用のMapのままにするか、ImmutableMapを返すように指定する必要がありますか？ 一方で、これがまさにインターフェースが作成された理由です。実装の詳細を非表示にします。 一方、このままにしておくと、他の開発者はこのオブジェクトが不変であるという事実を見逃す可能性があります。したがって、私は不変オブジェクトの主要な目標を達成しません。変更可能なオブジェクトの数を最小限に抑えてコードをより明確にするため。最悪の場合でも、しばらくすると、誰かがこのオブジェクトを変更しようとする可能性があり、これによりランタイムエラーが発生します（コンパイラーは警告しません）。

90 java  design-patterns  immutable-collections 

WinFormsを使用して、MVPメソッドを初めて実装しようとしています。 各層の機能を理解しようとしています。 私のプログラムには、クリックするとopenfiledialogウィンドウを開くGUIボタンがあります。 したがって、MVPを使用して、GUIはボタンクリックイベントを処理し、presenter.openfile（）;を呼び出します。 presenter.openfile（）内で、ファイルのオープンをモデルレイヤーに委任する必要がありますか、または処理するデータやロジックがないので、リクエストに基づいて単純にopenfiledialogウィンドウを開く必要がありますか？ 更新： 私はこれについてさらに支援が必要だと感じたときに報奨金を提供することを決定しました。できれば、以下の特定のポイントに合わせて調整し、状況を把握できるようにします。 さて、MVPについて読んだ後、パッシブビューを実装することにしました。事実上、プレゼンターによって処理されるWinform上の一連のコントロールと、モデルに委任されたタスクを用意します。私の具体的なポイントは以下のとおりです。 Winformが読み込まれると、ツリービューを取得する必要があります。ビューはしたがってpresenter.gettree（）などのメソッドを呼び出す必要があると私は思っていますか？これは、モデルに委譲し、ツリービューのデータを取得し、作成して構成し、それをプレゼンターは、ビューに渡され、ビューに単純に割り当てられます。 これはWingridのデータコントロールでも同じですか？私もdatagridviewを持っているのですか？ 私のアプリには、同じアセンブリを持つ多数のモデルクラスがあります。また、起動時にロードする必要があるプラグインを備えたプラグインアーキテクチャもサポートしています。ビューは単にプレゼンターメソッドを呼び出し、プラグインをロードしてビューに情報を表示するメソッドを呼び出しますか？その後、どの層がプラグイン参照を制御します。ビューは彼らまたは発表者への参照を保持しますか？ ツリービューのノードの色からデータグリッドのサイズなど、ビューはプレゼンテーションに関するすべてのことを処理するべきだと私は思っていますか？ それらが私の最大の関心事であると私は思います、そしてこれらの流れがどうあるべきかを理解していれば、私は大丈夫だと思います。

90 c#  .net  winforms  design-patterns  mvp 

ディレクトリをtar.gzして使用しようとしています tar -czf workspace.tar.gz * 結果のtarには.svn、サブディレクトリにディレクトリが含まれますが、現在のディレクトリには含まれません（*tarに渡される前に「表示」ファイルのみに展開されるため） 私がしようとしました tar -czf workspace.tar.gz .代わりに、「。」が原因でエラーが発生します。読んでいる間に変更されました： tar: ./workspace.tar.gz: file changed as we read it *ディレクトリ内のすべてのファイル（ドットプレフィックスを含む）に一致するようにするトリックはありますか？ （Linux SLES-11（2.6.27.19）でbashを使用）

89 linux  bash  design-patterns  tar 

クローズ。この質問はもっと焦点を合わせる必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てるようにします。 6年前に閉鎖されました。 この質問を改善する Reactorパターンはウィキペディアで説明されていますが、少し抽象的すぎます。このパターンをより具体的に説明できますか？理想的には、reactorパターンのいくつかのアプリケーションを説明するコードスニペットまたは高レベルのクラス図を使用します。

89 design-patterns 

依存性注入またはシングルトンパターンをいつ使用するかをどのように識別しますか。「シングルトンパターンよりも依存性注入を使用する」と書かれている多くのWebサイトを読んだことがあります。しかし、私がそれらに完全に同意するかどうかはわかりません。私の中小規模のプロジェクトでは、シングルトンパターンの使用は間違いなく簡単です。 たとえば、ロガー。使用できますLogger.GetInstance().Log(...) が、これの代わりに、作成したすべてのクラスにロガーのインスタンスを挿入する必要があるのはなぜですか？

88 design-patterns  oop  dependency-injection 

私は質問をされました、私は私の答えをここでレビューしてもらいたいと思いました。 Q：インターフェースを実装するよりも、抽象クラスを拡張する方が適切なシナリオはどれですか？ A：テンプレートメソッドデザインパターンを使用している場合。 私は正しいですか？ 質問を明確に述べることができなかった場合は申し訳ありません。 抽象クラスとインターフェイスの基本的な違いを知っています。 1）特定の操作（メソッドの実装）ではすべてのサブクラスに同じ機能を実装し、他のいくつかの操作（メソッドシグネチャのみ）では異なる機能を実装する必要がある場合は、抽象クラスを使用します 2）インターフェースの実装に準拠できるように、署名を同じ（および実装が異なる）にする必要がある場合は、インターフェースを使用します 3）最大1つの抽象クラスを拡張できますが、複数のインターフェースを実装できます 質問を繰り返します：上記のシナリオ以外に、特に抽象クラスを使用する必要があるシナリオはありますか（テンプレートメソッドのデザインパターンは概念的にこれのみに基づいていることがわかります）？ インターフェイスと抽象クラス これら2つのどちらを選択するかは、実際には何をしたいかによって異なりますが、幸いなことに、ErichGammaは私たちを少し助けてくれます。 常にトレードオフがありますが、インターフェイスは基本クラスに関して自由を与え、抽象クラスは後で新しいメソッドを追加する自由を与えます。–エーリヒ・ガンマ コード内の他の多くのものを変更せずにインターフェイスに移動して変更することはできないため、これを回避する唯一の方法は、まったく新しいインターフェイスを作成することです。これは必ずしも良いことではない場合があります。 Abstract classes主に密接に関連するオブジェクトに使用する必要があります。Interfaces無関係なクラスに共通の機能を提供するのに優れています。

87 java  design-patterns  interface  abstract-class 

アルゴリズムをクラスから切り離すことについては多くの話があります。しかし、説明されていないことが1つあります。 彼らはこのような訪問者を使用します abstract class Expr { public <T> T accept(Visitor<T> visitor) {visitor.visit(this);} } class ExprVisitor extends Visitor{ public Integer visit(Num num) { return num.value; } public Integer visit(Sum sum) { return sum.getLeft().accept(this) + sum.getRight().accept(this); } public Integer visit(Prod prod) { return prod.getLeft().accept(this) * prod.getRight().accept(this); } visit（element）を直接呼び出す代わりに、Visitorは要素にvisitメソッドを呼び出すように要求します。それは、訪問者についてのクラスの無意識の宣言された考えと矛盾します。 PS1あなた自身の言葉で説明するか、正確な説明を指摘してください。私が得た2つの応答は、一般的で不確実なものに言及しているためです。 PS2私の推測：getLeft()基本的なを返すのでExpression、呼び出すvisit(getLeft())と結果が得られますvisit(Expression)が、getLeft()呼び出すvisit(this)と別のより適切な訪問呼び出しが発生します。したがって、accept()型変換（別名キャスト）を実行します。 PS3 Scalaのパターンマッチング=ステロイドのビジターパターンは、acceptメソッドなしでビジターパターンがどれほど単純であるかを示しています。ウィキペディアはこの声明に次のように付け加えていaccept()ます。「リフレクションが利用できる場合はメソッドは不要であり、テクニックに「ウォークアバウト」という用語を導入している」という論文をリンクしています。

87 design-patterns  visitor 

まず、誰かがだまされて叫ぶ前に、私はそれを簡単なタイトルに要約するのに苦労しました。別のタイトルは「ドメインモデルとMVCモデルの違いは何ですか？」だったかもしれません。または「モデルとは何ですか？」 概念的には、モデルはビューとコントローラーによって使用されるデータであると理解しています。それを超えて、モデルを構成するものについては多くの異なる意見があるようです。ドメインモデル、アプリモデル、ビューモデル、サービスモデルなどとは何ですか。 たとえば、リポジトリのパターンについて最近尋ねた質問で、リポジトリはモデルの一部であると空白で言われました。ただし、モデルを永続性モデルおよびビジネスロジック層から分離する必要があるという他の意見を読みました。結局のところ、リポジトリパターンは、具体的な永続化メソッドをモデルから切り離すことになっているのではないでしょうか。ドメインモデルとMVCモデルには違いがあると言う人もいます。 簡単な例を見てみましょう。MVCデフォルトプロジェクトに含まれているAccountController。含まれているアカウントコードの設計が不十分である、SRPに違反しているなど、いくつかの意見を読みました。MVCアプリケーションの「適切な」メンバーシップモデルを設計する場合、それは何でしょうか。 ASP.NETサービス（メンバーシッププロバイダー、ロールプロバイダーなど）をモデルからどのように分離しますか？それともあなたはまったく？ 私の見方では、モデルはおそらく検証ロジックを備えた「純粋」である必要がありますが、ビジネスルール（検証以外）から分離する必要があります。たとえば、新しいアカウントが作成されたときに誰かにメールを送信する必要があるというビジネスルールがあるとします。それは私の見解では実際にはモデルに属していません。それで、それはどこに属しますか？ この問題に光を当てる気がある人はいますか？

86 asp.net-mvc  model-view-controller  design-patterns  business-logic-layer