オブジェクト指向は真理ではなくドメインに依存する

　オブジェクト指向は、当然のことながら、完璧な理論ではありません。盲目的に使用すると、余計にシステム開発の失敗要因となります。従って、オブジェクト指向の弱点を熟知する必要があります。そこで今回は、オブジェクト指向の弱点を書くことにしました。
　オブジェクト指向の弱点は、細かいところを言えば色々ありますが、その根本的理由はドメイン（問題領域）に依存することから発生しています。巷で誤解が発生するような表現が有名なものの、開発しようとしているドメインに即したものとしてオブジェクトは作成されます。従って、森羅万象あらゆることがオブジェクトで表現できるという誇大広告は一部誤りです。
　この理由は難しいので例を挙げます。例えば、オートマトンを実装するときのことを考えましょう。オートマトンをオブジェクト指向プログラミングで実装する場合、大概の人は状態をオブジェクトとして実装するでしょう。何故ならば、オートマトンの状態遷移関数と出力関数は、状態とセットで実装する方が保守性と拡張性が上がるからです。オートマトンの定義に正確に従って、状態を文字列として実装すると、長い多分岐処理（switch文やif文など）が必要となります。しかしながら、拡張性と保守性を考えると、この状態は好ましくありません。オブジェクト指向で考えたとき、そういう考えから、状態をオブジェクト化して、一部の関数で多分岐プログラムを書くことを避けます。こうすることにより、状態遷移が複雑化した時の、拡張と保守を容易にします。これがオブジェクト指向プログラミングの定石です。
　オブジェクト指向プログラミングの多分岐を避ける定石は、正しく絶対的なように感じる人もいるでしょう。しかしながら、オートマトン本来の意味を改めて考えてみると、必ずしも正解とは言えない事に気づきます。というのも、状態遷移と関数は本来別々のものだからです。たまたま、そのドメイン内でそうなっているからと言って、状態が常にそうなるとは限っていません。状態の本質から離れてしまっています。
　これは、システム開発の根源に起因する問題です。誰しも求められるシステム以外の要因をオブジェクトに求めません。学術的に正しいからと言って、ビジネスシステムの人間オブジェクトに、遺伝子などの詳細な情報を実装しません。すなわち、世界の真理とシステムとは明確な乖離があり、オブジェクトは真理ではなく、ドメインに依存しているのです。
　この問題は取るに足りない問題だと考える人が大半でしょう。システム開発が我々のお仕事であり、使用しない真理を追い求める必要はありません。いえ、それどころか、そうする行為は有害だからです。しかしながら、真理とドメインが乖離している事を意識せず、オブジェクト指向が絶対的に正しい錯覚している状態でシステム開発をすれば、見落とされた矛盾がプロジェクトを失敗へと導きます。プロジェクトが失敗する原因は、大きな一つの要因ではなく、小さな無数の要因から構成されています。
　しかし、勘違いしてはならなりません。弱点があるからオブジェクト指向を採用しないという考えは間違いです。何故ならば、全ての人間の思考法に間違いがあり、完璧な方法など存在しないからです。やはり、狼男を撃つ銀の弾丸は存在しません。
　我々技術者およびシステム開発の関係者がするべきことは盲目的な否定でなく、妄信でもなく、長所と弱点をよく把握し、お客様を満足させることです。お客様がついていけない高尚なシステムは要りませんし、迷信に基づくシステムもいりません。お客様を満足させるのが唯一無二の目的であり、それだけを目指するべきと私は考えています。

オブジェクト指向の本質

