top / index / prev / next / target / source

2005-05-09 diary: オブジェクト指向レス開発

いがぴょんの日記 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

オブジェクト指向レス開発

改めて言うまでも無いことのはずなのですが、オブジェクト指向の乱用は原則として有害です。特に業務システムにおいては、オブジェクト指向は主題・メインディッシュにはならないはずです。当然、業務そのものが主題です。そうであるのに…

オブジェクト指向レス開発という選択肢

私は昔から (少なくとも前世紀から) 「オブジェクト指向技術の適切な使用」について考えたり考えさせられたりすることが多かったです。そして最近はそれらが より明確に「オブジェクト指向レス開発」という考えにまとまってきました。このイメージが有意識にとどまっているうちにメモしておきます。

昔から (多くの場合 前の世紀から) オブジェクト指向にたずさわっている人々の多くにとっては、オブジェクト指向というのはオブジェクト指向言語のことを指していたのではないかと考えます。(実際の道具としてオブジェクト指向言語と向き合ったものです)構造化プログラミング言語では表現できない局面にオブジェクト指向が適用できたときには、これはとても便利なものだと実感したものです。構造化プログラミング言語では表現しづらくて困っていたものがオブジェクト指向によって明快に解決できるのは、これはとても衝撃的でした。私は C++言語で初めてオブジェクト指向言語に触れたのですが、C言語ではなかなか表現しづらいものが、C++言語では とても明快に表現できたものです。C言語における達人の技が、オブジェクト指向言語によってより実装を行いやすくなったような印象もあります。ただし C++言語の場合には メモリの確保・解放タイミングのハンドリングの都合があり、リスト型にオブジェクト指向を導入するのには問題がありました。

私にとってのオブジェクト指向言語の転換ポイントは Java言語との出会いでした。Java言語は メモリ管理を JavaVMが内包していたので、リストなどにおけるオブジェクト指向採用が本格的に利用できるようになりました。オブジェクト指向が適用できる範囲が広がったのはとてもうれしかったです。しかもJava言語のAPIそのものが 単なるオブジェクト指向になっているのにとどまらず デザインパターンが適用されているのも印象的でした。最初にそれに気がついたのはファクトリパターンだったでしょうか。ああ、なるほど、これは便利だな、と感心しました。

そのような経験の中で、私は基本的にはオブジェクト指向やデザインパターンは便利なものであって様々な問題を解決してくれる有益なものであると認識しています。優れた技術者のオブジェクト指向やデザインパターン適用については、ほんとうに感心させられることが多いです。最近いちばん感動したのは、Eclipseプラグインにおけるデザインパターンの適用事例です。Eclipseプラグインのような部位においてはデザインパターンは非常に効果的に役立ちます。

ところが困ったことに 最近オブジェクト指向やデザインパターンを乱用した「良くない設計」や「良くない実装」を多く見かけるのです。私は業務システムの世界で働いています。業務システムにおいてはフレームワーク部のようなミドルウェア的な部位を除き デザインパターンなんてほとんど登場しないはずです。それどころかオブジェクト指向ですら、そもそもクラスの導出の場面すら無いです。多くの業務はクラス導出できるほど単純ではありません。規模や携わる人数とも関係があると思いますが、経験的に 規模が大きければ大きいほど、仕様変更が入りやすくなればなるほど、デザインパターンやオブジェクト指向は導入しづらくなります。(あまり経験のない人は、規模が大きくなればなるほど、仕様変更が入りやすくなればなるほど、オブジェクト指向が効果が出るものと誤解している向きがあります)「説明を受ける、あるいは資料を読まないと読解できないソースコード」、「現実的な試験工程と乖離した試験単位」などがあればあるほど、キケンな傾向にあると判断できます。もっともキケンな設計・実装には、「継承」や「実装」が必要な箇所において適切に利用されず、代わりにデザインパターンが嫌というほど盛り込まれています。デザインパターンの技のデパートのようなプロジェクトはキケンがいっぱいなのです。

「良くない設計」や「良くない実装」をしてしまわないための一番の近道は、「構造化分析手法」の適用だと考えています。基本的に規模が大きければ大きいほど、携わる人間が多ければ多いほど、そして仕様変更が入る確率が高ければ高いほど、構造化分析および構造化プログラミングがなされていないと手詰まりになります。「失敗オブジェクト指向」にしてしまわない近道の一つは、「構造化」の導入であると私は確信しています。というか、そもそもオブジェクト指向においても「構造化」にまつわる概念は存在しているのですが、多くの文献や記事においては 「構造化手法」の側面は かなり薄っぺらくしか扱われていないように考えます。その実例として Java言語のパッケージ構造についての現実的な利用についての話題を ほとんど書籍や雑誌で見かけないことから現れています。(現実的な現場の多くでは適切に運用されているのですけれども…)

そして もう一つ重要なポイントなのですが、オブジェクト指向やデザインパターンのなかの多くの技は「構造化」という観点からは リレーショナルデータベースにおける「逆正規化」に相当しているのだという点です。残念なことに、多くの人に、この点もあまり理解されていません。オブジェクト指向は ほんとうに注意深く導入しない限り、プログラムの理解を妨げ、試験をしづらくし、生産性を下げ、保守性を下げます。オブジェクト指向は間違いなく「逆正規化」に相当します。そもそもオブジェクト指向やデザインパターン適用について、これらが生産性や保守性に与える効果についての統計的な情報にほとんど出会わないことについても、これは悲しい現実であると受け止めています。

ということで私の感覚上の重要度としては下記のようなバランスです。そして 規模が大きければ大きいほど、重要度の相関関係が指数的なものになり 構造化の重要度はますます向上します。

基本的に構造化手法で物事を考えるのです。構造化では解決できないものについて、オブジェクト指向を導入します。オブジェクト指向だけでは解決できないものについて、仕方がないのでデザインパターン適用を考えます。導入に際しては、それが多くの人に受け入れられる直感的で 理解しやすく、試験工程や保守工程、そして仕様変更にも適切に対応できるようになっているのか、常に注意を行うべきなのです。難しいことなのですけれどもね。

、、、ここのところ、「オブジェクト指向を利用しない／利用させないコンサルティング」という嘘のようなほんとうの業務に立て続けに携わったので、とくにそのように感じました。、、、世の中の書籍や雑誌ではオブジェクト指向やデザインパターンを利用できないと・理解できないと困るような感じで書いてあるのですが、現実的には むしろ「オブジェクト指向を利用させない」ことの方が重要で、そして難易度がとても高いのです。

この日記へのツッコミ

関連する日記

この日記について