Smalltalkベストプラクティス・パターン

また、デザイン（設計）についての本でもありません。デザインというものが、絞り込まれたオブジェクト間の関係を定義するプロセスであるなら、設計上の問題は、確かに実装時の問題としても出現するでしょう。デザイン・パターンはそういった共通性を捉えるのに非常に効果的です。しかし、それらはこの本の直接のトピックではありません。これはSmalltalkをうまく動かすための本です。オブジェクトをうまく相互作用させるのとはまったく異なったトピックなのです。

設計ーー本書で述べたトピックよりも少し上流（私の視点で）を扱ったテクニックはたくさんあります。オブジェクトを2つに分割することで再利用性を高めたり、メソッドやメソッドのセットをオブジェクト化することで柔軟性を得るパターンなどがあります。現時点でお勧めできるほんとしてGammaらの「デザインパターン」があります。

モデリングーー本書のパターンはSmalltalkが課す制限を解きます。モデリングに関しても、そこに課せられる多くの制限があり、それを解くべく重要な決断をしていかなければなりません。（10）

プログラムは語りかけてくるということを知っていますか？「ジョルトコーラをもっと買おう。」といった類のメッセージではありませんよ。プログラムはもっと重要なこと、つまりシステムがどのように構成されるべきかということを教えてくれるのです。

たとえば、今まで快調にプログラミングできていたのに、プログラムが突然ぎくしゃくして動かなくなってきたとしましょう。とても困るでしょうが、これはプログラムが話しかけてきているのです。何か大事なことを見過ごしていますよ、と言うふうに。

プログラムが語りかけてきた時、パターンが何をするべきかを教えてくれます。新しいメソッドを作ったり、新しいオブジェクトを作ったり、新しい変数を作ったりする必要がでてくるでしょう。語りかけには応じなければなりませんが、行動する前に、耳をとぎすますべきです。

プログラマなら誰しも、人生を難しくするために設計されたのかと思うようなシステムにつき合わされた経験があることでしょう（たとえば、今使っているこのワープロもそうです）。その痛みや不満に慣れ、あたかも生活の一部のように扱ってしまうのは簡単です。しかし、プログラムはそんなふうになるべきではないのです。あなたは、そのプログラムをきれいで簡潔で、読みやすいものに変えることができるのです。