　オブジェクト指向といえば、情報の隠蔽、継承、多態性が有名です。この言葉を知っている人は多いと思います。しかしながら、この3つの言葉の意味を本当の意味で理解している人が少ないと思います。そこで今回はオブジェクト指向の本質について書くことにしました。
　初めに言っておかねばならないことは、オブジェクト指向とは分析（OOA）・設計（OOD）・実装（OOP）の3つの事を考えねばならないという点です。オブジェクト指向はソフトウェア工学のあらゆる領域にまで発展しており、この3つのOOXがあることを念頭に置かねば足りません。さらに、OOA/OOD/OOP（OOX）はいくつも亜流があります。
　提唱者は同時に定義することが多いので、OOAとOODは大概手法が重なっています。それら方法論の中で有名なのは、リカーシブ開発、Booch手法、Coad/Yourdon手法、Texel手法、OMT、SOMA手法、OOSD、OOSE、MERODE手法、SSADMです。私は一応、これら手法に目を通しました。これら方法論の違いは、開発で起こる現象をどのようにしてとらえるのかという点にあります。共通点は分析・設計・実装の流れをスムーズにすることです。オブジェクト指向よりも前に使われていた構造化設計法は、この視点が不足していました。誤解されやすいのですが、オブジェクト指向方法論は、構造化設計技法の知識を前提としています。構造化設計技法を知らないと真に理解できません。また、実際にシステム開発をするときはアジャイル開発の手法とセットで使います。オブジェクト指向方法論は閉じたものではないのです。
　OOPにおいても、特定の言語だけのものではありません。よく見られる間違いは、C++などの特定言語のOOPに思考が縛られる事です。OOPを真に理解するには、少なくとも命令型、関数型、論理型、集合型、宣言型、の各種言語に触れる必要がありますし、さらに静的な型と動的な型によるOOPを経験せねばなりません。これらのOOPを経験して分かったことは、状態と抽象化と制御がOOPの核だといえるということです。
　オブジェクト指向を言語モデルとして考えたとき、キーとなるのは状態の変化です。OOPをする時点で、状態の変化が伴います。何故ならばOOPは、状態ありの計算モデルだからです。
　状態をどのようにして扱うのかという点で、OOPは役立ちます。モジュール性はOOPでなくともありますが、OOPはそれをさらに進めて、ある程度統一した方法でデータの抽象化とプロセスの抽象化を統一化します。さらに、情報の隠蔽の考えを適用し、スコープの範囲を制御します。これにより、変化に強いプログラミングが可能となります。
　もうお分かりになったと思いますが、情報の隠蔽・継承・多態性の3原則は、変化に対処するための概念です。すなわち、あらゆる変化をいかにして扱うのかというのがテーマであり、オブジェクト指向の本質なのです。情報の隠蔽により変化がもたらす影響範囲を狭め、継承により拡張性をもたらし、多態性によりバリエーションと統一性を実現します。
　オブジェクト指向の本質は変化への対処です。オブジェクト指向にある多種多様な概念に触れ、変化に対処する術を学びましょう。そうすれば、きっと優れた開発者になれるでしょう。

変化を否定する人はオブジェクト指向を理解していない

　私はオブジェクト指向が十分に普及していないと感じています。最近のプログラミング言語の多くが、オブジェクト指向をサポートしているのにも関わらず、オブジェクト指向を理解していない人が多い事が不思議でなりません。この状態は好ましくありませんので、オブジェクト指向の考えを広めるためのこの記事を書こうと考えました。
　オブジェクト指向は、文法を覚えたら理解したと言える程単純なものではありません。プログラミング言語が備える、オブジェクト指向に関する文法は、あくまでも実現するための手段であり、オブジェクト指向そのものではありません。オブジェクト指向は、その考え方を理解して初めて習得したと言えるものです。従って、オブジェクト指向がどの様な概念なのかを深く理解しなくては、マスターしていない事になります。残念な事に日本のIT業界の仕事のやり方を見ると、オブジェクト指向の考えを理解していないと思えてなりません。
　私がそう感じる理由は、日本には変化を頑なに否定し、変化に拒否反応を示す人が多いからです。新しいものを否定し、何でも反対を唱えるその姿勢には、オブジェクト指向を理解しているとは言えません。何故ならば、オブジェクト指向は変化を前提として考えだされた概念だからです。
　オブジェクト指向の前は、構造化プログラミングの考えが浸透していました。予め仕様を完全に決定し、ウォーターフォールに開発を進めていました。このやり方は、変化が少なく、プロジェクトの規模が小さいときには上手くいきました。しかしながら、プロジェクトの複雑化に伴いその考えは脆くも崩れ去り、ソフトウェア危機が唱えられるまでになりました。
　その状況に対応するために考え出されたのが、オブジェクト指向プログラミングです。オブジェクト指向は、今までの問題を改善するべく、データと振る舞いを一体化し、プログラムを局所化し、プログラムに拡張性をもたらしました。構造化プログラミングは、あらかじめ仕様を完全なものにするのが前提でしたが、オブジェクト指向プログラミングではその前提がありません。小さなプログラムを徐々に組み立てて、ソフトウェアおよびシステムを拡張させながら完成させます。
　オブジェクト指向の根底にあるのは、変化に如何に対応するのかです。変化に対応するために、プログラムの影響範囲を狭め、プログラムの拡張性を重視したのです。ですから、変化が早い現実から目をそらし、変化を拒み、無意味な管理をする保守的な態度は、オブジェクト指向の考えを体現しているとは言えません。
　人間は生きているから活動し、時がたつにつれて全てが変化します。その現実を無視し変化を否定するという事は、世の理に背を向けている事になります。人は生き、時は流れるので、変化が起こるのは当たり前の現象であり、それを踏まえたオブジェクト指向の考えはとても自然です。無理して自然の流れに逆らうよりも、現実を直視して自然を受け止め、オブジェクト指向の考えを実践しましょう。
　それこそが技術者として、いえ人そして自然な生き方だと私は思います。

