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

DTOを使用する意味は何ですか？それは時代遅れの概念ですか？ビューレイヤーでPOJOを使用して、データを転送および永続化します。これらのPOJOはDTOの代替と見なすことができますか？

132 java  design-patterns 

自動テストを学習する（そして愛する）ので、ほとんどすべてのプロジェクトで依存性注入パターンを使用していることに気付きました。自動テストを使用する場合、このパターンを使用することは常に適切ですか？依存性注入の使用を避けるべき状況はありますか？

124 design-patterns  dependency-injection 

依存性注入（DI）は、よく知られた流行のパターンです。ほとんどのエンジニアは、次のような利点を知っています。 単体テストの分離を可能/簡単にする クラスの依存関係を明示的に定義する 優れた設計の促進（たとえば、単一責任原則（SRP）） すばやく切り替え実装を可能にする（DbLogger代わりにConsoleLogger例えば） DIは良い、有用なパターンであるという業界全体のコンセンサスがあると思います。現時点ではあまり批判はありません。コミュニティで言及されている欠点は、通常は軽微です。それらのいくつか： クラスの数が増えました 不要なインターフェイスの作成 現在、同僚とアーキテクチャ設計について話し合っています。彼はかなり保守的ですが、心を開いています。ITの多くの人々は最新のトレンドをコピーし、利点を繰り返し、一般的にはあまり考えすぎないため、あまり深く分析しないでください。 お願いしたいことは： 実装が1つしかない場合、依存性注入を使用する必要がありますか？ 言語/フレームワーク以外の新しいオブジェクトの作成を禁止すべきですか？ 特定のクラスの単体テストを計画しない場合、単一の実装をインジェクトするのは悪い考えです（実装が1つしかないため、「空の」インターフェースを作成したくないとしましょう）。

118 design-patterns  architecture  dependency-injection 

私は「Coders at Work」を読んでいて、この本でインタビューした専門家の中には、デザインパターンにあまり熱心ではないという事実に直面しています。 これには主に2つの理由があると思います。 設計パターンは、その用語で考えることを私たちに強制します。言い換えれば、何か新しいものを発明することはほとんど不可能です（たぶん良いでしょう）。 設計パターンは永遠に続きません。言語とテクノロジーは急速に変化します。したがって、設計パターンは最終的には無関係になります。 したがって、特定のパターンなしで適切にプログラミングする方法を学習し、それらを学習しないことがより重要かもしれません。 ポイントはまた、通常、人々が問題に直面し、あまり時間がないときに、パターンを使用しようとすることでした。これは、既存のコードをコピーして貼り付けて、わずかな変更を加えてプロジェクトを機能させることを意味します。何かを変更したり追加したりするとき、開発者は自分のコードではなく、深く理解していないため、どこから始めればよいかわかりません。

107 design  design-patterns 

GoFがデザインパターンブックを読み始めました。いくつかのパターンは非常に似ているように見えますが、概念的な違いはわずかです。 Pythonなどの動的言語では不要なパターンがいくつかあると思いますか（たとえば、動的機能に置き換えられるため）。

98 design-patterns  python 

特にデータアクセスのコンテキストで、Interpreterを使用してFree Monadについて話している人々を見てきました。このパターンは何ですか？いつ使用したいですか？どのように機能し、どのように実装しますか？ （このような投稿から）私はそれがモデルをデータアクセスから分離することだと理解しています。よく知られているリポジトリパターンとの違いは何ですか？彼らは同じ動機を持っているように見えます。

95 design-patterns  functional-programming  haskell  dsl  monad 

