dependencies - 「モジュール性を実現するための依存関係の管理」

Question

上記の発言はできますか？それは正しいですか？モジュール性と依存関係は別のものですか、それとも相互に関連していますか? ヘルプ...

Answer 1

それらは異なるものですが、明らかに関連しています。たとえば、2 つの (疑惑;-) コンポーネント A と B があり、A が B に依存し、B が A に依存している場合、それらは実際には別個のコンポーネントではありません。成分。真のモジュール性を実現するには、依存関係を念頭に置く必要があります。依存関係の反転は、クリーンで正しい依存関係を実現するための重要な手法の 1 つです。また、この古典的な本を強くお勧めします。選択した言語が C++ の場合に最も適切ですが、他の多くの言語にも適用できる豊富なアドバイスが含まれています。

Answer 2

巨大なモノリシックなコード本体があるとします。それはそれ以外のコードに依存しません。モジュラーとは呼ばないと思います。

たとえば、60の外部コード本体に依存する、くっきりとした無駄のないスリムなコード本体があるとします。繰り返しになりますが、私たちはそれをモジュラーとは呼ばないと思います。

したがって、モジュール性は、他の何よりも人間の認知的限界に関するものだと思います。

それで：

1. 依存関係の数は管理可能である必要があります。カップリング？
2. 依存関係が発生する場所は簡単に見つけられるはずです。PINの分離（Atul Apteの統合ポイント）？
3. 他の人に依存するコードのサイズも管理可能でなければなりません。凝集？

Answer 3

私はアレックスに同意します。モジュールが絡み合っている場合、実際には個別のモジュールはありません。また、外部のモジュール間の依存関係は、より目に見える/ローカライズされた内部構造よりも制御が困難です。実際、それらは見過ごされがちです。

また、もつれは客観的で測定可能なアンチパターンですが、特定のプロジェクトとプロセスにとって意味のある依存関係ルールを検討する必要があります。これらはより主観的であり、あなただけが定義できます。

重要なのは、あなたが決定した制約が何であれ、開発者がそれらの存在を簡単に認識できるようにすることと、それらを破るかどうか/いつ破るか、違反が統合/ビルドに含まれる場合は上級者に警告することです。

Structure101はこれらすべてをサポートしています。また、 Lattix、SotoArc 、および SonarJも確認することをお勧めします。Jdepends は、とりわけサイクルを検出するオープン ソース プロジェクトです。しかし、今すぐ何かを使い始めてください。