再利用という名の幻想

　オブジェクト指向の話題で必ず出るのが再利用という概念です。その中で、オブジェクト指向を使えば全てのものが再利用できるかのような誇張した表現をたまに目にします。しかしながら、結論を先に言いますと、再利用できないオブジェクトは存在します。今回はその理由とともに、オブジェクト指向の現実を語ります。
　オブジェクト指向の解説で「全てのものはオブジェクトで表現でき、オブジェクト指向を使えば既存のオブジェクトを再利用できる。」という旨の謳い文句を見かけます。この様な文章を見ると、まるでオブジェクト指向が万能薬の様ですが、現実はそれほど甘くありません。全てをオブジェクトで表現できるのは、半分嘘で半分真実です。そして、既存のオブジェクトを再利用できるというのも半分嘘で半分正解です。
　オブジェクトは抽象的な概念であり、全ての物事は抽象的に表現可能であるというのが真実です。そして、抽象的なものは目的が合致すれば再利用できるというのが実態です。これからそのメカニズムを詳しく解説します。
　少々あざとい例ですが、システム利用者オブジェクトを考えてみます。このシステム利用者オブジェクトは如何なるシステムでも再利用できるでしょうか？答えは否です。何故ならば、システム利用者オブジェクトは、問題領域に左右されるからです。販売システムならば「買う」メソッドを持っているでしょうし、医療システムならば「受診」メソッドがあるでしょう。
　これは抽象化の本質に起因する問題です。抽象化とは、複雑な現実の細部を意図的に無視して扱いやすくする事ですので、視点によりオブジェクトの性質が変わります。従って、再利用できない、もしくは再利用する価値のないオブジェクトは存在します。当然と言えば当然のことなのですが、意外とこの事実を忘れている人が多いようです。
　誤解がないように明記します。だからといって、オブジェクト指向は役に立たない概念ではありません。しかしながら、過度の期待による幻想は抱かないようにせねばなりません。如何なる技術もその本質をよく理解して使用せねばならないのです。

再利用できるオブジェクトを発見する方法

　オブジェクトの再利用とは何かの記事で、オブジェクト指向は分析・設計・実装の3つの段階があり、各段階のオブジェクトは違う事について書きました。また、容易にオブジェクトを再利用できない事も書きました。この記事ではそれを踏まえ、如何にして再利用できるオブジェクトを発見するのかについて書きます。
　オブジェクトを最大限に再利用するには、再利用に値するオブジェクトを識別しなくてはなりません。ただし、漫然とオブジェクト指向でシステムを構築していても、再利用できるオブジェクトは識別できません。再利用しやすいオブジェクトを識別するには工夫が必要です。
　オブジェクトを識別する方法を考えるには、再利用について深く考えなくてはなりません。再利用というからには、違うプロジェクトでも使用できなくてはなりません。では、違うプロジェクトでも再利用できるオブジェクトとは一体何なのでしょうか？
　人間が考える事や事象には一定のパターンが存在します。そのパターンをオブジェクトとして抽象化すれば、それを再利用する事が可能となります。つまり、再利用できるオブジェクトの正体は一定のパターンであり、再利用の原理はプロジェクト間で共有できるパターンを使用する事だと言えます。
　あらゆるシステムには、不変的な部分と、そのシステム特有の部分が存在します。違うシステムにも再利用したいわけですから、普遍的な部分に注目すればよいのです。これが分かれば、再利用できるオブジェクトを識別する方法は自ずと導き出されます。
　オブジェクト指向を実施する際、我々はUML図などを使用します。その図のシステムの特殊な部分もしくは、特殊な事柄でない部分をマークすれば（どちらか少ない方をマークすれば見やすい）、自ずと再利用できるオブジェクトが浮かび上がります。後は、複数のプロジェクトで作成した図と暗ラベルと再利用できるオブジェクトを具体化できます。
　この際重要なのは、分析・設計・実装は厳密に区分できない事を考慮する事です。オブジェクト指向は現実の世界の事象をオブジェクトして抽象化し、情報処理技術の世界へと徐々に具象化していきます。ですから、分析・設計・実装の各段階は独立して存在しているのではありません。各段階も複数の抽象化段階が存在します。そのオブジェクトの変化も着目しなくては、よいオブジェクトは発見できません。その点に注意すれば後は簡単です。
　漫然とオブジェクト指向でシステムを構築しないで、システムの普遍部分と特殊部分を見分けましょう。そうすれば、再利用できるオブジェクトを発見でき、オブジェクト指向の恩恵が受けられます。

オブジェクトの再利用とは何か

