■

オブジェクト指向

前回、この話題に触れました。
今回はもう少し噛み砕いてみたいと思います。


まず、オブジェクト指向が果たそうとしているものは、「複雑さを解消する」と「変更に強い構成を作る」事なんだと思います。「開発効率を上げる」とか「品質の良いプログラムを作る」という事が最終的な目的であって、「複雑さを解消」する為だけにオブジェクト指向を用いる訳ではありませんが、目的が大きすぎたり漠然としすぎたりすると焦点がずれてしまいそうなので、あえて「複雑さを解消する」と「変更に強い構成を作る」事だとします。

複雑さを解消する

複雑さを解消する事が何故重要か。
これを考える場合、まず複雑さが解消されなかった場合どうなるか、想像してみます。

  • ひたすら複雑な分岐条件が入り乱れたメソッドを見た場合、普通まっとうなエンジニアであればゲンナリします。
  • また、そのメソッドの仕様をプログラム・ソースから把握しようとした場合、調査がとても大変そうです。
  • また、仕様が分かってきたら実際に動かしてみようとすると思うのですが、その時の動作パターンは大量の分岐条件によって天文学的数になっている可能性があります。

あまり良い事は無いようです。自分は、「解消しなきゃ」と思ってきました。では、

  • まっとうなエンジニアがゲンナリしないようにする。
  • 調査を簡単にする。
  • 動作パターンを少なくする。

これらの目的を達成することで、得られるメリットとは何でしょう。


恐らく、

  • プログラムの保守性が上がる。
  • 解析コストが減る。
  • テスト作業のコストが減る。

こういったメリットが得られます。解析コストは、まったく新規の場合不要ですが、プログラムの保守性向上とテスト作業のコスト・ダウンは、現代のシステム開発プロジェクトでは非常に大きなメリットだと思います。

複雑さを解消する場合に負うべきリスク

これだけで自分はオブジェクト指向を使うべきだ、と思います。が、最近書いたように、ここで思考停止をさせるのはリスクを見逃す事ですので、あえて更に深く考えてみました。

この2点がぱっと思い浮かびました。
まず前者は、開発するシステムが1人で企画、計画、製造までやるような小さな規模であればあまり問題になりません。（そういう規模であれば、メリットも少ないかも知れません）しかしそれなりに規模が大きいシステムの場合、1人で設計、製造を行う事は無理です。その為、少なくとも設計者は全員オブジェクト指向を使える事が、オブジェクト指向という技法をそのシステム開発プロジェクトに導入する条件になります。
また後者は、プログラムの結合度、凝集度を的確に数値化するなり何かしら評価しやすい形にする必要があります。絵・モデルに出来る、という点も整理できているかどうかを見る一つの視点になりますが、定量的な評価は難しいかも知れません。


導入する鍵を握るポジションを担えれば話は別ですが、そうでなければ少なくともこの2点の懸案が解消されなければ、リスキーと言ってしまって良いのかも。