123コメント42KB

■２CHデザパタ■

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

NGNG

安いのでいいからGoF（知らねーよ）とやらに書いてないデザパタを
１０００まで書くスレ。

0002デフォルトの名無しさん

NGNG

空ルーチンパターン。（盗作）
引数と返り値だけ実装して中身空なのを作る。
そういうのを大量に作って設計しながら最後に実装。

0003デフォルトの名無しさん

NGNG

捨てプレゼンパターン
プレゼンテーション用に小規模のを作る。
前金が入ったら経験を生かして作りなおす。

0004デフォルトの名無しさん

NGNG

>>1

「2CHPLoP」で立て直したほうがいいと思われ。

0005デフォルトの名無しさん

NGNG

そこらのツールパターン。
特殊なデータ使うプログラムの為に専用ツールを作成せず、
テキストエディタとか既存のツールが吐き出すデータに
合わせたプログラムを作る。

0006デフォルトの名無しさん

NGNG

コピーペーストパターン
既存の動作保証のとれたソースをそのまま流用する。
テストの手間を大幅に削減できる。下手な改造は禁物。

0007デフォルトの名無しさん

NGNG

>>4 PLOP?
それも知らんなあ・・・。

0008デフォルトの名無しさん

NGNG

ゲームパターン。
ゲーム風マン・マシンインターフェース。
（派生パターン一杯あり）

0009デフォルトの名無しさん

NGNG

バッチパターン
GUIの裏で実はバッチファイルが動いてるだけ

0010デフォルトの名無しさん

NGNG

偽EXEパターン
EXEファイルを実行するが実はVMで動いている。

0011デフォルトの名無しさん

NGNG

エラー処理レスパターン
エラー処理をいっさいしない。

00122chスレ-厨房-煽りパターン (2CA)

NGNG

スレと無関係な厨房を煽りで関連付けるパターン。

0013デフォルトの名無しさん

NGNG

単発質問パターン
わからないことはスレ立てて聞く。

0014デフォルトの名無しさん

NGNG

>>7

PLoPとは新しいパターン(デザインパターンに限ったものではない。)
を生み出すためのコミュニティ。
例.JPLoP(Japan Pattern Language of Programming)

0015デフォルトの名無しさん

NGNG

コミュニティパターン
まともな成果が出た試しがない

0016デフォルトの名無しさん

NGNG

御用聞きパターン。
別スレッドで動いてる処理プログラムが各プログラムの注文を
巡回して聞いて周る。

0017デフォルトの名無しさん

NGNG

ところでGoFって何の略？
GoF本自体は知ってるけど…
（「オブジェクト指向（略）デザインパターン」って本ですよね？）

0018デフォルトの名無しさん

NGNG

Gang of Four

0019デフォルトの名無しさん

NGNG

デザインパターンの収集／編纂をした、Eric Gamma 他、４名のC++厨房を、四人組(Gang of Four)と呼んだのが起源。

0020デフォルトの名無しさん

NGNG

がんまはSmalltalkの大家だろうが。ヴォケ。>>19

0021デフォルトの名無しさん

NGNG

「実績無し珍パターン発明」パターン
「よーし、デザインパターン１０００個集めちゃうぞ」とか逝って、
使用実績も普遍性も洗練もない珍パターンを発明してしまう。
JPLoPや、企業内のパターン収集で、よく見受けられる。

♯無理せず気長にいきませう。

0022デフォルトの名無しさん

NGNG

>>20
・デザインパターン本のサンプルコードはC++
・InterViewやET++から題材をとっている

0023デフォルトの名無しさん

NGNG

名前：NullResponseパターン
概要：内容を伴う必要がないが、掲示板の特性を生かした操作をしたい時
適用可能性：
　簡易にageたり、sageたりしたい場合
　スレッドのカウントを増やしたい場合
　ネタを殺したい場合
結果：
　簡易にすばやく使用できる
　掲示板によっては、内容のない返答を書きこみできない場合がある
　目的が曖昧になる可能性がある
関連するパターン：
　MailResponseパターン：
　　メール欄に書きこむことで、間接的に意図を伝えるパターンだが、
　　今回のパターンで用いられるsageは、内容より操作を促すので、
　　使用される文脈に違いがある。
　　ただし、ageの場合の付加的な内容追加には効果がある。

