Pythonによるアーキテクチャパターン

第3章. 束の間の幕間カップリングと抽象化について

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

読者の皆さん、抽象化について少し話を逸らすことをお許し願いたい。 これまで抽象化については何度も話してきた。 例えば、Repositoryパターンは永続的なストレージに対する抽象化である。しかし、良い抽象化とは何だろうか？ 私たちは抽象化に何を求めているのだろうか？ そしてそれらはテストとどのように関係しているのだろうか？

チップ

この章のコードはGitHubのchapter_03_abstractionsブランチにある：

git clone https://github.com/cosmicpython/code.git
git checkout chapter_03_abstractions

派手なパターンに隠された本書の重要なテーマは、単純な抽象化を使って厄介な詳細を隠せるということだ。 楽しみながらコードを書いているとき、あるいは型にはまったコードを書いているとき、¹ 私たちは自由にアイデアと戯れ、物事を打ち出し、積極的にリファクタリングすることができる。しかし大規模なシステムでは、システム内の他の場所で下された決定によって制約を受けることになる。

コンポーネントBが破壊されることを恐れてコンポーネントAを変更できない場合、コンポーネント、結合していると言う。各コンポーネントが他のコンポーネントをサポートし、すべてのコンポーネントが時計の歯車のように所定の位置に収まっている。専門用語では、結合された要素の間に高い結束力があるとき、これが機能すると言う。

グローバルに見れば、カップリングは厄介なものだ。 、コードを変更するリスクとコストを増大させる。時には、変更をまったく加えることができないと感じるほどだ。アプリケーションが大きくなるにつれて、結合力のない要素間の結合を防ぐことができなければ、結合は超直線的に増加し、システムを効果的に変更することができなくなる。

（図3-1）システム内の結合の度合いは、詳細を抽象化することで減らすことができる（図3-2）。

図3-1. たくさんのカップリング

[ditaa,apwp_0301]
+--------+      +--------+
| System | ---> | System |
|   A    | ---> |   B    |
|        | ---> |        |
|        | ---> |        |
|        | ---> |        |
+--------+      +--------+

図3-2. カップリングを減らす

[ditaa,apwp_0302] +--------+ +--------+ | System | /-------------\ | System | | A | ---> | | ---> | B | | | ---> | Abstraction | ---> | | | | | | ---> | | | | \-------------/ ...