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

最近、リポジトリパターンをORMと組み合わせて使用​​するのは良い習慣ではないことを読みました。私の理解から、これはSQLデータベース上で提供する抽象化がパターンに含まれるには漏れやすいためです。 これについていくつか質問があります。 ORMを切り替えたい場合はどうしますか？リポジトリに含まれていない場合、アプリケーションにORM固有のコードが含まれます。 ORMを使用せず、データアクセスとオブジェクトデータの入力にADO.NETを使用している場合、リポジトリパターンはまだ有効ですか？ リポジトリパターンではなくORMを使用する場合、よく使用されるクエリはどこに保存しますか？各クエリをクラスとして表現し、インスタンスを作成するための何らかのクエリファクトリを用意するのが賢明でしょうか？

20 design-patterns  orm  repository 

エンティティコンポーネントシステムアーキテクチャは、定義上、オブジェクト指向ですか？それは私にとってより手続き的または機能的だと思われます。私の意見では、オブジェクト指向言語で実装することを妨げるものではありませんが、堅実なオブジェクト指向の方法で実装することは慣用的ではありません。 ECSはデータ（E＆C）を動作（S）から分離しているようです。証拠として： アイデアは、エンティティにゲームメソッドを埋め込まないことです。 そして： コンポーネントは、特定の目的に必要な最小限のデータセットで構成されます。 システムは、特定のコンポーネントを持つエンティティのセットを使用する単一目的の機能です これはオブジェクト指向ではないと思います。オブジェクト指向になることの大部分は、データと振る舞いを組み合わせることだからです。 証拠として： 対照的に、オブジェクト指向のアプローチは、プログラムの残りの部分から直接アクセスできない場所にデータを配置することをプログラマに促します。代わりに、データにバンドルされている一般にメソッドと呼ばれる特別に記述された関数を呼び出すことにより、データにアクセスします。 一方、ECSは、行動からデータを分離することのすべてのようです。

20 design-patterns  object-oriented  functional-programming  architectural-patterns  entity-component-system 

原則は変更する1つの理由があるモジュールとして定義されます。私の質問は、確かにこれらの変更理由は、コードが実際に変更を開始するまでわからないということですか？ほとんどすべてのコードには、変更される可能性がある多くの理由がありますが、これらすべてを確実に予測し、これを念頭に置いてコードを設計しようとすると、非常に貧弱なコードになります。コードを変更する要求が入り始めたときにのみ、SRPの適用を実際に開始することをお勧めしますか？より具体的には、1つのコードが複数の理由で複数回変更された場合に、変更する理由が複数あることを証明します。変更の理由を推測しようとすると、非常に反アジャイルに聞こえます。 例は、ドキュメントを印刷するコードです。それをPDFに印刷するように変更する要求が来てから、ドキュメントにいくつかの異なるフォーマットを適用するように変更するために2番目の要求が行われます。この時点で、変更する理由（およびSRP違反）が複数あることを示す証拠があり、適切なリファクタリングを行う必要があります。

20 design-patterns  single-responsibility 

私はいつも、ソフトウェアのさまざまな部分にいくつの異なる例外クラスを実装してスローすべきかと考えていました。私の特定の開発は通常C ++ / C＃/ Java関連ですが、これはすべての言語の問題だと思います。 スローする例外の良い数と、開発者コミュニティが良いライブラリに期待するものを理解したいと思います。 私が見るトレードオフには以下が含まれます： より多くの例外クラスにより、APIユーザーの非常に細かいレベルのエラー処理が可能になります（ユーザー構成やデータエラー、またはファイルが見つからない） 例外クラスを追加すると、単なる文字列メッセージやエラーコードではなく、エラー固有の情報を例外に埋め込むことができます 例外クラスが増えると、コードのメンテナンスが増えます 例外クラスが増えると、APIがユーザーに近づきにくくなる可能性があります 例外の使用法を理解したいシナリオは次のとおりです。 ファイルのロードやパラメーターの設定を含む「構成」段階 ライブラリがタスクを実行し、おそらく別のスレッドで何らかの作業を行う「操作」タイプのフェーズ中 例外を使用しない、またはより少ない例外を（比較として）使用しないエラー報告の他のパタ​​ーンには、次のものがあります。 例外は少ないが、ルックアップとして使用できるエラーコードを埋め込む エラーコードとフラグを関数から直接返す（スレッドからは不可能な場合がある） エラー時にイベントまたはコールバックシステムを実装（スタックの巻き戻しを回避） 開発者として、あなたは何を見たいですか？ 多数の例外がある場合、とにかくそれらを個別に処理するエラーを気にしますか？ 操作の段階に応じて、エラー処理タイプを優先しますか？

20 design-patterns  exceptions 

