オブジェクトの広場編集員が贈るオススメ書籍
- 今、この本がアツい！-

まずは「オブジェクト指向とは何ぞや？」というオブジェクト指向の考え方に始まり、UML 、ソフトウェアパターンの概要、フレームワーク、開発プロセスという、『オブジェクト指向を用いたソフトウェア開発』に必要な考え方とコツが詰まった本です。
もともとは Web ページに連載していた記事からの編集出版ということで、各章ごとに著者が異なりテーマとポイントがはっきりしています。特に UML に関しては、１章分を割いてユースケースモデルについて、記述方法が説明されています。全体を通して言えることなのですが、実例と図が多く、理解しやすく読みやすいと思います。各章のテーマで出てくる用語の説明もきちんとしているので、ちょっとしたリファレンスとしても使えるのではないでしょうか。

オブジェクト指向の基本については既に学んだ方が知識を整理するための読み物として、また、オブジェクト指向の考え方から実際にどう使っていくかまでを広く学びたい方の入門書としても読んでいただきたい 1 冊です。

「オブ脳」という言葉を耳にしたことはありますか？どうも「オブ脳」とは「オブジェクト指向を理解している脳みそ」のことらしいですよ。それで「オブジェクト指向を理解している」となると、これまた大層な脳みそっぽいのですが、そんな「オブ脳」を手に入れるのは難しいことじゃないんだよ、という視点で書かれている本です。

あ〜、オブ脳が欲しい！と思う方、まずは、第 1 部（オブジェクト脳育成への道）に目を通してみてください。ここだけで「オブ脳」が軽く手に入る寸法となっている模様。

とりあえず、第 1 部 2 章の冒頭に登場する「最初の質問」に答えて自分のオブ脳具合をチェックしてみるという楽しみ方も◎です。

ある業務で、ある開発プロセスの内容を検討する際に、（先輩からの紹介で）本書に出会いました。
本書では、ドメイン分析を、 " そのドメインが本来持つ固有な性質・知識をまとめて、そのドメインの固有な概念構造を得ることで、システム全体の再利用性と生産性の向上を図る "プロセスとして定義しています。
この目的を満たすための手法として、D-AME （ * 参考）をはじめ、分析モデリングを実施するための様々な技術や手法が紹介されています。どの分析手法でも、共通して「モデルとして表す前に、ドキュメントとして、そのドメインの特徴や本質をまとめる」こと、「その特徴や本質が持つバリエーションを洗い出すこと」が大切であると述べられています。

私自身、この本を読んで、「 " モノ " の本質を捉える」事の大切さと楽しさを知りました。オブジェクト指向で開発されている方も、そうでない方も、分析作業を行う際には、是非参考にして頂きたい一冊です。

（ * 参考） D-AME ：
A ： Anarysis （分析：ドメインの中に含まれるさまざまな情報を整理する）
M ： Modeling （整理した情報を様々なモデルに表す）
E ： Engeneering （ドメインに必要な機能を作成する）
の三段階に分けて分析を実施する手法。

お客様の業務やシステムへの要求をどう文書化するか苦悩していたときに出会った一冊です。
単なる机上の空論ではなく、タイトルの通りとても実践的な内容で、それでいて内容がよく整理されている点が気に入りました。
設計スコープ ( 議論の対象となっているシステムは何か ?) と目的レベル ( ユーザ目的、要約など ) という視点、事前条件と最低保証、成功時保証という考え方は、とてもしっくり胸に落ちました。「事後条件」でなく「最低保証」「成功時保証」であるのが面白いところです。
また、随所にユースケースの記述例が載せられ、各書式の長所・短所も整理されています。Tips も豊富で、実際にユースケースを記述するとき、また要求のまとめ方を検討する際、とても参考になります。

組み込み系編集員からの紹介文

