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

ソフトウェアに抽象化が多すぎて設計パターンが多すぎる、またはその逆を言うには、どうすればもっと多くの抽象化が必要かを知ることができますか？ 私が協力している開発者は、これらの点に関して異なる方法でプログラミングしています。 いくつかの小さな機能をすべて抽象化し、可能な限りデザインパターンを使用し、いかなるコストでも冗長性を回避します。 私を含む他の人は、より実用的であることを試み、すべての設計パターンに完全に適合するわけではありませんが、適用される抽象化が少ないため、理解がはるかに速いコードを記述します。 これはトレードオフであることを知っています。プロジェクトに十分な抽象化が行われていることをどのように確認できますか？ 例、Memcacheを使用して汎用キャッシングレイヤーを作成する場合。私たちは本当に必要ですかMemcache、MemcacheAdapter、MemcacheInterface、AbstractCache、CacheFactory、CacheConnector、...またはこれは、保守が容易とまだ良いコードは、これらのクラスの半分しか使用している場合ですか？ Twitterでこれを見つけました： （https://twitter.com/rawkode/status/875318003306565633）

29 design-patterns  architecture  clean-code  abstraction  architectural-patterns 

デメテルの法則は次のように述べています： 各ユニットは、他のユニットに関する限られた知識のみを持つ必要があります。現在のユニットに「密接に」関連するユニットのみです。 各ユニットは、その友人とのみ会話する必要があります。見知らぬ人と話をしないでください。 身近な友達とだけ話してください。 C＃6.0では、null-conditional operatorと呼ばれる新しい演算子が導入されました。私見、それはコーディングを容易にし、読みやすさを向上させます。ただし、クラスフィールドをナビゲートするのが簡単で、すでにヌル（のようなものvar x = A?.B?.C?.D?.E?.F?）をチェックしているため、より結合されたコードを簡単に記述できます。 この新しいオペレーターがデメテルの法則に反すると述べるのは正しいですか？

29 c#  design-patterns  object-oriented-design 

質問を注意深く読んでください：理由ではなく、方法を尋ねます。 私は最近、データベースを使用して不変データを保存することを提案するこの答えに出会いました： あなたが説明するマジックナンバーの多くは、特にそれらが部品に依存している場合は、コードではなく実際にデータであるように聞こえます。[...] SQLタイプのデータベースを意味する場合もあれば、単にフォーマットされたテキストファイルを意味する場合もあります。 あなたのプログラムが行うことの一部であるデータがある場合、やるべきことはプログラムにそれを置くことだと私には思えます。たとえば、プログラムの機能が母音をカウントすることvowels = "aeiou"である場合、その中にあることの何が問題になっていますか？結局のところ、ほとんどの言語には、まさにこの使用のために設計されたデータ構造があります。上記のように、「フォーマットされたテキストファイル」にデータを配置することで、データを分離するのはなぜですか？選択したプログラミング言語でフォーマットされたテキストファイルを作成しないのはなぜですか？これはデータベースですか？それともコードですか？ これは馬鹿げた質問だと思う人もいるかもしれませんが、真剣に質問します。「変数に誤解を招く名前を付けないでください」や「あなたの言語が取るに足らない」。 たとえば、次の記事をご覧ください：データをPuppetコードから分離する際の問題。問題？何の問題？Puppetがインフラストラクチャを記述するための言語である場合、ネームサーバーが8.8.8.8であることも記述できないのはなぜですか？問題はコードとデータが混在しているということではないように私には思える1が、人形は十分に豊富なデータ構造や他のものにインタフェースする方法を欠いていること。 このシフトが邪魔だと思います。オブジェクト指向プログラミングでは、「任意にリッチなデータ構造が必要」と言われたため、コードの力をデータ構造に付与しました。その結果、カプセル化と抽象化が行われます。SQLデータベースにもストアドプロシージャがあります。コードから腫瘍を取り除くかのように、データをYAMLまたはテキストファイルまたはダムデータベースに隔離すると、そのすべてが失われます。 コードからデータを分離するこのプラクティスがどのようになったのか、そしてそれがどこに向かっているのか、誰でも説明できますか？誰もが著名人による出版物を引用したり、「データからコードを分離する」ことを新たな戒めとして示し、その起源を示す関連データを提供できますか？ 1：そのような区別さえすることができれば。Lispプログラマーを探しています。

29 design-patterns 

3つのタスクを実行する大きなメソッドがあり、それぞれを個別の関数に抽出できます。そのタスクごとに追加の関数を作成する場合、コードが良くなるか悪くなるか、そしてその理由は何ですか？ 明らかに、メイン関数のコード行は少なくなりますが、追加の関数宣言があるので、クラスには追加のメソッドがありますが、クラスがより複雑になるため、これは良くないと思います。 すべてのコードを書く前にそれを行うべきですか、それともすべてが完了するまでそのままにしてから関数を抽出する必要がありますか？

