オブジェクト指向の簡潔なまとめ
最近になって、オブジェクト指向について改めて見直す機会があったので、簡潔にまとめてみました。
そもそもオブジェクト指向とは?
オブジェクト指向は、一般的にプログラミングテクニック扱いされています。しかし、本来は変更の多い「機能」ではなく
安定した「問題領域」をモデル化することで、理解しやすく、変更、修正に強いソフトウェアを開発するための開発手法です。「問題領域」をモデル化してコンピュータの世界を隠ぺいし、人間に歩み寄るのが中核となるコンセプトなので、元来トップダウンで、下流の「How」よりも、上流の「Why」「What」を重視します。もちろん、設計や実装ではコンピュータの世界を強く意識する必要があります。
オブジェクトとモデル化
オブジェクトとは、ソフトウェアの世界で特定の問題を解決するために、現実世界の物理的なものや概念等をモデル化したものです。
また、モデルとは「現実世界の物事を特定の目的に合わせて抽象化したもの」になります。モデルは特定の目的を満たせば良く、目的と関係ない特性を省略できます。モデルの例は以下のとおりです。
- プラモデル -> プラスチックで造形のみをモデル化
- 地図 -> 現実世界の位置に関する情報のみをモデル化
- 組織図 -> 集団の階層関係や関連をモデル化
上記の例と同様に、オブジェクトは「現実世界を元に、特定の目的のために、ソフトウェアの世界で表現されたモデル」になります。わかりづらいので、例としてJavaでデータベースを操作するためのオブジェクト「Connection」を挙げます。
Javaプログラムとデータベースの通信は複雑で、通信方式や操作、解釈が様々です。そのため、エンジニアがその都度、データベースの仕様を調べてプログラム化するのは負担が大きいです。
しかし、Connectionオブジェクトは、「データベースの共通的な操作のみ」をモデル化して、通信方式などを隠ぺいし、エンジニアの負担を軽減します。エンジニアは、Connectionのみを意識して、必要な操作を呼び出せばよいのです。
上記のように、オブジェクトは優れた特性を備えています。オブジェクトの主なメリットは以下の通りです。
- 問題領域にちなんだ名前を持ち、人間が識別できる = ソフトウェアの見える化、抽象化
- 再利用できる = 開発コストの削減、ソフトウェアの資産化
- 既存のオブジェクトを元に拡張できる = 開発コストの削減
- 容易に差し替えられる = 変更への対応性
オブジェクト指向の暗黒面
オブジェクト指向は強力ですが、致命的な弱点があります。それは、「オブジェクトの抽出、モデル化が極めて難しい」ということです。
オブジェクトの抽出、モデル化は「絵画」のようなもので正解がなく、効果的に使うには、かなりの熟練が必要です。
私の短い経験では、中途半端な理解で抽出されたオブジェクトは、まともに動かなかったり、変更も再利用もできず、維持メンテが困難なことが多いです。それならば、シンプルな分、丁寧にメンテされた構造化プログラムのほうがマシです。
別のパラダイムと組み合わせる
多くのエンジニアがオブジェクト指向を使いこなせない現実を踏まえてなのか、最近は関数型やDSL等の別のパラダイムが注目されています。オブジェクト指向は今後も利用されるでしょうが、ソフトウェアの生産性、品質向上のために、これらのパラダイムにも注目すべきでしょう。関数型やDSLについて、多くを語れるほど詳しくないため、この記事では踏み込まないこととします。
まとめ
最後にこの記事で言いたいことをまとめます。
参考文献
- The Art and Science of Smalltalk
- Object Oriented Modeling and Design
- Domain-Driven Design: Tackling Complexity in the Heart of Software
- Design Patterns: Elements of Reusable Object-Oriented Software