　オブジェクト指向が目指すもののひとつが再利用です。しかし有名な割に実際は再利用はそれほどされていません。その原因は、オブジェクト指向における「再利用」という言葉があまり理解されていないのが原因です。そこで今回は、オブジェクト指向における再利用について解説する事にしました。
　一番大事なのはオブジェクト指向におけるの部分です。オブジェクト指向＝オブジェクト指向プログラミングだと、誤解している人が多いので先ずはその誤解を解きます。
　オブジェクト指向は、分析段階・設計段階・実装段階（プログラミング）の3段階あります。分析段階で現実をモデル化し、設計段階でシステムを設計し、実装段階でコーディングします。各段階におけるオブジェクトの意味するものは異なります。分析でのオブジェクトは現実の情報を抽象化したもの、設計段階でのオブジェクトは分析段階で概念を情報処理技術に射影したもの、実装段階でのオブジェクトとはプログラムの塊です。
　さらに、オブジェクト指向の定義は明確ではない点に注意が必要です。オブジェクトとは何らかのもの（実体）を意味します。しかし、どのように実体を捉えるのかは人により異なります。それ故、オブジェクト指向方法論が数多く存在し、オブジェクト指向を謳うプログラミングごとに差異が生じています。
　オブジェクトの再利用について考える時は、以上の事柄を踏まえなくてはなりません。オブジェクトは意外と再利用できないという言葉をよく聞きますが、漫然と再利用としているだけでは出来ないのは当然です。オブジェクトという一意の意味を持たない曖昧模糊としたものを、再利用するのは簡単ではありません。オブジェクトを再利用しようという確固たる意志と適切な行動が必要です。どの段階のオブジェクトを再利用するのかを考えなくてはなりません。全てのオブジェクトが再利用できるのではなく、再利用できるオブジェクトは条件が存在します。
　オブジェクト指向分析で再利用できるオブジェクトは、問題領域に関するオブジェクト（アーキテクチャ）です。アーキテクチャは同じ問題領域ならば一部再利用する事が出来ます。一般的には、同じ業種かつ同じ課題を持つプロジェクトに再利用できます。オブジェクトをさらに抽象化すれば、同じ課題における解決法＝オブジェクトも再利用できます。分析段階の目的が現実をモデル化する事なので、分析段階における再利用できるオブジェクトとは、現実をモデル化して得られた知見でありアーキテクチャなのです。
　オブジェクト指向設計で再利用できるオブジェクトは、システム化する上で実体およびその関連を抽象化したものです。一言でいえばデザインパターンです。設計で再利用できるオブジェクト＝デザインパターンを抽出するのは難しい事です。
　何故ならば、問題の抽象化をせねばならないからです。デザインパターンを実務で使用した事のある人ならばよくわかると思いますが、デザインパターンは教科書どおりには適用できません。実際に使用する際には、問題領域に応じた形で特化せねばなりません。従ってオブジェクト指向設計におけるオブジェクトを再利用するには、個別の事例を解いた上で、その問題を抽象化してパターン化せねばなりません。一番初めのプロジェクトで出来る事ではなく、数多くのプロジェクトにおける事例を検討し、それらのデザインを抽象化せねばならないのです。
　オブジェクト指向プログラミングで再利用できるオブジェクトは、設計で得たオブジェクトを具象化したものです。一言でいえばイディオムです。この段階で得られる再利用できるオブジェクトは、プログラミング言語が特定される抽象度が低いパターンと言えます。この段階で得られるオブジェクトは抽象度が低く一番再利用しにくいものであり、オブジェクト指向は再利用できないという人の大半はこの部分だけを指しています。
　長くなりましたので纏めに入ります。オブジェクト指向を実践したからと言って、ただで再利用できるオブジェクトは入手出来ません。オブジェクト指向は複数の段階があり、各段階におけるオブジェクトを正しく認識し、複数の事例を抽象化して漸く再利用できるオブジェクトが得られます。各段階のオブジェクトは抽象度が違うものなので、得られた再利用できるオブジェクトは抽出したのと同じ段階でのみ再利用できます。さらに、明文化しないと再利用できません。再利用は簡単にできる万能な概念ではありません。初めから全てを再利用するは不可能なのです。
　しかしながら、明文化出来ない情報を技術者は再利用できます。人はこれを経験と呼びます。人間は高度な抽象化能力を持ち、脳に蓄えられた情報から高度な仕事をする事が可能です。ですから、本当に再利用できるオブジェクトは、技術者の技と知識そのものだと言えます。
　本当の意味で再利用が可能なのは技術者です。IT業界は意外とオブジェクトを再利用できない事が判明していますが、それは技術者を軽視した結果だと私は思えてなりません。「オブジェクト指向なんて言っているけど実際は再利用は出来ていない」と安易な一言で済ますのではなく、オブジェクトとは何か、再利用とは何かを深く考えなくてはなりません。