29 java  design-patterns 

エンティティフレームワークが、レイヤー間でデータを転送するために同じプロパティを持つ新しいオブジェクトを作成するロジックを提供しないのはなぜですか？ エンティティフレームワークで生成したエンティティオブジェクトを使用します。

29 design  design-patterns  architecture  domain-driven-design  entity-framework 

データベースに文字列ペイロードを保存します。2つのグローバル構成があります。 暗号化 圧縮 これらは、構成を使用して有効または無効にすることができます。その場合、どちらか一方のみを有効にするか、両方を有効にするか、両方を無効にします。 私の現在の実装はこれです： if (encryptionEnable && !compressEnable) { encrypt(data); } else if (!encryptionEnable && compressEnable) { compress(data); } else if (encryptionEnable && compressEnable) { encrypt(compress(data)); } else { data; } デコレータパターンについて考えています。それは正しい選択ですか、それとももっと良い選択肢がありますか？

28 design  design-patterns  object-oriented-design  refactoring 

従来のクラス階層のよく知られた欠点は、実世界のモデリングに関しては悪いことです。例として、動物の種をクラスで表現しようとしています。実際にそれを行うといくつかの問題がありますが、解決策を見たことがないのは、サブクラスが、ペンギンが飛べないようなスーパークラスで定義された動作またはプロパティを「失う」場合ですおそらくより良い例ですが、それが私の頭に浮かぶ最初の例です）。 一方では、すべてのプロパティと動作について、それが存在するかどうかを指定するフラグを定義し、その動作またはプロパティにアクセスする前に毎回チェックする必要はありません。Birdクラスでは、鳥が簡単かつ明確に飛ぶことができると言いたいだけです。しかし、その後、どこか恐ろしいハックを使用することなく、「例外」を後で定義できればいいと思います。これは、システムがしばらくの間生産的だったときによく起こります。突然、元の設計にまったく適合しない「例外」が見つかり、それに対応するためにコードの大部分を変更する必要はありません。 それでは、「スーパークラス」とそれを使用するすべてのコードに大きな変更を加えることなく、この問題をきれいに処理できる言語または設計パターンがありますか？ソリューションが特定のケースのみを処理する場合でも、いくつかのソリューションが一緒になって完全な戦略を形成する場合があります。 もっと考えた後、リスコフの代替原則を忘れていたことに気付きました。それができない理由です。すべての主要な「機能グループ」に対して「特性/インターフェース」を定義すると仮定すると、階層のさまざまなブランチに特性を自由に実装できます。たとえば、Flying特性はBirds、いくつかの特殊なリスや魚によって実装できます。 したがって、私の質問は「どのようにして形質を実装しないのですか？」スーパークラスがJava Serializableである場合、たとえば「ソケット」が含まれている場合など、状態をシリアル化する方法がなくても、1つでなければなりません。 それを行う1つの方法は、最初から常にペアですべての特性を定義することです：FlyingとNotFlying（チェックしないとUnsupportedOperationExceptionがスローされます）。Not-traitは新しいインターフェースを定義せず、単純にチェックすることができます。特に最初から使用する場合、「安い」ソリューションのように聞こえます。

28 design-patterns  liskov-substitution 

すべてのプログラミングプロジェクトについて、過去のプログラミング経験のあるマネージャーは、プロジェクトのデザインパターンを推奨するときに輝かそうとします。理にかなっている場合、またはスケーラブルなソリューションが必要な場合、デザインパターンが好きです。たとえば、プロキシ、オブザーバー、コマンドパターンを積極的に使用してきましたが、毎日そうしています。しかし、オブジェクトを作成する方法が1つしかない場合、Factoryは将来的にすべてを簡単にする可能性がありますが、コードを複雑にし、純粋なオーバーヘッドであるため、Factoryパターンを使用することを本当にためらっています。 だから、私の質問は私の将来のキャリアと、ランダムなパターン名を投げるマネージャータイプに対する私の答えです： どのデザインパターンを使用しましたか？最悪の設計パターンはどれですか、それらが理にかなっている単一の状況を除いて考慮する必要があるものです（読んでください：どの設計パターンが非常に狭く定義されています）？（アマゾンの全体的な良い製品のネガティブなレビューを探して、デザインパターンを使用する際に最もバグを起こした人々を探しているようです。）そして、ここでアンチパターンについてではなく、通常と考えられるパターンについて話しています「良い」パターン。 編集：一部の人が答えたように、問題はほとんどの場合、パターンが「悪い」のではなく「間違って使用されている」ことです。パターンを知っていれば、それはしばしば誤用されるか、使用するのが難しい場合でも、答えとして当てはまります。