002423の実装

NGNG

0025デフォルトの名無しさん

NGNG

クロスキャストと Capsule パターン
ttp://member.nifty.ne.jp/masarl/article/nifty-logs.rsrc/capsule.html

0026デフォルトの名無しさん

NGNG

厨パターン

とりあえずVB/HSP/Ruby/Uvaを叩いて溜飲を下げる、その場
しのぎの為の常套手段。

0027デフォルトの名無しさん

NGNG

>>22
おいおい、ほんとに読んだのか？

0028デフォルトの名無しさん

NGNG

「パターンハッチング」とか読むと、GoF各人のスタンスが見えて面白いかも。

http://www.amazon.co.jp/exec/obidos/ASIN/4894711486/qid%3D1004941021/sr%3D1-2/ref%3Dsr%5F1%5F0%5F2/250-4312002-7861838

0029デフォルトの名無しさん

NGNG

Never ending method

◎目的
クラスにオペレーションが一つであることを保証し、かつインスタンスの
内部状態によって振る舞いが変化する。

◎別名
Dependence

◎動機
出来の悪い上司に睨まれ会社を追い出されそうなとき、複数かななる
オペレーションで重要かつ複雑なものを一つにまとめて保守性を向上
させる。

◎適用可能性
次のような場合Never ending methodパターンを使用する。
・出来の悪い上司に睨まれ会社を追い出されそうなとき。
・憎たらしい後輩が、そのソースコードを引き継ぐ場合。
・ごちゃごちゃとたくさんあるメソッドを一つにまとめたい。

◎結果
・会社に戻ってきて欲しいというメールがくるかもしれない。
・今すぐ会社を出て行けというメールがくるかもしれない。
・コードはある意味保守の必要は無くコストの削減につながる。

0030デフォルトの名無しさん

NGNG

◎実装
Never ending methodパターンには、いくつかの実装方法がある。

1.オートマトンを用いた実装。
状態遷移テーブルをつくり、状態変数と入力よりオペレーション
ラベルへジャンプする。状態遷移テーブルはできるだけ大きいほう
が良く、状態変数も複数あるほうがよい。

保守性を高めるポイントとして状態遷移図のようなものを残さない
ことである。このようなドキュメントやコメントは二重管理となり
混乱を招くのでソースコードで一元管理すべきである。

2.if else の多重ネスト
再起的な構造をもたないメソッドの集まりなら、if else を使うこ
とで一つにまとめることができるかもしれない。メソッドをCのマク
ロのように展開するとよいだろう。

if elseの多重ネストを導入するなら、引継ぎ保守をするものはその
ソースコードの注意深く観察するようになり、見落としによる問題の
発生を未然に防ぐことができるだろう。

3.ワークバッファーの再利用
文字列を取得したり加工するのにバッファーを用いるが、これを再利
用しない手は無い。メソッドを一つにまとめることにより、これらの
バッファーをシェアすることが可能となる。

再利用のポイントとしてoffsetの使用があげられる。

gets(buf);
if (flag1)
gets(buf + 13);
if (!flag2)
gets(buf + 15)
else
gets(buf + 15);

このようにoffsetを用いることでバッファーの再利用が促進される。

◎使用例
わが社に出入りしていた派遣プログラマーがこのパターンを使用した[92]
提携会社のCOBOLプログラマがこのパターンを乱用した[95]

0031デフォルトの名無しさん

NGNG

>>24 OOPSLAに、三角帽かぶせられた四人組登場、という話なので、
(いい意味で)厨房みたいな演出だと言いたかったんですが。