現在、すぐに使用できるオブジェクトリレーショナルマッパーを使用するか、独自のロールを作成するかを選択できる状況にあります。 残念ながら、データ層とビジネス層が一緒にマッシュされたレガシーアプリケーション（ASP.NET + SQL Server）があります。システムは、データアクセスに関して特に複雑ではありません。相互に関連するテーブルの大規模グループ（35〜40）からデータを読み取り、メモリ内で操作し、サマリー形式で他のテーブルに保存します。現在、いくつかのリファクタリングの機会があり、データアクセスを分離して適切に構造化するために使用する候補技術を検討しています。 どんなテクノロジーを選択したとしても、 ドメインモデルに、持続性に無知なPOCOオブジェクトがある モックアップされた基礎となるデータソースに対してドメインモデルオブジェクトをユニットテストできるようにする抽象化レイヤーがあります パターンとフレームワークなどに関しては、明らかにこれに関するものがたくさんあります。 個人的には、EFをADO.NET Unit Testable Repository Generator / POCO Entity Generatorと組み合わせて使用​​することを推進しています。これはすべての要件を満たし、Repo / UnitOfWorkパターン内に簡単にバンドルでき、DB構造は適度に成熟（既にリファクタリング済み）であるため、モデルに毎日変更を加えることはありません。 ただし、グループの他のメンバーは、独自のDALを完全にゼロから設計/ローリングすることを提案しています。（カスタムDataMappers、DataContexts、リポジトリ、どこでもインターフェイス、具体的なオブジェクトを作成するための依存性注入過剰、カスタムLINQから基になるクエリ変換、カスタムキャッシングの実装、カスタムFetchPlanの実装...）狂気として私。 投げかけられた議論のいくつかは、「少なくとも、私たち自身のコードを制御できるようになる」または「以前のプロジェクトでL2S / EFを使用したことがあり、頭痛に過ぎなかった」です。（私は以前に実稼働環境で使用したことがありますが、問題はごくわずかであり、非常に管理しやすいものでした） だから、あなたの超経験豊富な開発者/アーキテクトには、この製品を完全な災害になると思われるものから遠ざけるのに役立つかもしれない知恵の言葉があります。EFの問題をかわすことで得られる利益は、車輪の再発明を試みることで、すぐに失われると思います。

20 design-patterns  database-development  entity-framework  nhibernate 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 オブジェクト指向のデザインパターンと原則の違いは何ですか？それらは異なるものですか？私が理解している限り、両方とも共通の目標（柔軟性など）を達成しようとします。パターンは原則であり、その逆も言えると思いますか？ 設計原理= SOLID（つまり、依存関係反転の原理） デザインパターン= Gof（抽象ファクトリーパターン）

20 java  c#  design-patterns  object-oriented  terminology 

私はしばしば、Javaのヘルパークラスまたはutilクラスまたはあらゆる種類の言語に直面しています。それで、私はこれがアンチパターンの一種であり、この種のクラスの存在はソフトウェアの設計とアーキテクチャに欠けているだけかどうかを自問していた。 多くの場合、これらのクラスは、多くのことを行う静的メソッドのみを使用して制限されます。しかし、ほとんどの場合、実際にはコンテキストに依存し、ステートフルです。 私の質問は、そのような種類の静的ヘルパー/ユーティリティクラスについてのあなたの意見は何ですか？利点はもちろんクラス名だけを使用した高速呼び出しであるためです。 そして、これらの種類のクラスの使用を避けるのは、どのような抽象化レベルですか？ 私の意見では、キーワード「static」はクラスの宣言（Java）内でのみ許可され、メソッドでは許可されません。私の意見では、この方法でそれを使用することは、Javaで手続き型パラダイムとオブジェクト指向パラダイムを組み合わせて、キーワードの誤用を回避するための優れた代替手段であると考えられます。 答えによる追加： 最初は、異なるパラダイムを組み合わせたり、マシンまたはvmでコンパイルされたコード内で実行時解釈スクリプト言語を使用したりすることは完全に合法だと思います。 私の経験では、プロジェクトの開発プロセス中に、そのような種類のヘルパーやユーティリティ、または名前が何であれ、コードベースの忘れられた隅々で成長し、使用されています。そして、リファクタリングを行う時間や設計をもう一度考える時間がないため、時間の経過とともにそれをさらに悪化させます。 staticJavaから削除する必要があると思います。特に今では、さらに洗練された関数型言語要素を使用することができます。

19 design-patterns  anti-patterns  static 

パターンのリファクタリングによると： クラスが多くのことをしようとすると、多くの場合、インスタンス変数が多すぎます。クラスのインスタンス変数が多すぎる場合、複製されたコードはそれほど遅れることはありません。 インスタンス変数が多すぎるとコードが重複しますか？

19 design  design-patterns  object-oriented  object-oriented-design  refactoring 