28 bad-code  anti-patterns  patterns-and-practices  design-patterns 

最近、私はたくさんの適度に大きなPythonのコードベースに出くわしたMyClassAbstractFactory、MyClassManager、MyClassProxy、MyClassAdapterなどのクラス。 一方で、それらの名前は、対応するパターンを調査し、学習するように私を指し示しましたが、クラスが何をするのかをあまり説明していませんでした。 また、彼らはプログラミングの単語の禁止リストに収まるように見える：variable、process_available_information、data、amount、compute：私たちの機能については何も教えていない、過度に広範な名前、単独で使用する場合。 CommunicationManagerそれとも、あるべきPortListenerでしょうか？または、私は問題をまったく理解していないかもしれません...？

28 design-patterns  naming 

異なるロールを持つ複数のユーザーが含まれるリソースにアクセスできるREST APIを構築しています。 スコープをシンプルに保つために、「student / teacher / class」ドメインを取り上げます。 GET /students アクセスするリソースです。 ユーザーには、学生や教師などの役割がある場合があります 生徒はクラスの生徒にのみアクセスできます。教師は、教えるクラスの生徒にアクセスできます。いくつかの用途は学生であり、他のクラスも教えます。彼らは彼らのクラスの生徒と彼らが教えるクラスの生徒にアクセスできなければなりません。 理想的には、これを2つの機能として実装します。ロールごとに1つ、ユーザーが複数のロールを持つ場合は「結合」します。 私の質問は、これを実装するためにどのパターンを使用すればよいですか？ 外部的に ロールごとにAPIを分割する必要がありますか？GET /teacher/studentsそしてGET /student/studentsそれは右の私には思われません。 すべてを維持する私は1つのリソースです（推奨） 内部的に 内部的にどのように実装する必要がありますか？ すべての方法は、BIGスイッチで開始する必要がありますか、役割ごとに行う必要がありますか 役割ごとにリポジトリを実装する必要がありますか？ これを達成するのに役立つ設計パターンはありますか？ 副次的なコメントとして：私はASP.NET Web APIとEntity Framework 6を使用していますが、概念的な実装には関係ありません。

27 design-patterns  programming-practices  rest  web-api 

誰かが、Observerとの違いについての標準的な答えと、Mediatorあるパターンを他のパターンよりも使用する必要がある場合の要約を私に提供できますか？ 私が必要となる状況の種類が不明だObserverとどのような種類が必要になりますMediator

27 design-patterns 

シングルトンパターンに関するさまざまな意見を読みました。一部の人は、すべてのコストで回避する必要があると主張し、他の人は、特定の状況で役立つ可能性があると主張しています。 シングルトンを使用する1つの状況は、特定のクラスAのオブジェクトを作成するためにファクトリー（たとえば、タイプFのオブジェクトf）が必要な場合です。ファクトリーは、いくつかの構成パラメーターを使用して一度作成され、その後、タイプAがインスタンス化されます。したがって、Aをインスタンス化するコードのすべての部分は、シングルトンfをフェッチし、新しいインスタンスを作成します。たとえば、 F& f = F::instance(); boost::shared_ptr<A> a = f.createA(); 一般的な私のシナリオは 最適化の理由（複数のファクトリオブジェクトは必要ありません）または共通の状態を共有するためにクラスのインスタンスが1つだけ必要です（たとえば、ファクトリはAのインスタンスをいくつ作成できるかを知っています） コードのさまざまな場所でFのこのインスタンスfにアクセスする方法が必要です。 このパターンが良いか悪いかについての議論には興味がありませんが、シングルトンの使用を避けたい場合、他にどのようなパターンを使用できますか？ 私が持っていたアイデアは、（1）レジストリからファクトリオブジェクトを取得するか、（2）プログラムの起動中のある時点でファクトリを作成し、パラメータとしてファクトリを渡すことでした。 ソリューション（1）では、レジストリ自体がシングルトンであるため、シングルトンを使用しないという問題を工場からレジストリに移行しました。 （2）の場合、ファクトリオブジェクトの元となる初期ソース（オブジェクト）が必要なので、別のシングルトン（ファクトリインスタンスを提供するオブジェクト）に再びフォールバックするのではないかと心配しています。このシングルトンのチェーンをたどると、他のすべてのシングルトン を直接または間接的に管理する1つのシングルトン（アプリケーション全体）に問題を減らすことができます。 この最後のオプション（他のすべての一意のオブジェクトを作成し、他のすべてのシングルトンを適切な場所に注入する1つの初期シングルトンを使用）は、許容できる解決策でしょうか？これは、シングルトンを使用しないことを勧めるときに暗黙的に提案される解決策ですか、それとも他の解決策は何ですか？ 編集 私の質問の要点は一部の人によって誤解されていると思うので、ここにいくつかの情報があります。ここで説明するように、シングルトンという言葉 は、（a）単一インスタンスオブジェクトを持つクラスと、（b）そのようなオブジェクトの作成とアクセスに使用されるデザインパターンを示すことができます。 物事を明確にするために、（a）には ユニークオブジェクト、（b）にはシングルトンパターンという用語を使用します。だから、私はシングルトンパターンと依存性注入が何であるかを知っています（最近、私は作業中のコードからシングルトンパターンのインスタンスを削除するためにDIを多用しています）。 私のポイントは、オブジェクトグラフ全体がmainメソッドのスタックにある単一のオブジェクトからインスタンス化されない限り、シングルトンパターンを通じていくつかの一意のオブジェクトに常にアクセスする必要があるということです。 私の質問は、完全なオブジェクトグラフの作成と配線をメインメソッドに依存させること（たとえば、パターン自体を使用しない強力なDIフレームワークを使用すること）が、シングルトンパターンを使用しない唯一のソリューションかどうか です。

