のんちゃん。あーい。
by tsuyodrive
S M T W T F S
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30


オブジェクト指向で考える。

3年前から本格的にオブジェクト指向の世界で仕事してきました。
私の仕事はCATIA V5のカスタマイズであり、基本的にVC++とCAAとCOMと呼ばれるコンポーネント技術(?)を使っての開発。
もうバリバリオブジェクト指向なのです。

ところが。

できあがった設計書や、ソースについてよーく考えてみました。確かに設計書ではクラス設計書、フィーチャ属性表、インターフェース仕様書などを作っています。ソースもコメントは//だし、オブジェクトをnewしたり、フィーチャからQueryInterfaceしたりしています。確かにオブジェクト指向が理解できないと書けない仕様書・ソースです。
しかし、これらがオブジェクト指向を使って開発しているものとはもはや言い難い。そう思えるようになってしまいました。
いや、言い方が悪いのかもしれません。
オブジェクト指向における技術は読めるし、理解できる。しかし、徹底的に活用しているかというと、必ずしもそうではないのです。
端的な例で言うと、一番初めに6つのコマンド(機能)ができて、それらを元にさらに次のリリース、リリースと行くに従いコマンド数が増えていきました。
あるとき、CATIAのバージョンUPに伴いいくつか新しい付加機能を追加する必要があり、操作性の一貫性を保つためそれらを開発したコマンド全てに追加しました。
またあるとき、内部ライブラリを一新するため、それまでのGUIは踏襲しながら新しい機能へ挿げ替えを行ったため、同じ顔つきながら別のコマンドが増えていきました。
コマンドの数は新旧合わせると約70個、その7割は似て非なるコードのコピーで作られています。
理由は「同じような機能を開発するから」ただそれだけ。

オブジェクト指向を理解できる人たちが携わって、なぜ似て非なるコードが大量生産されてしまっているのでしょうか?これは非常に大問題です。
なぜなら、これから新しい追加機能を付加することが不可欠となったとき、全てのコマンドに対して(少なくとも新しいコマンドに対して)、まったく同じコードをそれぞれにコピーして、それぞれの単体テストを行い、結合テストを行う必要がでてきます。もしくは、共通の機能に不具合があり早急に修正が必要とされる場合、似て非なるコードをコピーしているため全てのコマンドに対して(少なくとも新しいコマンドに対して)、同じ修正を加える必要が出てきてしまうのです。

オブジェクト指向って、何でしたっけ。
継承って、どういうときに使うのでしょうか。
この問題は実はずーっと見てみぬフリをしてきましたが、開発が先細りになるにつれ人が減ってきたのに、くだらないメンテナンス工事に無駄な工数を使い、通常の開発を圧迫するようになってきているのは判っていました。
よくよく考えたら、種をまいているのは自分たちではないですか。

結局、新しい(オブジェクト指向は決して新しい技術ではないですが)ものを理解しても、それまでの慣習や、あまり面倒を抱え込みたくないという意識から、目先に簡単に移るやり方へと流れてしまう傾向があるようです。本来、このような構造プログラミングからオブジェクト指向プログラミングへの移行は大きなパラダイムシフトを伴うものですが、
開発する人が何が変わったかを本質的に捉え、どう生かさなければいけないのかをじっくり考えてから取り組まないと、結局何も変わらないということなのでしょう。

このような問題を解く鍵は、「オブジェクト指向を使うと何がうれしいのか?」を良く考えることです。また、日頃抱えている問題や課題をどう解決するべきか?それを良く考えることです。
今この二つをつき合わせて思いつくのは次のような事柄です。
『オブジェクト指向の特に「継承」を上手に利用すると、少ないコードで、属性をちょっと変えるだけで多くのインスタンスを作り出すことができる。これはすなわち、共通のGUIや機能を持っているコマンド群には全て適用できる話である。コード量が減ればその後のテスト、工事、改善、不具合対応のすべてにおいて費用削減が可能となるはずである。』

長い文章ですみません。
しかし、今後自分のやるべきことが何かはっきりとしてきました。
オブジェクト指向をもっともっと徹底活用することで開発費用を下げ、生産性を向上させ生産余剰能力を増やし、他社に真似のできない開発プロセスを開発すること。です。
[PR]
by tsuyodrive | 2004-11-30 03:16 | 仕事
<< VBA楽しいな? 土日。 >>