オブジェクト指向プログラミングを学ぶ
オブジェクト指向プログラミングという言葉は、広い意味で使われている。 オブジェクト指向プログラミングをキーワードにすべてを調べあげて理解するというアプローチは、現実には無理。 重要そうなところを見繕って集めてみたところで、混乱するばかり。
この記事では、さまざまなアプローチの中で、クラスを使って独自の「型」を定義するプログラミングスタイル、関連するデータとロジックをまとめて、小さな入れ物に格納する「カプセル化」を重視するプログラミングスタイルの学び方の参考図書を紹介したい。
あるスタイルが具体的にわかってくると、それとは異なるスタイルや、力点を置くポイントの違いが、わかるようになってくる。 まずは、オブジェクト指向プログラミングの中で、型・クラス・カプセル化に力点を置くスタイルを身につけることを、実践的な学び方として推奨したい。
型とカプセル化を重視したスタイルを学ぶための三冊
以下の三冊は、必携書。すべてを読み切り理解することはできないかもしれないが、手元において少しずつ身に着けていきたい古典的名著。
- マーチン・ファウラー リファクタリング
- エリック・エヴァンス ドメイン駆動設計
- バートランド・メイヤー オブジェクト指向入門 原則・コンセプト
- バートランド・メイヤー オブジェクト指向入門 方法論・実践
読み方のヒント
どの本も全部を順番に読んでいくというより、ざっと全体を眺めたら、とりえあず、要点をみつくろって読むのが良い。基本は拾い読み。 あとは、何かの機会に、少しずつ、拾い読みの範囲を広げたり、拾い読みしたところを、なんども読み直してみる。
「リファクタリング」の読み方
「第3章 コードの不吉な臭い」に列挙されている臭いの最初の6つ(「変更の分散」まで)を、重点的に読む。そして、その中に登場する、リファクタリングパターンだけは、一通り読むようにする。同じパターンが何度もでてくるので、何が、リファクタリングの基礎的な技法かが理解できる。
それだけでも、だいぶ、クラスの使い方とかカプセル化の感じがつかめるようになってくる。
「ドメイン駆動設計」の読み方
読みにくい本です。まず、その前提で拾い読みする。
すぐに理解できるかどうかは別として、この本の根底にある考え方や、何に重点を置いているかに触れるための、最初の必読個所は、以下。
- まえがき
- 第9章 暗黙的な概念を明示的にする
- 第15章 蒸留
- 結論
ドメイン駆動設計という設計スタイルが、何を重視しているかに触れるには、この4か所を、ぜひ読んでほしい。すべてが理解できなくても、エヴァンスのこだわりポイント、設計スタイルが、よくでている個所。
この設計スタイルを支える技法としては、次の2つの章が基本。
- 第5章 ソフトウェアで表現されたモデル
- 第10章 しなやかな設計
ただし、この2つの章は、必読ではない。オブジェクト指向プログラミングの基本的な技法の話なので、型とかカプセル化が理解できていれば、改めて、この2つの章を読み直す必要はない。 この2つの章が「わけがわからん」と思ったら、値オブジェクトを具体例で解説した情報や、リファクタリング本にあたったほうが良い。
なお、エヴァンス本は、たとえ話から始まることが多いけど、なんのたとえか最初はわからず、混乱するのが多くの人が陥るワナ。私もそうだった。 最初は、たとえ話は読み飛ばすくらいでよいと思う。
もう一つ注意点。 クラス図やデータベースが登場する説明を、データモデリングの話として読んでしまうことも、多くの人が陥るワナ。ある程度、データモデリングや手続き的なアプリケーションプログラミングができる人ほど、このワナに陥りやすい。
「型」や「カプセル化」の話なんだ、というとことをいつも意識して読んだほうがよい。 たとえば、最初はメソッド定義のないクラス図の個所は読み飛ばすべきだし、データベースと関連づけて説明されている個所も読み飛ばしたほうが良い。 関心の焦点はあくまでもドメインロジックをどうやって独自の型で定義するか、そして、独自の型の定義にどんな意図と効果があるか、ということを読み取ることに焦点を合わせたい。
「オブジェクト指向入門」の読み方
分厚いし、内容も難解なので、読破しようなどとは、考えないほうが良い。 しかし、オブジェクト指向プログラミングの考え方を学ぶには、この本には有用な情報が詰まっている。 契約による設計とか、コマンドとクエリの分離など、良く知られた設計原則は、この本で提唱されている内容。
著者のバートランドメイヤーさんは、ご本人がおっしゃっているように「分類マニア」。とにかく、品質の分類、判断基準の分類、継承の分類、... など、分類好き。テーマごとに細かく分類し、それをひとつずつ解説するものだから、この厚さになってしまう。 だから、基本的には、「ああ、また分類病がはじまったな」くらいの感覚で、最初はちょっと距離を置いて、全体をぼんやり追いながら、全体としてどんなことが書いてあるかを掴むことから始めるとよいと思う。
拾い読みするとしたら、重点ポイントは、以下。
- 第3章 モジュール性
- 第5章 オブジェクト技術への道
- 第11章 契約による設計:信頼性の高いソフトウェアを構築する
- 第17章 型付け
- 第22章 クラスの見つけ方
- 第23章 クラス設計の原則
- 第27章 オブジェクト指向分析
- 第28章 オブジェクト指向構築過程
- 第29章 オブジェクト指向という手法を教える
拾い読むといってもちょっと多いかな。まずは、何が書いてあるかを知るには、ざっとこのくらいは目を通しておきたい。 「継承」について書いてある章は意識的に割愛してあります。メイヤーさんは、熱烈な実装継承押しなんですが、私は、逆に実装継承は、やらない派なので。 実装継承は、リスコフが予言していたように、カプセル化原則をやぶるため、好ましくないであろう、というのが現場での実証実験の結果だよね、という立場です。
もっと読みやすい本が欲しいよね
ということで、書いたのが、拙著。
現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
この本は、「Java言語入門」的な本と、難解な「ドメイン駆動設計」との間を埋める本が求められているのでは、という企画から生まれた本。 最初に話をもらった時、私自身、そういう間を埋める本があったらいいな、と思っていたので二つ返事で引き受けた。 出版できるまでは、いろいろあったんだけど、なんとか世に送り出すことができた。 おかげさまで、出版から2年たった今でも地味に売れ続けているので、それなりの評価をしてもらえているのかな。 特に、口コミというか、若手にススメた、みたいな話を時々目にするので、本の企画意図通りの読まれ方がされているのかな、とうれしく思っている。
この本を書く時、「継承」「カプセル化」「ポリモーフィズム」「型」とか、いう言葉は、できるだけださずに、コードの書き方の工夫に振り切って、なぜそうすることのメリットがあるかをできるだけ、わかりやすく書こうと思った。
わかりやすさという点では、それなりの結果がだせたのではと自負している。 まあ、そういうわかりやすさが気に入らない人もいるんだなあ、ということもわかった(笑)。役に立つことが書いてあるけど、書き方が悪い、というコメントを見たとき、役に立つことは伝わったんだよね?、伝わったのに書き方が悪いってどういうこと?という感じで、とても不思議だった。
あと、現実的ではないとか、実際には導入できない、というコメントもいくつか見かけだけど、「自分が実際にやって、それなりの結果を出してきた内容だけ」を書いたので、うーん、実際にやっているんですけど、という感じなんだよね。逆に言うと、例えば国際化対応とか、テスト駆動開発とか、私自身が実際にやっていないことは、何も書いてないんですよね。
まあ、わかりやすいので、読む人の持っている設計スタイルとの干渉が強くて、そういう反応もあるんだろうな、と思っている。何が書いてあるかは、それなりに伝わっているんだろうなあと。
今、書き直すとしたら、もうちょっと型の説明とか、カプセル化の説明は、どこかでしたほうが良かったかなと思う。 ポリモーフィズムについても、具体的に、多重定義、総称性、部分型について、わかりやすく書ければ、そのほうが良かったかもしれない。
この本は、ドメイン駆動設計への入門書的な意味あいは確かにあるし、書いているときに、ドメインモデルを中心にすることは、そうとう意識して説明した。 ただ、私がもうひとつ意識していたのは、バートランド・メイヤーのオブジェクト指向入門。 メイヤーさんは、オブジェクト指向は、プログラミング技法にとどまらず、ソフトウェア全体の構造と秩序、ソフトウェアの開発プロセス、ソフトウェアの開発技法の学び方や知識の共有・流通まで、さまざまな側面が大きく変わる革命なのだ、ということを力説している。 私自身、そこはおおいに共感している。そういう思いがあって、9章 オブジェクト指向の開発プロセス、10章 オブジェクト指向の学び方と教え方の2つの章は、どうしても入れたかった。
まとめ
後半は、自著の宣伝みたいになっちゃったけど、独自の型を定義し、ドメインロジックをカプセル化する設計スタイルを学ぶ入門書としては、お役にたてるのではと思っています。
私の本の内容がものたりなかったら、ぜひ、前半でとりあげた三冊を手元に置いて、最初は拾い読みでよいので、読んでみてください。 型とカプセル化にこだわるオブジェクト指向プログラミングがわかってくると、世の中のさまざまなオブジェクト指向に関する情報の関係性(と無関係性?)が、いろいろ見えてくると思います。