でざぱた本は、Smalltalkで必須な定石・イディオムを、
他の言語ユーザ(C++,Java)に伝えるのに便利な本として、5～6年前から重宝してます。

なにか間違ってたら、具体的に指摘して下さい。

003229

NGNG

>>31は>>19=31が>>20へ文句言ってるって事か？

GoFを通して読むと基本はSmalltalkにありって感じがするが。。。
サンプルがC++だったのは当時厨房にそれが流行してたからだろ？

0033デフォルトの名無しさん

NGNG

age

0034デフォルトの名無しさん

NGNG

>>29
一見、読むのめんどくさい感じだけど、結構おもろかった。
辛口ですな。
『Refactoring To Patterns』って論文あるんだけど、そこで
GoF本のカタログ項目を拡張して、０～２個の「＊」で使用頻度を
表してる。「Never ending method」は星二つだ。

0035デフォルトの名無しさん

NGNG

>>31 >>32
デザインパターンの話が言語に還元されるのは意味不明なんだけど。
この言語ではダブルディスパッチできる/できないなんて点が特定の
パターンをコードに落とす際に有利に働いたりするというだけで、
Smalltalk/C++/Javaのどれかヘビーに依存してるなら誰も参照しないだろ
少なくともいわゆるオブジェクト指向をサポートしてる言語では
有用ですよーということをアピールしなきゃなんないのでSmalltalk
ではうまくできてC++ではできない、とか言われても作者は全然
嬉しくないだろう。単に実装者の無能が露呈するだけだ。

0036デフォルトの名無しさん

NGNG

シングルオブジェクトパターン

オブジェクト指向がよくわからないときに使用する。
アプリケーションに必要な機能を唯一のアプリケーションオブジェクト
で実現する。

類似）
Doc-View onlyパターン

0037質問スレじゃないけど

NGNG

ダブルディスパッチて何？

0038デフォルトの名無しさん

NGNG

>>37

相討ち

0039デフォルトの名無しさん

NGNG

エミュレーターパターン
機種間移植でソース量が多い場合、仕様書が無い場合など、
いっそターゲット機上で動く現行機のエミュレータ－を作ってしまった
方が速いかもしれません。

0040デフォルトの名無しさん

NGNG

エミュレータ－はなにも独立して動くフル仕様のものである
必要はありません。
アプリのソースと不可分で一体でしか動かないとかでもOK。

0041デフォルトの名無しさん

NGNG

専用機パターン
いろいろなアプリが動くコンピューターではなく、
そのアプリケーション専用のマシンにしてしまった方が
都合が良い場合もあります。
汎用機では常識ですけど、PC系では忘れている人がいるかもしれません。

0042デフォルトの名無しさん

NGNG

専用機パターン２
電源を入れると自動的にアプリが立ちあがって専用機としてしか
動かないようにします。

マシンの使い方を覚える必要が無く、
アプリケーションの使い方だけ覚えれば良いので
御客様の学習負担を軽減できます。

0043デフォルトの名無しさん

NGNG

ファミコンパターン

専用機パターンの派生で、複数のアプリケーション起動用の
ディスケットを作っておき、ラベルにアプリ名（日本語）を
大きく書いておきます。

フロッピーディスクドライブにディスケットを入れて電源を
入れるだけでそれぞれの専用機として立ちあがります。

0044デフォルトの名無しさん

NGNG

クライアント/サーバー一体パターン

非Ｃ／Ｓアプリの場合。
下手なＵＩアプリを時間をかけて作るより、ＩＥなどのブラウザと
サーバーを一つのマシンに入れて作ったほうが速い場合も
あります。

0045デフォルトの名無しさん

NGNG

Ｒｕｂｙ！

0046デフォルトの名無しさん

NGNG

テロ対策パタン

SHOW THE FLAG!

と言いたくなるくらい、要りもしないフラグを
多用しバグを引き起こすパタン

0047デフォルトの名無しさん

NGNG

ニセ板違いパターン

