無差別に技術をついばむ鳥

この記事は、ネタつつき22−アクセス指向設計（AOD）の続編です。引き続き楽しく読んでいきましょう♪
前回の最後で次はアクセス指向プログラミングだと書きましたが、重要な事を書くのを忘れているのに気付きました。設計段階でプログラミング上重要となるのはオブジェクト設計です。今回はそのオブジェクト設計について書きます。無論、ネットワーク構築、データベース構築なども重要となってきますが、それは既存の方法となんら変りありません。アクセス指向設計が他のアプローチと違うところは、メタデータのアクセス性についても考える点です。オブジェクト設計時に一番多い間違いは、不適切なクラス定義から生じます。本来オブジェクト指向設計では実装言語を意識してはなりませんが、多くの人がついつい実装面を意識して継承するためだけに不適切なクラスの親子関係や、メソッドとクラスの関係を定義してしまいます。そういった誰しもあるような間違いを設計段階で防ぐために、アクセス指向設計ではメタデータのアクセス性に意識を集中させる事により、クラス設計に論理上の矛盾が無いかをチェックします。では実例を見るために、引き続きインドリの観察をしてみましょう。

ドリィちゃん「ねぇインドリ。オブジェクトデザインは終わった？」
インドリ「うん♪終わったピヨ♪えっとねぇ・・・うちの店は文房具も売っているから、メタデータの少ない文房具オブジェクトから本オブジェクトを継承して・・・」
ドリィちゃん「ちょっとまったぁぁ！論理的に考えて文房具の子オブジェクトが本オブジェクトと言うのはおかしいわぁ。それならば、商品抽象オブジェクトから文房具オブジェクトと本オブジェクトを継承させるべきよ。ちょっと想像してみて。本オブジェクトが文房具オブジェクトの子にした場合、本オブジェクトは文房具としてアクセスされる可能性がある事も意味するわ。それじゅあ変だよね♪」
インドリ「なるピヨ。本を清算した後、いつの間にか文房具になっていたら吃驚するもんね♪あれ？詳解Linuxカーネルを買ったのに、家に帰ってから見たら大学ノートに変っていたぞ！」
ドリィちゃん「・・・いや、本が文房具に変身することは無いと思うけどぉ・・・もしあったとしたらそれは詐欺被害だよね・・・例えとしてしてどうかな・・・まぁおかしい事を分かってもらえればそれでもいいわ。・・・あれ？何で本オブジェクトに買うメソッドがあるの？」
インドリ「その方がプログラミングしやすいと思ったピヨ。」
ドリィちゃん「それならば【買われるメソッド】ね。でもねぇ、本と言ったオブジェクトは再利用できるかもしれないから、プロジェクトに依存した動きをする受動態メソッドは止めておくべきよ。違うプロジェクトからこのオブジェクトをアクセスする時に、店で買われるメソッドとか、ネットで買われるメソッドとかあったら気持ち悪いじゃない。オブジェクトがどうアクセスされるのかを考えて柔軟性があるようにするべきよ。ライブラリの再配布問題もあるしね。」
インドリ「その通りだね♪わかったよ♪」

順調良く進んでいるようですね。先ほどドリィちゃんが指摘していましたが、なるべく広範囲のプロジェクトからアクセスできるようにオブジェクトを定義するのがアクセス指向設計の勘所です。オブジェクト指向をしているのにも関わらず再利用し難いオブジェクトを定義していませんか？オブジェクトは再利用できないと、ただ開発コストがUPするだけです。十分に注意しましょう。あと、保守性向上の為に論理的に正しい定義をする事に意識を集中させながらクラスのデザインを行いましょう。
その他にもアクセス指向設計ではアクセスするリソースとセキュリティ上のアクセス要件を決定します。こうする事により、並列的な実装とセキュアな実装が出来るようになります。これでアクセス指向設計の解説は終わりです。多分ね♪

トラックバックURL

FC2ブログユーザー専用トラックバックURLはこちら