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

例＃1：MVVMアプリケーションにビューが表示され（ディスカッションの目的でSilverlightを使用しましょう）、新しいページに移動するボタンをクリックします。 例＃2：同じビューに別のボタンがあり、クリックすると、子ウィンドウ（ダイアログ）に詳細ビューが開きます。 ユーザーのクリックに応答するメソッドを持つボタンにバインドされたViewModelによって公開されるCommandオブジェクトがあることを知っています。しかし、それではどうでしょうか？どうすればアクションを完了できますか？いわゆるNavigationServiceを使用していても、何を伝えているのでしょうか？ 具体的には、従来のビュー優先モデル（WebやSL組み込みナビゲーションフレームワークなどのURLベースのナビゲーションスキームなど）では、Commandオブジェクトは次に表示するビューを知る必要があります。パターンによって促進される懸念の分離に関しては、これは境界線を越えるようです。 一方、ボタンがCommandオブジェクトに接続されておらず、ハイパーリンクのように動作する場合、ナビゲーションルールはマークアップで定義できます。しかし、ビューでアプリケーションのフローを制御し、ナビゲーションは単なる別のタイプのビジネスロジックではありませんか？（場合によってはyes、その他の場合はnoと言うことができます。） 私にとって、MVVMパターンのユートピア実装（および他の人がこれを公言していると聞いたことがあります）は、アプリケーションがヘッドレスで実行できるように（つまり、ビューなし）ViewModelを配線することです。これにより、コードベースのテストに最も広い領域が提供され、ビューがアプリケーションの真のスキンになります。そして、私のViewModelは、メインウィンドウ、フローティングパネル、または子ウィンドウに表示されるかどうかを気にするべきではありませんか？ このアプローチによると、各ViewModelに表示するビューを「バインド」するのは、実行時に他の何らかのメカニズムに依存します。しかし、ビューを複数のViewModelと共有したい場合、またはその逆の場合はどうでしょうか？ したがって、View-ViewModel関係を管理する必要があるため、子ウィンドウ/ダイアログの表示など、ビュー間をナビゲートする必要がある場合に何を表示するかを知るために、MVVMパターンでこれをどのように実現しますか？

33 design-patterns  silverlight  mvvm 

私は長い間Webプログラミングを行ってきましたが、どこかで、今日の仕事をしている理由を追跡できませんでした（または、どうしてこのように物事をするようになったのですか）。 私は基本的なASP Web開発から始めましたが、非常に早い段階で、ページ上でディスプレイとビジネスロジックが混在していました。クライアント側の開発は大きく異なり（VBScript、さまざまなJavaScriptの種類）、サーバー側の検証について多くの警告がありました（したがって、クライアント側のロジックからは遠ざかりました）。 その後、しばらくの間ColdFusionに移りました。ColdFusionはおそらく、タグを使用して表示ロジックとビジネスロジックを分離した最初のWeb開発フレームワークでした。私には非常にはっきりしているように見えましたが、非常に冗長であり、ColdFusionは市場の需要が高くなかったため、先に進みました。 その後、ASP.NETバンドワゴンに飛び乗り、MVCアプローチを使用し始めました。また、Javaはエンタープライズシステムの象牙の塔の言語であるように思われ、MVCアプローチも試しました。その後、ASP.NETはこのMVVM設計パターンを開発し、Java（正確にはJ2EEまたはJEE）も苦労し、MVC2アプローチを採用しました。 しかし、今日、私が発見したのは、バックエンドプログラミングではなく、興奮と進歩がそこにあるということです。また、サーバー側ベースのMVCプラクティスは時代遅れのようです（人々はもうJSTLを実際に使用していますか？）。今日、私が取り組んでいるほとんどのプロジェクトで、JavaScriptフレームワークとクライアント側の開発は、すべてのエキサイティングで革新的な進歩が行われている場所であることがわかりました。 サーバーからクライアント側の開発へのこの移行が行われたのはなぜですか？JEEプロジェクトの1つの単純な行カウントを行いましたが、JavaScriptにはJavaよりも多くのコード行があります（サードパーティライブラリを除く）。JavaやC＃などのプログラミング言語を使用したほとんどのバックエンド開発は、単にRESTのようなインターフェイスを作成することであり、表示、視覚化、データ入出力、ユーザーインタラクションなどのすべての苦労が対処されていることがわかりますAngular、Backbone、Ember、Knockoutなどのクライアント側フレームワーク経由 jQueryの前の時代に、n層開発のMVCのM、V、Cの間に明確な概念線があった多くの図を見ました。jQuery後、これらの線はどこに描かれますか？MVCとMVVMは、クライアント側のJavaScriptコードにすべて揃っているようです。 私が知りたいのは、なぜそのような移行をしたのですか（サーバー側プログラミングの強調からクライアント側へ、コンパイル言語の優先からスクリプト言語へ、命令型プログラミングから関数型プログラミングへ、これらはすべて同時に発生したようです） ）そして、この移行/シフトはどのような問題を解決しましたか？

