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

何年も前、私は経済学の教授と、デザインパターン、プログラマー向けの共通言語の確立方法、よく知られている問題をうまく解決する方法などについて話していました。 それから彼は、これは彼が経済学の学生に使用するのとまったく反対のアプローチであると私に話しました。彼は通常問題を提示し、最初に解決策を見つけるように依頼したので、彼らは最初にそれについて考え、最初に問題を解決する方法を見つけようと試みました。 だから私は、「デザインパターン」アプローチが本当にプログラマーを賢くするのか、または愚かなものにするのかと考えていました。新しい革新的な方法。 どう思いますか？

21 design-patterns 

ときどきファクトリーとMVC以外にデザインパターンを使用することはあまりないので、もっと使い始めたいです。 このケースでのデザインパターンの使用について、あなたの意見が欲しいという具体的なケースがあります。 私のアプリケーションでは、さまざまな状況でかなり頻繁にオブジェクトを変換する必要があります。GWTを使用しており、Hibernate POJOはシリアル化できず、回線経由で送信できないため、Hibernate POJOをDTOに変換する必要がある場合があります。 別の状況では、Solrによるインデックス作成のためにJavaオブジェクトをSolrInputDocumentに変換する必要があるかもしれません。 このためにデザインパターンを使用する必要があるかどうかを知りたいです。「オブジェクトの変換」は、パターンによって柔軟/抽象的な方法で処理できる一般的なタスクのようですが、実際にはどうなるかわかりません。 パターンがなければ、CourseToSolrInputDocument（CourseはアプリケーションのHibernateエンティティです）など、変換のタイプごとに個別のクラスを作成するだけです。またはCourseToCourseDTO。これらの各変換クラスにconvert()は、ソースオブジェクトを入力として受け取り、出力オブジェクトを返す単一の静的メソッドが呼び出される場合があります。 しかし、それは実際にはパターンではありませんか？そこで、ジェネリックを使って何かから始めて、Converterインターフェイスを実装するこのクラスを作成しました。しかし、どういうわけか、愚かなtgoがジェネリックインターフェイスを作成していると感じています。 public class CourseToSolrInputDocument implements Converter<Course, SolrInputDocument> { @Override public void convert(Course source, SolrInputDocument destination) { //To change body of implemented methods use File | Settings | File Templates. } } したがって、ここでの本当の質問は、汎用オブジェクト変換に適用されるパターンがありますか？また、あなたのアプローチは何ですか？また、変換ごとのクラス型アプローチを使用するよりも利点は何ですか？

21 java  design-patterns  object 

私はリクエストを処理するプロジェクトに取り組んでおり、リクエストにはコマンドとパラメーターの2つのコンポーネントがあります。各コマンドのハンドラーは非常にシンプルです（<10行、多くの場合<5）。少なくとも20のコマンドがあり、50を超える可能性があります。 私はいくつかの解決策を考え出しました： コマンド上の1つの大きなスイッチ/ if-else 機能へのコマンドのマップ 静的クラス/シングルトンへのコマンドのマップ 各コマンドは少しエラーチェックを行い、抽象化できるビットは、各コマンドに定義されているパラメーターの数をチェックすることだけです。 この問題の最善の解決策は何ですか？また、その理由は何ですか？また、私が見逃したかもしれないデザインパターンにもオープンです。 それぞれについて、次の賛否両論のリストを作成しました。 スイッチ 長所 すべてのコマンドを1つの関数に保持します。シンプルなので、これは視覚的なルックアップテーブルになります 1か所でしか使用されない大量の小さな関数/クラスでソースを乱雑にする必要はありません。 短所 とても長い プログラムでコマンドを追加するのが難しい（デフォルトのケースを使用してチェーンする必要がある） マップコマンド->関数 長所 小さい一口サイズのチャンク プログラムでコマンドを追加/削除できる 短所 インラインで行う場合、スイッチと視覚的に同じ インラインで行われない場合、多くの機能が1か所でのみ使用されます マップコマンド->静的クラス/シングルトン 長所 ポリモーフィズムを使用して単純なエラーチェックを処理できます（3行だけですが、それでも） マップと同様のメリット->機能ソリューション 短所 多くの非常に小さなクラスがプロジェクトを混乱させます 実装がすべて同じ場所にあるわけではないため、実装をスキャンするのは簡単ではありません 追加のメモ： 私はGoでこれを書いていますが、ソリューションは言語固有のものではないと思います。他の言語でも非常に似たようなことをする必要があるかもしれないので、私はより一般的な解決策を探しています。 コマンドは文字列ですが、便利であれば、これを簡単に数値にマップできます。関数のシグネチャは次のようなものです。 Reply Command(List<String> params) Goにはトップレベルの機能があり、私が検討している他のプラットフォームにもトップレベルの機能があるため、2番目と3番目のオプションの違いがあります。

21 design  design-patterns  map  switch-statement 

私の現在の仕事では、古いコードを数回クリーンアップする仕事をしました。多くの場合、コードは迷路であり、その背後のデータはさらに複雑です。私は物事をすてきな、きちんとした、モジュール式の方法にまとめると思います。各メソッドは1つのことを行い、それをうまく行います。それは物事が南に行き始めるときです... 常に、私はきれいなAPIになり、それをすべて結びつける実際の方法はありません。解決策は、最終的にすべての「クリーン」メソッドを呼び出す、大きない「グルー」メソッド（通常は条件ステートメントでいっぱい）を記述することです。 通常、glueメソッドは、クリーンアップしようとしたコード/データのもつれの簡潔なバージョンになります。一般的に読みやすいですが、それでもいらいらします。 そのような方法を避けるにはどうすればよいですか？これはもつれたデータの症状なのでしょうか、それとも私が間違っていることを反映しているのでしょうか？

21 design-patterns  object-oriented  programming-practices  ruby 

私は開発チームでかなり新しいです。 いくつかの強力な議論や「落とし穴」の例が必要なので、上司は最終的にUnobtrusive JavaScriptの利点を理解し、彼とチームの他のメンバーがこのようなことをやめるようにします。 <input type="button" class="bow-chicka-wow-wow" onclick="send_some_ajax(); return false;" value="click me..." /> そして <script type="text/javascript"> function send_some_ajax() { // bunch of code ... BUT using jQuery !!! } </script> かなり一般的なパターンを使用することをお勧めします。 <button id="ajaxer" type="button">click me...</button> そして <script type="text/javascript"> // since #ajaxer is also delivered via ajax, I bind events to document …

21 design-patterns  javascript  jquery 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 データモデルには、約12の機能領域に分離できるほぼ200のクラスがあります。ドメインを使用するのは良かったのですが、分離はそれほどきれいではなく、変更することはできません。 エンティティフレームワークを使用するようにDALを再設計しており、これまで見てきたほとんどの推奨事項は、リポジトリパターンの使用を推奨しています。ただし、実際に複雑なオブジェクトモデルを扱うサンプルはありません。私が見つけたいくつかの実装は、エンティティごとのリポジトリの使用を提案しています。これは、大規模で複雑なモデルにとってはばかげており、維持できないようです。 操作ごとにUnitOfWorkを作成し、エンティティごとにリポジトリを作成する必要は本当にありますか？数千のクラスになってしまう可能性があります。これが不合理であることは知っていますが、リポジトリ、作業単位、およびエンティティフレームワークを複雑なモデルや現実的なビジネスアプリケーションに実装するガイダンスはほとんど見つかりませんでした。

21 asp.net-mvc  entity-framework  design-patterns 

メソッドチェーンを使用してオブジェクトをセットアップするパターンを頻繁に使用しますが、Builderor Prototypeパターンに似ていますが、各メソッド呼び出しで新しいオブジェクトを作成せず、代わりに元のオブジェクトを変更します。 例： new Menu().withItem("Eggs").withItem("Hash Browns").withStyle("Diner"); このパターンに名前があるのか​​、それがアンチパターンと見なされるのかどうか疑問に思うだけです。なぜなら、より流に読むことができても、長いメソッドチェーンにつながる可能性があるからです。

21 design-patterns  coding-style  code-quality  patterns-and-practices  method-chaining 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 非同期のノンブロッキングイベント駆動プログラミングが大流行しているようです。これが何を意味するのか、基本的な概念を理解しています。しかし、私が確信していないのは、コードが非同期であることのメリットとなるタイミングと場所、またはブロッキングIOを非ブロッキングにする方法です。ライブラリを使用してこれを行うことができると確信していますが、より深い概念と、それを自分で実装するさまざまな方法にもっと興味があります。 このテーマに関する包括的な/決定的な書籍、または他のリソース（デザインパターンのGoF、CのK＆R、bashなどのtldpなど）はありますか？ （注：イベント駆動プログラミングの学習に関する私の質問と実際に機能的に同じ質問であるかどうかはわかりません）

21 design-patterns  learning  books  architectural-patterns  asynchronous-programming 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店しました。 私はデザインパターンを研究しており、フライウェイトパターンに出くわしました。私は自分のアプリケーションでパターンを使用する機会を探していましたが、その使用方法を理解するのに苦労しています。また、他の人のコードを読んだときに、フライの重量パターンが使用されている兆候は何ですか？ 定義によると： 共有を使用して、多数の詳細なオブジェクトを効率的にサポートします。 正しく読んだ場合、辞書とハッシュテーブルはフライウェイトのインスタンスになる可能性がありますが、これは正しいですか？ 前もって感謝します。

21 design-patterns 

製品のリストがあります。それらのそれぞれは、Nプロバイダーによって提供されます。 各プロバイダーは、特定の日付の価格を提示します。その価格は、そのプロバイダーが新しい価格を設定するまで有効です。その場合、プロバイダーは新しい日付で新しい価格を提供します。 現在、MySQLテーブルヘッダーは次のようになっています。 provider_id, product_id, price, date_price_effective 1日おきに、当日に有効な製品/価格のリストを作成します。各製品のリストには、その特定の製品を持つプロバイダーのソート済みリストが含まれています。そのようにして、特定の製品をたまたま最良の価格で提供できる人に注文することができます。 有効な価格を取得するために、を持つすべての行を返すSQLステートメントがありますdate_price_effective >= NOW()。その結果セットは、次のようなファイルを取得するために必要なソートとフィルタリングを行うルビースクリプトで処理されます。 product_id_1,provider_1,provider_3,provider8,provider_10... product_id_2,provider_3,provider_2,provider1,provider_10... これは私たちの目的にはうまく機能しますが、SQLテーブルはおそらくこの種の情報を保存する最良の方法ではないという悩みがあります。この種の問題は、他のより創造的な方法で以前に解決されたと感じています。 SQL以外にこの情報を保存するより良い方法はありますか？または、SQLを使用している場合、私が使用しているものよりも良いアプローチがありますか？

21 design-patterns  database 

MVCとMVVMの違いがはっきりとわかりません。ViewModelのCommandは、ControllerのActionメソッドに似ていると思います。また、コントローラーとViewModelの両方が、データバインディングを介してモデルの状態を変更した後、それ自体を更新するようにビューに通知します。2つのパターンの主な違いは何ですか？

21 asp.net  design-patterns  silverlight 

クラスに多くのパラメーター（たとえば4個以上）を持つコンストラクターがある場合は、おそらくコードの匂いであることがよく知られています。クラスがSRPを満たすかどうかを再検討する必要があります。 しかし、10個以上のパラメーターに依存するオブジェクトをビルドし、オブジェクトを作成し、最終的にBuilderパターンを使用してこれらすべてのパラメーターを設定するとどうなりますか？Person個人情報、仕事情報、友人情報、興味情報、教育情報などを含むタイプオブジェクトを作成するとします。これは既に良いことですが、どういうわけか同じ4つ以上のパラメーターを設定していますか？なぜこの2つのケースは同じと見なされないのですか？

21 design-patterns  constructors  builder-pattern 

私は最近、Code Reviewで私のJavaの回答を削除しました。 private Person(PersonBuilder builder) { やめる。赤旗。PersonBuilderはPersonを構築します。それは人について知っています。PersonクラスはPersonBuilderについて何も知らないはずです-それは単なる不変の型です。ここで、Aに依存するBに依存するAに依存する循環カップリングを作成しました。 Personはパラメータを取得するだけです。構築せずにPersonを作成するクライアントは、それを実行できる必要があります。 私は下票で平手打ちされ、それを（引用して）赤旗と言った、なぜ？ここでの実装は、Joshua Blochが彼の「Effective Java」本（アイテム＃2）で示したものと同じ形をしています。 したがって、Javaでビルダーパターンを実装する正しい方法は、ビルダーをネスト型にし（これはこの質問の目的ではありません）、製品を作成することです（ビルドされているオブジェクトのクラス）このように、ビルダーに依存します： private StreetMap(Builder builder) { // Required parameters origin = builder.origin; destination = builder.destination; // Optional parameters waterColor = builder.waterColor; landColor = builder.landColor; highTrafficColor = builder.highTrafficColor; mediumTrafficColor = builder.mediumTrafficColor; lowTrafficColor = builder.lowTrafficColor; } https://en.wikipedia.org/wiki/Builder_pattern#Java_example 同じBuilderパターンの同じWikipediaページには、C＃の実装が大きく異なります（そして、はるかに柔軟です）。 //Represents a product created …

20 java  design-patterns  coupling  builder-pattern 

名前付き引数とオプションの引数をサポートする言語を使用する場合、ビルダーパターンは実用的ではなくなりますか？ ビルダー： new Builder(requiredA, requiredB).setOptionalA("optional").Build(); オプション/名前付き引数： new Object(requiredA, requiredB, optionalA: "optional");

20 design-patterns  builder-pattern 

OOPでグローバルが悪である理由はたくさんあります。 共有を必要とするオブジェクトの数またはサイズが大きすぎて関数パラメーターで効率的に渡されない場合、通常はグローバルオブジェクトではなく依存性注入をお勧めします。 しかし、ほとんどすべての人が特定のデータ構造について知る必要がある場合、なぜ依存性注入がグローバルオブジェクトよりも優れているのでしょうか？ 例（特定のアプリケーションを深く掘り下げることなく、ポイントを一般的に示すための簡略化されたもの） 種類、名前、色、速度、位置など、膨大な数のプロパティと状態を持つ仮想車両が多数あります。多数のユーザーがそれらをリモートコントロールでき、膨大な数のイベント（両方ともユーザー、開始および自動）は、多くの状態またはプロパティを変更できます。 素朴な解決策は、それらのグローバルコンテナを作成することです。 vector<Vehicle> vehicles; どこからでもアクセスできます。 よりOOPに適したソリューションは、コンテナーをメインイベントループを処理するクラスのメンバーにし、コンストラクターでインスタンス化することです。それを必要とし、メインスレッドのメンバーであるすべてのクラスには、コンストラクターのポインターを介してコンテナーへのアクセスが許可されます。たとえば、外部メッセージがネットワーク接続を介して着信した場合、解析を処理するクラス（接続ごとに1つ）が引き継ぎ、パーサーはポインターまたは参照を介してコンテナーにアクセスできます。解析されたメッセージの結果、コンテナの要素が変更された場合、またはアクションを実行するためにそこからデータが必要な場合、信号やスロットを介して数千の変数を投げる必要なく処理できます（または、それらをパーサーに保存して、パーサーを呼び出した人が後で取得できるようにします）。もちろん、依存性注入を介してコンテナへのアクセスを受け取るすべてのクラスは、同じスレッドの一部です。異なるスレッドは直接アクセスしませんが、ジョブを実行してからメインスレッドに信号を送信すると、メインスレッドのスロットがコンテナを更新します。 ただし、クラスの大部分がコンテナにアクセスできるようになった場合、グローバルとはどう違うのでしょうか？非常に多くのクラスがコンテナ内のデータを必要とする場合、「依存性注入方法」は単なる偽装グローバルではありませんか？ 答えの1つはスレッドセーフです。グローバルコンテナを乱用しないように注意を払っていますが、近い将来、他の開発者が近い締め切りの圧力の下で、すべてを気にせずに別のスレッドでグローバルコンテナを使用する可能性があります衝突の場合。ただし、依存性注入の場合でも、別のスレッドで実行されている誰かにポインターを与えると、同じ問題が発生する可能性があります。

20 design-patterns  object-oriented  dependency-injection