質問内容が理解できないけど、どうやら専門板のある分野の話しらしい
確かにプログラムの話しなんだけどよくわからんから、うざい。
という場合に適用する。

実装例
　板違い。Unix板へ逝け

派生パターン
ニセスレ違いパターン
ニセ板違いパターンをスレッド単位で適用したパターン

実装例
　スレ違い、MFCスレへ逝け

0048デフォルトの名無しさん

NGNG

言語もどきパターン

使いなれた言語風に書いてしまう。
例
ＣでＢＡＳＩＣ
Ｃで殆どインラインアセンブラ。

0049デフォルトの名無しさん

NGNG

ダウンロードパターン
クライアントマシンにはローダーだけ置いておいて、本体、設定ファイル
などはサーバーからＤＬする。

利点：
未完成のまま納品してもなんとかなる。
違法ユーザーを検出できる。

0050デフォルトの名無しさん

NGNG

「実行時クラス情報(RTCI)」ってトリッキーで面白いと思いました
dynamic_cast を使わずに(VC++5.0 とかはデフォルトでは使えないし)
わりと安全に基底クラスから派生クラスにキャストできるような仕組みなんだけど，
詳しくは MFC のソースを読むか，吉田弘一郎著「極めるVisualC++」を買うと
いうことで割愛（笑い

これってマクロみたいな仕組みのある言語じゃないと辛いっすねー。。。

0051デフォルトの名無しさん

NGNG

>>50
ん、誤爆？

MFC の CRuntimeClass クラスを使って実装してるやつね。シリアライズも出来て便
利なんだけど、MFC が CObject 単一継承を強制される要因でもある。なんつーか、
もう捨てたい。（リフレクションがある Java みたいな言語だと、もっと素直にかける
んだけど）

005250

NGNG

むはは，やっぱし誤爆に見えましたか (´ー`)
スレッドの雰囲気もアレだし，
ちょっとゴミっぽい書き込みもいいかなーと思ったんで。わらぃ。

VCL も TObject からの派生を強制されているし，
もしかしたら RAD の実現にはある程度の強制が必要なのは
大宇宙の真理の一つなのでは，と電波っぽいことを考えてみたりして。

あー，でも Java のことあんまし知らないんで
ヘタなこと考えると本当の電波になるかもわからんですね (´ｰ`)y- ｺﾏﾙ

結論としては，C++ なら素直に dynamic_cast 使えと。

0053デフォルトの名無しさん

NGNG

全部一箇所に多重継承パターン

全部グローバルとどこが違う？

0054デフォルトの名無しさん

NGNG

オートセーブ

ユーザーがデータ変えた時とか、定期的とかに自動的にセーブ。

0055デフォルトの名無しさん

NGNG

　ファミコンパターン　追加改良

ついでにレジューム機能追加。

0056デフォルトの名無しさん

NGNG

全部セーブパターン。

メモリ内容を全部セーブしてしまう。

利点：何も考えなくてもあらゆるセーブが可能。
欠点：ファイルがでかくなる。

0057デフォルトの名無しさん

NGNG

Ruby!!!!!!!!

0058デフォルトの名無しさん

NGNG

卒論ほぼ完了していたのだけど,パターンランゲージに触れてはどうかと教授に
進められたのですが,どう触れればよいのやらと,途方にくれております.
情けないことですが....

まず最初にパターンランゲージというのが良く分からないのでその後に繋がり
ません. 理解されている方,どうか教えてくらはい.　止めた方が良いぞという
後ろ向きのアドバイスも歓迎です.

結城さんの作られたパターンランゲージを読んでみても纏め方としてのよさ
はわかるのですが,なんでそこまで特殊なもの扱いされるのかわかりません.

