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

ソフトウェアエンジニアリングの設計パターン(よく発生する問題の再現可能なソリューション)とベストプラクティス

1
ドメインイベントを使用するか、アプリケーションレイヤーにすべてを調整させるかの選択方法
ドメイン駆動設計への最初のステップを設定し、ブルーブックとすべてを購入しました。特定のソリューションを実装するための3つの方法を見ています。記録のために:私はCQRSまたはイベントソーシングを使用していません。 ユーザーリクエストがアプリケーションサービスレイヤーに入ってきたとします。その要求のビジネスロジックは(何らかの理由で)エンティティ上のメソッドとドメインサービス上のメソッドに分けられます。これらのメソッドを呼び出すにはどうすればよいですか? これまでに収集したオプションは次のとおりです。 アプリケーションサービスが両方のメソッドを呼び出すようにします メソッドインジェクション/ダブルディスパッチを使用して、ドメインサービスをエンティティにインジェクトし、エンティティに実行させてからドメインサービスのメソッドを呼び出します(または逆に、ドメインサービスがエンティティのメソッドを呼び出すようにします) エンティティメソッドでドメインイベントを発生させ、そのハンドラーがドメインサービスを呼び出します。(私が話しているドメインイベントの種類は、http://www.udidahan.com/2009/06/14/domain-events-salvation/です) これらはすべて実行可能だと思いますが、どちらかを選択することはできません。私はこれについて長い間考えていましたが、3つのセマンティックの違いがもはや見られなくなるまでになりました。何を使うべきかのガイドラインを知っていますか?

7
データベースでビットマスクを使用する利点と欠点
少し前に同僚と話をしましたが、彼はデータベースに保存されているすべての値を理解するのが難しいため、ビットマスクの使用に間違いなく反対しました。私の意見では、例えば現在のユーザーの役割を決定するためにそれらを使用することは必ずしも悪い考えではありません。それ以外の場合は、別のテーブルに保存する必要があり、これによりもう1つのJOINが発生します。私が間違っているかどうか教えてもらえますか?ビットマスクを使用する他の副作用、利点/欠点はありますか?

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

4
大きなデータベースで誤ったデータ更新を回避するために従うべきプラクティスは何ですか?
実稼働展開の前の一般的なアドバイスは、最初にDBをバックアップすることです。このように、新しい更新に潜在的なデータ損失または論理データ破損につながる可能性のある問題がある場合、古いレコードを比較して修正するためのバックアップがまだあります。 ただし、DBサイズが数GBになるまでこれはうまく機能します。DBのサイズが大きくなると、バックアップの完了に長い時間がかかります。コード展開の論理的な問題による論理データの破損を回避するために、このような状況で従うべきベストプラクティスは何ですか?

2
新しいSystem.Tupleクラスの使用は設計が悪いですか?
System.Tupleのコンセプトは、新しいクラスをインスタンス化せずに単一の関数呼び出しで複数のパラメーターを返すことができるという点で気に入っていますが、Microsoft Patterns&Practices、SOLID Principlesなどの優れたプログラミングプラクティスを無視します。 私はこの機能をどれだけ自由に使用すべきか、または必要なときにエッジケースシナリオでのみ使用すべきかどうかを測定しようとしています。

9
保守性の問題があるプロジェクトで新しいチームリーダーとして何をすべきか?
この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 保守性の問題を抱えたコードプロジェクトを担当しました。プロジェクトを安定した足場にするために何ができますか? 私は、単体テスト、IOC、MEF、静的クラス、純粋なデータセットなど、多くの重要なものが欠けている非常に大きな多層.NETシステムで作業している場所にいることに気づきました。わずか24年ですが、私はここに3年近く滞在しました(このアプリは5年間開発中です)。主に時間の制約により、他のがらくたに合うようにたわごとを追加しています。空き時間に多くのプロジェクトを行った後、これらすべての概念がどれほど重要かを理解し始めました。また、従業員の交代により、私はこのプロジェクトのチームリーダーになりました。このアプリを改善するためのスマートな方法を考え出したいと思います。経営陣に価値を説明できる方法。私は何をしたいのかというアイデアを持っていますが、それらはすべて前もって大きな利益を得ることができず、とても圧倒的です。人々がどのようにこれに対処したか、または対処したかについての物語は、非常に興味深い読み物です。ありがとう。

6
試行/キャッチ/ログ/再スロー-アンチパターンはありますか?
try / catchの周りにすべてのコードブロックを散らかすのではなく、中央の場所またはプロセスの境界で例外を処理することの重要性が良いプラクティスとして強調されているいくつかの投稿を見ることができます。私たちのほとんどはそれの重要性を理解していると強く信じていますが、主に例外中のトラブルシューティングを容易にするために、より多くのコンテキスト固有の情報(例:メソッドパラメータ合格)、方法はtry / catch / log / rethrowの周りにメソッドをラップすることです。 public static bool DoOperation(int num1, int num2) { try { /* do some work with num1 and num2 */ } catch (Exception ex) { logger.log("error occured while number 1 = {num1} and number 2 = {num2}"); throw; } } 例外処理の優れた実践を維持しながら、これを達成する正しい方法はありますか?このためにPostSharpのようなAOPフレームワークについて聞いたことがありますが、これらのAOPフレームワークに関連するマイナスまたは主要なパフォーマンスコストがあるかどうかを知りたいです。 ありがとう!

4
ユーザー定義フィールドを許可するのは悪い習慣ですか?
一般的に言えば、webappのデータベースにユーザーが作成したフィールドを許可することは悪い習慣と見なされますか? たとえば、妻用のホームインベントリwebappを作成していますが、妻はさまざまなアイテム用に独自のフィールドを定義したいと考えています。私は彼女がアイテムのカテゴリを作成し、それらのカテゴリに「機能」を追加できるようにすることを計画していました。機能は、文字列として保存されたキー/値になります。たとえば、「オーディオCD」というカテゴリがある場合、「アーティスト」、「トラック」などの機能を追加できますが、「家具」などの別のカテゴリでは、「素材」などの機能を追加できます「(木材、プラスチックなど)。次に、任意のアイテムを1つ(または多数)のカテゴリに属し、それらの機能をアイテムに追加します。 これらの機能による検索には文字列の比較が必要であり、データの検証が必要ないなどの問題を見ることができます。アジャイル方法論に従って、新しいカテゴリと属性を考え出すことをお勧めします。私たちが行くように。私の例では、それは小さなユーザーベース(2人)であり、作成されるレコードの量は少ないので、それほど悪くはありません。 しかし一般的に言えば、人々は「現実の生活」でこのようなことをどのように処理しますか?

5
ゲッターとセッターの組み合わせ
jQueryなどのJavaScriptライブラリは、プログラミングインターフェイスで「ゲッター」と「セッター」を組み合わせます。例: $('element').css({'color','blue'}); 色を設定するか、 $('element').css(); 要素のCSSを取得します。 そのようなパターンには名前がありますか?また、アプリケーションで使用することをお勧めしますか?


4
依存関係の注入は、ctorで実行するか、メソッドごとに実行する必要がありますか?
考慮してください: public class CtorInjectionExample { public CtorInjectionExample(ISomeRepository SomeRepositoryIn, IOtherRepository OtherRepositoryIn) { this._someRepository = SomeRepositoryIn; this._otherRepository = OtherRepositoryIn; } public void SomeMethod() { //use this._someRepository } public void OtherMethod() { //use this._otherRepository } } に対して: public class MethodInjectionExample { public MethodInjectionExample() { } public void SomeMethod(ISomeRepository SomeRepositoryIn) { //use SomeRepositoryIn } …

6
戦略パターンの利点
if / thenの場合にコードを書くことができるのに、なぜ戦略パターンを使用するのが有益なのですか? 例:TaxPayerクラスがあり、そのメソッドの1つが異なるアルゴリズムを使用して税金を計算します。では、なぜif / thenケースを持ち、戦略パターンを使用する代わりに、そのメソッドで使用するアルゴリズムを見つけられないのでしょうか?また、なぜTaxPayerクラスの各アルゴリズムに個別のメソッドを実装できないのですか? また、実行時にアルゴリズムが変更されるとはどういう意味ですか?

12
条件文のこの使用はアンチパターンですか?
作業中のレガシーシステムでこれをよく見ました。次のような機能があります。 bool todo = false; if(cond1) { ... // lots of code here if(cond2) todo = true; ... // some other code here } if(todo) { ... } つまり、関数には2つの部分があります。最初の部分は何らかの処理(ループ、副作用などを含む可能性があります)を実行し、その途中で「todo」フラグを設定します。2番目の部分は、「todo」フラグが設定されている場合にのみ実行されます。 物事を行うのはかなりlyい方法のように思えます。実際に時間をかけて理解したほとんどのケースは、フラグの使用を避けるためにリファクタリングできると思います。しかし、これは実際のアンチパターンであるか、悪いアイデアであるか、それとも完全に受け入れられるものですか? 最初の明らかなリファクタリングは、2つの方法に分割することです。ただし、私の質問は、ローカルフラグ変数を作成し、複数の場所に潜在的に設定し、後でそれを使用して次のコードブロックを実行するかどうかを決定する必要があるかどうか(現代のOO言語)についてです。

5
思考をC ++からC#に移行する方法
私は経験豊富なC ++開発者であり、言語を非常に詳細に知っており、その特定の機能の一部を集中的に使用しました。また、私はOODの原則とデザインパターンを知っています。私は今C#を学んでいますが、C ++の考え方を取り除くことができないという気持ちを止めることはできません。私はC ++の強みに一生懸命縛り付けたので、いくつかの機能がなければ生きられません。また、C#でそれらの適切な回避策または代替策を見つけることができません。 どのような良いプラクティス、デザインパターン、イディオム C ++の観点から、C#で異なっているあなたは提案することができますか?C#で馬鹿げていない完璧なC ++デザインを取得するにはどうすればよいですか? 具体的には、対処するC#風の良い方法を見つけることができません(最近の例): 確定的なクリーンアップを必要とするリソース(ファイルなど)の有効期間を制御します。これは簡単usingに手に入れることができますが、リソースの所有権が転送されているときに適切に使用する方法[... betwen threads]?C ++では、単に共有ポインタを使用して、適切なタイミングで「ガベージコレクション」を処理します。 特定のジェネリックの関数をオーバーライドすることに常に苦労しています(C ++での部分的なテンプレートの特殊化などが大好きです)。C#でジェネリックプログラミングを行う試みを放棄する必要がありますか?ジェネリックは意図的に制限されている可能性があり、特定の問題領域を除いてジェネリックを使用するのはC#っぽくないですか? マクロのような機能。一般に悪い考えですが、問題の一部の領域では、他の回避策はありません(たとえば、デバッグリリースにのみ送信されるログのように、ステートメントの条件付き評価)。それらを持たないということは、if (condition) {...}定型文を追加する必要があることを意味しますが、副作用を引き起こすという点ではまだ同じではありません。

6
ゲッターとセッターを定義する順序は?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 ゲッターとセッターを定義する順序のベストプラクティスはありますか?2つのプラクティスがあるようです: ゲッター/セッターペア 最初にゲッター、次にセッター(またはその逆) ここで違いを明らかにするために、ゲッター/セッターペアのJavaの例を示します。 public class Foo { private int var1, var2, var3; public int getVar1() { return var1; } public void setVar1(int var1) { this.var1 = var1; } public int getVar2() { return var2; } public void setVar2(int var2) { this.var2 = var2; } public int getVar3() …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.