何かと注目を集めている MDA （ Model Driven Architecture ）ですが、その一方で「理想は分かるけれども、本当に実現できるの？」という声も多く聞かれます。そんな疑念をお持ちの皆様方に朗報です。「実行プラットフォームに依存しないモデル (PIM : Platform Independent Model) からソースコードを自動生成する。」という MDA の基本理念自体はExecutable UML の前身である Shlaer-Mellor 法によって既に実現・実践されているのです。

本書には Executable UML が提唱する PIM を作成するための考え方や開発の進め方等々、MDA を実践する上で大変参考になる話題がギッシリ詰まっています。MDA の未来に思いを馳せている人は勿論のこと、懐疑派の人にも是非手にとって頂きたい一冊です。

ビジネス系編集員からの紹介文

「実装できないモデルは単なるスケッチに過ぎない」そこまで、強気に書かれていたら読んでみようと思うのが人間というもので、まんまと出版社の思惑通りに買ってしまったのがこの本です。
本書では、オンライン書店の例を元に、ユースケースから 実際のクラス図に落とし込み、テストを実施するまでの流れに沿って、丁寧に解説されています。特に、ライフサイクルについての説明は詳しく書かれており、文章で分りにくいと感じても、随所に用いられているクラス図やステートチャート図が理解を助けてくれます。

最初本を買った際には、自分の関わっている業務とは関連が薄いかなと思ったのですが、読んでみると、自分が曖昧に理解していたことが明確になったり、自分の業務にも当てはめられる考え方が書かれていたりで、勉強になりました。
UML を学びたての方には、学んだことを確認しながら次のステップへと自然と導いてくれる一冊であり、UML を実際に業務に取り入れられている方にとっても、役立つ考え方が詰まった一冊であると思います。

設計におけるパターン本のバイブルと言えば GoF 本ですが、その次に挙がってくる書籍とすれば、通称 POSA 本といわれる本書でしょう。
本書は、設計レベルで必要なパターンを抽象度の高いものから順に、アーキテクチャパターン、デザインパターン、イディオムという名称で 3 つに分類しています。POSA 本 ＝ アーキテクチャパターンの本として知られているので、アーキテクチャパターンが本書の中で重要なパターンと言えるでしょう。
GoF 本のデザインパターンは設計レベルで遭遇する問題の解決方法をプログラムに落とし込めるような形式でパターンとしてまとめられているのに対し、本書のアーキテクチャパターンは、システムの骨格を設計する上で遭遇する問題に対して、どのようなモジュール構成を取るべきかというモジュール間での責務の分担方法とそのための指針をパターンとしてまとめています。従って、本書を見たからといって、すぐにそのパターンを使ってプログラムに落とし込めるものではありません。アーキテクチャを検討する上で必要な観点を教えてくれるパターン本といったところでしょうか。

また、本書はパターン本として知られていることが多いですが、ソフトウェアを設計する上で理解しておくべき重要な概念も整理されています。

• カプセル化、情報隠蔽の違いは？
• インターフェースと実装を分離するメリットは？
• システムの非機能的特性とは？

といったことに対して説明ができなければ、本書の第 6 章 「パターンとソフトウェアアーキテクチャ」の章を見るだけでも価値はあるでしょう。ただ、整理されているもののわかりやすく書いてあるとはとてもいえません。もし、本書を読むのであれば、理解を深めるためにもアーキテクチャに興味のあるエンジニアと読書会を開いてみんなで読み進めていくことをお勧めします。
ちなみに、私もそうして本書を読破しました。一人で読んでたら途中挫折してしまうので。。。

およそ 800 ページに渡る本書は、J2EE のアーキテクチャに始まり、設計手法、コーディング標準、テスト、データアクセス、パフォーマンスにいたるまで開発プロセス全てが記述されており、J2EE プロジェクトに関わる人間にとって、必要な知識ギッシリです。
とはいっても、新人である私にはまだまだ難しい概念も、同様にギッシリ詰まっています。本書のレベルとしては J2EE がある程度わかっていることが前提かもしれません。そんな私が読んだ限りでも、今参加しているプロジェクトで実際に使われており、必須の内容ばかりだと思います。翻訳も大変分かり易いです。読破するには少し時間はかかるとは思いますが、熱い本には間違いないでしょう！

