スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

業務アプリケーションにはオブジェクト指向は向かない

前に述べたオブジェクト指向論の続きである。

まず私はアンチ・オブジェクト指向論者でもなく、オブジェクト指向信者でもない。何でもかんでも、オブジェクト指向で組めば生産性が上がるという記述にしばしば疑問を覚えるだけである。

世の解説書で、オブジェクト指向を論じるとき、対比されるのは、手続き型あるいは構造化プログラミング、およびデータ中心思考(DOA)だ。この際、どのようなアプリケーションを念頭に置いているかで全く意味は変わってくると思うのだが、それを意識している本はほとんどない。

データ中心の業務アプリでは、オブジェクト指向を徹底させることは不可能だと思う。オブジェクト指向が有効なのは、制御系・処理系かスタンドアロンのアプリケーションである。

もしメモリ中心のエンティティでオブジェクト指向を行った場合、以下の問題がある。
・大量のデータに対応できない(メモリを逼迫する。ディスクに退避する場合ディスクアクセスが発生する)
・検索およびそのためのインデックスを都度組む必要
・リンク先のオブジェクトも都度生成(遅延ロードなどのメカニズムが必要)
・排他制御、トランザクションのメカニズムを組み込む必要
など、DBMSで実装されている機能をすべて実装する必要がある。

もし、
1. マルチアクセス
2. データ中心

のどちらかであるならオブジェクト指向は使えるが、両方を満たす場合純粋なのは不可能。ORマッピングツールを使って擬似的に行うことになるか、データ中心指向で行くしかない。

メーラーなどのアプリケーションもデータ中心だが、大きな違いはスタンドアロンでメールデータにアクセスするのはシングルユーザという点だ。この場合、排他制御やトランザクションは不要になる。

昔読んだ情報処理試験の解説書では、データ中心指向からオブジェクト指向が現れたとなっているがこれは全くのうそだ。構造化プログラミングから発展して最初のオブジェクト指向言語Simulaが誕生した。DOAとは何の関係もない。

業務アプリケーションとは、会社の業務である、受発注、会計、在庫管理、人事、顧客管理などのシステムのことで、データ自体が重要な意味を持っている。このようなアプリケーションの場合、DBが比類なく重要であり、DB設計を見れば、どんなアプリケーションなのかあらかた見当がつく。

このアプリケーションに、OOAを適用するのは問題があるのだ。
OOAのメリットは、カプセル化、すなわちデータと処理が一体になっているところにある。ところが業務アプリケーションが対象とするデータ、エンティティは情報としての意味があるだけで処理は必要ないここが多くの人が勘違いしている点だ。

例えば顧客を表すクラスとして、Personクラスがあったとしよう。Personクラスに必要な処理とは何だろうか。人だから、歩く、食べる、考える、仕事する、などのメソッドが実装できるだろうか。意味はない。多くのオブジェクト指向の教科書が出すたとえが役立たないのはこの点だ。

Person単体では意味の持たせようがない。属性に対するsetter, getterがあるというかもしれないが、それはPersonに実装する機能ではない。もちろんsetterやgetterで整形したりできるメリットはあるが、publicの単純な実装であるなら構造体となんら変わりない。せいぜい誕生日属性から年齢を割り出すメソッドを実装することができるかもしれない。まあ、それも誕生日クラスを作ってやればいい。

では次にオブジェクト指向が活用される例として、例えば、Stringクラスを見てみよう。これはメンバーに文字列を持ち、その文字列に対して、検索や部分的な取り出し、比較などのメソッドが実装されている。まさにこれは適切なオブジェクト指向の実装だ。
また例えば、Calendarクラスを見てみると、これはメンバーに指定した日時が格納され、それに対してさまざまな処理ができる。ところが、Personクラスでは、その名前から想像されるような機能は何一つない。ある本では、従業員クラスがあって、業務を遂行するというメソッドを例として書いていた。これは全くナンセンスだ。

お分かりのように、業務アプリケーションでは、そのエンティティクラスに機能を実装する意味はほとんどない。構造体を少し便利にすることが可能、というぐらいのものだ。

もしPersonクラスらしい意味を持たせることができるとなると、ゲームアプリのようにそのPersonをゲームの中に登場させることだろう。そうすれば「人」らしい機能を実装できる。社長起立!もこれなら意味を持つ。

業務アプリのデータはそれ自体は現実を反映しているが、オブジェクトというほどには昇格できない。このようなエンティティのクラス図の作成には、正規化されたE-R図とほぼ同様になり、DOAで用いられるデータモデル手法がそのまま適用できる。

Personオブジェクトが集合になったとき、検索や統計の処理が必要になるだろうし、またデータベースに保存する必要が出てきたときにも何らかの処理が必要になる。しかし、それは単体のオブジェクトの中に実装することは勧められない。例えば検索の場合、Personの集合に対して行う処理なので、Personクラスの中で実装するのは不適切であり混乱を招く。そういう実装も可能だが、クラスが、そのクラスのインスタンスの集合を管理するという形になってしまう。EJBのエンティティBeanは、その点論理的に問題がある。インスタンスが一レコードを表すと同時に、検索やDBへの変更・削除を実装することになってしまう。そして結局、DTOやValueObjectを導入するという奇妙な結果になる。

デザインパターンなどの実践でも、エンティティ中心のクラスと処理中心のクラスは分離される。そうなると、エンティティクラスはほとんどオブジェクト指向のメリットは生かせず、よって教科書に出てくる現実のもののたとえは完全に破綻する。エンティティクラスは単なるデータであり、生き物にはなり得ない。
エンティティに処理を加える必要はない。もちろんオブジェクト指向バリバリの処理系でもエンティティクラスは出てくるが、しかし処理系ではエンティティクラスが中心ではないので別段そこに処理が実装されていなくてもよい。UMLの教科書ではわざわざ処理を加えるが、上記の理由から不適切である。

メールやワープロソフトもデータを扱うが、業務アプリケーションのデータとは意味が違う。メールやワープロではどんな内容が入るかは意味がないが、業務アプリケーションでは意味を持ってくる。メールやワープロでは文字を可視化したり処理したりすることに意味があるが、業務アプリではそういうことは関心の中心ではない。

DOAの人にとってドメインはDBそのものであり、エンティティクラスは作るとしても補助的なキャッシュ的な役割でしかない。OOAの人にとってはエンティティクラスがドメインの中心であり、DBは永続ストアで陰に隠れている。

関連記事
スポンサーサイト

trackback


この記事にトラックバックする(FC2ブログユーザー)

ORマッピング Cachタ

<BR> 少し前に、業務アプリケーションとオブジェクト指向の関係について述べた。業務アプリケーションにはオブジェクト指向が向かない理由として、1.エンティティクラスに機能は必要ない、2.メモリ中心で実装した場合困難がある、ということだったが、2番目の点について

コメント

非公開コメント

プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。