それと,JPLoPにも一応入っているのだけど,そこでなされる会話がほとんど
わかりません. 観念的のようでいて,ただの知識自慢の話のようでいて,レベル
が高いというよりか排除的といいましょうか....
また,悲しいことに,過去ログ読んでみても,なんだかしったかぶりの変な人同士
がすれ違いを気にせずに一方的な話をしているだけに感じてしまうのですが,
僕の感覚はおかしいでしょうか....
英単語交じりの文章は,どうも読みにくいし,入り難い....
JPLoPの過去ログ読めば読むほど鬱になっていく...
もう時間がない...

0059デフォルトの名無しさん

NGNG

>僕の感覚はおかしいでしょうか....
正常です。
馴染んでしまうのが異常、実社会でコミュニケーション出来ないタイプ。

0060デフォルトの名無しさん

NGNG

>>28
この本、訳が最悪なんだよね・・・・。買い取ってもらおうかと本気で考えた本
の一つ。
長瀬氏が、監修された本は買わないことに決めた俺。
売名のために翻訳しているだけだから出すことに意味があるのかもしれませんが
ひどすぎると思います。今のポリシーで本を訳される限り、尊敬できないです。

0061デフォルトの名無しさん

NGNG

>>58
＞なんでそこまで特殊なもの扱いされるのかわかりません
デザパタ本の話？
特殊じゃなくて良く使われるからデザイン_パターン_なんだけど。

0062デフォルトの名無しさん

NGNG

>>60
OO関連の本を探してると長瀬氏の翻訳本に良く当たる。
この分野に翻訳ができる人が少ないのではないだろうか。

0063デフォルトの名無しさん

NGNG

＞　５９

俺も禿同。貴方は正常だよ。
友○氏と長○○氏の大人気ない喧嘩の後から
おかしな雰囲気がさらにおかしくなったね。
その時,こりゃだめだと思って速攻抜けたけど,最近はどうよ？
頭が良いと思っている人たちの喧嘩ほど見ていて恥ずかしいものはないね。（藁

週休二日のはずが,ここ半年月休二日だ。鬱だ。

0064デフォルトの名無しさん

NGNG

>>62
今野氏の本も多いけどこれも訳にばらつきがある。
平鍋氏が関わっている本が今の所満足できる。

>>61
デザパタでなくて、パターンランゲージという概念についてだろうよ。
ちゃんと読んでやれよ！

0065デフォルトの名無しさん

NGNG

＞　６３

自分達の問題解決もまともにできないのに,パタン言語の識者っていうのも,おかしな
話だよね.

0066デフォルトの名無しさん

NGNG

デザパタ書いたことある人いるのか？
いたら自慢してくれよ。

0067デフォルトの名無しさん

NGNG

ここに書いてるじゃんか！

0068デフォルトの名無しさん

NGNG

>>65

問題解決が苦手だからうまくなろうと思って関わってんじゃないの。
本当は人付き合いが苦手なだけかもしれないが（w

0069デフォルトの名無しさん

NGNG

>>63
止めて正解だ。それよりデザパタだ。

0070仕様書無しさん

NGNG

Kusakabe method

◎目的
あるクラスのインタフェースを、クライアントが求める他のインタフェースへ変換する。
Kusakabe パターンは、インタフェースに互換性の無いクラス同士を組み合わせることができるようにする。

◎別名
void

◎動機
議論アプリを例にすると、質問クラスを再利用しながら構成してゆくのが好ましいが、
質問クラスは電波回答クラスを考慮に入れて設計されたものではないので、
各オブジェクトを組み合わせる事が出来ない、と言う事が起こり得る。
このようなとき、電波回答クラスのインタフェース(Kusakabe method)と質問クラスの実装を継承して対応できる。

◎適用可能性
次のような場合 Kusakabe method パターンを使用する。
・質問に答えたくない場合。
・間違いを認めたくない場合。

◎結果
・皆に叩かれる。
・本が売れなくなる。

◎使用例
～ということにしたいのですね。[92]
～と思いこみたいのですね。[95]

0071デフォルトの名無しさん

NGNG

自己イニシャライズパターン

呼び出される関数の最初に初期化済みかどうかの判定を入れ
初期化してなかったら初期化する。

