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

29章結合

　

エドワード・ヨードンとラリー・コンスタンチンは、古典『Structured Design』（邦訳『ソフトウェアの構造化設計法』）の執筆にあたってさまざまなプログラムを調査し、プログラムのコストがかかる原因を調査した。そして、コストのかかるプログラムにはすべて共通の特性があることに気づいた。1つの要素を変更するために他の要素を変更しなければいけないのだ。コストのかからないプログラムは局所的な変更で済む傾向にあった。

この変更の伝播特性は「結合（Coupling）」と名付けられた。1つの要素を変更するのに他の要素の変更が必要であれば、2つの要素は特定の変更に関して結合している。

たとえば、呼び出す関数と呼び出される関数は、呼び出される関数の名前の変更に関して結合している。

caller()
    called()

called() // この名前を変更するときは呼び出し元（複数）を変更すること
    ... // 本文のフォーマットを変更しても呼び出し元の変更は不要

2つめのコメントは、結合の重要なニュアンスを強調している。2つの要素は結合していると言うだけでは不十分だ。どの変更に関して結合しているかを言わなければ意味がない。2つの要素が起こり得ない変更に関して結合しているのであれば、私たちが気にかけるような結合ではない。実際に転がり落ちることはないのに、山頂の巨石が村を押しつぶすのではないかと怯えるようなものだ。

プログラムのソースコードを眺めるだけでは、結合を分析できない。2つの要素が結合しているかを知るためには、どんな変更がされたのか、もしくはされそうかを知らなければいけない（試しに、どのファイルが一緒にコミットされる傾向にあるか調べてみよう。そのファイルは結合している）。 ...