Active Recordパターンを使用中の柔軟性の保持

作者 Sadek Drobi , 翻訳者 編集部 投稿日 2007年11月10日

セクション

設計/アーキテクチャ

トピック

Object Oriented Design ,

設計 ,

Architecture

タグ

ActiveRecord ,

Antipatterns

Rails、Hibernate、他のORMツールに使用されているActive Recordパターンはdatabase rowのオブジェクトへのマッピングを許容するデータ持続パターンである。しかしながらこの実用的なツールはBob Martin氏によると混乱の源であるそうだ(source)。”テーブルとクラス、コラムとフィールド間のA1:1応答”はテーブルとオブジェクトが似ているという予測 に基づいているのだが、一方実際はデータの周りにおいてプログラミングスタイル指向でOOPは実質的に反対の性質を持っているのである。

オブジェクトはデータを隠し、パブリックインターフェースはメソッドの周りに構築されているので、ビヘイビアを表示する。データストラクチャはデータを表示し、通常それらはビジネスルールを含んでいない。それゆえにオブジェクトデータストラクチャの免疫力と被攻撃性は異なっているのである。オブジェクトは新しいタイプに免疫がある。なぜならOOPにおいてアルゴリズムはそれらが扱っているような種類のオブジェクトに関する情報を所有していないからである。でも、それらは新しい機能に対する免疫はない。

古い例：shape.draw();は要点を突いている。呼び出し元はどの種類の形が描かれているか全く想像がつかないのである。実にもし私が新しい種類の 形を追加したらdraw()を呼び出すアルゴリズムは変更に気付かず、そして再構築、再テスト、もしくは再デプロイの必要がないのである。

[…] 

更に同様にもし私がシェープクラスに新たなメソッドを加えると全てのシェープの誘導体が修正されなければならない。

反対にデータストラクチャを使用するアルゴリズムは新しい機能に免疫があるが、新しいタイプの付加に対しては虚弱なのである。

次はデータストラクチャを使用するアルゴリズムを考えて欲しい。

switch(s.type) { 

  case SQUARE: Shape.drawSquare((Square)s); break; 

  case CIRCLE: Shape.drawCircle((Circle)s); break; 

} 

[…]

もし私がShape.erasexxx()のようなあらたな機能一式を追加したら何が起こるか考えてみてほしい。存在しているコードに影響はない。実に再コンパイル、再テスト、再デプロイする必要がないのである。

[…] 

同じようにもし私が新しい種類のシェープを追加したら、全てのアルゴリズムを見つけてそれに対応するスウィッチステートメントに新たなシェープを追加しなければならない。

Bob Martin氏はActive Recordパターンを使用することによってこの”関連性データベースとオブジェクト指向の言語間の障害ミスマッチ”に混乱を引き起こすという。また彼 は”Active Recordはオブジェクトのように見える”が、実のところそれは”データストラクチャのように使用されるべきである”と論じている。Active Recordクラスが良くビジネスルールメソッドを含んでいるので、ビヘイビアを表示するのは事実である。しかしながらActive Recordは”ほとんど全てのActive Record誘導体がaccessorとmutatorを通してデーターベースコラムをエクスポートするので”データの非表示を許容しない。

”問題はActive Recordsがデータストラクチャであるということである。それにビジネスルールを入れても本物のオブジェクトにはならないのである。最後には Active Recordsを採用しているアルゴリズムはスキーマにおける変化、タイプにおける変化に対して虚弱なのである。

[…] 

だからActive Recordの周囲で構築されたアプリケーションは、データストラクチャの周りで構築されたアプリケーションなのである。そしてデータストラクチャの周りで構築されたアプリケーションは、手続き型なのでありオブジェクト指向ではないのである。Active Recordの周りで自分達のアプリケーションを構築する際に逃すチャンスはオブジェクト指向のデザインを使用するチャンスなのである。”

これはActive Recordsが使用されるべきではないという事ではない。Bob Martin氏は”良いデザインはどのようにして異なるスタイルの異なる被攻撃性と免疫をミックスしてマッチするかにかかっているのである。”しかしながら、彼はそれを”アプリケーションの規則を構成する”ために使用するべきではないことを擁護している。彼の意見ではそれはむしろ”データベーステーブルをアプリケーションから分離させる層の中”に帰属させるべきあるということだ。そしてデータベーステーブルの困難なデータストラクチャとアプリケーションオブジェ クト間で”優良なトランスポートメカニズム”の役割を果たすべきであると彼は述べている。これで”ビヘイビアを表示しデータを隠すオブジェクトに方向付けられた"アプリケーションはオープン・クローズドの原則(PDF・英語)に基づいてデザインされており、新たな種類を付加することにより新たな機能の付加に対して柔軟さを保つ のである。

原文はこちらです：http://www.infoq.com/news/2007/11/oop-vs-active-record

• 次へ >