全てを初期化していると時間が掛かる
いつ初期化するか一意的でない。
などの場合に有効。

使用例：
一度読んだread_onlyファイルはバッファに置いておき、
二回目以降はバッファから持って来るファイル読み込みルーチン。

0072デフォルトの名無しさん

NGNG

>>71
コンストラクタに初期化処理を入れたクラスで事足りそうだが。

0073デフォルトの名無しさん

NGNG

＞いつ初期化するか一意的でない

0074デフォルトの名無しさん

NGNG

>>71

char *func(void)
{
static int i_init = 0;
char c_buf[1024];
FILE *fp;

if (i_init == 0)
{
fp = fopen("read_only", "r");
fgets(c_buf, 1024, fp);

i_init = 1;
}

return(c_buf);
}

こんなん駄目？

007574

NGNG

あら、インデントしくじりました。すみません。

0076デフォルトの名無しさん

NGNG

そんなやつ。
bufが違うけど。（消えちゃうじゃん）

007774

NGNG

>>76

char *func(int i_clear)
{
　　static int i_init = 0;
　　static char c_buf[1024];
　　FILE *fp;

　　if (i_init == 1 && i_clear == 1)
　　{
　　　　memcpy(c_buf, '\0', 1024);
　　　　i_init = 0;
　　}
　　else if (i_init == 0)
　　{
　　　　fp = fopen("read_only", "r");
　　　　fgets(c_buf, 1024, fp);
　　　　fclose(fp);

　　　　i_init = 1;
　　}

　　return(c_buf);
}

うう、バグ直しました・・・
鬱。

0078デフォルトの名無しさん

NGNG

>>72
それだと
> 全てを初期化していると時間が掛かる
これが満たせない。

必要に応じて初期化（もっと汎用的に言えば遅延評価）は、パターンと呼ぶに
ふさわしい常套手段だと思います。

0079デフォルトの名無しさん

NGNG

>>77
上等じゃん。俺なんかマニュアル無いとfgets()なんて使えない。

フラグの代りにファイル名ごとにフラグ配列持つとか、
HashTableに入れて存在確認でやる様にすると完璧かも。

ファイルの例だけだと只のキャッシュになってしまうけど、
一般化して考えると面白いかもしれない。

0080デフォルトの名無しさん

NGNG

>>58
あんまりいい教授でないようですね。

0081デフォルトの名無しさん

NGNG

>>79
一般化するとProxyパターンじゃないの？

0082デフォルトの名無しさん

NGNG

こうして新しいが既存のものよりショボイ車輪が再発明されるのです。

0083デフォルトの名無しさん

NGNG

>>82
いやいや、こうやって既存のものに対する理解を深めていくんでしょ。書籍を
一読しただけで、応用まですべて理解するのは一握りの天才だけ。

0084デフォルトの名無しさん

NGNG

勝手にオブジェクト指向で括るな。
氏ね。>Proxyとか言ってる奴。

0085デフォルトの名無しさん

NGNG

くくってないだろ。
デザパタ=OOとか勘違いしてるかわいそうな人、
まだいるんだね。

0086デフォルトの名無しさん

NGNG

>>58
> JPLoPの過去ログ読めば読むほど鬱になっていく...

どこで読めるか教えてくれ

0087voidの弟子

NGNG

>>2
そういうのって「スタブ」っていうんだよね？:)

0088デフォルトの名無しさん

NGNG

>>85
詳しそう何で教えてください。デザパタってなんすか？

0089デフォルトの名無しさん

NGNG

デザイン・パターン

暗記でプログラミングしようという厨房に好まれる。
他のＰＧを見下そうという信者にも好まれる。

0090デフォルトの名無しさん

NGNG

デザパタの例

１）singleton
１個だけ生成する。
まあ、staticのことかな？

２）memento
publicとpribateに分ける。

まあ、こういった当たり前の事を難しく言い替えて得意になるという
明治～昭和初期あたりの文学で流行ったパターン。

