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

はじめに

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

なぜデザインは失敗するのか？

カオスと聞いて何を思い浮かべるだろうか？おそらく騒々しい証券取引所や、朝の台所など、すべてが混乱してごちゃごちゃしている様子を思い浮かべるだろう。秩序という言葉を思い浮かべるとき、おそらく何もない静謐な部屋を思い浮かべるだろう。しかし、科学者にとっては、カオスは均質性（同一性）を特徴とし、秩序は複雑性（差異）を特徴とする。

例えば、よく手入れされた庭は高度に秩序だったシステムである。庭師はパスやフェンスで境界を定義し、花壇や野菜畑に印をつける。しかし、意図的な努力がなければ、庭は荒れ果ててしまう。雑草や草が他の植物を駆逐し、パスが覆い尽くされ、最終的にはどの場所も同じように見えるようになる。

ソフトウェア・システムもまた、混沌に向かう傾向がある。新しいシステムを作り始めた当初は、コードはきれいで整然としたものになるだろうと大それたことを考えるものだが、時間が経つにつれて、コードがごちゃごちゃとエッジケースを集め、マネージャークラスやutilモジュールの混乱した泥沼に陥ってしまうことに発見する。賢明な階層化アーキテクチャが、ぐちゃぐちゃのゴミのように崩れてしまっていることを発見するのだ。混沌としたソフトウェアシステムは、機能が同じであることを特徴とする：ドメイン知識を持ち、メールを送ったりロギングを実行するAPIハンドラー、計算はしないがI/Oを実行する「ビジネスロジック」クラス、そしてシステムのどの部分を変更しても危険と隣り合わせになるように、すべてが他のすべてに結合している。このようなことはよくあることで、ソフトウェア・エンジニアリングは、カオスを表す独自の言葉「泥の大玉アンチパターン」を持っている（図P-1）。

図 P-1. 実際の依存関係ダイアグラム（出典：Alex Papadimoulis著「Enterprise Dependency: Big Ball of Yarn）

チップ

荒野が庭の自然な状態であるのと同じように、大きな泥の玉がソフトウェアの自然な状態なのだ。崩壊を防ぐには、エネルギーと方向性が必要だ。

幸いなことに、泥の大玉を作成しないためのテクニックは複雑ではない。

カプセル化と抽象化

カプセル化と抽象化は、プログラマとして誰もが本能的に手を伸ばすツールである。 この本の背景テーマとして繰り返されていることなので、少し考えてみよう。

カプセル化という言葉には、振る舞いの単純化とデータの隠蔽という、密接に関連する2つの考え方が含まれている。この議論では、最初の意味で使っている。コードの中で行う必要のあるタスクを定義し、そのタスクを明確に定義されたオブジェクトや関数に与えることで、振る舞いをカプセル化する。私たちはそのオブジェクトや関数を抽象化と呼んでいる。

次の2つのPythonコードの断片を見てみよう：

urllibで検索する。

import json
from urllib.request import urlopen
from urllib.parse import urlencode

params = dict(q='Sausages'