最初に扱ったオブジェクト指向言語が Smalltalk だった私にとって、随所に頷かされる一冊です。「パターン」と言うとどうしてもデザイン・パターンを思い浮かべてしまうかもしれませんが、本書は、設計についての本ではありません。いかにシンプルに、いかに深遠に、「コードでいかにコミュニケーションを行なうか」という、いわば「コーディング作法」についてのケント・ベックの叡智です。Boolean を返すメソッドの頭には is/was/will をつける（例：isNil ）といったパターンや、一時変数には処理の役割を表す名前をつける、といったパターンなど、 92 個のパターンが紹介されています。

• 継承することなく実装を共有するにはどうしたらよいでしょう？
• オブジェクトの振る舞いをパラメータ化するにはどうしたらよいでしょう？
• インスタンスごとに表現の仕方が異なるような状態を表すにはどうしたらよいでしょう？

そんな何気ない疑問の答えが、本書には、ちりばめられています。

Smalltalk でコーディングする際は、是非、膝の上に載せておきたい一冊です。Smalltalker ではない方にも、参考になると思います。

オブジェクト指向という面から見て、しかもそれなりに実用に耐える「面白い」言語を挙げるとすれば、私は Ruby を挙げたいと思います。
この本は、Ruby をソースコードから斬るという実にシンプルな発想で書かれています。しかし、その内容はただソースコードを解読することにとどまらず、処理系に必要とされる広範な技術分野をわかりやすく説明しています。

また、すでに広く使われている Ruby という優れた実装の紹介だけではなく、Ruby という処理系の方向性から来るアルゴリズムの選択のメリットとデメリットに触れながら、どのようなトレードオフがあるのかという面にも一言加えられている個所があり、非常にうれしい内容となっています。特に、Ruby の弱点でもあるスレッドに関する章（ 19 章）は、簡潔な章ですが、可搬性とパフォーマンス問題やネイティブなスレッドとの相性問題というトレードオフがなぜ生まれるのか、頷きながら読むことができると思います。

私自身、この本の半分も内容を味わっていませんが、Ruby に興味のある人はもちろん、言語系一般に興味のある人まで楽しめる内容になっていますのでぜひおすすめしたいと思います。

この本では、理解しにくいコードや明らかにメンテナンス性が悪いコードのことを「臭う」と表現しています。この「臭う」コードを徐々に改善していく手順が事細かに書いてあり、初心者がすぐにでも真似しやすい内容となっています。
この本の特徴を箇条書きでまとめると、とりあえず動くコードを、

• 読みやすく、メンテナンス性に優れていて
• 時にはデザインパターンを適用し
• コードをよりオブジェクト指向っぽく

するための例を大量に集めたテクニックカタログとでも言うべきでしょうか。コード例は Java でかれていますが、改善方法はオブジェクト指向に基づいたものなので C++ など他のオブジェクト指向言語を使用されている方も参考になると思います。

ところで私がこの本と出会った経緯ですが、現在参加しているプロジェクトで Java によるコーディングを始めたときに、オブジェクト指向っぽくないと言われ先輩からこの本を紹介されたのがきっかけでした。学生時代に Fortran77 でプログラミングしていたため、どうしても関数中心にプログラムを組んでしまい、さらにプログラミング経験が浅いためコードのわかりやすさ、メンテナンス性のないコードを書いていました。そこで、この本にかかれている例に適応されるような部分を徹底的に真似しました。真似することにより、自分のコードから「臭う」部分が消えていき、さらにはオブジェクト指向の考え方や、その恩恵などもわかるようになってきました。
こういった理由から、私と同様オブジェクト指向初心者、プログラミング経験が浅い方などにぜひ読んでほしいと思います。