さて、2つのリソースがAlbumありSongます：と。APIは次のとおりです。 GET,POST /albums GET,POST /albums/:albumId GET,POST /albums/:albumId/songs GET,POST /albums/:albumId/songs/:songId 私たちはいくつかの歌が嫌いであることを知っていSusyます。たとえば、と呼ばれます。どこにsearch行動を起こすべきか？ 別の質問。さて、今ではもっとリアルになっています。アルバム1を開き、すべての曲を読み込みます。JSオブジェクトを作成します。それぞれが曲データを保持しremove、次のようなメソッドはほとんどありませんupdate。 曲オブジェクトにはID、名前、およびものがありますが、どの親に属しているかについての手がかりはありません。これは、クエリによって曲のリストを取得するためです。私が間違っている？ だから、私はいくつかの解決策を見ますが、私は本当に確信がありません。 親IDをオプションにします-get-parameterとして。私は現在このアプローチを使用していますが、butいアプローチだと感じています。 List,Create /songs?album=albumId Update,Delete /songs/:songId Get /songs/?name=susy # also, solution for first question ハイブリッド。OPTIONSメタデータを取得するためのクエリを実行するためにアルバムIDが必要なため、今では便利です。 List,Create /album/:albumId/songs Update,Delete /songs/:songId POST /songs/search # also, solution for first question 各リソースインスタンスで完全なURLを返します。APIは同じですが、次のような曲を取得します。 id: 5 name: 'Elegy' url: /albums/2/songs/5 このアプローチはHATEOASと呼ばれると聞きました。 だから...親IDを提供するには id: 5 …

19 design  design-patterns  rest  ajax 

a）SRPとSoCの違いは何ですか？おそらくSRPはクラスレベルで適用されますが、SoCはsystem、subsystem、module、class、またはfunctionレベルで適用できます。 b）a）への回答が「はい」の場合、SoCはクラスレベルでSRPの同義語に適用されますか？ ありがとうございました

19 design-patterns  single-responsibility 

私は大学生で、デザインパターンについて学び始め、デザインパターンの目的を理解するのに苦労しています。私はそれらを研究しようとしましたが、私が見つけたすべてのリソースは、専門的ではなく学術的な方法でそれらについて話しているようです。 彼らの目的は何であり、学ぶことは重要ですか？

19 java  design-patterns 

これは、非常に多くのように思われる設計上の決定です。コンテキストを必要としないメソッドにコンテキストを渡す方法にコンテキストを渡す方法。正しい答えがありますか、それともコンテキストに依存しますか。 ソリューションを必要とするサンプルコード // needs the dependency function baz(session) { session('baz'); } // doesn't care about the dependency function bar() { baz(); } // needs the dependency function foo(session) { session('foo') bar(); } // creates the dependency function start() { let session = new Session(); foo(session); } 可能な解決策 スレッドローカル グローバル コンテキストオブジェクト …

19 design-patterns 

アジャイルなソフトウェア開発とすべての原則（SRP、OCPなど）を考えるとき、ロギングをどのように扱うかを自問します。 実装の隣のロギングはSRP違反ですか？ yes実装はロギングなしで実行することもできるはずだからです。それでは、より良い方法でロギングを実装するにはどうすればよいですか？いくつかのパターンを確認し、ユーザー定義の方法で原則に違反するのではなく、原則に違反することが知られているパターンを使用する最良の方法は、デコレータパターンを使用することであるという結論に達しました。 SRP違反のない完全に多数のコンポーネントがあり、ロギングを追加するとします。 コンポーネントA コンポーネントBはAを使用します Aのロギングが必要なので、Aで装飾された別のコンポーネントDを作成し、両方ともインターフェースIを実装します。 インターフェースI コンポーネントL（システムのロギングコンポーネント） コンポーネントAはIを実装します コンポーネントDはIを実装し、Aを装飾/使用し、ロギングにLを使用します コンポーネントBはIを使用します 利点：-ロギングなしでAを使用できます-Aをテストすると、ロギングモックが不要になります-テストが簡単になります 欠点：-より多くのコンポーネントとより多くのテスト これはもう1つの公開討論の質問のように思えますが、デコレータやSRP違反よりも優れたログ戦略を誰かが使用しているかどうかを実際に知りたいです。デフォルトのNullLoggerであり、syslogロギングが必要な場合、実行時に実装オブジェクトを変更する静的シングルトンロガーはどうでしょうか。

19 design-patterns  logging  single-responsibility  decorator 

その人気にもかかわらず、依存性注入（および/またはDIコンテナーの使用）が、バグ数の削減、保守性の向上、または実際のソフトウェアプロジェクトの開発速度の向上に役立つことを示す経験的証拠はありますか？

18 design-patterns  dependency-injection  inversion-of-control  ioc-containers  evidence-based 

以下のコードでは、eコマースサイトでの単純な単一アイテム購入を使用していますが、私の一般的な質問は、すべてのデータメンバーを更新して、オブジェクトのデータを常に有効な状態に保つことです。 関連するフレーズとして「一貫性」と「状態は悪」を見つけました。ここで説明します：https : //en.wikibooks.org/wiki/Object_Oriented_Programming#.22State.22_is_Evil.21 <?php class CartItem { private $price = 0; private $shipping = 5; // default private $tax = 0; private $taxPC = 5; // fixed private $totalCost = 0; /* private function to update all relevant data members */ private function updateAllDataMembers() { $this->tax = $this->taxPC * …

18 design-patterns  object-oriented  php  state