32 design-patterns  javascript  programming-practices 

現在、ユーザーが存在し、各ユーザーが1つまたは複数のロールを持つシステムで作業しています。ユーザーに列挙値のリストを使用することは良い習慣ですか？これ以上良いものは考えられませんが、これは大丈夫ではありません。 enum Role{ Admin = 1, User = 2, } class User{ ... List<Role> Roles {get;set;} }

32 design-patterns  object-oriented 

私の友人は、すべての開発者が嫌うプロジェクトで小さな会社で働いています：彼はできるだけ早くリリースするように圧力をかけられています、彼は技術的な負債を気にしているようです、顧客は技術的な背景などを持っていません 彼は私に、このようなプロジェクトでのデザインパターンの適切性について考えさせた物語を教えてくれました。ここに物語があります。 Webサイトのさまざまな場所に製品を表示する必要がありました。たとえば、コンテンツマネージャーは製品を表示できますが、APIを介してエンドユーザーまたはパートナーも表示できます。 製品から情報が欠落している場合がありました。たとえば、製品が作成されたばかりのとき、それらの束には価格がありませんでしたが、価格はまだ指定されていませんでした。説明のないものもあります（説明は、変更履歴、ローカライズされたコンテンツなどを含む複雑なオブジェクトです）。出荷情報が不足しているものもありました。 デザインパターンに関する最近の読み物に触発され、私はこれが魔法のNull Objectパターンを使用する絶好の機会だと思いました。だから私はそれをやったが、すべてがスムーズできれいだった。product.Price.ToString("c")価格を表示するため、またはproduct.Description.Current説明を表示するために電話する必要がありました。条件付きのものは必要ありません。ある日、利害関係者はnull、JSON を使用して、APIで別の方法で表示するように要求しました。また、「Price unspecified [Change]」と表示することにより、コンテンツマネージャーにとっても異なります。そして、私は最愛のヌルオブジェクトパターンを殺さなければなりませんでした。それはもはや必要ではなかったからです。 同様に、いくつかの抽象的な工場といくつかのビルダーを削除しなければなりませんでした.3か月間、基礎となるインターフェイスが1日に2回変更されたため、美しいFacadeパターンを直接のugい呼び出しに置き換えました。関係するオブジェクトはコンテキストに応じて異なる必要があることを要件が告げたとき。 3週間以上の作業は、デザインパターンを追加してから1か月後にそれらを引き裂くことで構成され、私のコードは最終的に自分を含む誰もが維持できないほどのスパゲッティになりました。そもそもこれらのパターンを使用しない方が良いと思いませんか？ 確かに、要件が絶えず変化し、製品の凝集性や一貫性を実際に意識していない人によって指示されるようなタイプのプロジェクトで自分自身で作業する必要がありました。この文脈では、あなたがどれだけ機敏であるかは問題ではなく、問題に対する洗練された解決策があり、最終的にそれを実装すると、要件が大幅に変更され、エレガントな解決策が適合しないことがわかりますもはや。 この場合の解決策は何ですか？ デザインパターンを使用せず、思考を停止し、コードを直接記述しますか？ チームがコードを直接記述している間に、別のチームが入力前に2回考えて、数日後に元のデザインを破棄するリスクを冒すような体験をするのは興味深いでしょう。同じ技術的負債。そのようなデータがない場合、20人月のプロジェクトに取り組むとき、事前に考えずにコードを入力するのは適切ではないと断言するだけです。 もう意味をなさないデザインパターンを維持し、新しく作成された状況にさらにパターンを追加しようとしますか？ これも正しくないようです。パターンは、コードの理解を簡単にするために使用されます。パターンを入れすぎると、コードが混乱してしまいます。 新しい要件を含む新しいデザインを考え始めてから、古いデザインをゆっくりと新しいデザインにリファクタリングしますか？ 理論家として、またアジャイルを好む人として、私は完全にそれに夢中です。実際には、毎週ホワイトボードに戻って以前のデザインの大部分をやり直さなければならないこと、そしてその費用を支払うだけの十分な資金も顧客も待つ時間がないことを知っているとき、これはおそらく動作しません。 だから、提案はありますか？

