クラス設計やパッケージ設計、モジュール設計で相互依存しては行けない理由

Question

クラスなどを設計する際に相互依存しない設計が良いみたいですが、
相互依存していた場合のデメリットが分かりません。

片方を修正しても、インターフェースを変えない限りはもう片方の修正は必要ないと考えています。

テストする時も適当にモック作れば良いと考えています。

なにが、そんなに推奨されていないのでしょうか。

経験談でもいいので、相互依存させると上手くいかない理由をご教授くださいませ。

宜しくお願い致します。

Answer 1

◇デメリット

a. C#やJavaなどの世代別ガベージコレクション(GC)を採用している言語では問題ないのですが。
相互参照はメモリリークを発生させやすい土壌を作ります。

このためリファレンスカウント型のGCやGCがない言語(C++)ではメモリ管理が複雑になります。

ご存知だと思いますが、相互に参照するクラスA,クラスBがある時

A <--> B

これを片方のクラスを参照親とするかA -> BもしくはB -> A。
AとBで共通するCクラスを導出し以下の形にできます。

A -> C
B -> C

b. コードを読む人への負担軽減。
コードが飛び飛びになると、あとで読む人への負担が増加します。

Comments

[退会済みユーザー]

ご回答ありがとうございます。

考えていなかったことを回答していただいたので
ベストアンサーにさせていただきます。

Answer 2

個々に独立して運用できなくなり、常にセットで使用することになります。

そうなると、**それって、全体で一つのモジュールにしたほうが良いじゃないか。**となります。

Comments

[退会済みユーザー]

ご回答ありがとうございます。
一理ありますね。参考にさせて頂きます。

ただ、それだけの理由で、相互依存は駄目と言われているのでしょうか？

Answer 3

片方を修正しても、インターフェースを変えない限りはもう片方の修正は必要ないと考えています。

依存していると、片方の修正でもう片方の修正が必要になってくるからです
本当に、修正が必要でない、ならいいんですが

Comments

[退会済みユーザー]

片方の修正というのは、例えばメソッドのシグネチャの変更とかでしょうか？
それでしたら、別に片方向依存でも起こりうることです。

相互依存ならではの、苦しいことってなんでしょうか？

[y_waiwai]

片方向依存
Aのクラスを変更 → Bのクラスも修正
相互依存
Aのクラス変更修正 ⇔ Bのクラス変更修正