ソフトウェア開発方法論
オブジェクト指向の評価基準
オブジェクト指向の評価基準として、Robert C. Martinによる、オブジェクト指向設計の原則（Principles of OOD）について説明します。
1)SRP：単一責任の原則（Single Responsibility Principle）
クラスを変更する理由は1つでなくてはならない。また、クラスの責務（役割）は1つでなければならない。
2)OCP：オープン・クローズド原則（Open-Closed Principle）
機能拡張をソース追加で行うことができ、既存ソースを修正できないようになっているべきである。
3)LSP：リスコフの置換原則（Liskov Substitution Principle）
あるクラスで正しく動作する場合、そのクラスの派生クラスでも正しく動作すべきである。
4)DIP：依存関係逆転の原則（Dependency Inversion Principle）
呼び出し側のモジュールは呼び出される側のモジュールに依存してはならない。どちらも抽象クラスに依存すべきである。
5)ISP：インターフェース分離の原則（Interface Segregation Principle）
使用していないインターフェースに依存してはならない（使用されないメソッドを公開すべきではない）。
このように、オブジェクト指向に関して、これまでにもさまざまなノウハウが蓄積されています。このノウハウが形式知としてまとまっているものの代表が、上記原則であり、デザインパターンである、と言えるでしょう。デザインパターンと一口に言っても、いろいろなものが発表されていますが、その中でも特に有名なのは、GoF（The Gang Of Four）のデザインパターンでしょう。「車輪の再発明」を行わない意味でも目を通しておくことをお勧めします。
少し話がそれますが、ここで、UMLについて紹介したいと思います。オブジェクト指向の開発方法論として、1990年代ごろには、Booch法やOMT法等、いくつかのものが提唱されていました。現在では、それらの開発方法論自体は、UP（Unified Process）やRUP（Rational Unified Process）等の開発プロセスとしてまとめられています。
しかし、これら開発方法論の大きな功績として忘れてはならないのが、UML（Unified Modeling Language）の誕生でしょう。UMLは、それまでバラバラの表記法を使用していた夫々の開発方法論のノウハウを統合して策定されました。このUMLが、オブジェクト指向を普及させる推進力となったのは間違いないでしょう。
プロジェクトの現場では
構造化技法とオブジェクト指向、両者の住み分けはどのようになっているのでしょうか。実際の現場における使われ方について見ていきたいと思います。これまでも散々言われてきたことですが、「オブジェクト指向は難しい」ことは事実でしょう。つまり、スキルレベルがある程度以上の開発者でないと、オブジェクト指向を使いこなすことはできません。
他方、開発プロジェクトは、オブジェクト指向を使いこなせるだけのスキルレベルを持つ開発者のみで構成されているとは限りません。むしろ、そのようなケースのほうが少ないでしょう。特に大規模プロジェクトになるとなおさらです。この観点から言うと、すべての開発者がオブジェクト指向を駆使して開発するケースは少ないと言って良いでしょう。
もともと、オブジェクト指向の目的の1つが再利用化だったこともあり、オブジェクト指向は再利用されるようなプログラムを作成する際に大活躍します。その再利用されるプログラムがフレームワークであり、プロジェクトの共通基盤であるのです。すなわち、既に開発されているフレームワークを特定プロジェクト向けに拡張したり、プロジェクト固有の共通基盤を設計開発するのは、オブジェクト指向を使いこなせるスキルレベルを持つ一部の開発者が行います（図3）。
ほかの大多数の開発者は、それらフレームワークや共通基盤をルール通りに使いこなすことが多いでしょう。そういう意味では、フレームワークや共通基盤が整備されたプロジェクトにおいては、敷かれたレール通りにコーディングするだけなので、プログラマーとしては「つまらない」かもしれませんね（ただし、オブジェクト指向を理解していないで良いという訳ではないので、その点はお間違いなく）。
最後に、オブジェクト指向と似た言葉として、アスペクト指向という言葉を紹介しておきます。現状ではアスペクト指向は、開発方法論というよりも、1つの考え方と見なしたほうが良く、さらに言うと、オブジェクト指向のすき間を補完する目的であると言えます。オブジェクト指向ではうまく分類できない特性（複数のクラスで共通に持つ機能等）を「アスペクト」と見なし、クラスの切り口とは別にプログラミングできる仕組みが整備されつつあります。
さて、次回は、いよいよ開発プロセスを紹介していきたいと思います。お楽しみに！
