「オブジェクト指向でなぜつくるのか」は良い本だ

「オブジェクト指向でなぜつくるのか」を読んで、良い本だと感じた。
ラフなメモ書き。

10年前に書かれた第2版の本なのに、オブジェクト指向をキーワードにして、これだけ幅広く記載しているのはすごいな、と思った。
本にある図を参照して、イメージ図を自分で書いてみた。

「オブジェクト指向」を開発者が混乱するのはなぜか？
犬や猫の鳴き声をポリモルフィズムで表すとか、その例自体が混乱させる。
現実世界を全てオブジェクトに置き換えられるわけではないのに。

理由は、元々はオブジェクト指向プログラミングから発生したのに、オブジェクト指向設計や再利用部品群やデザインパターン、UMLなどの派生した概念と混同しているから。
特に、オブジェクト指向設計は汎用の整理術なので、オブジェクト指向プログラミングとは全く異なる。

オブジェクト指向プログラミングで、メモリ領域の話と絡めて説明しているのは分かりやすい。
メモリにクラスやインスタンスがロードされる感覚がなければ、良いプログラムは書けないだろう。

一方、オブジェクト指向設計では、クラスは集合、インスタンスは要素として集合論に持ち込んだり、メッセージパッシングからクラスの責務・役割分担へ発展させたりして、本来のオブジェクト指向プログラミングから離れた方向に向いている。

面白かった点は、ビジネスソフトウェアと組込みソフトウェアでは、設計・分析の考え方が違う点だ。
ビジネスソフトウェア設計では、システム化される業務と人間の手作業の業務を明確に分ける。
システム化された領域のうち、データモデルのみが現実の出来事の世界を反映しているに過ぎない。
だから、業務分析でシステムの境界を明確にし、システム化する業務を詳細化することが非常に重要になってくる。

一方、組み込みソフトウェア設計では、機械装置が最初にありき、で、機械装置の機能を全自動化するためにソフトウェアで実現する。
もちろんオブジェクト指向設計もできるが、機能の状態遷移図の方が設計でも重要になってくる。
つまり、どういう状況で、どういう動作を行うのか、という要求分析の方が重要になってくる。

この違いが面白い。
組み込みソフトウェア開発は経験がなかったので、この辺りのフィーリングの違いは興味深く読んだ。

オブジェクト指向の影響は、オブジェクト指向のプログラムは再利用しやすい点より、フレームワークやコンポーネントなどの再利用ライブラリを作り出した。
そして、再利用する設計思想を抽出するコンセプトから、デザインパターンが生まれた。
デザインパターンも数多くの流派を生み出した。
再利用できるイディオムやノウハウ、プロセスという観点で、アナリシスパターン、アーキテクチャパターン、そして、組織パターンなどがある。
XPもプロセスパターンの一種である、と考えれば、オブジェクト指向の影響が見受けられる。

Scrumも、「More Effective Agile」で一番気に入った言葉「スクラムチームはソフトウェアのコンポーネントのように振る舞うので、ブラックボックスとして扱うべきだ」から考えると、オブジェクト指向の影響を受けているように思える。
スクラムチームは自律的なチームなので、プロジェクトマネージャはチームのインプットとアウトプットだけ評価すればよく、マイクロマネジメントする必要はなく、チームをブラックボックスとして扱うべき。
スクラムチームはコンポーネントのように疎結合で独立してるならば、複数のスクラムチームを疎結合で組み合わせることで、内部の無駄な影響なしで大規模なチームを構成しやすくなる。
つまり、コンウェイの法則「アーキテクチャは組織構造に従う」を、複数のスクラムチームで構成された大規模な組織は、は良い意味で実現している。

そんなことまで連想させてくれて面白い。
そして、改めて、アジャイル開発はオブジェクト指向の影響を色濃く受け継いでいることを再認識した。

【追記】
2021年4月に第3版が出版された。
平鍋さんの記事もある。

『オブジェクト指向でなぜつくるのか』第3版