32 design-patterns  agile  changes 

プログラミングでは、最小原理の原理と呼ばれるものは何ですか？この概念は、優れたAPIの設計にどのように関係していますか？これはオブジェクト指向プログラミングのみに適用されるものですか、それとも他のプログラミング手法にも浸透していますか？これは、「メソッドで1つのことを実行し、それをうまく実行する」という原則に関連していますか？

32 design  design-patterns  object-oriented 

私は、ソフトウェアデザインの観点から分析するオープンソースソフトウェアを選択する必要があるソフトウェアデザインクラスを受講しています。 それは大きなプロジェクトでなければなりません：100,000行以上のコード。 優れたソフトウェア設計に関する優れた洞察を得るために、非常によく設計され、設計されたソフトウェアを選択したいと考えています。 良い設計とは、意味のあるクラスとアーキテクチャ、（設計）パターンの適切な使用、抽象化の適切な使用、コンポーネントの適切な編成、コンポーネント間の高い凝集性と低い結合などを意味します。 私に提案するソフトウェアはありますか？ ソフトウェアには適切な設計が必要なだけで、設計を文書化する必要はありません。:) エンドユーザー用のアプリケーションである必要はありません...また、ライブラリ、ツールなどにすることもできます...

32 design  design-patterns  architecture 

デザインパターンを活用することの重要性は常に認識しています。他の開発者がどのように最も適切な開発者を選ぶかについて興味があります。決定に役立つ一連の特性（フローチャートなど）を使用していますか？ 例えば： オブジェクトは関連しているが、具象クラスを指定したくない場合は、Abstractを検討してください インスタンス化が派生クラスに委ねられている場合は、Factoryを検討してください 集合オブジェクトの要素に順番にアクセスする必要がある場合は、Iteratorを試してください または何か似たような？

32 c#  design-patterns 

「4つのギャング」デザインパターンから、ファクトリメソッドがあります。 class Factory(product) case product when a new A when b new B when c new C end new Factory(a) なぜこれが、3つのクラスが持つよりも有用であるa、bとcし、それらを個別に呼び出しますか？

32 design-patterns 

「ビルダー」パターンは「テレスコープコンストラクター」アンチパターンに対処することに制限されていますか、それとも不変オブジェクトの複雑な作成のより一般的な問題に対処すると言うことができますか？ StringBuilderクラスは、その名の単語「ビルダー」を持っているが、それは伸縮コンストラクタとは何の関係もありません、それは単に私たちは不変オブジェクトのコンストラクタに渡す必要があることを、すべてのデータを収集するのに役立ちます。 私には、答えは非常に明確な「はい」のように見えますが、このトピックについては意見の相違があるようです。 私はこの質問に答えていました：プログラマーSE：コンストラクターでの正当な「本物の仕事」？OPが複雑なツリーを含む（おそらく不変の）オブジェクトを作成したい場合、「ビルダー」パターンのアイデアがポップアップし、それを調査中に「StringBuilder」スタイルのオブジェクト作成と言われるこのQ＆Aを見つけましたではない私には明確ではない理由のために、「ビルダー」パターンの適用、：stackoverflowの-のStringBuilderとビルダパターン。（その質問に答えた人は、私が知る限り説得力のあるポイントを作ることができませんでした。）

31 design  design-patterns  builder-pattern 

Builderパターン（主にJava）の多くの実装を見てきました。それらはすべて、エンティティクラス（クラスとしましょうPerson）とビルダークラスを持っていますPersonBuilder。ビルダーはさまざまなフィールドを「スタック」し、new Person渡された引数とともにを返します。Personクラス自体にすべてのビルダーメソッドを配置するのではなく、明示的にビルダークラスが必要なのはなぜですか？ 例えば： class Person { private String name; private Integer age; public Person() { } Person withName(String name) { this.name = name; return this; } Person withAge(int age) { this.age = age; return this; } } 簡単に言えます Person john = new Person().withName("John"); なぜPersonBuilderクラスが必要なのですか？ 私が見る唯一の利点は、Personフィールドをとして宣言できることfinalです。したがって、不変性が保証されます。

