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

最近、シングルトンの使用（および過剰使用）に関する問題について多くの議論がありました。私も私のキャリアの早い段階でそれらの人々の一人でした。現在、問題が何であるかを見ることができますが、良い選択肢を見つけることができない場合がまだ多くあります。反シングルトンの議論の多くは実際にそれを提供しません。 ここに私が関わった最近の主要なプロジェクトの実例があります： アプリケーションは、頻繁に更新されないサーバー状態からの大量のデータを使用する多くの個別の画面とコンポーネントを持つシッククライアントでした。このデータは基本的にシングルトンの「マネージャー」オブジェクト、つまり恐ろしい「グローバル状態」にキャッシュされていました。データの保存と同期を維持するアプリ内のこの場所を1つにして、サーバーからさまざまなサポートデータを繰り返し要求することなく、開いた新しい画面で必要なもののほとんどを照会できるようにするというアイデアでした。サーバーへの絶え間ないリクエストは帯域幅を使いすぎます-そして私は週に数千ドルの追加のインターネット請求書を話しているので、それは受け入れられませんでした。 基本的にこの種のグローバルデータマネージャーキャッシュオブジェクトを持つ以外に、ここで適切と思われる他のアプローチはありますか？もちろん、このオブジェクトは「シングルトン」である必要はありませんが、概念的には「シングルトン」であることが理にかなっています。ここできれいな代替品は何ですか？

554 design-patterns  dependency-injection  anti-patterns  caching 

