オブジェクト指向のデメリット
再利用は容易ではない
ソフトウェアを部品として再利用できる、という点は、オブジェクト指向によってもたらされる利点の１つとして、よく主張されてきた。
ソフトウェアの開発を繰り返していくたびに、再利用できる部品がどんどん揃って、開発は楽になっていき、開発コストも小さくなっていく、というのが、オブジェクト指向を薦める際の謳い文句であった。
だが現実には、ソフトウェアを部品として再利用できるケースは多くない。それは、作る側と使う側、それぞれに超えるべき壁があることが原因だ。
作る側の壁としては、部品化のための工数をかけられるかどうか、という問題がある。
ソフトウェアを部品として再利用できるようにするためには、部品化を見据えた設計をしておく必要がある。やみくもに作ったソフトウェアでは、一部を部品として他に流用することはできない（その結果、コピー＆ペーストが多用されることになりがちだ）。
部品化のための設計は、そのソフトウェアを開発する本来の工数とは別に、余分な工数をかけて行うことになる。だが、部品として再利用できるようにしても、本当に再利用されるとは限らない。再利用されなかった場合は、かけた工数が無駄になってしまう。現実的には、部品化を見据えて設計しておくことは難しい。
使う側の壁としては、オブジェクト指向的に良く設計された部品は、使う側にもそれなりの知識や技術を要求する、という点が挙げられる。
完成度の高い部品の仕組みは、高度な設計思想に基づいていることが多い。部品を使うためには、その設計思想を理解する必要がある。
例えば、XMLファイルを読み書きする部品は、SAXやDOMといった概念で構成されている。初心者が、ちょっとXMLファイルの読み書きをしたい、と思っても、APIを見ただけで尻ごみしてしまうだろう。
開発工数は増加する
ソフトウェア開発にオブジェクト指向を導入すると、開発コストが削減できる、というのは、たいていの場合は誤りである。むしろ、従来よりも大幅に工数が増えることが多いだろう。
まず、ソフトウェアの設計に、かなり時間がかかる。これは、オブジェクト指向設計に慣れているかどうかの問題ではない。オブジェクト指向によって、良く整理された、構造の美しいソフトウェアを作ることはできるが、その分、頭を使って考える時間も長くなるのだ。
逆にいえば、力技で書き上げてしまう場合は、設計の時間はほとんどかからない。ちょっとしたテストツールなどの場合は、むしろオブジェクト指向設計などしない方が良いかもしれない。
また、オブジェクト指向設計では、モジュールの切り分けが重要となる。初心者は、さまざまな機能を１つのファイルや関数に詰め込んでしまうことが多い。オブジェクト指向設計では、限られた機能を持つたくさんのモジュールが互いに連携するような構造になる。その代わり、関数やクラスの数は増える。ソースコードのファイル数や行数も増えることになるだろう。即ち、コーディングの量は、従来よりも増えることになるはずだ。
要員確保が難しい
オブジェクト指向的に開発したソフトウェアでは、開発プロジェクトに参加できる技術者の敷居が高くなる。オブジェクト指向の技術を身につけている上級の技術者しか、担当できなくなるためだ。
それも、単にオブジェクト指向の一般的な技術を知っているだけではなく、そのソフトウェアを設計した当時の設計思想や独自の概念に精通している必要もある。でないと、せっかく組み上げたソフトウェアの構造が、新たな修正によって乱され、壊れてしまう可能性もある。
将来の機能追加や、不具合の修正において、急遽、要員を割り当てる必要が生じても、スキルのある技術者は空いていない、ということもあり得る。
それでも、オブジェクト指向が良い理由
これらのデメリットがあるにも関わらず、冒頭では、オブジェクト指向はたいへん有力であり、必須のスキルである、と述べた。それは、オブジェクト指向には、下記のように、メリットもあるからである。
オブジェクト指向によってもたらされるこれらのメリットは、ソフトウェアが大規模、複雑になればなるほど、前述したデメリットを覆すほどの圧倒的な効果を発揮する。
可読性が向上する
オブジェクト指向的に組み上げられたソフトウェアは、高度に汎用化・抽象化されており、一見するだけでは理解できないかもしれない。だが、その背景にある設計思想さえ理解できれば、巨大なソフトウェアであっても、全体の仕組みを把握することができる。
オブジェクト指向的に組み上げられたソフトウェアのソースコードは、設計書の内容を、プログラミング言語を使って具象化したもの、と見ることができる。設計書とのギャップが小さいため、設計書に従って読み解いていくことができる。
設計思想のないソフトウェアは、ソフトウェアの処理を初めから１つずつ順に追っていくしかない。このようなケースでは、経験の浅い技術者でも、熟練した技術者でも、誰が読んでも同じくらい時間がかかってしまう。せっかくの技術力も効果を発揮しない。ある程度の規模になると、解読はもう不可能となる。
品質が保証できる
オブジェクト指向では、個々のモジュールは限定された機能を持ち、互いに切り分けられている。そのため、単体テストは容易になる。また、機能が限定されているため、不具合を作り込む可能性も減らすことができる。
オブジェクト指向においては、ソフトウェアの不具合は、それらのモジュールが互いに連携する仕組みの不備に起因することも多い。このような不具合は、ソースコードよりも抽象的な、設計書のレベルで検証することができる。不具合があったとしても、その原因や修正方法を明確に説明することができる。
やみくもに作られたソフトウェアでは、不具合が見つかっても、場当たり的な対処しか施しようがない。修正方法が正しいかどうかは、テストで確かめることになる。即ち、動かしてみないと正しいかどうか分からない。そのため、予想だにしない他の部分に悪影響を与えてしまうことも多い。
開発工数を削減できる
オブジェクト指向のデメリットでは、オブジェクト指向によって設計や実装の工数は増加してしまう、と述べた。だがそれは、ソフトウェアの規模がそれほど大きくない場合の話である。
ある程度の規模になると、オブジェクト指向的に設計をした方が、より効率的に考えをまとめて、プログラミングに着手できるようになる。
実装においても、オブジェクト指向ではモジュールの切り分けに重点が置かれるため、作業の分担などが柔軟に行える。その結果、開発プロジェクトのスケジュール的な進みを早めることもできる。
そして何よりも、テストフェーズに至った後の工数は、オブジェクト指向によって大幅に削減できるだろう。前述したように、不具合の可能性を予め減らすことができるし、可読性の向上によって不具合の原因も突き止めやすくなる。ソフトウェア開発では、プロジェクトの終わりになって問題が多発し、状況が悪化しがちだが、オブジェクト指向によって、その危険性はかなり減らすことができるだろう。