従来のコードベースには、あまりにも多くのフィールド/責任を持つ非常に大きなクラスがあります。これが Pizza オブジェクトであると想像してください。

次のような非常に詳細なフィールドがあります。

• ペパロニ
• ソーセージ
• hasBellPeppers

これらの 3 つのフィールドが真である場合、最高のピザがあることを私は知っています。ただし、このクラスは拡張や変更に対してオープンではないため、PizzaType や isSupreme() などを追加することはできません。コードベース全体の人々は、同じif(a && b && c) then isSupreme)ロジックをいたるところに複製しています。この問題はかなりの数の概念で発生するため、このオブジェクトを多くのサブオブジェクトに分解する方法を探しています。たとえば、疑似後方ビルダー パターンです。

これは正しいアプローチですか？このパターンはすでに存在しますか？

タイトルが示すように、検証クラスがモデルのすべてのプロパティにアクセスできるようにするのは良い考えかどうか疑問に思っています。理想的には、一部のフィールドでは、有効かどうかを確認するために 10 以上のフィールドが必要になるため、これを行いたいと考えています。10 個以上のパラメーターを持つ関数を使用することはできますが、使用したくはありません。それとも、モデルとバリデーターが互いに結びつきすぎてしまうのでしょうか? ここに私が言いたいことの小さな例があります。ただし、このコードは無限ループになるため機能しません。

私が正しく、それが良い考えである場合、get プロパティ UserID を使用して無限ループを修正するにはどうすればよいですか?

ありがとうございました。

解決

生産する

完璧ではありませんが、私が始めたものよりもはるかに優れています. 基本的に、decorator パターンを使用することにしました。私の次のステップは、ほとんどの場合、各検証から Init() 関数を削除し、それを SetModel() 関数などに置き換えることです。そうすれば、各検証でモデル内のすべてのプロパティにアクセスできます。

皆さんありがとう。

ボブ・マーティンのOODの原則、特にSRPテキストを読んでいて、それが言っていることの精神をかなりよく理解していますが、リンクの2ページ（本の150ページ）から特定の言い回しを完全には理解していません。 ）：：

言い換えると：

それぞれの責任は変化の軸であるため、これら2つの責任を別々のクラスに分けることが重要です。

ここで「変化の軸」とは正確にはどういう意味ですか？

スタックオーバーフローのユーザー、

大規模なメソッドを使用して大規模なクラスを作成しないようにするにはどうすればよいですか。締め切りがきついときは、まとめてハックしようとすることになり、リファクタリングが必要な混乱に陥ります。

1 つの方法は、テスト駆動型開発から始めることです。これは、SRP (Single Responsibility Principle) だけでなく、優れたクラス設計にも役立ちます。

また、開発者がコントロールをダブルクリックし、発生するイベント メソッドで行ごとに入力しているのも見られます。

助言がありますか？

Mixinsは通常、クラスに新しい動作を導入することを考えると 、これは通常、クラスに複数の動作があることを意味します。

クラスに単一の責任がある場合、これは変更の理由が1つしかないクラスとして定義されます。

だから、私はこれを2つの異なる視点から見ることができます

1. クラスには変更の理由が1つだけあります。混合されたモジュールにも、変更の理由が1つだけあります。クラスが変更された場合、クラスのみを再テストする必要があります。モジュールを変更した場合は、モジュールのみを再テストする必要があります。したがって、SRPはそのままです。

2. クラスには、変更の2つの理由があります。クラスが変更された場合、クラスとモジュールの両方を再テストする必要があります。モジュールが変更された場合は、クラスとモジュールの両方を再テストする必要があります。ヘンジ、SRPに違反しています。

ミックスインの使用は単一責任の原則に違反し、最終的にはシステムの保守が困難になりますか？

少し主観的かもしれませんが、私の現在の状況についてご意見をお聞かせください。オブジェクトのシリアル化/逆シリアル化に使用されるクラスがあります。

私がこのアプローチを気に入っているのは、2 つの機能を同じレベルに保つためです。ただし、私の目標は、静的メソッドの使用を避けることです (実行可能な場合)。SRP に違反しているようにも感じますが、このオブジェクトの主な目的は、xml 文字列からシリアライズ/デシリアライズできるようにすることです。

この状況での静的メソッドの使用について何か考えはありますか? ToXmlString非静的にするだけで、FromXmlString静的のままにする必要がありますか? MyClass のシリアル化のみを処理する新しいクラスを作成する必要がありますか?

編集：

ここで説明するクラスは、単純な転送オブジェクトです。サードパーティ製ツールから値を保存/復元するために使用されます。

ありがとう！

単一責任の原則について読んだばかりですが、ある時点で、Robert C. Martinは、クラスに複数の責任があることを確認するのは難しい場合があると述べています。

誰かがそのようなクラスの例を提供できますか？

私が見たASP.NETMVCの例のほとんどは、ユーザーがオブジェクト（またはオブジェクトのコレクション）を表示してから、そのページからユーザーが入力したフォームを表示するページに移動するシナリオを示しています。適切な入力でフォームを送信すると、ユーザーはオブジェクト（またはリスト）を表示するページにリダイレクトされ、ユーザーは変更が成功したことを確認できます。

ビジネスルールごとにビューまたはリストページがないシナリオに遭遇しました。

ASP.NET MVCでのこのシナリオの良いアプローチは何ですか？

昔はClassicASPとASP.NETを使用して、入力を処理してから、成功メッセージまたはエラーのあるフォームをすべて同じページからユーザーに表示していました。これは、ベストプラクティス（SRP、ビューにロジックがないなど）に反しているようです。

簡単な方法の1つは、変更が成功したことをユーザーに通知する新しいページにリダイレクトすることですが、その後、ユーザーはいつでもそのページにアクセスできます。これから保護するためのロジック（つまり、tempdata）を入れ始めると、ソリューションが汚れ始めます。

ランディングページにリダイレクトできましたが、確認がありません。エンドユーザーがランディングページに戻ったときに確認を表示するメッセージングシステムに頼ることができるでしょうか。

単一責任の原則では、たとえば、Invoiceクラスにはそれ自体を印刷するコードを含めるべきではないと述べています。印刷は別のクラスに分離する必要があります。

Invoiceしかし、ソフトウェアのさまざまなレイヤーにクラスの階層があるとします。

印刷の責任を分離するには、どのような手法または設計パターンを使用できますか?

アイデア:

• の各サブクラスをテストし、適切な印刷コードを実行する大きなifステートメントを持つ個別のクラス。Invoiceこれは間違っているようです。
• 来客パターン。問題は、ビジター インターフェイスがコア レイヤーに存在し、カスタマイズされたレイヤーのクラスへの参照が必要になることです。Core レイヤーを変更して、Customized レイヤーに新しいサブクラスを追加できるようにしたいと考えています。

Apple のガイドラインに従って、iPhone アプリケーションの画面ごとに UIViewController のサブクラスを 1 つ作成します。しかし、これらのクラスはコードの行数とメンバー変数の数の両方の点で非常に大きくなることが一貫してわかっています。

定義上、それらは非常に多くの異なる問題 (たとえば、ビューのライフ サイクル、ビューとモデルの間の仲介、場合によってはタッチ処理、制御ロジック、アラートの管理、その他の UI 状態など) を担当することになります。

これは、単一責任の原則に違反するだけでなく、単体テストがほぼ不可能な大量のコードが生成されます。

どのような責任/懸念事項を新しいクラスに分割する傾向がありますか? UIViewController サブクラスの場合、どのような種類の責任が明確な分離の良い候補になると思いますか?