関連オブジェクト

• どうでもいいのかも(よくないのかも)知れないが、そいつは永続オブジェクトつーかオブジェクトデータベースなシステムである。
• Rootクラスが有る。所謂頂点クラス。Objectクラスみたいなもんだ。
• Rootクラスには、IDという属性が有る。データベース上で自分を一意に特定するための値。実体は数字か文字列みたいなもの。意味的には(データベース空間という仮想ヒープ上の)ポインタや参照(に指される対象)みたいなもの。コレを合札としてシステムに問い合わす(いわゆる検索)ことでselfが実メモリ上にロードされる。
• オブジェクトは普通は、他のオブジェクトへの参照となる属性を持たない。つまり他のオブジェクトを参照するために普通の手段を使わない。
  • これはべつに原理的に必須な要請じゃないと思うのだが、とりあえず某(の中の常識)ではそうしている。実際そう制約されても困らないし。
• Rootの子に、関連クラス じゃない(普通の)クラスとして、Itemというクラスが定義されてる。普通のクラスはこれの子孫として作る。
• Rootの子に、関連クラス として、Relというクラスが定義されてる。系の中の関連クラスはこれの子孫として作る。
  • Relには、上記の禁を破る(笑)属性として、"右"と"左"という属性が有る。これが他のItemを参照する(正確にはRootだが、Relを参照するのは稀なので説明を略する)ための、事実上唯一(唯二？)の属性である。
• インスタンスたちを「繋げ」たいときは、

  anItemL <-(左)- aRel -(右)-> anItemR

  という参照をさせる。(矢印は到達可能性)
• Relの右や左は、単なる参照(つまりIDと同じ型)であり、配列などを保持して一対多関連を認識したりはしない。1つのRelインスタンスはあくまで左右2個のItemの間をしか繋がない。
  • 一対多や多対多をやりたいときは、「そのリンクの数だけ」Relのインスタンスを作れ、ということ。
• Relの左右の到達可能性が片側矢印(Item向き)になっている。つまりRelに「繋げられ」てるItemは、繋げられてることを直接は知らない。
  • じゃあ関連を知りたいときにゃどうするか？ってーと、
    • (例えば自分の右側のItemを知りたいときは) anItemL.ID==aRel.左 なaRelをシステムから検索して得て(何個が得られるかは事前には不明)、更に得られたaRel個々についてaRel.右==anItemR.ID なanItemRを検索して得る(個数はaRel1個に対し必ず1個のはず)、という手順を(API内部では)踏んでる。
  • デメリット：手順がややこしい。遅いし、普通の言語の参照のセマンティックスに合わない(!)のでコーディングが煩雑。
  • メリット：関連のことは関連に任せてしまえる。Itemが影響されない。例えば関連「の」仕様が変更になってもItemは修正しなくて済む(かも知れない)。柔軟性は高い。
• Relインスタンスは、左右両方のItemが存在する間だけ、存在できる。
  • Relは、左右(どちらか一方にせよ)のitemの乗り換えは許されていない。
  • 左右どちらかのItemが削除されると、間のRelは必ず自動的に削除される。
  • 子孫クラスのカスタマイズ次第では、逆(?)も出来る。間にそのRelが有る限りItemの削除要求を拒絶する、という制約を実現できる。
• Relクラス(とその子孫クラス各々)は、自分の左右にどのItemクラスを「繋いで」も良いか？を知っている。

このページを編集 (3052 bytes)

以下の 2 ページから参照されています。

• オブジェクト指向デザインのキーワード　最終更新: 2003-12-31, 11:40:17 <61-27-2>
• 関連クラス　最終更新: 2003-11-15, 16:59:41 <airh128>

This page has been visited 3204 times.