0091デフォルトの名無しさん

NGNG

staticを普通に使ったんじゃ寿命管理できない…

0092デフォルトの名無しさん

NGNG

>>90
あとは、

class ProcManager {};　// abstract
class RealTimeProcManager : public ProcManager {}
class RoundRobinProcManager : public ProcManager {}

みたいなクラス階層があった場合に、

「ProcManager のインターフェースを実装したインスタンスが1つだけ存在」

というのも綺麗に書きにくいかな。

> 当たり前の事を難しく言い替えて
確かに Memento とかは、馴染みにくい単語だね。Singleton, Bridge, Command あたりは
直感的だと思うが、どうよ？

0093デフォルトの名無しさん

NGNG

いや、名前より解説の方が難しい単語の羅列の解説が多い。
例もわざわざ難解な例を作ってるように見えるし。

0094デフォルトの名無しさん

NGNG

直近データパターン

処理プログラムの近くに扱うデータを書くパターン。

例：
printf("hello");

データは一箇所に集めて・・・。というパターンの逆パターン。
ファイル名、表示文字列などは直近に置いた方が可読性が高い。

逆の例：

String　hello_str={"hello"};
String　world_str=・・・・
・・・・
・・・・
printf( hello_str );

無駄無駄無駄！

0095デフォルトの名無しさん

NGNG

>>94
変数スパンと変数生存期間は短くしろ、というヤツだね。

設計ではなく実装よりの話なのでデザパタには載ってないけど、CODE COMPLETE
で解説されてるのを読んだ覚えがある。

0096デフォルトの名無しさん

NGNG

んーデザイン（設計）レベルの話は反応が薄いので最近は実装よりにしてみましたが
たしかに実装そのものですね。

0097デフォルトの名無しさん

NGNG

システムジェネレーターパターン

システム構成を記述したファイルを起動時などに読みこみ、
モジュールを集めて適切なシステムを自分で組み立ててしまう
パターン。

0098デフォルトの名無しさん

NGNG

スキャンジェネレーターパターン

ハード・ソフトを自分で検出、計測し、適切なシステムを自分で組み立ててしまう
パターン。

0099デフォルトの名無しさん

NGNG

プラグインパターン。

後から任意の追加モジュールを実装出来るようにアプリケーションを
作る。

0100デフォルトの名無しさん

NGNG

偽プラグインパターン。

後から任意の追加モジュールを実装出来るようにアプリケーションを
作ったふりをして、モジュール読みこみに偽装してアプリケーション
本体ごと新しいバージョンに書き替える。

0101デフォルトの名無しさん

NGNG

inseparably パターン

◎目的
クライアントが求めないソフトウェアを、クライアントが利用しているソフトウェアと
不可分なものとしてリリースする。

◎適用可能性
次のような場合に　inseparably パターンを使用する。
・ある分野でのシェアを背景に、別の分野でのシェアを奪取するとき
・独占禁止法などが適用される懸念がある分野のアプリケーションをリリースするとき

◎実装
inseparably パターンには、いくつかの実装方法がある。

1. OSのバグ修正パックを用いた配布
OSベンダーは、ユーザが絶対に必要とするOSのバグ修正パックに含める形で、
目的のソフトウェアを同時配布することができる。このとき、できるだけ致命的な
バグ修正を含めると効果的であるため、OSの初回リリースでは致命的なバグを
残しておくことが重要である。

2. スイートを用いた配布
キラーアプリケーションを保持するベンダーは、一連の製品を統合するスイート
製品の一部として目的のソフトウェアを同時配布することができる。このとき、キ
ラーアプリケーションと競合他社製品との連携を極めて困難にしつつ、自社ス
イート製品内で強固な連携機能を提供すると効果が高い。

◎使用例
・Microsoft がブラウザ戦争に勝利するために、OS拡張機能と不可分な形でIEを
　リリースした。

■ このスレッドは過去ログ倉庫に格納されています