読者です 読者をやめる 読者になる 読者になる

オブジェクト指向のデメリット

 組み込みではオブジェクト指向の採用があまり進んでいません。この背景となっているオブジェクト指向のデメリットについて、今回まとめたいと思います。
 
1. 必要なリソースが大きい
 オブジェクト指向によるプログラムは、言語構造上メモリを贅沢に使います。 一方で処理速度に関しても、オブジェクト指向で書かれた関数はインライン化しにくい傾向を持つ上、関数の数も多くなるため、オーバーヘッドによるロスが大きくなります。
 またフレームワーク上で動作することを前提とした言語もあり、その場合処理効率が更に大きく落ちることになります。


2. コードの量が増える
 オブジェクト指向では、オブジェクト間のインターフェースやアクセサなど、構造や設計を示すための記述が要求されるため、非オブジェクト指向のプログラムよりコードの量が増える傾向にあります。
 これはプログラムの規模が小さくなるほど開発を非効率なものにします。


3. 設計が難解
 オブジェクト指向のソフトウェアは、フローチャート主体、あるいはデータ主体で設計を進められた従来のパラダイムより設計が難解です。
 設計で妥協すると、C++を高機能なC言語として使ってしまうように、リソースだけ浪費してオブジェクト指向のメリットが全く活かされないという事態を招きます。
 そのため、オブジェクト指向による開発では優秀な設計技術者が必要となります。


4. 処理の流れが追いにくい
 プログラムを構成するオブジェクトそれぞれが独立して状態を持つため、オブジェクト指向のプログラムではフローチャート的なステップを追った解析が難しい場合が少なくありません。
(オブジェクト指向のプログラムを図化するために策定されたUMLも、処理の流れを記述するアクティビティ図は整備が遅れ気味でした。現在でも十分に整備されたとはいえない状態です)
 デバッグも、処理の流れではなく入出力によるテストが主体となります。


5. ライブラリ型の構造が不適となる
 例えばC言語のヘッダファイルでは、数学に関する機能(sin()関数、cos()関数など)はまとめてmath.hに、文字列操作に関する機能はまとめてstring.hに格納するなど、機能による分類で構造を記述しています。
 こうした機能によって分類するライブラリ型の構造は、オブジェクト指向では考え方として不適となります。
 例えばC#にもMathクラスなどがありますが、あれは一種の妥協の産物といえるものです。


6. 低レイヤ層との親和性が損なわれる
 WindowsLinuxUNIXなどのOSや、デバイスドライバといった低レイヤのプログラムは基本的に非オブジェクト指向言語で記述されており、APIなどもその非オブジェクト指向言語に立脚した形でユーザー層に公開されています。
 そのためオブジェクト指向言語で低レイヤ層の機能を使おうとすると、フレームワークやインターフェース機能などが要求される場合が少なくありません。