状況 今晩、私はStackOverflowに関する質問に回答しました。 質問： 既存のオブジェクトの編集は、リポジトリレイヤーまたはサービスで行う必要がありますか？ たとえば、借金のあるユーザーがいる場合。彼の借金を変えたい。UserRepositoryで実行するか、たとえば、BingingServiceなどのサービスでオブジェクトを取得して編集し、保存する必要がありますか？ 私の答え： オブジェクトを同じオブジェクトに変更する責任を負い、リポジトリを使用してこのオブジェクトを取得する必要があります。 状況の例： class User { private int debt; // debt in cents private string name; // getters public void makePayment(int cents){ debt -= cents; } } class UserRepository { public User GetUserByName(string name){ // Get appropriate user from database } } 私が受け取ったコメント： ビジネスロジックは実際にはサービス内にある必要があります。モデルではありません。 インターネットは何と言っていますか？ …

397 design-patterns  layers 

これを始める前に、抽象化と依存性注入の概念をよく知っていると言っておきましょう。ここで目を開ける必要はありません。 まあ、私たちのほとんどは、「グローバル変数を使用しないでください」、または「シングルトンはグローバルであるため悪です」と本当に理解せずに何度も言います。しかし、不吉なグローバルな状態で本当に悪いのは何ですか？ たとえば、システムフォルダパスやアプリケーション全体のデータベース資格情報など、アプリケーションのグローバル構成が必要だとしましょう。 その場合、これらの設定を何らかのグローバルスペースで提供する以外に良い解決策はありません。これは、アプリケーション全体で一般的に利用できます。 私はために悪いことを知っている虐待それを、しかし、世界的なスペースが本当にあるTHAT悪？もしそうなら、どんな良い選択肢がありますか？

328 design-patterns  state  globals 

複数のクラスが一連の規則と実装を順守しているということは、インターフェースのポイントではありませんか？

243 design-patterns  coding-standards  interfaces 

私はアプリケーションを構築することを検討しています。そのアプリケーションのコアは、数千のif ... then ... elseステートメントで構成されます。このアプリケーションの目的は、あらゆる風景で牛がどのように動き回るかを予測できるようにすることです。彼らは太陽、風、食物源、突然の出来事などの影響を受けます。 このようなアプリケーションはどのように管理できますか？数百のIFステートメントの後、プログラムがどのように反応するかは予測不可能であり、特定の反応につながることをデバッグすると、毎回IFステートメントツリー全体を走査する必要があることを意味すると思います。 ルールエンジンについて少し読みましたが、この複雑さをどのように回避できるかわかりません。

214 design  design-patterns  business-rules  prolog  logic-programming 

Clean Codeという本を読みましたRobert C. Martinによる。この本では、小さな関数の作成、名前の慎重な選択など、コードをクリーンアップするための多くの方法を見てきました。しかし、今日、上司はこの本を読んだ後のコードの書き方が好きではありませんでした。 彼の議論は 小さな関数を書くと、コードが何をしているのかを見るために各小さな関数に移動しなければならないので苦痛です。 メインループが300行を超える場合でも、すべてをメインの大きなループに入れると、読みやすくなります。 コードを複製する必要がある場合にのみ、小さな関数を作成してください。 コメントの名前を使用して関数を記述しないでください。上記のコメントを使用して複雑なコード行（3〜4行）を入力してください。同様に、失敗したコードを直接変更できます これは私が読んだすべてのものに反しています。通常、どのようにコードを記述しますか？1つの大きなループ、小さな関数はありませんか？ 私が使用する言語は主にJavascriptです。明確に名前が付けられた小さな関数をすべて削除し、すべてを大きなループに入れたので、今は本当に読みにくいです。しかし、上司はこの方法が好きです。 一例は次のとおりです。 // The way I would write it if (isApplicationInProduction(headers)) { phoneNumber = headers.resourceId; } else { phoneNumber = DEV_PHONE_NUMBER; } function isApplicationInProduction(headers) { return _.has(headers, 'resourceId'); } // The way he would write it // Take the right …

209 design-patterns  refactoring  clean-code  functions 

私はいくつかのレガシーコードでグローバル変数を使用する代替案を見つけようとしていました。しかし、この質問は技術的な選択肢に関するものではなく、私は主に用語について心配しています。 明らかな解決策は、グローバルを使用する代わりに関数にパラメーターを渡すことです。このレガシーコードベースでは、値が最終的に使用されるポイントと最初にパラメーターを受け取る関数の間で、長い呼び出しチェーン内のすべての関数を変更する必要があることを意味します。 higherlevel(newParam)->level1(newParam)->level2(newParam)->level3(newParam) どこnewParam私の例では、グローバル変数以前だったが、それは代わりに、以前にハードコード値だったかもしれません。ポイントは、newParamの値がで取得されhigherlevel()、で「移動」する必要があることlevel3()です。 値を変更せずに「渡す」多くの関数にパラメータを追加する必要があるこのような状況/パターンの名前があるかどうか疑問に思っていました。 うまくいけば、適切な用語を使用することで、再設計のソリューションに関するリソースをさらに見つけ、同僚にこの状況を説明できるようになります。

209 design-patterns  terminology  anti-patterns  parameters  globals 

私はシニアのジュニア開発者であり、彼らの思考や推論を理解することに苦労しています。 私はドメイン駆動設計（DDD）を読んでいますが、なぜこれほど多くのクラスを作成する必要があるのか​​理解できません。ソフトウェアを設計するその方法に従えば、最大で2つのファイルと3〜4の関数で置き換えることができる20〜30のクラスになります。はい、これは面倒な場合がありますが、ずっと保守しやすく読みやすいです。 ある種のEntityTransformationServiceImpl機能を確認したいときはいつでも、多くのクラス、インターフェース、それらの関数呼び出し、コンストラクター、それらの作成などに従う必要があります。 簡単な数学： 60行のダミーコードと10クラスX 10（このようなロジックはまったく異なるとしましょう）= 600行の乱雑なコードと100クラス+ラップして管理するためのその他のコード。依存性注入を追加することを忘れないでください。 乱雑なコードの600行を読み取る= 1日 100クラス= 1週間 誰もが簡単にメンテナンスできると言っていますが、何のためですか？新しい機能を追加するたびに、ファクトリ、エンティティ、サービス、および値を持つ5つのクラスを追加します。この種のコードの移動は、乱雑なコードよりもずっと遅いように感じます。 たとえば、1か月で50KのLOC乱雑なコードを記述する場合、DDDには多くのレビューと変更が必要です（どちらの場合もテストは気にしません）。1つ追加するだけで1週間以上かかる場合があります。 1年で多くの乱雑なコードを作成し、何度も書き換えることもできますが、DDDスタイルでは、乱雑なコードと競合するための十分な機能がまだありません。 説明してください。このDDDスタイルと多くのパターンが必要なのはなぜですか？ UPD 1：たくさんの素晴らしい回答を受け取りました。どこかにコメントを追加したり、リストを読むためのリンクを使って回答を編集してください（DDD、デザインパターン、UML、コード完了、リファクタリング、実用的） ..非常に多くの優れた書籍）、もちろんシーケンスを使用して、理解を開始し、一部の皆さんと同じようにシニアになることもできます。

209 design-patterns  domain-driven-design  source-code 

それは私が聞いたアイデアのほんの一握りの場所です。SQLで純粋に問題を解決しようとすると、特定のレベルの複雑さを超えると、コードで実際に処理する必要があることを多少認めます。 このアイデアの背後にあるロジックは、ほとんどの場合、データベースエンジンが、コードで実行できるよりもタスクを完了するための最も効率的な方法を見つけるのにより良い仕事をするということです。特に、データに対して実行される操作を条件として結果を作成する場合などです。おそらく現代のエンジンでは、クエリのコンパイルされたバージョンを効果的にJITしてキャッシュし、表面上は理にかなっています。 問題は、この方法でデータベースエンジンを活用することが本質的に悪い設計慣行であるかどうか（およびその理由）です。データベース内にすべてのロジックが存在し、ORMを介して単にヒットしている場合、行はさらにぼやけます。

204 design-patterns  sql 

真面目なプログラマーとして、MVCとは何かという質問にどのように答えますか？ 私の考えでは、MVCは一種の曖昧なトピックです。そのため、視聴者が学習者である場合は、論争の対象とはならない一般的な用語で自由に説明できます。 ただし、知識豊富な聴衆、特にインタビュアーと話している場合、「それは正しくない！...」という反応のリスクを冒さないための方向性を考えるのに苦労しています。私たちは皆、実世界での経験が異なり、同じMVCの実装パターンに2回出会ったことはありません。 具体的には、厳密性、コンポーネント定義、部品の分離（どの部品がどこに適合するか）などに関して意見の相違があるようです。 それで、MVCを正しく、簡潔で、議論の余地のない方法でどのように説明すればよいですか？

202 design-patterns  mvc  definition 

GitHubとCodePlexでいくつかのС＃とJavaクラスライブラリプロジェクトの歴史を見てきました。オブジェクトの直接インスタンス化とは対照的に、ファクトリクラスに切り替える傾向が見られます。 なぜファクトリクラスを広範囲に使用する必要があるのですか？クラスのパブリックコンストラクターを呼び出すことで、昔ながらの方法でオブジェクトが作成される、非常に優れたライブラリがあります。最後のコミットで、著者は数千のクラスのすべてのパブリックコンストラクターCreateXXXをすぐに内部に変更し、クラスの内部コンストラクターを呼び出して新しいオブジェクトを返すだけの数千の静的メソッドを持つ1つの巨大なファクトリークラスを作成しました。外部プロジェクトAPIは壊れており、よくできています。 なぜこのような変更が役立つのでしょうか？このようにリファクタリングのポイントは何ですか？パブリッククラスコンストラクターの呼び出しを静的ファクトリメソッド呼び出しに置き換えることの利点は何ですか？ いつパブリックコンストラクターを使用する必要があり、いつファクトリーを使用する必要がありますか？

162 design-patterns  refactoring  constructors  factory 

腐敗防止レイヤーの本当の意味を理解しようとしています。私はそれがレガシーコードまたは悪いAPIを移行/回避する方法であることを知っています。私が理解していないのは、それがどのように機能し、何が望ましくない層からきれいに分離するのかということです。 私はいくつかの検索を行いましたが、簡単な例や説明が見つからないため、それを理解し、簡単な例で説明できる人を探しています。私の質問を満足させる答えは、単純なものである必要があり（必ずしも短くはありません）、実装と使用のわかりやすい例を提供する必要があります。 私のユースケースについては、この質問を参照してください。

151 design-patterns  api-design  legacy  bad-code 

少なくとも10年前にギャングオブフォー（GoF）のデザインパターンを初めて知って以来、これらの23のパターンは、パターンスペースと呼ぶのが非常に大きなものの小さなサンプルにすぎないという印象を持っています。この架空のパターンスペースは、一般的なオブジェクト指向ソフトウェア設計の問題に対するすべての推奨ソリューション（既知または未知）で構成されています。 そのため、既知の文書化された設計パターンの数が大幅に増加すると予想しました。 それは起こりませんでした。GoFの本が出版されてから20年以上経っても、Wikipediaの記事には12個の追加パターンしかリストされていません。（特定のトピックを扱っているため、ここでは同時実行パターンを含めませんでした。） その理由は何ですか？ GoFのパターンセットは、実際には私が考えているよりも包括的ですか？ 新しいパターンを見つけることに興味がなくなったのは、おそらくそれらがソフトウェア設計にあまり役に立たないことがわかったからでしょうか？ 他に何か？

144 design-patterns  object-oriented-design 

私は20年間ビジネスに携わっているシニア開発者の1人と話し合いました。彼は、彼が書いているブログでオンタリオ州でよく知られています。 奇妙なことは、彼が私に言ったことです。彼は、教科書から書かれており、現実の世界を説明していないため、作業するのが悪夢のようなコードがあると言いました。UI /データベース/データレイヤーに新しいフィールドを追加するには、2〜3時間かかりますが、彼のコードでは30分かかります。 もう1つのことは、ほとんどのプログラマーが設計パターンを理解しておらず、保守の観点からは良くないため、設計パターンを避けることです。 また、カナダのほとんどのWeb開発者は、データモデルを分離せずに、データレイヤークラスから継承することを好むという考えもあります。「モデルをデータ層から分離することは業界標準ではないでしょうか？」彼は時々言ったが、ここのほとんどの人はそれがあまりにも多くの仕事であるのでそれをしないことを好む。 ベストプラクティスを使用してコーディングしない理由は、メンテナンスの悪夢であり、従業員のほとんどがそれを理解していないためです（自分自身を除く）。時間。 Stack Overflowは、人々が業界標準に従うことを主に奨励していることを考えると、このような意見を聞くのはとても奇妙です。数日のうちに新しいフィールドや機能を絶えず排除せざるを得ないという問題は、十分に柔軟な固体パターンを推測することができないということですか？これは私がこれから理解していることの要点のようです。 これらの声明をどう思いますか？

135 design-patterns  industry-standard 

ここで推奨事項を探しています。戻り値が存在しないか判断できない場合に、メソッドからNULLまたは空の値を返す方が良いかどうかに苦労しています。 例として、次の2つの方法を使用します。 string ReverseString(string stringToReverse) // takes a string and reverses it. Person FindPerson(int personID) // finds a Person with a matching personID. ではReverseString()、戻り値の型が文字列であるため、呼び出し側はそれを期待しているため、空の文字列を返します。また、この方法では、呼び出し元はNULLが返されたかどうかを確認する必要がありません。 でFindPerson()、NULLを返す方が適切なようです。NULLまたは空のPersonオブジェクト（new Person()）が返されるかどうかに関係なく、呼び出し側は、何かを行う前に（呼び出しなどUpdateName()）PersonオブジェクトがNULLまたは空であるかどうかを確認する必要があります。ここでNULLを返すだけで、呼び出し側はNULLをチェックするだけでよいのはなぜですか。 他の誰かがこれに苦労していますか？どんな助けや洞察も大歓迎です。

135 object-oriented  design-patterns  architecture  object-oriented-design