以下は、以前アスペクト指向のメーリングリストで紹介されていた文書です。
ソフトウェア進化のためのMixin 型を使ったプログラミング手法
今頃になって、これを読んでいたり……。というか、面倒な部分を飛ばしながら斜め読みしてみたり。
この文書では、コンポーネント間に依存性が生じてしまうためMixin型というものをJavaに導入したことが書かれています。
これを読んだ意見というほどのものではありませんが、感想が2つ。それを書いてみます。
コンポーネント間の依存関係を切り離すといえば…… §
コンポーネント間の依存関係というのは、実際の開発上の問題に即して言えばクラス間の依存関係と言っても良いわけですが。相互に依存し合ったコードは、ちょっと直すだけでも影響が広範囲に波及しかねないので、面倒な存在と言えます。依存性がなく独立したクラスは、容易にテストが可能であって、しかも、変更も容易です。専門家の人なら、もっと難しく素晴らしい理由をいくつも挙げられるかもしれません。まあ、依存関係は少ない方が良いと言うのは間違いないと思います。依存関係を減らすということは、私が以前に話題にした複雑さを軽減するという効能も持つと思って良いと思います。
さて、今回のテーマとなった文書を読みながら、ふと思い出したのは、前に私が書いたmockオブジェクトを作成できない場合に、delegateを使ってテスト可能なクラスを設計する方法です。ここで示したサンプルソースで言うと、delegateを使う前はClassBがClassAに依存していましたが、使用後は依存しなくなっています。つまり、C#のdelegateによってクラス間の依存関係を切り離されたことになります。
こういう使い方にどのような意味があるのか、好ましい使い方であるかは分かりませんが、C#のdelegateにはクラス間の依存関係を切り離すという効能があると考えることができるかもしれません。
依存性を切れば良いと決まったものか…… §
2つめの感想です。
確かに、依存関係を切り離すことは、好ましいことと言えます。しかし、好ましいからと言って、何でもかんでも切り離すことが正しいのかというと、それも違うような気がします。
たとえば、プログラムの複雑さという視点で考えると、依存関係を切ることで複雑さは軽減されると思って良いと思います。しかし、依存関係を切るために使用される手段がソースコードに追加されることによって、コードの含まれる構成要素が増えて、それらに新たな相互関係が発生します。減る関係があれば、増える関係もある、というわけです。また、上手く依存関係を切っていかないと、依存関係を切ることによって、かえって分かりにくいプログラムになる可能性もあるような気がします。適切に依存関係を切るにも、それなりのセンスが必要であるように思います。
そういうことから考えると、安易に依存関係を切れば良いものか?という疑問も浮かびます。難しく考えないで、とりあえずシンプルに依存させておいた方がずっと良い結果を生むケースの方が多いのではないか、と言うことです。
おそらく、システムの規模や、性質によって、答は一様ではないような気がします。システムの規模が巨大になれば、積極的に依存関係を切っていかないと、そもそも開発が成立しない可能性も考えられます。また、汎用ライブラリのようなものであれば、他の汎用ライブラリとの依存性は少ない方が使い勝手が良くなります。しかし、小さなユーザープログラムのソースコード上で、依存性を無理に切っていく必要はないような気もします。
以上は、感想として、そう思っただけで、本当にそうかどうか分かりませんが。
