3

私は SOLID の原則をチームに紹介しましたが、チームはその原則を理解し、喜んで使用しています。

S - SRP - Single Responsibility Principle
O - OCP - Open/Closed Principle
L - LSP - Liskov Substitution Principle
I - ISP - Interface Segregation Principle
D - DIP - Dependency Inversion Principle

私は、これらの原則を使用するためにすでにリファクタリングされたいくつかのプロジェクトを彼らに提供しました。プロジェクト内の非常に疎結合されたクラス間の接続を確認するのに苦労している場合に私が見る最大の問題. クラス図を作成しても、接続が表示されません。私が言及している特定のプロジェクトも、実装に依存性注入と XML 構成を使用しています。ただし、これには目的があり、使用されているクラスを見つけるのがさらに難しくなります。

クラス間の関係と、それらがプロジェクト内でどのように使用されているかを視覚的に示す最良の方法は何ですか?!

編集日: 2008/10/24 20:40

UML コメントに基づいて、組み込みの Visual Studio クラス図を参照して、アプリケーションのモデルを構築しようとしました。各インターフェースの説明はできますが、それらが明確に接続されているかどうかはまだわかりません。

4

2 に答える 2

1

UML 相互作用図は、そのような関係を明示的に示すことができます。

UML クラス図は、このクラスがそのインターフェースを使用していることと、このインターフェースがそのクラスによって実装されていることの両方を示すことができます。

現在、そのような図は、特定の実行のために行われた特定の選択に関する「時点」ステートメントであり、特定のインジェクションが発生した可能性があります。したがって、図を提供することで、使用している一般的に柔軟な設計からある程度離れていますが、人々がそのような図を役立つと考えていることは理解できます.

私はインターフェイスとの関係で設計の側面について考えようとしていますが、インターフェイスによって記述されたメソッドが実際に「どのように」機能するかを理解する必要はなく、実装が何をしているのかを理解する必要はありません。独自の考えは、依存関係に対してブラック ボックス アプローチを採用する必要があるということです。ですから、そのような図を必要とせず、代わりに責任の観点から考えるよう人々を励ますことをお勧めします。(問題が解決しないまでは問題ありませんが、診断にはさらに多くのことが必要になる場合があります)。アプリケーションのコードの他の部分で同じ精神的アプローチを取ることができますか?

于 2009-10-24T14:47:07.773 に答える