27 design-patterns  programming-practices  anti-patterns  singleton 

既存のアプリケーションのグリーンフィールドモジュールにDDDのようなアプローチを使用しています。アーキテクチャが原因で100％DDDではありませんが、いくつかのDDDの概念を使用しようとしています。：2つのエンティティからなる-私は（私はまだDDDについて学んだ私はそれが適切な用語だと思う）有界コンテキストを持っているConversationとMessage。メッセージは会話なしでは存在せず、システム内のすべてのメッセージは会話の一部であるため、会話がルートです。 私が持っているConversationRepository、データベース内の会話を見つける（それは本当に多くのゲートウェイのように、私は用語「リポジトリ」を使用しますが）クラスを。会話を見つけると、（ファクトリを介して）その会話のメッセージのリストも作成します（プロパティとして公開されます）。これはMessageRepository、会話が取得されたときにのみ存在するため、本格的なクラスは必要ないと思われるため、物事を処理する正しい方法のようです。 ただし、メッセージの保存に関しては、メッセージの集約ルートであるため、これはConversationRepositoryの責任ですか？つまり、ConversationRepositoryで、たとえばAddMessageMessageをパラメーターとして受け取り、データベースに保存するというメソッドが必要ですか？または、メッセージを検索/保存するための別のリポジトリを用意する必要がありますか？論理的なことは、エンティティごとに1つのリポジトリのようですが、「コンテキストごとに1つのリポジトリ」も聞いたことがあります。

27 design-patterns  architecture  domain-driven-design 

私は、MVC3でNInjectを使用した依存性注入にかなり満足しています。MVC3アプリケーションでの作業中に、私はNInjectを使用してカスタムコントローラー作成ファクトリを開発しました。そのため、作成されたコントローラーには、このコントローラーファクトリを介して依存関係が注入されます。 今、私はWindowsアプリケーションを開発し始めています、私はアプリケーション全体の依存性注入を使用したいと思います。つまり、ユニットテストを容易にするために、すべてのオブジェクトをNInjectを介して作成する必要があります。作成されたすべてのオブジェクトがNInject Factoryのみを通過するようにする必要があります。 たとえば、Button_Clickイベントで任意のWindowsフォームで次のように記述した場合： TestClass testClass = new TestClass() そしてTestClass、たとえば、上の任意の依存関係を持ってITest、それが自動的に解決されなければなりません。私が使用できることを知っています： Ikernel kernel = new StandardKenel() //AddBinding() TestClass testClass = kenel.get<TestClass>(); しかし、オブジェクトを作成するたびにこれを行うのは面倒です。また、開発者は特定の方法でオブジェクトを作成する必要があります。もっと良くできますか？ オブジェクト作成用の中央リポジトリを作成すると、すべてのオブジェクト作成でそのリポジトリが自動的に使用されますか？

27 .net  design-patterns  unit-testing  dependency-injection 

プログラマーが意味をなさない領域に物事をまとめる傾向があるコードベースがあります。たとえば、エラーログがある場合、次の方法でログインできます。 ErrorLog.Log(ex, "friendly message"); 彼は、まったく同じタスクを達成するために他のさまざまな手段を追加しました。例えば SomeClass.Log(ex, "friendly message"); 単に向きを変えて最初のメソッドを呼び出します。これにより、利点が追加されずに複雑さが増します。これを説明するアンチパターンはありますか？

26 design-patterns  anti-patterns