5

私は 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 の原則に従うことは常に良い習慣です。ただし、これまでの回答では、フォーム ベースのアプリのデザイン パターンは推奨されていません。

4

4 に答える 4

5

少しずつリファクタリングしてみてください。

モジュールで作業している場合は、いくつかのインターフェースをあちこちに追加してみてください ;-) 作業を進めてください。あなたが書く新しいコードは、SOLID でなければなりません。古いコードを可能な限りカプセル化して、古いがらくたをファサードの後ろに置きます。今すぐ書き直す必要はありません。ファサードの背後にある古いコードをカプセル化し、ファサードの単体テストを作成できる限り、ずっと気分が良くなるはずです。

例: では、機能の一部を実装するクラスのコレクションがあるとします。請求書処理。現在、これらのクラスは多くの場所で使用されており、多くの重複が発生していると思います。請求書の合計金額を計算するためのコードは、それを表示するすべてのページにコピーされます。その場合に私が行うことは、請求書の取得、新しい行の追加、合計金額の計算などのメソッドを公開する請求書サービスを作成することです。多くのリファクタリングなしで、このサービスにあるコードを配置するよりも、同じデータベース スキーマなどを保持します。しかし、これからはあなたのページはIInvoiceServiceインターフェイスであり、うまくモックできます。それは少し「カーペットの下のほこりを拭き取る」ことですが、少なくともがらくたがさらに広がるのを止めることができます. 次に請求モジュールで何かを行う必要がある場合 (バグの修正、新機能の実装)、既存のコードを少しきれいにします。時間が経つにつれて、カーペットの下のほこりの量はますます小さくなります。あなたは自分のやり方に固執し、サービス インターフェースが適切でクリーンなままであることを確認する必要があります。

DI フレームワークの導入など、システム全体にさらに変更を加える必要があるかもしれませんが、変更は最小限にとどめてください。通常、遠くに行き始めると、すべてを書き直していることに簡単に気付くことができますが、それは望ましくありません。

小さな変更を加え、頻繁にコミットします。

于 2012-07-14T18:09:04.677 に答える
0

それは、「誰かからアパートを買ったばかりなのに、いたるところに汚れがあります。きれいにするべきですか、それともそのままにしておくべきですか?」と尋ねるようなものです。

答えは明らかです。アプリケーションが複雑だとおっしゃいました。アーキテクチャが悪いという理由だけで複雑な場合は、より理解しやすくするチャンスがあります。ビジネスの問題の性質上、複雑であり、アーキテクチャが悪いとさらに悪化します。

SOLID は非常に重要な原則です。また、GRASP のガイドラインにも注意を払ってください。低カップリングと高凝集性について言及しており、これらは SOLID ではなく GRASP に属しているため、そうしていると思います。

最も明白なアプローチは、正しい方向に一歩一歩リファクタリングすることです。クラスを分離し、責任を定義し、よりまとまりを持たせ、インターフェースとコードを導入します。これらは、SOLID の Open-Closed Principle や Liskov Substitution Principle よりもはるかに重要です。

于 2012-07-14T19:42:38.743 に答える
0

私の提案は、機能を選択して単体テストを開始し、Moq や FakeItEasy などのモック ライブラリを導入することです。

これがあなたに譲渡されたコードであることは完全に理解しています。しかし、単体テストを行うと、どのコードが単一の責任の適切な候補であるか、サービスである必要があるか、またはリポジトリに移動する必要があるかがわかります。

すでに DI を実装しようとしていますが、AutoMapper のようなものも使用すると、多くの時間を節約でき、コードをより小さく、より明確に保つことができます。

私があなたの状況のように引き渡されたとき、私がしたことはボブおじさんの本を読んだことですhttp://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052アイデア

コメントの更新: 最初の 3 か月後のアプリでは、バグが少なくなり、新しい変更を実装するのが少し簡単かつ迅速になりました。最良の部分は、ドメインの知識が得られたことです。レガシーおよびバグの原因となる新しい変更を阻止した 1 つの良い点は、Anit-Corruption レイヤーでした。このリンクをお読みくださいhttp://domaindrivendesign.org/library/peng_hu_2007_2

于 2012-07-14T20:19:21.923 に答える