Tidy First? ―個人で実践する経験主義的ソフトウェア設計

31章結合 vs 分離

　

なぜすべてを分離しないのか？ そもそも、なぜ結合がそこにあるのだろうか？

結合は、夜のレゴのパーツのように、それを踏むまで明らかでないことが多い。ある振る舞いを変更しようとして、「ああ。これを変更するなら、あれもそれも変更しなければいけない」と気づく。もしくは、さらにひどい場合には、変更を本番環境に投入して、何かを壊し、そこで「ああ。あれもそれも変更しなければいけなかったのか」と気づく。無意識の憶測にあなたは気づいていないのだ。

ディスカウントキャッシュフローでは、多少の結合を考慮に入れている。たとえば、ある振る舞いを実装するのに、すばやくできるが結合がある方法と、時間とお金はかかるが分離している方法があったとする。開発当時は、経済的に正しい判断をして、結合のあるやり方で実装したのではないだろうか。つまり収入を先にして、支出をあとにしたのだ。そして、今が支出のときというわけだ。

システムに結合がある別の合理的な理由は、それがまさに今まで問題でなかったからだ。山頂の巨石が、今まさに村へ向けて転がり落ちそうになっていて、それを受けて判断をしたのだ。「国際化が必要になるなんて思ってもいなかった！」 人は、自分がするはめになるまで気づかないものだ。

結合がある最後の理由は、多少の結合は不可避だからだ。申し訳ないが、これについては「自信を持って主張する」以上の根拠はない。根拠については今後取り組むつもりだ。

結合がある理由はあまり重要ではない。あなたは今、結合のコストを払うか、分離のコストを払うかの判断に直面している。「先に整頓するか？」という問いはこの判断を小さくしたものだ（ただし結合がコードの乱雑さの要因になっているのは一部にすぎないが）。

具体例を見てみよう。通信プロトコルだ。シンプルな実装方法は、送信用の関数と受信用の関数を作ることだ。 ...