私は ASP.NET アプリケーション (Web フォーム ベース) の開発を続けていますが、以前の開発者は優れたオブジェクト指向設計の原則、つまり SOLID ( http://www.remondo.net/solid-principles-csharp-interface-分離/ )。私は次のような投稿を読んだことがあります: Long-holded, wrong programmingsumptions .

問題は、多くのクラスが結束力が低く、結合度が高く、多くのクラスが単一の責任を持っていない (多数の責任を持っている) ことです。私の具体的な質問は次のとおりです。SOLID の原則に従うことから始めるべきですか、それともクラスを調整してさらに追加することによって開発を続けるべきでしょうか? 私はこれまで常に SOLID のような原則に従おうと努めてきましたが、私が話しているアプリケーションは非常に大規模で複雑です。私はこのプロジェクトに取り組んでいる唯一の開発者です。

完全な書き直しは今のところ問題外ですが、いつの日か可能になるでしょう。

更新 15/07/2012 これまでのところ、SOLID は設計原則であり、GRASP は設計パターンであり、おそらくページ コントローラ タイプのアプリケーションよりも MVC に適していることがわかりました。このリンクによると、モック オブジェクトもおそらく MVC に適しています: http://www.asp.net/mvc/tutorials/older-versions/overview/asp-net-mvc-overview。これまでの回答に基づいて、SOLID の原則に従うことは常に良い習慣です。ただし、これまでの回答では、フォーム ベースのアプリのデザイン パターンは推奨されていません。

これは非常に単純な質問ですが、私はまだ非常に不安です。

クラスがアクセサメソッドを介してプライベートメンバーへの参照を返すことが現在広く受け入れられているのはなぜですか？これはカプセル化の原則を完全に破っていませんか？これでよければ、メンバーを公開してみませんか！？

編集私が考えていたケースはこれです

メンバーabuseMeの状態が変更されたため、evの状態は推移性によって変化しました。

DDDのコンテキストでは、オブジェクトが集約ルートである場合、これはOKではありません。引用します

外部オブジェクトがルートへの参照のみを保持できるようにします。内部メンバーへの一時的な参照は、単一の操作内でのみ使用するために渡すことができます。ルートはアクセスを制御するため、内部の変更によって目隠しすることはできません。

[ドメイン駆動設計、エリックエバンス]

...セッターシュメッター..。

すべてのドメイン オブジェクトの Id 属性に文字列型を使用しています。例えば：

ここにはトリックはありません。nullは「値のない」値を表し、新しい Person が作成されて永続化される前にId残りnullます。

現在、「値のない」スペースを強化しnull、空の文字列と空白文字列はすべて「値のない」値であると言う議論があります。

つまり、実行する代わりにエンティティが新しいかどうかを確認するにはif (person.Id == null):if (string.IsNullOrWhiteSpace(person.Id))

私の謙虚な意見では、これは匂いまたは設計原則の違反ですが、どちらが原因かわかりません.

質問:この決定が違反している設計原則 (存在するnull場合) はどれですか?

(オッカムのかみそりの原理、エントロピー、または KISS に似たものであるべきだと思いますが、よくわかりません)

グラフを表すデータベースに永続化されたドメインモデルがあります。グラフは、ブランチを介して接続されたノード（NodeTypeA、NodeTypeBなど）で構成されます。2つの一般的な要素（ノードとブランチにはプロパティがあります）。グラフが計算エンジンに送信されます。計算を実行するには、エンジンを次のように初期化する必要があります（簡略化された擬似コード）。

最後に、計算は次のように実行されます。

優れた設計原則を使用して上記を達成するのに役立つ、関連する設計パターンがそこにあるかどうか疑問に思っています。これが理にかなっていることを願っています。フィードバックをいただければ幸いです。

LSP では、クラスはその基本クラスに置き換え可能であるべきであると述べています。つまり、派生クラスと基本クラスは意味的に同等でなければなりません。

しかし、LSP はインターフェイスを実装するクラスにも適用されるのでしょうか? 言い換えれば、クラスによって実装されたインターフェイス メソッドがユーザーが期待するものと意味的に異なる場合、これは LSP 違反と見なされますか?

ありがとうございました

メイン プロジェクトのパブリック API を再設計する幸運な選択肢があります。安らかな API を作成するという目標として始まったものは、[多くの追加機能が追加された後]、rest/json-rpc の不一致として終わりました。

ですから、再考して再設計する時が来ました。ただし、より複雑な操作を解決する方法についていくつかのアイデアが必要です。

基本的なCURD操作は既に実装されており、正常に動作します。

各リソースは、階層的なスラッグによってアクセスされます。

ロケールと出力フォーマットも追加されています。

わかりました、ここでトリッキーな部分に進みます:

プロジェクトの基本的なリソースは、タイトルとサブノードを持つフォルダーに似ています。「フォルダ」には、サブフォルダとアイテムを含めることができます。

新しいフォルダまたはアイテムをフォルダに追加するベスト プラクティスは何ですか?

PUT/PATCH は、リソースをフォルダーにリンクするためではなく、フォルダーに関する情報を更新するために必要ですか? 新しいフォルダを作成するには POST が必要です。

もう少し追加すると、フォルダーからフォルダーへのリンク操作とアイテムからフォルダーへのリンク操作を区別するためのベスト プラクティスは何でしょうか。リンクには、ターゲットとは別の名前を付けることができることに注意してください。POSIX システムのシンボリック リンクに似ています。

私の考えは（既存のリソースに対して）です：

逆はどうでしょうか。リンクを解除しますか？

しかし、これは良いデザインですか、それとも後で戻ってきますか?

xls ソース (ole db) からデータをロードし、出力ファイルの仕様に従ってフォーマットし、処理されたフィールドをマージして、csv に保存するなどの作業を完了する必要があります。

特定のタイプでなければならないデータの複数のフィールドを処理する方法は? 特定の方法でフォーマットされている - など

この問題のクラス構造を抽象化するのに苦労しています。

どのデザインパターンが私に最も適していますか?

質問はあなたにとってとても簡単かもしれません。しかし、多くの場合、それは非常に複雑だと感じています。誰もがカスタムcmsでウェブサイトを開始し、後でWordpress、Drupal、Joomlaなどに移動しました。

私は以前、cmsを拡張できるように設計上の決定を下した、より良い本やブログの投稿を探していました。私にとって興味深いと思われる本のいくつかは

1. PHP5CMSフレームワークの開発
2. Pro Zend Framework CMS

あなたがそのような本に出くわしたかどうか、またはあなたが他の本を推薦するかどうか見ることは素晴らしいでしょう。私はPHPを探しているだけでなく、次のブロガーを作成するのに役立つあらゆる種類の本を読むことに興味があります。

私が興味を持っているのは

1. ブロガー
2. drupalgardens
3. タンブラー

と同様のもの。

ありがとうございました

this のような正しい入力および出力タイプを扱う、これに似たいくつかの質問があります。私の質問は、どのようなグッド プラクティス、メソッドの命名、パラメーターの型の選択など、遅延実行事故から保護できるものですか?

これらはIEnumerable、次の理由により、非常に一般的な引数タイプである最も一般的です。

• 堅牢性の原則 に従います。

• で広く使用されていますLinq

• IEnumerableコレクション階層の上位にあり、新しいコレクション タイプよりも古い

ただし、遅延実行も導入されます。メソッド (特に拡張メソッド) を設計する際に、最も基本的な型を使用することが最善のアイデアであると考えていたのに、間違っていた可能性があります。したがって、メソッドは次のようになります。

明らかに危険なのは、上記の関数をレイジーLinqと混ぜ合わせて非常に影響を受けやすいことです。

より大きな編集：

もう一度言いますが、言語の機能に対する批判は建設的ではありませんが、良い実践方法を求めるのは StackOverflow の強みです。これを反映するように質問を更新しました。

ここで大きな編集：

上記の行を明確にするために-私の質問は、2番目の式が評価されないことではなく、真剣に評価されないことです。プログラマーはそれを知っています。私の心配は、Shuffleメソッドが実際にその時点までクエリを実行することです。何も実行されない最初のクエリを参照してください。同様に、別の Linq 式 (後で実行する必要があります) を構築するときに、カスタム関数が台無しになります。言い換えれば、呼び出し元に知らせる方法Shuffleは、Linq 式のその時点で必要な関数ではありません。ポイントが家に帰ることを願っています。申し訳ありません！:)メソッドに行って検査するのと同じくらい簡単ですが、皆さんは通常どのように防御的にプログラムするのですか..

