■２CHデザパタ■

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

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

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

>>1

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

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

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

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

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

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

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

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

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

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

>>7

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

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

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

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

Gang of Four

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

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

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

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

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

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

　

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

厨パターン

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

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

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

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

Never ending method

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

◎別名
Dependence

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

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

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

◎実装
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]

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

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

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

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

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

age

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

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

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

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

類似）
Doc-View onlyパターン

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

>>37

相討ち

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

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

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

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

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

ファミコンパターン

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

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

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

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

Ｒｕｂｙ！

テロ対策パタン

SHOW THE FLAG!

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

ニセ板違いパターン

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

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


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

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

言語もどきパターン

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

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

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

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

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

>>50
ん、誤爆？

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

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

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

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

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

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

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

オートセーブ

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

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

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

全部セーブパターン。

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

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

Ruby!!!!!!!!

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

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

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

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

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

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

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

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

＞　５９

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

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

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

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

＞　６３

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

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

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

>>65

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

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

Kusakabe method

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

◎別名
void

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

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

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

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

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

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

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

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

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

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

>>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);
}

こんなん駄目？

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

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

>>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);
}


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

デザイン・パターン

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

デザパタの例

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

２）memento
publicとpribateに分ける。

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

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

>>90
あとは、

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

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

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

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

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

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

直近データパターン

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

例：
printf("hello");

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

逆の例：

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

無駄無駄無駄！

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

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

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

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

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

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

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

プラグインパターン。

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

偽プラグインパターン。

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

inseparably パターン

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

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

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

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

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

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

そんな手口でも、勝利しちゃうんだよね現実は。

■名前：「表示があれば何でもＭＶＣ」パターン

■別名： ＭＶＣ Type N (N=I,II,...)

■動機： ＯＯで、画面付きのシステムを作れといわれた。
　　　　 でも適当なフレームワークが見当たらない。
　　　　 画面と、モデルがあるんだから、ＭＶＣが適用できるに違いない。
　　　　 (ところで、コントローラとかイベントが見当たらないぞ？)

■構成要素：
　　　　モデル：　　　　JavaBean, EJB
　　　　ビュー：　　　　JSP
　　　　コントローラ：　Servlet
　　　　イベント：　　　HTTP要求

　　　　※ なお、JavaBeanとEJBは省略可。Servletを省略すると厨房とみなす。

■落とし穴：
　　　　なんとなく、元のＭＶＣとは違う。

■事例：
　　　　　国際事務危機
　　　　　じゃかるた・すとらっつ
　　　　　えんひどら・ばらくーだ

■バリエーション：
　「よーし次は、ＤＢ屋のアーキテクチャも、ＭＶＣ でリプレースだ！」

　　　　モデル：　　　　ＲＤＢＭＳ
　　　　ビュー：　　　　プレゼンテーション(JSP)
　　　　コントローラ：　ビジネスロジック(ServletとStoredProcedure？)

age

チンギスハーン

騎馬兵団を階層的に集約し、ユーラシア大陸全域にわたる
人類史上最大の大帝国を構築する。

ＧｏＦヲタにデザパタは２３パターンどころじゃない事を教える為に
立てたけど、ヲタの耳に念仏ﾀﾞｯﾀｰﾖ。

>>106
ﾌﾚｰﾑﾜｰｸ･ｦﾀをﾋﾆｰｸってみましたが、何か。

■名前:「理由なし状態保持回避」パターン

■別名: ステートレス・パターン

■動機: 関数型言語や並列言語にならって、変数代入や状態保持を回避すべきだと
　　　　強い信念を持ってしまう.

　　　　[理由]
　　　　・純関数言語は代入なしだから、
　　　　　それがXXXX言語でも正しいと思い込む.
　　　　・型システムが簡単になる.
　　　　・状態保持は処理系が行うべきだ
　　　　・並列化しやすい, etc.

■実装: ・状態保持の方が効率的に見える場面でも、一々再計算してみる.
　　　　・関数呼び出しをネストしてみる.
　　　　・引数を使って、状態保持を隠蔽してみる.
　　　
■使用例: ステートレスなWebアプリケーション (StatelessServlet)

■応用: 私の頭はfunctional なので、貴方のおっしゃっている事は状態保持していません.

　　　　　

age

骨無しばっかだね。

ネタ擦れだから。

http://www.hyuki.com/dp/dpinfo.html
にいろいろあるYO!

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　hyuki を知らずして2chでデザパタを語るなと…
＼
　 ￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　 （　・∀・）　 ∧ ∧ ＜　だからｿﾝﾅｺﾄ言ってないでしょ！！
　（　　⊃ ）　 (ﾟДﾟ；)　　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣ （つ＿つ＿＿__
￣￣￣日∇￣＼|timpoPad|＼
　　　 　 　￣　　　=========　 ＼

■ 名前:「xTreme 仕様変更」 パターン

■ 別名:「週120時間」(120-hour week) パターン

････以下略

In article >>114, デフォルトの名無しさん/sage/114 wrote:

> ■ 別名:「週120時間」(120-hour week) パターン

のこりの48じかんはさぼっているのですね :-p

クラスレスパターン

問題を解決する為にあえてクラスを作らない。
iアプリ開発で使われている。

hikaru-madokaパターン

最初に安全な実行ファイルhikaru.exeを配布し、評判と別に危険ではないという
認識が広まった頃にトロイ入りのmadoka.exeを配布する。

手続き型逐次実行クラスパターン。
http://www.alien-factory.co.uk/main.html

SetFullScreenModeクラスにはビクーリしたよ！

■名前：ｼﾞｻｰｸｼﾞｴｰﾝ・パターン

■動機：２ちゃんねるで議論すると、
　　　　皆分かっている範囲でしか突っ込まないから、
　　　　50〜100レス程度で同じ議論が繰り返される。

■実装：議論が有意義なものになるように、自分でレスを全部書く。

■落とし穴：２ちゃんねるに書き込む必然性がない。

あー、学生のころ読んだな、と思ったら へねぱた だった。

test

test2

保守あげ