多くの場合、OOPは自然に人々が世界について考える方法に対応していると聞きます。しかし、私はこの声明に強く反対します：私たち（または少なくとも私は）遭遇するものの間の関係の観点から世界を概念化しますが、OOPの焦点は個々のクラスとその階層を設計することです。 日常生活では、OOPの無関係なクラスのインスタンスになるはずのオブジェクト間に、ほとんどの関係とアクションが存在することに注意してください。このような関係の例は次のとおりです。「私の画面はテーブルの上にあります」。「私（人間）は椅子に座っています」; 「車が道路にあります」; 「キーボードで入力しています」。「コーヒーマシンは水を沸かす」、「テキストはターミナルウィンドウに表示される」。 動詞が2つのオブジェクトに作用して何らかの結果/アクションを生成するアクション（関係）である2価（たとえば、「私はあなたに花を贈った」など）の動詞の観点で考えます。フォーカスがアクションであり、2つ（または3つ）の文法上の】オブジェクトが等しく重要です。 それとは対照的に、最初に1つのオブジェクト（名詞）を見つけて、別のオブジェクトに対して何らかのアクションを実行するように指示する必要があるOOPとは対照的です。考え方は、名詞で動作するアクション/動詞から名詞で動作する名詞にシフトします。これは、すべてが受動的または再帰的な音声で言われているようです。たとえば、「テキストはターミナルウィンドウで表示されています」。または、「テキストは端末ウィンドウに表示されます」。 焦点が名詞にシフトされるだけでなく、名詞の1つ（文法主題と呼びましょう）には、他の名詞（文法オブジェクト）よりも高い「重要性」が与えられます。したがって、terminalWindow.show（someText）とsomeText.show（terminalWindow）のどちらを言うかを決定する必要があります。しかし、実際にshow（terminalWindow、someText）を意味するのに、操作に影響を与えることなく、このような些細な決定を人々に負わせるのはなぜですか？[結果は操作上重要ではありません。どちらの場合もテキストはターミナルウィンドウに表示されますが、クラス階層の設計において非常に深刻な場合があり、「間違った」選択は複雑で保守が難しいコードになります。 したがって、OOP（クラスベース、シングルディスパッチ）を行う主流の方法は難しく、それは非自然的であり、人間の世界に対する考え方に対応していないためです。CLOSの汎用メソッドは私の考え方に近いものですが、残念ながら、これは一般的なアプローチではありません。 これらの問題を考えると、OOPを行う現在の主流の方法が非常に一般的になったのはどうしてですか。そして、もしあれば、それを退位させるために何ができるでしょうか？

86 design  design-patterns  object-oriented 

Javascriptはプロトタイプベースのオブジェクト指向言語ですが、次のいずれかの方法により、さまざまな方法でクラスベースになります。 自分でクラスとして使用する関数を書く フレームワークで気の利いたクラスシステムを使用する（mootools Class.Classなど） Coffeescriptから生成する 最初はJavascriptでクラスベースのコードを書く傾向があり、それに大きく依存していました。しかし最近、私はJavascriptフレームワークとNodeJSを使用していますが、これらはクラスの概念から離れ、次のようなコードの動的な性質により依存しています。 非同期プログラミング、コールバック/イベントを使用するコードの作成と使用 RequireJSを使用したモジュールのロード（グローバルネームスペースにリークしないようにするため） リスト内包表記（マップ、フィルターなど）などの関数型プログラミングの概念 とりわけ これまでに収集したことは、私が読んだほとんどのオブジェクト指向の原則とパターン（SOLIDやGoFパターンなど）は、SmalltalkやC ++のようなクラスベースのオブジェクト指向言語向けに書かれたものです。しかし、Javascriptなどのプロトタイプベースの言語に適用可能なものはありますか？ Javascriptに固有の原則やパターンはありますか？コールバックの地獄、悪の評価、またはその他のアンチパターンなどを避けるための原則

79 design-patterns  javascript  object-oriented  patterns-and-practices  design-principles 

YAGNIはどの時点で適切なコーディング慣行に優先する必要がありますか？私は職場でプロジェクトに取り組んでおり、同僚に良いコード標準をゆっくりと導入したいと思っています（現在は存在せず、すべてが韻や理由なしでハッキングされています）が、一連のクラスを作成した後（私たちはTDD、または悲しいことにどんな種類のユニットテストもしないでください）私は一歩後退し、YAGNIに違反していると思いました。なぜなら、これらのクラスのいくつかを拡張する必要がないことを確信して知っているからです。 具体的な例を次に示します。一連のストアドプロシージャをラップするデータアクセスレイヤーがあり、基本的なCRUD機能を備えた基本的なリポジトリスタイルのパターンを使用しています。すべてのリポジトリクラスに必要なメソッドがいくつかあるので、リポジトリ用の汎用インターフェイスを作成しましたIRepository。ただし、その後、各タイプのリポジトリ（例：）に「マーカー」インターフェース（つまり、新しい機能を追加しないインターフェースICustomerRepository）を作成し、具象クラスがそれを実装します。ファクトリー実装でも同じことを行い、ストアドプロシージャによって返されたDataReaders / DataSetsからビジネスオブジェクトを構築しました。リポジトリクラスの署名は次のようになります。 public class CustomerRepository : ICustomerRepository { ICustomerFactory factory = null; public CustomerRepository() : this(new CustomerFactory() { } public CustomerRepository(ICustomerFactory factory) { this.factory = factory; } public Customer Find(int customerID) { // data access stuff here return factory.Build(ds.Tables[0].Rows[0]); } } ここでの私の懸念は、YAGNIに違反しているということです。99％の確実性でCustomerFactory、このリポジトリに具体的なもの以外のものを提供する理由がないことを知っているからです。ユニットテストがないため、MockCustomerFactory同じようなものは必要ありません。また、非常に多くのインターフェイスがあると、同僚が混乱する可能性があります。一方、工場の具体的な実装を使用することは、デザインの匂いのようです。 適切なソフトウェア設計とソリューションのオーバーアーキテクトとの間で妥協する良い方法はありますか？すべての「単一実装インターフェース」が必要なのか、または、例えば、基本インターフェースと単一のコンクリートのみを使用して、良いデザインを少し犠牲にして、プログラミングを心配しないのか疑問に思っています。実装が使用される場合のインターフェース。

76 design-patterns  software-craftsmanship 

オブジェクト指向プログラミングの文献には、設計パターンがたくさんあります。オブジェクト指向プログラミングに関するほとんどの本は、工場やデコレーターのようなパターンを設計するために1〜2章を捧げています。それでは、関数型言語の同等のパターンとは何ですか？なぜそれらについて本を書いていないのですか？関数型言語について、デザインパターンの必要性を取り除く特別なものはありますか？

75 books  design-patterns  functional-programming 

linuxdevcenter.comのStephen Figginsによるこの2003年の記事では、Bram CohenのBitTorrentは「すべてを修正」デザインパターンを使用していると説明されています。 どちらもBitTorrentを把握するのを難しくしますが、研究に値するあまり一般的ではないアプローチは、Cohenのi等性の使用です。プロセスを複数回適用してもそれ以上変更されない場合、プロセスはprocess等です。Cohen氏は、「すべてを修正」と呼ばれるデザインパターンを使用すると言います。これは、何が変わるかを実際に気にすることなく、多くの変更に反応できる機能です。彼は、「あなたは起こった出来事に注意し、そしてこの非常にwritten等な方法で書かれたすべてを修正する関数を呼び出し、起こっているかもしれないことをすべてクリーンアップし、ゼロからすべてを再計算する」と説明する。べき等性は困難な計算を簡単にしますが、少し複雑になります。コールが変更される場合、それが常に明確になるとは限りません。事前に知る必要はありません。関数を自由に呼び出すことができますが、 これは一見するとかなりいいですね。 ただし、べき等の「すべてを修正」関数を呼び出すと、効率を犠牲にしてシステムの堅牢性を向上させ、潜在的に収容システムを混乱させる可能性があります（慎重に計画して実行するプロセスを好む可能性があります）。 ただし、以前に使用したとは言えません。また、彼のアプリケーションのソースをオンラインで見つけることはできません（ただし、これに基づいていると主張するこのソースは見つかりました）。また、この記事以外で参照することもできません（そして、私のgoogle-fuはかなり良いと思います）が、SOApatterns.orgで「べき等機能」のエントリを見つけました。 このアイデアは別の名前でよく知られていますか？ 「すべてを修正」デザインパターンとは何ですか？長所と短所は何ですか？

74 design-patterns 

最近、Webアプリケーションを実行している人はすべてにMVCを使用したいと考えています。ただし、このパターンを使用するように説得することは困難です。一般的な考え方は、プログラムを表すフロントエンドからバックエンドロジックを分離することだと理解しています。一般的に、ビューは常にある程度コントローラーに依存しているようで、最終的にはモデルに依存します。コントローラーを追加することで得られる利点がわかりません。「これがアプリケーションの設計方法だ」という誇大広告をたくさん読んだことがありますが、どこに行くべきかがまだわからないかもしれません。私がMVCについて他の人と話すときはいつでも、誰がどのカテゴリに属する​​かについて異なる考えを持っているようです。 それでは、なぜMVCを使用する必要があるのですか？フロントエンドをバックエンドロジックから分離するだけでMVCを使用すると、何が得られますか？（このパターンのほとんどの「利点」は、インターフェイスを実装から分離するだけで得られ、別の「コントローラ」を持つ目的を説明できません）

74 design-patterns  mvc  rationale 

オブジェクト指向コードに使用される「デザインパターン」という用語を聞いたことがあるだけで、GoFパターンにはOOPデザインパターンのみが含まれていますが、デザインパターンは一般的に発生するプログラミング問題のエレガントなソリューションです。OOPに限定する必要があると言っていることは何もありませんが、ありますか？ オブジェクト指向プログラミングの領域外のデザインパターンの例をいくつか見たいと思います。あなたがいずれかを持っている？そのようなものさえ存在しますか（GoF本のような本は、必ずしも書かれている必要はなく、単に使用されるべきです;それで十分です）？ それらは特定のプログラミング言語に固有のものである場合がありますが、オブジェクト指向以外のパラダイムの一般的な（パラダイムレベル）パターンが優先されます。

70 design-patterns 

Stuart Sierraの講演「Thinking In Data」を見て、私が作っているこのゲームのデザイン原則として、そのアイデアの1つを取り上げました。違いは、彼はClojureで働いており、私はJavaScriptで働いていることです。その点で私たちの言語にはいくつかの大きな違いがあります Clojureは慣用的に機能するプログラミングです ほとんどの状態は不変です 「すべては地図です」というスライドからアイデアを取りました（11分、6秒から29分以上）。彼が言うことは次のとおりです。 2〜3個の引数をとる関数を見たときはいつでも、それをマップに変換してマップを渡すだけのケースを作成できます。これには多くの利点があります。 引数の順序を心配する必要はありません 追加情報を心配する必要はありません。余分なキーがある場合、それは私たちの関心事ではありません。ただ流れるだけで、干渉しません。 スキーマを定義する必要はありません オブジェクトを渡すのとは対照的に、データの非表示はありません。しかし、彼はデータの隠蔽が問題を引き起こす可能性があり、過大評価されていると主張しています。 性能 実装のしやすさ ネットワークまたはプロセスを介して通信するとすぐに、とにかくデータ表現について双方に同意する必要があります。これは、データだけを扱う場合はスキップできる余分な作業です。 私の質問に最も関連しています。これは、「機能を構成可能にする」で29分です。概念を説明するために彼が使用するコードサンプルは次のとおりです。 ;; Bad (defn complex-process [] (let [a (get-component @global-state) b (subprocess-one a) c (subprocess-two a b) d (subprocess-three a b c)] (reset! global-state d))) ;; Good (defn complex-process [state] (-> state subprocess-one subprocess-two subprocess-three)) …

69 design  design-patterns  architecture  functional-programming 

3層（DAL、BL、UI）でアプリの構築を開始しました[主にCRM、いくつかの販売レポート、在庫を処理します]。 同僚から、サービスレイヤーパターンに移行する必要があり、開発者が経験からサービスパターンにアクセスするようになったと言われました。彼は、将来そのようにアプリケーションを維持する方がはるかに簡単になるだろうと言いました。 個人的に、私はそれが物事をより複雑にしているだけだと感じており、それを正当化するような利益はあまり見られませんでした。 このアプリには、デスクトップアプリケーションの機能の一部（ただしごくわずか）を使用する小さな部分UIが追加されているため、コードを（あまり多くは）複製していません。いくつかのコードの重複のために、私はそれをサービス指向に変換しませんが、一般的にそれは非常に優れたアーキテクチャであるため、とにかくそれを使用するべきだと言いました。 私はそれでグーグルしようとしましたが、私はまだ混乱しており、何をすべきかを決めることができません。

68 design-patterns  architecture  web-services  services  service