上記の例はそれほど危険ではないかもしれませんが、要点はわかります。Linqそれは、特定の (カスタム) 関数が遅延実行の考え方にうまく適合しないことです。問題はパフォーマンスだけでなく、予期しない副作用についてもです。

しかし、このような関数は魔法のように動作しLinqます:

ご覧のとおり、両方の関数が を受け取りますIEnumerable<>が、呼び出し元は関数がどのように反応するかを知りません。では、皆さんがここで取っている一般的な予防措置は何ですか?

1. Linqカスタム メソッドに適切な名前を付けて、呼び出し元が?とうまくいくかどうかがわかるようにします。

2. 遅延メソッドを別の名前空間に移動し、 Linq-ish を別の名前空間に保持して、少なくとも何らかのアイデアを提供しますか?

3. IEnumerableメソッドを実行するための as パラメーターを受け入れず、immediately代わりに、より派生した型または具体的な型自体を使用してIEnumerable、遅延メソッドだけを残しますか? これにより、実行されていない可能性のある式を実行するという負担が呼び出し元にかかりますか? Linq外の世界ではIEnumerables をほとんど処理せず、ほとんどの基本的なコレクション クラスICollectionは少なくとも 1 つまで実装されているため、これは非常に可能です。

それとも何か？私は特に 3 番目のオプションが気に入っています。メソッド内でaまたは同様のLinqことを受け入れて実行する優れたプログラマーからの多くのコード (拡張メソッドに少し似ています!) を見てきました。彼らが副作用にどう対処するかはわかりません..IEnumerableToList()

編集：反対票と回答の後、プログラマーがLinqの仕組みを知らないわけではないことを明確にしたいと思います（私たちの習熟度はある程度のレベルにある可能性がありますが、それは別のことです）が、多くの関数が当時のLinqを考慮に入れました。現在、すぐに実行されるメソッドを Linq 拡張メソッドと一緒にチェーンすると危険です。だから私の質問は、Linq側から何を使用し、何を使用しないかを発信者に知らせるために、プログラマーが従う一般的なガイドラインがありますか? それは、使い方がわからない場合は助けられないというよりも、防御的にプログラミングすることです。（または少なくとも私は信じています）..