eclipseです。

Wさん、大変丁寧な説明ありがとうございます。
私の認識は大体合っていたようです。

前回のメールで「パターンの定義部分」という表現をしたのですが、
どうも言葉の定義だと思われてしまったみたいです。
これはコードのことを指していました。
曖昧な言い方をしてすみません。
つまり、
define Aggregate(P,A,B) = {...}
のようなコードです。
この{...}の部分はどんな感じで記述するのかなぁと、
それが一番興味があるところです。
それともパターンはユーザ定義不可能で、
システム組み込みなのでしょうか。
それだとちょっと面白みに欠けるかなと思います。

----- Original Message ----- 
From: "Fumisky Wells" <ttn3w7u2fs mx6.ttcn.ne.jp>
To: <langsmith quickml.atdot.net>
Sent: Tuesday, August 24, 2004 10:38 PM
Subject: [langsmith:102] Re: パターン支援言語？ ご意見拝聴


> W です。長文失礼します。
>
> eclipse wrote:
>
> >eclipseです。
> >
> >クラス間の関係を張ると具体的にどうなるのですか？
> >Aggregateの例では単にクラスに参照の配列が追加されるだけ(*1)
> >だと私は思ったのですが、そのようにマクロやテンプレートなどで
> >今のオブジェクト指向言語に変換できるものでしょうか。
> >それともクラス間の関係という概念は全く新しいものになるのでしょうか。
>
> eclipseさんの想像された通り、前者です。Aggregateぐらいだと、単にポインタ
> が埋めこまれるだけです。以下に具体例を書きますが、まずは前提条件です：
>
> - 共著関係 (Book : Author = 1:n)は話がややこしくなるのでここでは省略しま
す。
> - 改めて Aggregate 文を以下のように定義させてください：
>
> Aggregate P, A, B
>
> 1* クラス A, B に１対多関係を定義する
> (これまでどおりです）
> 2* B は所属する A を知っている(Aへのポインタを持つ）
> (単純なケースでは STLなどでもすぐ実現できるので話を面白くするため、
> 　　　追加させてください)
> 3* この関係を P と名付ける
> (前回までは話しを簡単にしようと思い略していましたが、どうもそういうわけに
も
> いかなさそうなので、ここで改めて正式な定義文を書くことにしました）
>
> - 話を簡単にするため、Aggregate のメソッドは add(), parent() だけとしま
す。
> - クラス定義中 /* X */ は、各クラス固有の属性を意味します。例えば、出版
> 社名、
> 本のタイトル、値段、著者名など
> - リンクドリストによる実装を書きます。
> もちろん、eclipseさんの例のように参照(やポインタ）の配列でも実現できます。
> - 見通しよくするため、friend 宣言や public/protected は略しました。
>
>
> /*------------------------------------------------------------------
> (1) パターンライブラリによる定義
> ------------------------------------------------------------------*/
> class Publisher {/* X */};
> class Book {/* X */};
> class Author {/* X */};
> Aggregate books, Publisher, Book; /* 出版リスト */
> Aggregate authoring, Author, Book; /* 著作本リスト */
> Aggregate dedicated_authors, Publisher, Author; /* 専属契約 */
>
>
> /*------------------------------------------------------------------
> (1') 上の定義式は以下の C++ に展開されます
> ------------------------------------------------------------------*/
> class Publisher {
> Book *books_first;
> Author *dedicated_authors_first;
> /* X */
> };
> class Book {
> Book *books_next;
> Publisher *books_parent;
> Book *authoring_next;
> Author *authoring_parent;
> /* X */
> };
> class Author {
> Book *authoring_first;
> Author *dedicated_authors_next;
> Publisher *dedicated_authors_parent;
> /* X */
> };
>
> /* Pattern クラス。GoF MEDIATOR に相当 */
> class books_class {
> void add(Publisher *, Book *); /* 実装略 */
> Publisher *parent(Book *b){ return b->books_parent; }
> };
> class authoring_class {
> void add(Author *, Book *); /* 実装略 */
> Author *parent(Book *b){ return b->authoring_parent; }
> };
> class dedicated_authors_class {
> void add(Publisher *, Author *); /* 実装略 */
> Publisher *parent(Author *a){ return a->dedicated_authors_parent; }
> };
> /*
> 後、books, authoring, dedicated_authors それぞれに対応する
> iterator も生成されますが、略します。
> */
>
> /* Patternクラスはのインスタンスは大域で１つだけ生成 */
> books_class books;
> authoring_class authoring;
> dedicated_authors_class dedicated_authors;
>
>
> /*------------------------------------------------------------------
> 使用例
> ------------------------------------------------------------------*/
> Publisher p;
> Author a;
> Book b, b2, ...;
>
> /* 関係の初期化 */
> books.add(&p, &b);
> authoring.add(&a, &b);
> dedicated_authors.add(&p, &a);
> :
>
> /* 本の著者 */
> ... authoring.parent(&b) ...;
>
> /*
> ある本の著者が専属契約している出版社
> (専属契約してない場合、NULL が返るとか例外処理とかになりと思いますが、
> ここで議論はしません。)
> */
> ... dedicated_authors.parent(authoring.parent(&b)) ...;
>
> /* 出版社が専属契約している著者の全著作(擬似コード) */
> for Authors *pa in dedicated_authors_iterator(&p){
> for Book *pb in authoring_iterator(pa){
> print pb;
> }
> }
>
>
> /*------------------------------------------------------------------
> (2) STL の場合(詳しくないので、間違っていたらコメントお願いします)
> ------------------------------------------------------------------*/
> class Publisher {
> list<Book*> books;
> list<Author*> authors;
> /* X */
> };
> class Book {
> Publisher *parent_publisher;
> Author *parent_author;
> /* X */
> };
> class Author {
> list<Book*> books;
> Publisher *parent_publisher;
> /* X */
> };
>
>
> 私からのコメント
> ----------------
> - (1) と (2) を比較し、(2) で十分となれば、
> C++ + パターンライブラリや、パターン支援言語なども不要ですね（自爆）。
> (2) の目に見えるクラス間の相互参照依存をどう見るか、がポイントでしょうか。
>
> - パターンライブラリに有利な条件（親へのポインタ）を入れたので
> 公正な比較とは言えないかも知れません。
> ただ、親(自分の所属するコンテナ)へのポインタ、というのはよくあるケース
> でもあります。
> 親へのポインタがないケースを考えると、STL もかなりシンプルになります。
>
> - (1) -> (1') の展開方法として、Jiri 本の中では
> マクロ + 専用プリプロセッサを使う方法と多重継承 + テンプレート +
> 専用プリプロセッサを使う方法を紹介しています。
>
> - 私の経験上、パターンライブラリは３つ以上のクラスが相互に依存している
> 場合にありがたみがありました。
> ただ、普通のハッシュやコンテナ(Perl, Ruby, STL でも提供されてますね)で
> 十分なケースが多いとは思います。
>
> - クラスごとのユニットテストを考えると
> (2) や (1') と比較して (1) はとっつきやすいと思います。
> 上のは簡単な事例でしたが、各クラス固有の属性 /* X */ が膨大だったり
> クラス数が増え、クラス間の関係も増える場合を想定してみて下さい。
>
> - もともと Jiri のパターンライブラリは巨大プロジェクト(*)の中から生まれ
> てきたもの
> なので、「多数のクラスが相互に関係しているケース」でないと
> 有利性が見えてこないです。
> ある意味特殊ケースであり、その特殊用途を言語レベルで支援する、なんてのは
> かなり特殊用途向きとなってしまうのかな(弱気)。
>
> (*) Jiri の本によると Mentor Graphics 社の CAD システム開発
> プロジェクトの中から生まれたようです。
>
> // W
>
>
>
>
> --
> ML: langsmith quickml.atdot.net
> 使い方: http://www.atdot.net/~ko1/quickml
>


--
ML: langsmith quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml