【日本一の】生成パターンのスレ【OOコンサル】

IoCやDIの本質が「生成パターン」だと思い込んでる人の議論を隔離するスレ

【本ｽﾚ】
　【GoF】デザインパターン5
　http://pc8.2ch.net/test/read.cgi/tech/1119158274/552
　http://pc8.2ch.net/test/read.cgi/tech/1119158274/560

552 名前： デフォルトの名無しさん [sage] 投稿日： 2005/07/18(月) 00:32:41

Eclipseプラグイン開発を読んでて思いついたんだが、ホストプラグイン(エクステンション
プラグインに提供する拡張点を持ったプラグイン)を書くのは将来の拡張可能性を考慮し
て予め拡張点を仕込まなければならず、これは(設計が)相当難しい。
これはEclipseのホストプラグインに限らず、拡張可能なフレームワークを書く時に出てく
る一般的な悩みなんじゃないかな？

そこで、FlyweightパターンにAOPを組み合わせる。
これはSeasar2(S2Container＋JBossAOPの方が拡張する側は書き易い気が･･･)を使っ
て実現できる。
そうすると、意図して拡張点を設計するよりは遥かに容易く拡張できる(点として設計する
必要がないというだけで、クラスが強く閉じてると拡張できないし、開きすぎてると意図し
ない影響を受けて動作が阻害されるから、考慮は必要)。

問題は、どこからでもインスタンスを取得できる(複数のクラスで共有される)事でスコー
プの範囲が限定できなくなる(しかし、限定されると拡張できない)点。
今はただの思いつきだけど、掘ってみると何か出てきそうな予感なんだけど、どうよ？

554 名前： デフォルトの名無しさん [sage] 投稿日： 2005/07/18(月) 00:40:48

>> http://pc8.2ch.net/test/read.cgi/tech/1119158274/552
そこでFlyweightが出てくる理由がまるで説明できていない。失格

560 名前： デフォルトの名無しさん [sage] 投稿日： 2005/07/18(月) 01:02:56

>> http://pc8.2ch.net/test/read.cgi/tech/1119158274/554
ありゃま、失礼。て言うか、最初の草稿時には書いてた気がするんだけど･･････
行が伸びたんで削った時に、その部分が含まれちゃったみたいorz

AOPを仕込むにはインスタンスが必要なんだよ。
例えば、あるクラス内でnewによって生成されたインスタンスがあるとする。
このインスタンスにAOPを仕込むには、なんとかして外部からそのインスタンス
を取得する必要がある。
生成をFlyweightパターンに一任すると、何処からでもインスタンスを取得でき
るから、自由にAOPを仕込める。

564 名前： 552 [sage] 投稿日： 2005/07/18(月) 01:14:23

>> http://pc8.2ch.net/test/read.cgi/tech/1119158274/558
そのレスって俺宛？意味不明の言葉って＿|￣|○|||

規模の大小を問わずフレームワークを考える場合に、拡張性を考えれば
考えるほどゴールからは遠くなるという悩みどこに対する解法として一石
を投じたつもりだったんだけど･･････

>> http://pc8.2ch.net/test/read.cgi/tech/1119158274/561
投稿前にリロードしてみて良かった。なるほど、そういう前提なわけね。
板とスレという単位でしか枝を持てない２ちゃん型掲示板ではそういうルー
ルなの？
MLなんかだと複数スレッド同時進行は当たり前なんで、俺的にはそういう
ノリだったんだけど･･････そういうルールがあるなら暫く黙っとく事にするよ。

Flyweightパターンが、どのような文脈で発見されたのか、GoF本第二章 ET++のDOCアプリケーションの章を確かめてみろ。
たぶん貴方のお気に入りの章なんだろ？

FlyweightパターンはGamma他が、ET++というXwindow上のMacAppクローン・フレームワークを作り、
その上でDocという名前のワードパッドのような最低限のワープロを実装した前後に出てきたパターンだ。
その目的は、文字のような極めて小粒度のオブジェクトを、OOP本来のオブジェクトとして扱いたい、
しかしオブジェクト生成やメモリー消費のオーバーヘッドは絶対に避けたい、
という問題に対する解答として出現した。

上記のパターン文脈を離れ、同様な場面はいろいろあると思う。
しかし、まるきり噛みあわない文脈で、Flyweightの名前を挙げても、
意思疎通は難しい。

むしろ、貴方が想定している環境におけるFlyweightの定義を一から説明し、
何故それにGoFのFlyweightパターンと同じ名前をつけるのか、説明すべきだろう。

なに？説明が面倒だって？学生だったGammaだって、その面倒な作業をしたんだ、
貴方にできないはずがないだろ（笑顔

>>6
回答期待しても無理無理。
荒らしだろどうせ

まぁ今更AOPとか言い出しても、
その分野俺は数年前からなんとかビジネスに結び付けようと四苦八苦してきたし、
そしてそのビジネス化ももう一昨年〜昨年始めに決着ついちまったんだ。(JBOSS AOP〜IBMのAOP注力宣言)
挙句に昨年はSeasar2 AOPが出たり、Spring Frameworkが普及し始めたり、いろいろ固まりつつある。

いまさら遅れてきてウマい飯にありつこうとしても、無理じゃないかな。

>>6
Flyweightという名称を使ったのは、こういう仕掛け(class Factory {})を一言で
伝達する事が可能だと思ったからだけど、それは間違いでした。
それは認めます。ごめんなさい。

class Factory {
　private static Factory singleton = new Factory();
　private Factory() {}
　private Map map = new HashMap();
　public Factory getInstance() { return singleton; }
　public Object getTarget(String target) {
　　Object obj = map.get(target);
　　if (obj == null) {
　　　obj = (Object)(Class.forName(target).newInstance());
　　　map.put(target, obj);
　　}
　　return obj;
　}
}

それから、俺はあっちのスレには初出とレス番晒した書き込み以外はしてない。
ID制導入して過去レス分も含めて晒してほしいくらいだ。

ええぇーと。
フレームワークやアーキテクチャの中身を見たこと無い人がよくやる
「屋上屋を重ねる」パターンだな。
J2EEだったら、JNDI経由でリファレンスとっておしまいの話だろう。
それを貴方が再インプリすることで、何かメリットあるの？

その他の応用例として、DB上に格納された変化し得る定数テーブルの分散参照ってのがある。
(例えば組織名称、役職名称等、変わり得る定数を、分散環境/クラスターのあちこちから参照する仕組み)

つかさぁ、こんなコード10年も昔に、最初のWebアプリ・パッケージ作った時から書きまくってるけど。

>>10
いみふめ。

とにかく他人の議論の妨害はやめておけ。
マナーを守らない人間は、仕事もそのレベルなんだろうと想像できるので、
相手するのがバカらしくなる。

>9
それって、(Modern C++ Designの)ファクトリとsingletonを組み合わせた
だけのような……

俺は10年近く前にパッケージ開発企画して
Java Mail API〜JAF APIを独自実装をした時に、
その手のコード書きまくったけどね。
典型的にはMailプロトコル(SMTP/POP3, IMAP4)やMIMEタイプ(text/plain, etc)を「表す」定数の管理。
定数の動的追加が必要じゃなけりゃ、static constかenumで充分なんだろうけど、
Java MailやJAFは、プロトコル・プロバイダー・クラスや、MIMEハンドラー・クラスを動的に追加できる構造なんでね。

プロトコル表す定数も動的に変更可能なように、APIの拡張設計をした。
ちなみに定数はシングルトンで充分なので>>9のパターンになるが、
プロトコル・プロバイダーやMIMEハンドラーは必要に応じてインスタンスを作成するファクトリー・パターンになる。

・・・つまり。DIだIoCだって話題、俺は10年前からやってるし、Java周辺で頑張ってる連中には当たり前の話題だって事。