31 java  design-patterns  builder-pattern 

これらの2つのケースの間で一般的に受け入れられている方法は次のとおりです。 function insertIntoDatabase(Account account, Otherthing thing) { database.insertMethod(account.getId(), thing.getId(), thing.getSomeValue()); } または function insertIntoDatabase(long accountId, long thingId, double someValue) { database.insertMethod(accountId, thingId, someValue); } 言い換えれば、一般的にオブジェクト全体を渡すか、必要なフィールドだけを渡す方が良いでしょうか？

31 design-patterns  object-oriented  programming-practices  coding-standards  encapsulation 

特定の条件が満たされるまでマップを反復処理し、後でその条件を使用してその他の処理を実行するコードがあります。 例： Map<BigInteger, List<String>> map = handler.getMap(); if(map != null && !map.isEmpty()) { for (Map.Entry<BigInteger, List<String>> entry : map.entrySet()) { fillUpList(); if(list.size() > limit) { limitFlag = true; break; } } } else { logger.info("\n>>>>> \n\t 6.1 NO entries to iterate over (for given FC and target) \n"); } if(!limitFlag) …

30 design-patterns  object-oriented  object-oriented-design  clean-code 

関連する質問を読みました。Pythonのような動的言語には不要なデザインパターンはありますか？Wikiquote.orgでこの引用を思い出した 動的型付けのすばらしいところは、計算可能なものをすべて表現できることです。また、型システムはそうではありません—型システムは通常決定可能であり、サブセットに制限されます。静的型システムを好む人は、「それでいい、それで十分だ。作成したいすべての興味深いプログラムが型として機能します。」しかし、それはばかげています。型システムができたら、どんな面白いプログラムがあるのか​​さえわかりません。 ---ソフトウェアエンジニアリングラジオエピソード140：Gilad BrachaによるNewspeakおよびPluggable Types 引用の定式化を使用して、「型として機能しない」有用な設計パターンまたは戦略があるのだろうか？

30 design-patterns  python  type-systems  dynamic-typing 

データアクセス/ビジネスオブジェクトにActiveRecordパターンを使用することの欠点は何ですか？私が頭の外から考えることができる唯一のことは、それが単一責任原則に違反しているということですが、ARパターンは十分に一般的であり、この理由だけではそれを使用しないことを正当化する「十分」ではないようです（もちろん私のビューは、以下で符号Iの作業の多くの場合、いずれもため斜めであってもよい任意）SOLID原理を。 個人的にはActiveRecordのファンではありません（Ruby on Railsアプリケーションを書くことは例外で、ARは「自然」だと感じます）。処理します。ビジネスオブジェクトを返すリポジトリを使用することを好みます。私が扱うコードのほとんどは、ActiveRecordのバリエーションを使用する傾向があります（メソッドがブール値である理由がわかりません）。 public class Foo { // properties... public Foo(int fooID) { this.fooID = fooID; } public bool Load() { // DB stuff here... // map DataReader to properties... bool returnCode = false; if (dr.HasRows) returnCode = true; return returnCode; } } またはpublic static Foo FindFooByID(int fooID)、ファインダやpublic void …

30 design-patterns 

同僚と私は、基本クラスとインターフェイスの関係について異なる意見を持っています。インターフェイスの実装が必要なときにそのクラスを使用できる場合を除き、クラスはインターフェイスを実装すべきではないと考えています。言い換えれば、私はこのようなコードを見たい： interface IFooWorker { void Work(); } abstract class BaseWorker { ... base class behaviors ... public abstract void Work() { } protected string CleanData(string data) { ... } } class DbWorker : BaseWorker, IFooWorker { public void Work() { Repository.AddCleanData(base.CleanData(UI.GetDirtyData())); } } DbWorkerは、インスタンス化可能なインターフェイスの実装であるため、IFooWorkerインターフェイスを取得するものです。契約を完全に満たします。私の同僚はほぼ同じものを好む： interface IFooWorker { void Work(); } …

30 design-patterns  object-oriented  object-oriented-design  interfaces