The Art and Science of Smalltalkでオブジェクト指向を理解する


会社の先輩から勧められた「The Art and Science of Smalltalk」という本を読んでみました。元は紙の出版物ですが、作者の許可をとった人が以下のWebサイトで無料で公開しているようです。

Stéphane Ducasse :: Free Online Books

Smalltalkって何?


1970年代から開発が続けられているオブジェクト指向プログラミング言語です。すべてのものがオブジェクトで表現されるなど、オブジェクト指向がJavaなどよりも徹底していて、デザインパターンの宝庫と呼ばれているそうです。実際、「エンタープライズアプリケーション・アーキテクチャパターン」や「エリック・エヴァンスのドメイン駆動設計(以下、DDD)」などの書籍でもSmalltalkの書籍が参考文献としてあがっています。また、テスト駆動設計の考え方もSmalltalkが発祥らしく、マイナーですが、歴史が長く洗練されているので後のプログラミング言語やフレームワークに多大な影響を与えているようです。この本はSmalltalkについて包括的に扱っており、Smalltalk自体の完成度の高さ、開発環境やVMでの実行など、興味深いところは多々あるのですが、その中でも他の言語でも役に立ちそうな考え方などをまとめてみます。

言語としてのSmalltalk


Smalltalkの言語仕様は極めてシンプルで、クラスの実装、継承、多態などを表現でき、JavaやC#がわかる人にも違和感が無い感じです。唯一、関数のようなコードの断片を実行できるコードブロックは、来年のJava8で導入されるラムダ式を彷彿とさせて独特ですね。

MVCアーキテクチャ


Smalltalk発祥のアーキテクチャパターンとして有名なMVCについても、丸々一章を割いた詳細な解説があります。MVCは、Pattern Oriented Software Architectureで大学の教授がもっともらしいコテコテ超重量級の解説をしていて抽象的な考え方になっていますが、この本で解説されているMVCは例が非常に具体的で、長い年月をかけて溜まったノウハウをまとめたものであることが良くわかります。例えば、依存性のあるオブジェクトに変更を通知する機能(Observerパターン)は、SmalltalkのObjectクラスに組み込まれており、複雑なオブジェクト間の関連が発生するオブジェクト指向言語では、どうしてもそのような機構が必要だったことがわかりますし、アプリケーションロジックをモデルとして抽出することの重要性や、モデルが単なるデータの入れ物ではなく、ロジックも含むこと、モデルをアプリケーションモデルとデータモデルに分けることなど、実践に即したことが書かれています。
(個人的にPattern Oriented Software Architectureはあの抽象的で体系立った感じがかっこ良くて大好きなのですが、もやもやした概念や抽象的な話ばかりなので、長年の実践を経て洗練された実態のあるプログラミング言語、クラスライブラリの説得力には勝てないですね・・・)


また、Smalltalkのクラスライブラリには、データモデルとビューをつなぐためのAdapterというクラスが用意されており、モデルがビューの言語を理解できなくても、モデルのデータをビューに引き渡すことができるなど、非常に洗練されています。特にコードブロックを駆使して、モデルのデータを変換するAspectAdapterの仕組みはシンプルでわかりやすく強力で良いですね。

Art of Smalltalk

イテレーティブな開発手法や、オブジェクト指向設計のポイントについて解説があり、個人的にこの本の中でもっとも内容が濃くて興味深いのがこの章でした。以下、気になったところをまとめてみます。

良い設計について


結局、オブジェクト指向プログラミング言語で最も難しいのは、「何をオブジェクトとして抽出するか」であり、フォーマルな手法はあるようですが、正解はなく経験を積むしか無いようです。以下、解説のある良い設計の原則(?)の一部です。どれも非常に重要ですね。

  • 実装からインターフェースを切り離せ
  • 複雑さはクラスに隠蔽せよ
  • クラス間の依存性は最小限にせよ
  • アプリケーションロジックからユーザーインターフェースを切り離せ
  • 複雑なアルゴリズムをオブジェクトに分解せよ

オブジェクトの抽出方法、特性


オブジェクトを抽出するヒントや考慮事項について、以下のようなことが挙げられています。

  • アプリケーション開発中に、「それ」について話することがあればオブジェクトにすべき
  • 実態のあるもの以外にもプロセス(操作や活動など)からも抽出できる
  • オブジェクトの属するレイヤを考える
  • オブジェクトのライフサイクル(DBに永続化されるのか、一時オブジェクトなのか)を考える


なんだかDDDと同じ匂いがしますね。と言っても、Amazonのレビューなどでは、DDDは出版当時でさえ目新しくはなかったという記述があるので、長年オブジェクト指向をやっている人にとっては、上記のような考え方は「常識」なのかもしれませんね
(自分は去年読んだDDDでようやく上記の考え方が頭に叩きこまれた感じですが・・・)

クラスの継承ってなんだ?


そもそもSmalltalkのオブジェクトは、現実世界のエンティティをそのまま表現したものではなく、あくまでコンピュータの世界でエンティティをモデル化したものであることが明記されています。そのため、クラスの継承はコードを共通化してシンプルに保つための機能であり、クラス、オブジェクトをひと通り抽出して機能を決めた後に、処理を共通化できそうなところを継承でまとめるのが良いとされ、現実世界とコンピュータの世界での「継承」について具体的に比較しています。

  • 現実世界: 楕円の特殊な場合が円なので、円が楕円を継承する(subtyping)
  • コンピュータの世界: 円を描画することはあっても、楕円を描画するのは特殊なときだけなので、恐らく楕円が円を継承する(subclassing)


これだけズバッと言い切ってもらえるとすっきりしますね。結局、重要なのは処理をオブジェクトに分解し、維持管理や、再利用性を高めることであり、継承はその中での「コードを共通化する」という補助的な役割しか果たさないようですね。よくあるプログラミング本での「人間クラスが動物クラスを継承して・・・」的な解説はほとんど無意味に思えます。この章には他にも、ソフトウェアを作る上で最も重要なことは、何が要件なのかを見定めることであること、シナリオの重要性や、Whole-Partパターン、TemplateMethodパターン、Strategyパターンにつながる考え方が示されており、短いですが非常に内容が濃いです。

まとめ


この本を読む以前にDDDやPOSA Vol1,Vol2、GOF、OriellyのHead First Design Pattern,Object Oriented Design And Analysis、EAAPなどを読んで実践していたので、オブジェクト指向やデザインパターンについて、そこそこ前提知識があるつもりでしたが、それでも加工されていない実践に即した純粋なオブジェクト指向について学べた意義は大きいと思います。より新しく本はいっぱい出ていますが、中途半端にオブジェクト指向について書かれた分厚い本を読むよりも実践的で「使える」オブジェクト指向を身につけられるのではないでしょうか。
(色々方法論はあるようですが、もっと体系立ったオブジェクト指向分析設計の本って必要なのかなぁ・・・)

オブジェクト指向設計とは編集