貴様ら！オブジェクト指向を教えろ！！第2章

貴様ら！オブジェクト指向を教えろ！！
http://pc2.2ch.net/test/read.cgi/tech/1047696495/l50

【夢】get

さらに【恋】もget

そして【星】になった・・・

　（　・∀・）＜　こんなのみつけたっち♪
http://muryou.gasuki.com/moe/hankaku10.html
http://muryou.gasuki.com/moe/hankaku09.html
http://muryou.gasuki.com/moe/hankaku08.html
http://muryou.gasuki.com/moe/hankaku07.html
http://muryou.gasuki.com/moe/hankaku06.html
http://muryou.gasuki.com/moe/hankaku05.html
http://muryou.gasuki.com/moe/hankaku04.html
http://muryou.gasuki.com/moe/hankaku03.html
http://muryou.gasuki.com/moe/hankaku02.html
http://muryou.gasuki.com/moe/hankaku01.html

http://saitama.gasuki.com/kaorin/
〜oノハヽo〜 ／￣￣￣￣￣￣￣ 　　　　　　　　　　　　　　　
　 (　＾▽＾) ＜　こんなのがございまーす♪　
= ⊂ 　　）　　 ＼＿＿＿＿＿＿＿
= (__/"(__)　ﾄﾃﾃﾃ...

立てるのが遅いです。

オブジェクト指向・嗜好・試行・至高・歯垢
http://pc2.2ch.net/test/read.cgi/tech/1049778124/
こっちが先です。

なんか静かだな・・・ｗ

http://saitama.gasuki.com/kaorin/
〜oノハヽo〜 ／￣￣￣￣￣￣￣ 　　　　　　　　　　　　　　　
　 (　＾▽＾) ＜　こんなのがございまーす♪　
= ⊂ 　　）　　 ＼＿＿＿＿＿＿＿
= (__/"(__)　ﾄﾃﾃﾃ...

　（　・∀・）＜　こんなのみつけたっち♪
http://muryou.gasuki.com/moe/hankaku10.html
http://muryou.gasuki.com/moe/hankaku09.html
http://muryou.gasuki.com/moe/hankaku08.html
http://muryou.gasuki.com/moe/hankaku07.html
http://muryou.gasuki.com/moe/hankaku06.html
http://muryou.gasuki.com/moe/hankaku05.html
http://muryou.gasuki.com/moe/hankaku04.html
http://muryou.gasuki.com/moe/hankaku03.html
http://muryou.gasuki.com/moe/hankaku02.html
http://muryou.gasuki.com/moe/hankaku01.html

マウスの処理をするために、リスナー登録をしますけど
通常ならやらない処理のマウスの命令まで書かなくてはなりませんよね？
そこで、アダプタを使えば無駄な命令をかかなくて　すむらしいのですが
なぜ、アダプタなしの状態で無駄な処理まで書かなければならないのでしょうか？

>>11
アダプタには君の言う「無駄な処理」が書いてあるから。

>>12
日本語がちょっとおかしいですね。
アダプタに無駄な処理が書いてるから
その後に具体的に説明しないとわかりません。

訂正

貴様のようなチンカスの残り野郎の為に
神はアダプタを用意してくださったのだ。

>>14
アダプタを作ったのは神じゃなくて人間だろ
お前は電波・お花畑にでも行け

>>15
禿げしく同意！

１５＝１６

うっさい

アダプタは神様からの贈り物だろ

>>18
つまらん

ageるおまえがウザイ
ウザすぎる
死ね！

俺は爆笑だったけどな

>>20
感情的な方ですねｗ
まぁ、1人位居てもいいか・・・貴重な存在ですし。

アクターもオブジェクト？

>>22
またageやがったな
この天邪鬼が
こうなったら透明あぼーんだ！
あと数秒でおまえなんか消えてしまう。
それも強制的にだ

>>24
テメェ！！さげるんじゃねぇよ！！！
あぁん？？

オブジェクトが持っているオブジェクトはなんて呼ぶの？

has-a や contains-of の関係にあるオブジェクト

インスタンス変数>26

インスタンス変数　ﾊﾆｬ?

>>29
インスタンス変数くらいなら、調べましょうよ

インスタンス変数は変数であってオブジェクトのことでは無い

オブジェクトを変数に入れます

だめすぎ

class Singleton
{
private:
　　static *m_Object;
　　Singleton()
　　{
　　　m_Object = new Singleton;
　　}
public:
　　virtual ~Singleton()
　　{
　　　　delete m_Object;
　　}

　　virtual Singleton *GetObject()
　　{
　　　　return m_Object;
　　}
};

の m_Object はインスタンス変数なんですよ。

訂正
誤: static *m_Object;
正: static Singleton *m_Object;

>>34
突っ込みどころが多すぎてどこに突っ込めばいいのかわからん

>>36
最後の 1 行だけじゃないの？ < ツッコミどころ

とりあえず new の無限ループと

すまん、マウスの誤操作。

new の無限ループと private なコンストラクタと、virtual な GetObject メソッドに突っ込んでおく。

コンストラクタの中身を、

　　if(m_Object != 0) {
　　　　m_Object = new Singleton;
　　}

にしないといけないね。
コンストラクタが private なのはこの場合あたりまえでしょ。
virtual なのは別に問題ないんじゃ。

間違い。if は == だね。

Singleton はふつう継承しないけど、OO のデフォルトは virtual だから、
コンストラクタ以外はなんでもかんでも virtual にするのは正しいですね。

class Singleton
{
private:
static Singleton *m_Object;
Singleton()
{
　　　　if(m_Object == 0) {
　　　　　　m_Object = new Singleton;
　　　　}
}
public:
virtual ~Singleton()
{
delete m_Object;
}

virtual Singleton *GetObject()
{
return m_Object;
}
};

これが正しいのかな。

>>40
コンストラクタがprivateじゃどうやってSingletonオブジェクトを構築するんだよ。
コンストラクタがprivateなクラスのインスタンスはそのクラス内でしか作成できないが、newが書いてあるのはそのprivateなコンストラクタの中。

しかもSingletonなんだからGetObjectはvirtualじゃなくてstaticだろ。

しかも
　　　　if(m_Object == 0) {
　　　　　　m_Object = new Singleton;
　　　　}

も相変わらず無限ループだし。

>>42 の GetObject を static にすれば OK かな。

>>44
m_Object は static だから無限じゃないと。

>>46
代入する前に次のコンストラクタが呼ばれちゃうよ。

おお、すごいことになってる。

結論: C++ で Singleton は無理！

コンストラクタで new したらマズいでせう

class Singleton
{
private:
　　static Singleton *m_Object;
　　Singleton()
　　{
　　}

public:
　　virtual ~Singleton()
　　{
　　}

　　static Singleton *GetObject()
　　{
　　　　if(m_Object == 0) {
　　　　　　m_Object = new Singleton;
　　　　}
　　　　return m_Object;
　　}
};

こうか？

>>51 だと、GetObject() を synchronized にしないと危ないと思うんだが、
C++ だとどうすればよいでつか？

マルチ・スレッドの場合ね < 52

>>52
処理系依存の方法でロックするしか無いでしょう。

>>52
Winならセマフォとかミューテックスとか

m_Object を volatile すればいいのかにゃ？

volatile じゃだめ。

>>55
なんか、情報筋の伝えるところによるとミューテックスやセマフォは遅いのでクリティカルセッションを使ったほうが良いそうだ。

たかだか十数行のソースで何故これほど意見が割れるのか。。。。

>>58
クリティカルセッションって
そこだけ割禁で突っ走るってこと？

このスレを見て、次のプロジェクトにC++を採用することをあきらめました。

>>60
ゴメン。セッション→セクション。
EnterCriticalSection使うと、排他的に実行できるそうだ。

>>62
ま大体同じようなもんだね

if(m_Object == 0) の if 文に突入してから終了するまでに、別のスレッドが m_Object
を参照できなくなればいいんですよね。

クリセクでできそうな気がするんだけど、だめなの？

クリティカルセクションを使ったマルチスレッド対応版をうｐしてみてくれ。

>>66
LokiPortあたりを見てくれ

ああ、なんてJavaは簡単なんだ。

十進BASIC
http://hp.vector.co.jp/authors/VA008683/

趣味のプログラムならこちらの方が楽しそう。

>>69
誘導
http://tako.2ch.net/denpa/index2.html

前スレはクソスレなりに面白い話も飛び交って、結構面白かったんだけどな。
このスレは終わらせちゃうの？前スレみたいに途中から軌道修正して面白い
スレになってくれることを期待しつつsage

ちなみにクラスが持ってるオブジェクトの変数はクラス変数と呼ぶのでは。
インスタンス変数だとnew したもの全部そうだし。あ、配列なんかは違うのか？

・クラス変数はオブジェクトの外
・Javaでは配列はオブジェクト

インドの電気屋の話

インドで電気屋を呼ぶと、それが電球交換のような単純な仕事でも５人も来るそうだ。

１人は梯子を運ぶ係
１人は梯子を支える係
１人は電球を運ぶ係
１人は電球を交換する係
１人は監督する係

すべての作業をやってくれるが日給一万円の人間を一人使うより
単純作業しかできないがその作業を完璧にこなす日給千円の人間を五人使うのは間違っちゃいない。

class Singleton {
  static std::auto_ptr<Singleton> inst;
  Singleton() {}
public:
  static inline Singleton* GetObject() {
    return inst;
  }
}
std::auto_ptr<Singleton> Singleton::inst( new Singleton() );

return inst.get();
だた。

・クラス変数はオブジェクトの外
・Javaでは配列はオブジェタト

オブジェクト＝クラス？
オブジェクト＝インスタンス？

どっちなんでしょう？それとも違うもの？
今まで下だと信じてたんですが。

オブジェクトってのは、クラスとインスタンスが分離する前に使われてた言葉です。

>>79
クラスじゃなくてもオブジェクト。
int a;
の a はオブジェクトです。

>>81
a をオブジェクトというような状況では int をクラスと呼ぶんじゃないか？

>>82
クラス型のオブジェクトじゃなくて、プリミティブ型のオブジェクトでろ。

プリミティブ型ってなんだYO？

>>84
intのこと

で、それだとなんでクラスじゃなくなるの？

C++なら、classキーワードを使って定義されたものじゃないから。

classキーワードじゃなくてもクラスはクラスだと思うんだけどな。

OOPの考案者は誰？

C でも int a; の a はオブジェクトですよ。「プログラミング言語 C 第2版」。

struct a{...}b;

aはオブジェクトではないが、bはオブジェクト。

>>88
思うだけ。

>>92
C++ではstructとclassの違いはデフォルトのメンバのアクセス制限だけなんだが、
それでもclassはクラスでstructはクラスでは無いと？

>>93
structは構造体

>>94
構造体とクラスの違いは？

すまん。つい調子に乗ってとてつもなく阿呆な質問をしてしまった。

>>96
うざ

intはクラスなの？

>>93
int はクラスじゃないよ。

>>98
intはC++などのclassキーワードで定義されるクラスではないけど
広い意味での型を意味するクラスだよ。

クラスでもクラスじゃなくても、int a; の a はオブジェクト。

オブジェクト指向のオブジェクトではないが。

C#だとそうでもない

えっと、つまり、実体が生成されたもの……
Effective C++ で言うところのオブジェクト定義されたものが
オブジェクトと言う事でしょうか。

>>102
「オブジェクト指向のオブジェクト」というのも変な言い方ですが、
オブジェクト指向なんてなかったころから、型の実体のことをオブジェクト
と言ってきている。
クラス型のオブジェクトがオブジェクトのすべてだという誤解をしているのでは。

俺の認識ではオブジェクトとインスタンスは同じ意味だけど、
インスタンスのほうが、クラスから作成された特定の1つのオブジェクトってイメージをくっきり表すような気がする。
たとえばSingletonだと普通はGetObjectじゃなくてGetInstanceだよね。

補足。
なんか例が悪かったなぁ。特定の一つってのは別にSingletonの唯一のインスタンスって意味じゃなくて、

Soundクラスに自身のオブジェクトを作成するメソッドがあったら
CreateInstance
だろうし、バッファ用のオブジェクトを作成するメソッドがあったらCreateBufferObject
（普通はObjectを省くだろうけど、もしつけるとしたらInstanceじゃなくてObjectだよね）だろうし。

>>105
英単語と専門用語の違いだよ。

http://www2.leverage.jp/start/

￣￣|￣￣|￣|
￣|￣￣|￣￣|ヽ＿∧
￣￣|￣￣|￣|´･ω･`） ﾖｶｯﾀﾅ
￣|￣￣|￣￣| /U
￣￣|￣￣|￣| |
￣|￣￣|￣￣| ∪
＾^＾^＾^＾^＾^＾^＾^＾^＾^＾

￣￣|￣￣|￣|
￣|￣￣|￣￣|
￣￣|￣￣|￣|彡
￣|￣￣|￣￣| ｼｮﾎﾞﾝ
￣￣|￣￣|￣|
￣|￣￣|￣￣|
＾^＾^＾^＾^＾^＾^＾^＾^＾^＾

>>76
auto_ptrを使ったら駄目だよ！！

オブジェクトと言えば、Ｃコンパイルした時の.oファイルを思い浮かべるんですが。

同じ言葉で違う意味を指す言葉が大杉

.o はリロケータブル・オブジェクト・モジュール。

C++ならboostに同期用のオブジェクトがあるからそれ使え

boost::mutex singletonMutex;

class Singleton
{
private:
　　static Singleton *m_Object;
　　Singleton()
　　{
　　}

public:
　　virtual ~Singleton()
　　{
　　}

　　static Singleton *GetInstance()
　　{
　　　　boost::mutex::scpoed_lock(singletonMutex);
　　　　if(m_Object == 0) {
　　　　　　m_Object = new Singleton;
　　　　}
　　　　return m_Object;
　　}
};

こうかい？

まあ、簡単に言うと

オブジェクト＝モジュールね。

で機能別にモジュールを作って組み合わせて使うのがオブジェクト指向

モジュールってなに？ .o のこと？

boost インスコしたら200MBくらい食ってしもた。
こんなサイズでかいの？

スマソ、スレ違いだった。

>>111
なんで？
なんで使っちゃ駄目なの？

>121
Effective SLT嫁。COAPの辺り。
GetObject()でinst をreturnした瞬間にinstがNULLクリアされるから。
auto_ptrを使うのは
・オブジェクトの所有権を移動させる場合
・ブロックが終了したときにnewしたオブジェクトを確実に解放したい場合
ぐらいにしとけ。それ以外はboost::shared_ptrですな

>>122
何か勘違いしていらっしゃいませんか？
instは自動変数ではありませんよ。
もう一度良くご確認なさってはいかがでしょうか？
また、>>77におきまして
return inst;
とあった箇所を
return inst.get();
修正しておりますので、そこの箇所への突っ込みはご容赦くださいませ。

　　　（　　ド・ド・DQNの大爆笑〜
　　　 `ー‐―V―――――――――――――――――――――――――――――
　　　　　 　　　　　;:'´ （　　　糞スレ立ててる>1さんを
　　　　　　　　_....._{{ 〃`ー―――――V―――――――――――――――――――
　　　　 　, - ' ,..､､.ヾ{{フ'⌒`ヽ､ 　　　　　　　（　　　笑ってちょ〜だい今日もまた
　　　　／　 ,:', -‐‐` ´ '´⌒ヽ　ヾ:､ 　 _....､､､､`ー――――V―――――――――――‐
.　　　,'　　 ,'´　,ィ ,ｨ ,' , 　 ｀ヽ',　 ',-<´　,　　　　 ｀ヽ. 　 　　　______　　　　　　　　..._
　 　 ,' 　　.i　 /|. /.| { i,　 i,　　}.　 }_,,）) lﾆ二二ミヽ.､ ':,　,.: '´ ,_.....__｀ヽ､ 　 　,..-‐-､),...._
　　　!　|　 ! .,'-.{ !　!|; |`､.}ﾞ!.!　|.　 !　ヽ.ｌ ./　,!　 ,,｀ヾ:､ ':, 　./'´￣｀ヾ､､ヽ,.:'´　,:‐:､ ,.-､ ヽ.
　　　',　',　|Vｧ=､ﾞ､ ｀ﾞ､!-_:ﾄ,ﾘ', l !　| 　 ﾞﾚ__,〃_/ﾘ　　!.'; .} ./ｌ_|___ﾉ!　ｌ　`､ ', 　/ //`''} }.';　',
　　　 ヽ､', l:!Kノ}. 　 　 f:_.)iﾞi: ﾘ !　l　ル'￣｀`　´-､,ﾉﾉ l l .!,;:=､｀:.｀:>=､.j,｝ |__人((　_ﾉﾉノ　 |
　　　　 | l!iヽﾞ- '　, 　　.!__:ﾉ ﾞ ,ﾘ l ﾘ'´ .|'￣ヽ 　 __　｀><ﾉ | {;:'ﾉ　ﾉtrﾃ;､.Y　! ,--､ 　 __`彡 ﾉ
.　　　　 ',|!!､ 　 　r‐┐ 　 ｀ ノ' /,ｲ　　! 　 __ ,　⌒'/!| | 　!.`ｰ‐'´, ﾞじ' ノ ! h. 　　._: ´　ｿ).（
　　　　　 'i!ﾞ､ヽ､　ﾞｰ'　　_, ィ,:',:''´ !　　!､　 ｰ'　　ノｲ ! |　| !､ 　!ﾌ ｀フ'ﾘ ! ﾙ'ヽ.._　_..､(ン ﾉ ）
　　　　　　ﾞ:､ｨ､jヾｰ::: 'iﾍ　ノ',ﾘ.／!　.| |ｰ`┬､' ´ 〃 l. トヾ､.ﾞ｀ｨ'' ´ヽ､///　＼二|｀＼ｰ‐‐'´
　　　,､- '´　ヽ､ﾞ､　　 {　｀＞"､　 !　 ! ! 　 |　｀>-､　|　|､　＿＿＿＿＿＿＿_∧＿＿＿＿__
　　/＼＼　　　　',　　 }　　 //｀ヽ|　 ',.!ﾞ､　!／／ ﾞ!/　 ! （　　　誰に〜も遠慮はいりません

>>76 のコードはコンストラクタが走る前に
GetObject()が呼ばれる可能性がある。　バグを発見しづらい危険なコードだ。

>>122
>GetObject()でinst をreturnした瞬間にinstがNULLクリアされるから。
NULLクリア？何がNULLになるんだ？
つーか、STL使ったことあるか？大丈夫か？

>123
>77見落としていた。スマヌ。
でも、生のポインタ渡すのってもっと邪悪じゃない？
auto_ptrって、生のポインタのdeleteとか保護できたっけ？

ちなみにVC++で

{
auto_ptr<Singleton> j(Singleton::GetObject());
}

Singleton* k = Singleton::GetObject();

なことやったらオチた。


>126
auto_ptrの指している生のポインタのこと。
プログラムじゃshared_ptr, weak_ptrしか使わないから
auto_ptrは良く解らんですな。

>>127

"まだ使用しなければならないインスタンス"をdeleteすると
不具合がおきるのは当たり前でしょう？
あなたの言に従うと"ポインタは危険なので使用してはならない"
ということにもなりかねません。

次のような例についてお考えください。
void func1() {
    int i;
    func2( &i );
    cout << i << '\n';
}
void func2( int* i ) {
    auto_ptr<int> g(i);
    *g = 1234;
}

>128
いや、まあそうなんだけど、大域領域に晒しておくもんだし、
そんなに貧弱でいいのかな、と。
＃普通、NULLチェックして再生成しない？

deleteしたところと、エラーが発生したところが全然別の
所になるから、場合によってはデバッグではまるなぁ。

追記
Modern C++ Designを読むのが一番てっとり早いな。
Singletonのところ。

>>129
なるほど、奥が深いのですねぇ。
要点をまとめると
・生ポインタ、std::auto_ptrは邪悪である
・Singletonにおいては、普通は、唯一のインスタンスが削除されたら再生成するように記述する
・shared_ptrは、参照先のオブジェクトが削除されたら、
  "NULLクリア"される

ってことですね。

>131
ん〜違う……といっても説明していないんだけど。

肝のところは
・オブジェクトの管理をライブラリに任せるのなら完全に任せる。
・オブジェクトをdeleteしていけないのならばその旨明示する。
つう所かな？

auto_ptrから生のポインタを引き出して渡すのは、auto_ptrが
所持しているはずのオブジェクトの所有権を他の所に渡して
しまっているようなものだから、『オブジェクトの所有権を明確化する』
という余計な仕事が増えるんだよね。

これを、例えばオブジェクトの実体の参照を渡すようにすれば、
渡されたオブジェクトをdeleteすることができないので、オブジェクトの
所有権は明確なままだよね。

あるいはboost::shared_ptrを使って、boost::weak_ptrを渡すように
するとか……

ついでに、こっちにまじめにコメントを入れると
・生ポインタ、std::auto_ptrは邪悪である
　->何にしろ『目的』をわきまえないで使用することは邪悪である

・Singletonにおいては、普通は、唯一のインスタンスが削除されたら再生成するように記述する
　->Sengletonは『唯一のインスタンスであることを保証する』ようにする必要がある

・shared_ptrは、参照先のオブジェクトが削除されたら、 "NULLクリア"される
　->auto_ptrのような破壊型コピー式のスマートポインタは、オブジェクトの
　所有権を他のスマートポインタに渡したあとは、そのオブジェクトへのアクセス
　手段を放棄する
かねぇ

>>131
そういう書き込みする時は、
相手が言った言葉以外の言葉を勝手に補っちゃだめだし、
相手のレス番を明記しておかなきゃ。

（＾＾）

age

関係ないが、パターンは非常に危険。

多くのパターンは名前しらなくても、無意識につかってる。
関数の中で他の関数を呼ぶ事に名称はないが、クラスの中で
他のクラスを所有している事に名前がついている。さてそれが
有益だろうか。

継承は非常に便利であるが、きれいに設計されていない限り、
読みにくく、クラスの相関が極めて複雑になり、設計全体が
破綻に導く可能性のある非常に危険なものでもある。熟練者
以外が迷った場合は大抵継承をしないやり方を選ぶべきだ。

また、オブジェクト指向は元来、生産性のために実行速度を
犠牲にした概念。スピードを損なわないように緻密に作らない
限り実行スピードは遅くなる。

パターンはといえば、そのようなオブジェクト指向の難点を
助長させる部分で非常に危険である。たとえば、技とすれば
Chain of Responsibilityはかっこいいが、実際に使うとなれば、
ロジックの流れの見にくさを考えると、使わないで切り抜けられる
なら、避けるべきロジック。単純なＩＦ文を使えばいいところに、
わざわざ複雑なロジックを組み込むようなものだ。

パターンはこの辺の実行パフォーマンスやメンテ性に対するリスク
を知り尽くしてる人が、自分がある程度の経験でしってるクラス周り
のロジックを整理するには有効である。だが、それ以外は弊害の方が
上回ることが多い。自分でクラスを１０個程度しか作った事がない
人がパターンを覚えることによって、スキルアップする分よりも、
優先順位偏りからくるリスクの方が大きい。

ＸＭＬパーシング技術のＳＡＸは継承を前提とした画期的設計に
なっているが、その設計に反対視する専門家は少なくない。

>>136
反対視する専門家って、具体的に誰？

>>136
継承を前提とした画期的設計って、MFC もそうだよね。

>>136
フレームワークも否定されますか？

俺は136に賛成。
いうと叩かれるから言わなかったけどデザパタはロクな設計じゃない気がする。
OO信者な俺には耐えられない。

>>140
気がするだけじゃ。
ねえ。
気分で設計する上役がいると仕事やりにくい。

>>141
いやこれがどう駄目ってわけじゃないけど。
直感的にヘタクソって思う。
これがさあ、微妙にヘタとかそういうレベルじゃないんだよ。
もう、なんつーか指摘するのも面倒なぐらいのレベル。
まず引っ掛かるのが分かりにくさ。
次に、引っ掛かるのがなんでオブジェクト指向でありながらロジック単位の話をするのか謎。
OOの話をしてるときに実装の話は普通でないんだけど何故かでる怪奇。

良くわからんな・・・
実装のことを考えずに、何を設計するの？

>>142
ある抽象レベルで話をしているのに、いきなり抽象レベルの違う
話題が出てくるとか？

142 じゃないが。
設計と実装を分けて考えられない人っていない？
自分で書いておきながら人に説明できないプログラムを書く人というか。

>>143
いや、オブジェクト指向がわからない人って共通してこれがわからないっつーのはわかるよ。
ただ、ちょっと考えてほしいんだよね。
コーダーなんかで終わらない為に。

>>146
説明が下手ってこと？

シンプルに考えられないってことか？

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

>>149
それじゃわからん。

>>142
要するに、何がわからないのかわからないってことか。

どうしてもいいたいことがわからない・・・
あるロジックを組む時に、それをどういうクラスの、どういうメソッド
を使って実現するのか考えることがオブジェクト指向設計ではないの？
ロジック単位で設計の話をしても、少しもおかしいとは思えない。

>>152
こういう人、いるね。

あぁ。馬鹿ばっかだよ。

>>152
具象的なロジックのクラスと、もっと概念的な抽象レベルのクラスの話だよ。
自動車クラスでも、ガソリン自動車と電気自動車とじゃ、制御系はまったく違う。
エンジンやモーターやガソリンタンクやバッテリーのクラスは、
それゃちがうよ。
でも、ハンドルやアクセルと言うメソッドは、どちらの自動車でも
変わりない。
エンジンを突っ込むか電気モーターを突っ込むかは考えずに、自動車
クラスを設計・テストすることはできる。

>>155
と説明しても、わかんねーんだよな。

アクセル・ペダルを踏むと前進する、という要求定義に、
ガソリン・エンジンにするのか、モーターの配線はどうするのか、
蒸気機関の燃料はどうするのかは関係のない話だから。

>>152 のようなやり方も OO ではありだけど、それ専用の
クラスになっちゃうからね。

うーん、抽象レベルのクラスを考えることも設計の一つではあるけれども、
自動車クラスっていう大きい単位のクラスを出しただけで、
それだけで設計できました、とは普通言えないよね。
抽象化のレベルにも色々あるはずで、もう少しそれをブレークダウンして
考えた方がいい場合もあるはず。
ものすごく複雑なロジックならば、それを起点にして抽象化して、
オブジェクト指向設計やってもいいと思うんだがな。

訂正。何がいいたいのかわからんな、これじゃ
×ものすごく複雑なロジックならば、それを起点にして抽象化して、
　オブジェクト指向設計やってもいいと思うんだがな。

○ものすごく複雑なロジックならば、ロジックレベルでの
　オブジェクト指向設計というものがあるはずでは。

>>159
インターフェースと方式とをごっちゃにしちゃいけないですね。
それはそれ、これはこれで設計する。

※　それ->自動車クラス、これ->ロジック

>>160
うん、ロジック・レベルで OO 設計したら、ロジックを見えなくするような
クラスにラップする。
どうすればそのクラスを使えるかだけわかるようにして、そのクラスが
どうやっているかは関係がなくなるようにしておく。

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

電気モーター・クラスとガソリン・エンジン・クラスを、ロジック・方式に
したがって設計してもいい。
そのままだと、外部からの取り扱い、メソッドが異なってしまう。
でも、最終的には、アクセルを踏み込まれるとより速く回るというように
扱えるように、インターフェースが統一されていればいい。
そのクラスが、アクセルを踏み込むほど、より速く回転する、ということだけ
を知っていれば扱えるようにしておけばいい。

そして、>>164 での動力部分の設計は、自動車クラスに影響を与えない。
もしくは、最小限の変更ですむようにする。

http://www.agemasukudasai.com/movie/

MotiveDevice md = new GasEngine;
md.pushAccelPedal(10); // どうやっているかは知らない

と、

MotiveDevice md = new ElecMotor;
md.pushAccelPedal(10); // どうやっているかは知らない

とが、同じ動作をすればいい。

>136
こらまた極論だなぁ

（デザイン）パターンは、あくまで技のコレクションでしかないよ。
柔道の『大外刈り』『一本背負い』とかとおんなじ。

GoFのデザインパターンは、C++を使用するときに『ライブラリで強制できないルール』を
『デザインパターンというマニュアル』でルール付けしているわけだ。

ただ、デザインパターンというマニュアルを強制する『仕様（C++言語の支援）が存在しない』
ので、良くわかっていないユーザー（プログラマ）が間違えて実装してしまうこともあるわけだ。
そりゃあ、相手が腰を引いている状態で『大外刈り』をしようとしてもうまくいくはずがない。
『技』は知っているだけではダメで、十分に練習して（経験をつんで）『身につける』ことが
とても重要だからね。
なぜか『デザインパターンを知ればすぐにプログラムの腕前が向上する』と思っている人が
多いけれど、パターンそのものはただの骨格でしかないので（しかも凄い曖昧な）、
そのままじゃ不完全なんだけどなぁ。
これはチームでのプログラムミングでも同様で、『チームプレイで』技の練習を行い
（経験を積み）身につけなくては使いこなせない。しかし使いこなせるようになると
チームのスキルが向上する->作れるプログラムの幅が広がる。
軍隊なんかその典型だよね。

で結論。デザインパターンという『考え方』は有用。しかし、デザインパターンの個々の
『技』については、（非常に限られた状況でないと）有用でないものも存在する。
そしてデザインパターンはあくまで『手段』でしかないので、有効に用いるためには
経験を積んで身につける必要がある。
といった所かな？

＃GoFのデザインパターンはC++でだからオブジェクト指向を使っているけど、
＃（デザイン）パターンという考え方の本質はオブジェクト指向じゃ無いと思う。
＃そもそも建築用語だし。

>>168
その考えがいまの時代にあわんというに。

>>168
デザパタはただひたすらヘタクソなだけなんだが。

>>170
下手なら練習すればいい。

>>169
合うか合わないか知らないが、ガタガタ言わずにとにかく習得する
努力をしているやつからいい仕事ができるようになってくる。

>169
漏れもそうおもう。会社は社員を『交換可能な部品』にしたがっているから、
職人なんてウザイだけなんだろうなぁ


デザインパターンというかたちで概念が固定化されると、今度は
ライブラリ／コンパイラ実装者がその概念を実装して扱いやすく
なるんじゃない？
BoostとかLokiみたいにさ。あるいはRubyとか……（他のは知らん）

デザパタは便利なツールだと思うんだが。UML と組み合わせて使うと。

もう説明するのも面倒臭いな。
勝手にすれば。笑
これだけはいっとくけどデザパタはオブジェクト指向ができない人が作ったものだ。
間違いなく。

当然のことをもっともらしく書いてるのがデザパタ。

>>175
反対視する専門家って、具体的に言うと誰？

>>176
そうだよ。

いや、あれはただわかってないやつが書いただけ。

冷蔵庫に牛乳があたかもしれない。

>>175
なんかの記事の受け売りか。

OOPL の文法は、デザイン・パターンに書いてあることができるようにするために
ああなっているんだよ。

>>176
ちゃんとした言葉で整理したってとこは評価できる。

175はその文章からしてデザパタを理解していないので無視してください。

ではでは次のお手紙です。

●えーと、こんにちは。僕は高２（今度３年さ！）のＷＩＺＡＲＤユーザーです。
「１００％採用」ということなので、これを書いています。１番初めにＷＩＺＡＲ
Ｄに出会ったのは２年前の１２月でした。それ迄はコピーなんて事は考えたことも
ありませんでした。学校の帰りに友達に誘われてＩ・ツーに連れていかれました。
そこで見たのがこのＷＩＺＡＲＤでした。その日僕もそこでレンタルして確か最初
にコピーしたのは「カサブランカ○愛を」だったと思います。その時、ＷＩＺＡＲ
Ｄもコピーしました。僕はそれから今年の２月迄コピーユーザーでした。このコー
ナーはいつも楽しく見てましたが是非、僕も載ってみたいと思ってました。でもこ
のコーナーに載せてもらうのにはちゃんとしたユーザーじゃないとだめなんじゃな
いかなぁーと思ってついに買ってしまいました。（お金借りて迄ね！）この時僕の
頭の中にはどんどん手紙送ってバンバンレポート券をもらってレポート代を浮かせ
ばすぐにお金は返せるという考えがプカプカ浮かんでいました。ですから是非とも
レポート券下さい。他のコピーユーザーの皆さんもＷＩＺＡＲＤを早く買いましょ
う。それとコピーユーザーのくせにこのコーナーに載ってレポート券をもらった人、
てめーのような奴ぁーＷＩＺＡＲＤを持つ資格はねぇーんだ
よ！フォーマットしちまうか、カッターでビリビリにするか中のディスク盤を引っ
張り出してライターで焙るとか（これは生ゴミが焼けているような匂いがします）、
して神様・仏様・ウエストサイド様に今迄の悪事を白状し頭を丸めて早瀬未沙さん
に土下座して謝るしかねーな。その後もちろんＷＩＺＡＲＤを２つ３つ買ってウエ
ストサイド様にも儲けさせるしかねぇーよ！正規の皆さんもそう思うでしょ？

ちょっと感情的になってしまいましたか終わりです。今回はＷＩＺＡＲＤとの出
会いを書かせて頂きました。最後ですが僕の名はＴｏｍです。この名だけは覚えて
おいて下さいね。読みずらい文章ですが（だっていつも国語と英語は２だモン！）
ここ迄読んで下さった人ありがとうございます。それと文章を打ち込んでくれた方
汚い字ですみません。（これは紙に書いているのでウエストサイドの人がパチパチ
と打ち込んでる訳さ！
ちなみにこの手紙レポート用紙に書いているんだ、だって便せん無いんだもん）で
は、皆さん、さよなら、さよなら、さよなら

Ｔｏｍ●

う〜んひさびさに壮烈な文章です。自分は３ヶ月前迄コピーユーザーだったこと
を宣言してるくせに堂々とコピーユーザーをけなしている・・・ほんでもって「頭
丸めろ」だって・・・Ｔｏｍさんは頭丸めましたか？ＷＩＺＡＲＤ２つ３つ買って
くれましたか？（つっこむ、つっこむ）これからもお手紙は下さい。それは有難い
事です。ハイ。

http://homepage3.nifty.com/coco-nut/

>>177
はぁ？何？専門家って？いるの？そんなの。
俺じゃないんだけど、それいったの。

デザインパターンの考え自体を否定しているのか、
例えば 「GoF パターンのこれ」 といった各々のパターンの出来についていってるのか、
どっちなんだ？

>>188
考え自体駄目。
だいたいオブジェクト指向じゃないじゃん。
絶対、オブジェクト指向だけをちゃんと覚えた方が楽だって。
いらないでしょデザパタなんて。
かなり腐ったパターンもあるし、絶対、これ作った奴怪しいって。

俺は型にはまるのはいやだ。

>>189
実装経験のないカタワ馬鹿いってよし。

俺流

なぜデザパタが生まれたか、勉強してください

>>189
議論したいなら具体例示せよ。
例えば、どのパターンのどの部分がオブジェクト指向じゃないの？
で、おまえの言っているオブジェクト指向って何？
なんか、かなーり狭い意味でのオブジェクト指向に固執しているような
気がするんだけど。

>>189
「腐ったパターンもあるし」ってことは、>>189が「腐ったパターン」であることを
具体的に示せるパターンもあるのだろうな。それがなんなのか、ぜひ知りたいものだ。

デザパタを適用できるのは全ソースの5%が限度。そう考えてる自分は
勉強不足ですか？

>>196
何を根拠に「5%が限度」なんて言うのだろう。
5%ってどう言うことなんだろう。

100KLineのプログラムがあると、
そのうち5KLineまでしかデザインパターンを適用できない、とか？
それは何かの調査結果とかですか？

複数クラスの関連は、デコレーターと継承しかない。オブジェクト
指向習得は、この二つをどうやって使い分けるかに始まる。

継承は、柔軟性、可読性が低いことから、クラス同士の明らかな
親子関係がない限り、デコレーターを使う方針に落ち着く。

その二つを使い分けれれば、あとは自分で最適な使い方をケース
バイケースで使って行けばいい。

自分は、デザパタに接することなく、自分でクラスを作ったり、
人のを見たり使ったりしながら、オブジェクト指向を覚えた。
ある日、クラス作りの幅を広げようと、デザパタの本を読んで
見た。

ほとんどは、自分が名前も知らずに使ってるものだった。
一部は経験から、クラス関係が複雑過ぎ、可読性があまりに低い
ため、意識的に避けるべきクラスの使い方だった。

デザパタは、クラスの裏技コンテスト的としては、インスピレーション
を多少得れたが、全体としては有益になるものはなかった。
逆に名前付けすることによる発想の硬直化という弊害の方
が大きい気がした。

>>197
いえ、全くの主観です。いろいろと試してみた結果こういう考えに至りました。
はっきりとした根拠は示せません。ごめんなさい。
ごめんなさいついでに、あなたはどれくらいの範囲に適用できてますか？

>>198
そか...デコレータしか理解できなかったんだね。

>>200

デコレータ以外もできたよ。そんな理解するのに難しいものでも
ないし。でも、アダプタにしてもシングルトンも普段から
使ってるものだった。シングルトンはただstatic変数の無数ある
うちの一つの使い方でしかないとおもった

>>197は厨房と認定されました。

　　　　　　　,-､/＾＾､,-､
　 　　　　/｀　/ 　　ヽ　´ヽ
　　　　<´￣｀　　　　　´￣｀>
　 　　く 　　　認　　厨 　 　 ,>
　 　　< ＼.. 　 　　　　　 ／ >
　 　 　く /　　定　　房 　ヽ ,>
　 　　　〈__ 　 　 人 　　　__〉
　　　　　　ヽ__,.<_,､_ゝ､_ノ

>>199
「どれくらいの範囲に」なんて、考えたことも無かったよ。

たとえば、全部のクラスの基底クラスがあって、その基底クラスに
ToString()なんてメソッドがあり、どのクラスのインスタンスに対しても
ToString メッセージを送りうるとすると、
デザインパターンの適用率は100%になったりしますか？

>>202
で？

>>198
has-a関係は継承で表現するの？デコレータで表現するの？

>>197

で、自分はどのような人にどの程度有益だと思ってるの？

>>189
純粋OOA、OODから作ったクラス群だけで実装できると思ってる馬鹿がいますな。
あんたが言ってるOOは、いわば戦略。デザパタは戦術のノウハウ。
階層が違うのに同列であつかって断罪するのは、馬鹿の証拠ですな。

それぞれのパターンは、私達の身の回りで何回も起きる問題
およびそれらの問題に対する解決ポイントを記述している。

そこで私達は、これらの解法を何回でも使うことができる。
同じ問題に対する解法を、何度も何度も最初から考え直さずに済むというわけだ。

has-a = デコレータ
is-a = 継承

っていうか、最初っから、そうした表現で表現した方がクラスの
相関はわかり易かったけど、あえて、デザパタの話してるから
デザパタ用語使ってみた。

オブジェクト指向はワークシェアリングの一種です。

>複数クラスの関連は、デコレーターと継承しかない。

というところがよく分からないけど、
俺もクラス構造の設計っていう意味だと継承にするか、委譲にするか
どちらかしかないと思っている。
あとは責務をうまく割り当てることだけに注力すればいい。
あんまりデザパタの出番はないと思う。

でも、FactoryMethod、ProtoType、Builderなんかの
生成系のパターンには結構有用なものが多いような
気がするんだけど、どうよ？
実行時にオブジェクトの構造をいつどうやって作るかって、設計では
重要だと思う。

>>207
俺はそれを手馴れと呼びたい。

あ、プい1が来ちゃった。んじゃ。

ソフトウェアパターンとは、優れたソフトウェア成果物（アーキテクチャ、分析、設計、実装、プロセスなど）
を明文化したもの。

ソフトウェアパターンの第一のメリットは開発者に共通の「用語（ボキャブラリ）」を提供できること。
ソフトウェアパターンの最大の価値は、個々のパターンに「名前」がついていること。

つまり「ソート」、「バックトラック法」、「スタック」、「二分木」、「再起構造」など、
アルゴリズムとデータ構造に関しては共通の用語を持っているが
これよりも上流の分析や設計に関する共通用語はこれまで存在しなかった。

デコレート（装飾）じゃなくて、デレゲート（委譲）じゃないのかな。

>>211
不特定多数の手馴れを文書化して、後からくる人にｵﾅｼﾞ苦労を
させないようにするっていうのは、賢い知恵だと思うがな。

>>210
個人的には、MVC分離を容易にしてくれるObserverパターンが
非常に有用だとおもうなあ。

>>213
名前がついた途端、そのものの進化が止まる。

用語を提供するのがソフトウェアパターン。

「関数Ａを再起呼び出しして・・・」、「ここの部分はスタックで実装してください」という表現が
開発者同士でスムーズに受け入れられているように、「ここのイベント通知はObserverパターンで設計しよう」
といった具合に、開発者のコミュニケーションを支援することができます。

>>210

Factoryは有用だね。俺は最初ＣＯＭをＣ＋＋で作りながら
覚えた。JavaではCalenderクラスが抽象クラスなのに、
インスタンス生成メソッドによって、実インスタンスクラス
を意識しないで使える技で非常に有用と思った。

でも、俺は後からデザパタ本で名前を知った。

結局、使えるのと、それを名前を知ってて使うのの差ではある
と思う。ボクシングでもコンビネーションは無数にあるけど、
名前がついてるのはほんの数個でしかない。では全部名前付け
するべきかといえばそうではなくて、逆にカタログ化すること
のよって応用性や即興性がなくなっちゃう。

クラスの相関パターンに関しても、やたら滅多ら名前付けする
のは有益とは思えない。一部有益なこともあるのは事実だと思う。
でも、それいったら何でも一部有益な部分はあるからして。

>>215
その苦労は労働生産性に多大な影響を与えるほどのものではない。
むしろ、後からくる人が考える機会を逸することこそ問題だ。

ソフトウェアパターンは注目度が高まり、もはや必須の知識になってきた。
しかし一方で「どうもソフトウェアパターンは好きになれない」という声も聞く。

「パターン化された」、「マニュアル化された」というコンセプトが気に障るとか
創造性が阻害されるとか、あたりまえの常識を収集して何が楽しいのか、理由はさまざま

確かにソフトウェアパターンしいうのは当たりまえのことを並べたに過ぎないもの。

しかし、コロンブスの卵のように、知っている人は簡単、確実な技術であっても、
知らない人は四苦八苦した挙句イチかバチかにしか到達できないもの

１０年以上の歳月をかけて熟成されてきたModel-View-Controllerパターンを
ゼロの知識段階で数ヶ月で唸り出せるものだろうか？

上見ると、カタログ化が有益に感じる人とそうでない人が
いるみたい。

そうなると、オブジェクト指向におけるパターンが必須では
ないことになる。

プログラミングにおいて、アルゴリズムは必須だけど、パターン
がそうではないのは、技術者によって有用性が大きくバラツキ
があるからであろう。

それは決して熟達レベルとか作業分野ではないようだ。どちらかと
いうと個人の「発想の手順」の違いに起因しているようにみえる。

>>216
名前がつくからこそ、進化が進む。

名前もついていないものの議論なんかできないっしょ？

＞１０年以上の歳月をかけて熟成されてきたModel-View-Controllerパターンを
＞ゼロの知識段階で数ヶ月で唸り出せるものだろうか？

マイクロソフトのビュー・ドキュメントとか知ってれば、十分できるでしょう。

過去の遺産を使えるのと、遺産を名前としてしってるのは全く別物でしょう。

我々が知ってるプログラミング技術は名前づけされていないが過去の
遺産を受け継いでいるのがほとんど。たとえば、Cでmallocを使って
関数内で領域を確保してそれをリターンするなんていうテクニックは皆
使ってるが、あえて名前があるわけじゃない。

デザインパターンは素敵派
・名前付けによって知識の共有が行える派
・名前付けが進歩を促すよ派
・直感的には思い付かないパターンも含まれているよ派


デザインパターンは役に立たない派
・名前付けによって進歩が停止する派
・当たり前の事しか表現されていない派
・わずかなコードにしか適用できない派
・そもそも考え方が駄目派
・クラスの関連が難しすぎるパターンが含まれている派


旨くまとめらんないかな。

パターンを使うことで創造性が阻害されるという意見もあるが
しかし「今までになかったものを作り出す」、「今までに無かったアプローチで成果物を作り出す」
という創造性を発揮するには、今までに存在していたものを知らなければならない。

よっぽどの天才以外は。

料理でも代表的な食材を使って代表的な料理を作った経験が無ければ、独創的な料理は無理。
囲碁や将棋では定石から入って定石をでるといういいかたがされている

誰もが知っている基本を抑えつつ、徐々に応用へと間口を広げるべきで
要点をなおざりにして枝葉に走る愚は避けるべき

>>218
その「有用な概念」に名前がついていると、会話が楽なんだよね。
その名前だけで話が通じるから。
協働で開発作業をしない人には、そういうボキャブラリは意味がないの
かもしれないですねえ〜。

名前はそれが表す実態の変化（進化）を拒む。

>>224
・・・最後の２行の例はテクニックというべきものではない

＞名前もついていないものの議論なんかできないっしょ？

名前がないから、発想が自由に開放される部分もある。

>>224
>マイクロソフトのビュー・ドキュメントとか知ってれば、

それはMVCの実現方法の一形態をすでに「理解している」ということだな。
アホか。

「守破離」という言葉があるが、「守」ができてないのに
「破離」をしたがる奴は、どの世界でも大成しないな。

知識の共有ってことでいえば、名前の乱立を避けるために
RFCを管理してる機関みたいなのが必要な気がするな。

ビュードキュメントなんて、ＭＶＣが「発明」されるずっと
前からあるし、ＭＳが作った概念なわけでもないことは呼んだこと
ある。おそれく、画面系インタフェイスが実現されてるシステムは
みんな多かれ少なかれ遥か前から使われているテクニック。

名前付けしなくても、遥か前から多くの人が多くの場で使っていた罠。

「四十八手集を読んでみたんだけどその殆どは、自分であみ出したものと一緒だった。
  残りいくつかは、体位に無理があり過ぎた。」

まず残念なのが、なんでパターンで覚えちゃうのかなって感じ。
高校や大学の数学でも基本さえしっかり覚えれば
数式や解法の丸暗記なんて必要ないのに隅から隅まで暗記する人がいるね。
それと同じようにデザパタを覚えることで
オブジェクト指向を理解できていないことを隠そうとしてる人がいる。
デザパタの考えが根本的に死んでることを理解するには
まずオブジェクト指向を覚えなきゃ話にならない。

>>234
MVC分離ってのは、その「皆が知っていた」概念に名前付けただけですよ。
罠でもなんでもないでしょが。

まあ、俺としては新人君がデザパタ知ってりゃOKなんてことにさえならなきゃ
どうでもいいや。

>>230
だったらあなたは名前をつけては駄目だというのか？

「ソート」という名前ができたから、ソートの進化が終わったか？
「バックトラック法」、「スタック」、「二分木」、「再起構造」では？

とはいいながら、あなたがいうことも正しいのは事実です

デザインパターンができたことによって考え方がその枠からでない人も大勢いる
しかし、それに気付いたのなら、とくに恐れる必要は無いのでは？

サッカのフェイントのテクニックとかパスワークのテクニックを
分類すれば、いくつかできるだろうな。

でもあえて選手がしないのは、「こうやったらこうやって」ってな
発想で十分で、有用性を感じないからだろうな。

騎乗位とか、バックとか。
名前があった方が、相手に要求する時簡単だろ。
別にそんな言葉知らなくても、自然に生み出すことはできるとは言え。

>>236
だから、パターンは優れた設計の基礎だって

>>241
あんた！　いいこといった！

>>232
デザパタは「守」の全てではない。一部をカタログ化したものにすぎない。

>>242
それが全てだな。
土台と思っている人と、天井と思っている馬鹿の会話は成立しない罠。

俺の親父は多分３パターンくらいしか知らないと思うが
ちゃんと俺を生んでくれたぞ。

親父がアクロバチックな技のレパートリ持ってるとは思えん

>>240
パスにしたって、特別な名前のあるパスってのがある。
たとえば「センタリング」。
（つか、サッカー詳しくないから、名前付きのパスってこれしか知らないのだけど。）

ある特定のパスをセンタリングと呼ぶことによって、
その技術---相手ゴール前にいる選手に、サイドからパスを出す---に特化した
練習も、細かい工夫もできるわけだ。

まあ、子供の出来と体位パターンとの相関は多分ないだろうからな。

＞土台と思っている人

他人に名前付けしてもらわないと土台が作れない馬鹿もいるな。

「デザパタは最低限のエチケットです」には賛成。

>>249
他の頭が良い人が作ってくれた土台だ。　それを使うことを恥には思わない。

パターンは設計の再利用だ。　むずかしくかんがえるなよ。

>>247みたいな、「会話と語彙の基礎」をいちいち説明してやらないと
理解できないとは、やっぱりこの業界ってカタワがおおいんだなあ。
藻前ら、技術者同士のコミュニケーションどうやっているんだよ？
もしかして、そういうことはしない、ﾋｷｰですか？

なんか、パターンに名前を付けるのがいいかどうかっていう話、
もうどうでもよくない？答えなんてでないだろうよ。
それよりも、>>198の

>ほとんどは、自分が名前も知らずに使ってるものだった。
>一部は経験から、クラス関係が複雑過ぎ、可読性があまりに低い
>ため、意識的に避けるべきクラスの使い方だった。

これが具体的に何なのか、どこが良くないのか話し合った方が
プログラマー的には有益だと思うんだが。

よーーーし、次はサイドから中に入れる奴いってみよう。

>>253
ソフトウェアパターンの第一のメリットは開発者に共通の「用語（ボキャブラリ）」を提供できること。
ソフトウェアパターンの最大の価値は、個々のパターンに「名前」がついていること。

ピッチャーが
「次は速球と同じスピードのボールでありながら、プレート付近でわずかに変化するボールを投げるよ」

というより
「次はカットファストボール投げるよ」

というように、その設計、概念を端的に表せる名前を付けてあげたほうがよいと思うのだが

そういうことではない？

>>256
そだね。デザパタはそれにつきるよ。

>>256
そーです。
でもって、実践ではカットファストボールをどのように使用して
バッターを仕留めるのかが重要なのに、カットファストボール自体
の投げ方を再発明することを重要視する馬鹿がいるという話です。

もちろん、よりよいカットファストボールの投げ方はあるかもしれな
いけど、既存の投げ方を知らないで0から改良型を開発するのは、多く
の場合、単なる無駄。

センタリングの例は、「複数の選手間のボールのやり取り」の話。
これは「複数のクラス感のメッセージのやり取り」の定法...デザインパターンと似てる。

変化球に名前を付けることは、
「何度も出てくる処理を、関数で表現する」ってことと似てる気がする。

# メタファの質に付いて語っても意味は無いと思うけど
# とりあえず思い付いたから...書いてみた。

>>258
そしてそのバカがスーパーグレートカットファストボールを作っちゃったりする。

結局、全部のメソッドをパブリックにしちゃって、やたら滅多ら
継承したがるレベルの輩(実は少なくない)にChain of Responsibility
を教えるほど怖いものはないな。

ＳＡＸのＡＰＩの規格を作る人には、デザパタ知ってても損はしないだ
ろうな。もちろん知らなくても十分出来るけど。関係ないが、個人的に
ＳＡＸを抽象クラスを使った継承を用いるデザインにしたのは間違い
だと思う。

カーブだのシュートだのフォークだのの投げ方は、
素直に人に教わった方が速い。
誰もが大リーグボールを発明できるわけではない。

クラスの作りの本質を学ぶのがオブジェクト指向では最も大事。

デザパタとは全く関係ないな。

ただし、アルゴリズムを学ぶことによってプログラミングの
本質を磨くことができる。

必ずしもネーミングの是非だけが問題ではない罠。

>>261
ベテランが空いた時間にそれをやるのは、役割上かまわないと思うけど、
経験知識の足りない奴がそれをやるのは、単なる時間の無駄。
サラリーマンが顧客向けシステムを作るという本当の目的を忘れてそん
なことに没頭しているのは、背任。

工夫する奴はどんな環境に置かれても工夫する。デザパタに出会ったからって
創造性が阻害されるものでもない。「へ〜そんなやり方あるんだ〜」で終わり。

俺、シングルトンを知らずに、インスタンスの数を２つまで
しか作れないクラス作ったけど、それって発明になるのかな。

ダブルトンでも命名させてもらおうかな。

でも３つにしたらトリブルトンになるし、きりがないからいいや。
static変数を使って、インスタンス数を制限するで十分だな、俺的に。
関係ないが、ｊａｖａのstatic{}をコンストラクタっぽく使った
クラス単位の初期化メソッドは最近便利でよく使ってる。パタン名
は知らないが、あれは便利なテクニックだな。

>>267
1- ?????????????????????????????
2- ???????????????????????????
3- GoF????????????
4- ????????????????????????????????
5- Java?static{} ????????????
6- ???(      )

???????????????

>>267
static領域を使って、インスタンス個数を有限個に制限するのは
すべてSingletonパターンの派生といえる。つうかGoFバイブルにも
書いてある。みんなやってることということだな。

スタティックイニシャライザは、テクニックでもなんでもないだろ。
単なるJava言語仕様の一部。

化けた...鬱

＞創造性が阻害されるものでもない。「へ〜そんなやり方あるんだ〜」で終わり。

結局、こんなの命名されなくたって知ってるってのと、複雑すぎて避けたい
ってのと両極端なんじゃない？かゆいところに届いてるのが少ないって
やつ。

どんどん発展していけば、デザパタの中でも優先度、お勧め度などの
ジャンル分けがきれいにされて、使えるものになるけど、今では
誰でもお勧めなもんではないわな。

ＳＡＸをの設計を否定している方がいるが、他にどういう設計ならよかったのだ？

>>269

で結局、君はデザパタ肯定してんの？

否定してるように聞こえるが。

結局、こんなの命名されなくたって知ってるってのと、複雑すぎて避けたい
ってのと両極端なんじゃない？かゆいところに届いてるのが少ないって
やつ。

>>273
何でそういう突っ込みになるの？>>267にレスしただけ。

あなたはマニュアルを全否定するのか？
とりあえず読んでみて、便利なら使う、使いにくいなら改良する、
使えないなら捨てる。それだけだ。みんなそうだろ？違うのか？

>>271
有機本しか読んでないけど、少なくともそれには
「いつ、どれを使うべきか」に関する直感的な説明があった。
そゆのでは不足なのかな。

例えば、「解決すべき問題」から、自動的に適用すべきパターンが導き出せるような
そういう公式っていうか、仕組みっていうか、そゆの必要かなぁ。

>>273

便利そうなマニュアルを読んでみる。本屋言って役に立ちそうな
本を読む。関連する全部の本を読む時間はないからな。

>>272
インターフェイスと実装の分離も、ポリモーフィズム実現の為の
継承も、「複雑だ」とぬかすアホがいるからな。会話するだけ無駄。

将棋やるんでも、いきなり定石を覚えるよりも、最初は定石知らずに
やって、ある程度打てるようになったら、徐々に自分なりに使えそうな
定石を覚えていくもの。

デザパタはある程度打てるようになった人にもろくに役に立たないって
いう程度だな。

SAXとDOMを比べたら、SAXのほうが100倍ましだろ。

>>198
> 複数クラスの関連は、デコレーターと継承しかない。オブジェクト
> 指向習得は、この二つをどうやって使い分けるかに始まる。

馬鹿じゃん。Decorator は、諸に継承使ってるじゃん。

おもいっきりOOがわかってないところもみどころだな。

>>236
> デザパタの考えが根本的に死んでることを理解するには
> まずオブジェクト指向を覚えなきゃ話にならない。

オブジェクト指向やデザイン・パターンがどうとか講釈する前に、
オブジェクト・コンポジションと Decorator パターンの違いを
理解することが先だよ。

正直な、毎度思うんだけどOOスレは、
秋葉の喫茶店で、オタが持ってる全ての
知識ﾋｹﾗｶﾃ話してんのとたいして変わらんなｗ
とにかく必死過ぎる…

>>136
> 継承は非常に便利であるが、きれいに設計されていない限り、
> 読みにくく、クラスの相関が極めて複雑になり、設計全体が
> 破綻に導く可能性のある非常に危険なものでもある。熟練者
> 以外が迷った場合は大抵継承をしないやり方を選ぶべきだ。

> Chain of Responsibilityはかっこいいが、実際に使うとなれば、
> ロジックの流れの見にくさを考えると、使わないで切り抜けられる
> なら、避けるべきロジック。単純なＩＦ文を使えばいいところに、
> わざわざ複雑なロジックを組み込むようなものだ。

プログラミング言語にもよるだろ
ところであんたの使っている言語は何？

>>236
デザインパターンを学べばオブジェクト指向も必然的に身についてくるだろうよ。
どういう言語を使っているか、どういうデザインパターンの本をよんでいるかにもよるが。

>>284
でも、それって素敵なことだと思うんだ。

パターンはこれから知ってて当然のモノになる。
というか、そうならないと困る。
ここの部分の設計はステートパターンです。と一言で説明できるのがどんなに楽か。

もし、それが有用だと思わない人は次の例を見てほしい。

「ここのデータ構造はスタックを使っていまして・・・」
「はい？　スタック？　なんですかそれは？　イチから説明してください。　」

あなたはこんな奴と仕事が出来ますか？

オブジェクト指向＝クラス使用 ではない。

クラスのない言語でも、オブジェクト指向プログラミングは書ける。

クラスを使う言語でも、オブジェクト指向に沿わないプログラムは
普通に書ける。

デザパタはクラスの相関パターンを示すもの。

デザパタ習得はオブジェクト指向習得とは全く別物である。

＞パターンはこれから知ってて当然のモノになる。

１０年以上前からあるＣ＋＋が未だに理解されずに広く普及しない
この国で、経験者でさえも有用性が二分するデザパタが近い将来
この国で必須になるのは想像しにくい。

>>289
デザインパターンの習得はオブジェクト指向ーつまりオブジェク
ト間メッセージ通信によるプログラミングーの、ありがちな応用
例ですよ。デザインパターンとオブジェクト指向を混同しちゃう
ひとって、そんなにいないと思うな。

>>289
> デザパタはクラスの相関パターンを示すもの。

ウソ。

>>136 は、「反対視する専門家」が誰なのかいまだ示していない。
>>136 の書き込みがウソであるのに、あたかも本当であるかのように権威付け
するために、反対視する専門家という架空の存在を持ち出しているに過ぎない。
反論があるなら、誰なのか示せ。

そもそも、この抽象的な「デザイン・パターン」はデザインが
絡むもの全てで存在する。ウェブ、家、ノートパソコン、缶ジュース然り。
ほとんどの場合、それらのパターンに正式な呼び名は使われている
わけでない。ついているにしても、数種の基本パターンに名前がつけられて
いるに尽きる。

たとえば、曲でも内輪で「ジミヘン的」曲みたいな呼び方をされるが、
公式にはその様な名称はなく、せいぜいロック、サンバなどの
大まかなスタイルを示すにとどまる。

ものづくりをする人には細かい「スタイル」にネーミングすることは
元来好まない。自分のイメージを好きなまま表現したい欲望が強く、
他人が名前付けしたものを組み合わせるように「考える」のを
このまないのだ。

ゆえに、この経験則の寄せ集めな「デザイン集」を学ぶことが
肌に合わないと感じる技術者が多いのは至極物づくり集団として
は自然なことなのだ。

>>289
> オブジェクト指向＝クラス使用 ではない。

はあ？　誰がそんなこといった？

>>294
馬鹿だなあ。この文脈で、デザイン・パターンは OO のデザイン・パターンの
ことだよ。

>>294
> ものづくりをする人には細かい「スタイル」にネーミングすることは
> 元来好まない。

具体的に、ものづくりをする人の何パーセントが好みませんか？
それとも、ウソですか？

>>294
> たとえば、曲でも内輪で「ジミヘン的」曲みたいな呼び方をされるが、
> 公式にはその様な名称はなく、せいぜいロック、サンバなどの
> 大まかなスタイルを示すにとどまる。

二部形式とかソナタ形式とか、厳密に名前がついていますが、それが何か？

オブジェクト指向なんてわかってるやつがやればいいじゃん。
車の運転できないやつ、したくないやつに無理に運転させる必要ない。
ただ、オブジェクト指向あやつるやつよりキャバクラの女のほうが
収入いいことは確かだ。

>>294
> ゆえに、この経験則の寄せ集めな「デザイン集」を学ぶことが
> 肌に合わないと感じる技術者が多いのは至極物づくり集団として
> は自然なことなのだ。

音楽は芸術でエンジニアリングではなく、ソフトウェアはエンジニアリングであって
芸術ではありませんが、一緒にしないこと。
なんでもごっちゃにすると、わけがわからなくなる。

# だからまあ、君にはデザイン・パターンも理解できないんだろうけど。

えっと、今更なんですが。


スレ違いです、多分。

コード進行とかを知らないギタリスト。いやだな。

>>294
音楽と工学の区別もつかないやつに、工学の OO がわかるわけがない。

うどんとソバの区別もつかないやつに、讃岐うどんと稲庭うどんの区別が
付くわけがない。

>>294
漏れも、294のような壮大な釣りのできる人間になりたいです。

>>300
ヘタに相手を馬鹿にした発言をとると、相手はよけい意固地になってしまう可能性がある。

というか、おれはデザパタを知ってるんだぞーと自慢する奴が多すぎ。
デザパタ否定者は、そいつらに反発して、こんな状況になってるのでは？

>>303
最後の喩え分かりにくいです...

>>306
蕎麦：芸術
うどん：工学
OO:讃岐うどん
非OO:稲庭うどん

なぜ294の話から、OOの話になったのかは不明。

俺はデザパタの受け売りで、複雑なクラス作りしまくる奴よりも、

シンプルかつ「動く」設計できる奴を取るな。

前者は売れない本でも書いて、自己満足に浸ってろと。

>>308
馬鹿だなあ。どんなデザイン・パターンを使ってもことが複雑になるようなときに
わざわざデザイン・パターンを使うのは、デザイン・パターンをわかっているとは
言わないんだよ。

デザイン・パターンは、使うと設計がシンプルになるときに使う。
たとえば Java のストリームとか。

>>308
漏れはデザインパターンを知ってる奴の方がシンプルなコードを書くと思うんだけどな。
>>308の言うシンプルなコードって言うのは、ポリモルフィズムを期待せず、
Switch-case や if-elseif の入り乱れたコードのことかい？

>>308
じゃあ、あなたはJavaを使えないですね

というか、最近のライブラリはほとんどつかえないですね

＞＞馬鹿だなあ。

それ余計だな。厨房レベルに下げるなよ。

>>308
> シンプルかつ「動く」設計できる奴を取るな。

デザイン・パターンを使うとうまくいくことがある。

>>308
> シンプルかつ「動く」設計できる奴を取るな。

Java のライブラリや VCL なんかはデザイン・パターンを使っているけどそうなっている。

>>308
> シンプルかつ「動く」設計できる奴を取るな。

JUnit や CppUnit なんかはデザイン・パターンを使っているけどそうなっている。
SAX もそうなっている。

つか、308が言いたかったのは
「受け売りで」の部分に集約されてると思うんだけど。
「理解できないものを使うよりは、理解できてるものを使え」
ってことじゃないか。

>>315-316
デザイン・パターンを知っている人にはシンプルになっている。

デザパタ狂信者を見てると、猫の手でも借りたく、自分の
プログラミング能力を必死に補おうとしてると、結論付け
せずにはいられないな。

がんばれよ。何やろうといいからさ。

>>136 は、「反対視する専門家」が誰なのかいまだ示していない。
>>136 の書き込みがウソであるのに、あたかも本当であるかのように権威付け
するために、反対視する専門家という架空の存在を持ち出しているに過ぎない。
反論があるなら、誰なのか示せ。

>>309 の訂正
>>308
どんなデザイン・パターンを使ってもことが複雑になるようなときに
わざわざデザイン・パターンを使うのは、デザイン・パターンをわかっているとは
言わないんだよ。

＞JUnit や CppUnit なんかはデザイン・パターンを使っているけどそうなっている。
＞SAX もそうなっている。

JUNITとかのTestUnit系の設計って動的なクラス名の引渡しの
部分なんてかなり苦し紛れが強いぞ。決して理想型ではないわな、
あの設計は。

ＳＡＸにしろ、まだ発展途上でこれからも仕様がどんどん変わって
行くだろうから、あれが完成型のごとく議論するのは危険だわな。

>>319
なんにせよ、狂信者ってのはまともには見えんよ。

>>322
SAX が完成形なんて君が言ってるんじゃないの。
だって、xpath があるし。

>>320
必死だな。

>>322
> TestUnit系の設計って動的なクラス名の引渡し

それは JUnit や DUnit のようなリフレクションがある言語の実装の問題でしょ。

>>322
> TestUnit系の設計って動的なクラス名の引渡し

CppUnit や小河童ではそんなことしてましぇーん。

非デザパタ狂信者を見てると、自分の勉強不足を棚に上げて
他の人が前に進もうとするのを、必死になってくい止めようとしてると
結論付けせずにはいられないな。

がんばれよ。何やろうといいからさ。

Q. 「あたかも」を使って簡単な文を作りなさい。

A. 冷蔵庫に牛乳があたかもしれない。

>>326
動的なクラス名の引き渡し...
prototypeパターンとかは駄目なの？

結論：デザパタ知ってて悪いことはない。

狂信的なだけならいい。押しつけてくるから始末におえない。
OO、デザパタ、Delphi どのカテゴリにもいる。

>>330
テスト・ケースがどんなクラス名で作られるのか、フレームワークを作った人は
知らないから、無理でしょ。

デザパタ狂信者を見てると、自分の能力不足を棚に上げて
他の人が賢く前に進もうとするのを、必死になってくい邪魔しようとしてると
結論付けせずにはいられないな。

がんばれよ。何やろうといいからさ。

>333
???????????????????????????

まあ、とりあえずデザパタの勉強はしとけと　損はしないよ

また化けた！safariめぇっ！

>>333
?????...??????????????????????????????
???????????????????????????

死のう...

http://yahooo.s2.x-beat.com/linkvp/linkvp.html

マカーよ、Cocomonarを使え。

（　´∀｀）/＜ 先生！！こんなのを見つけました。
http://www.freeweb2.kakiko.com/tama/moe/hankaku07.html
http://freeweb2.kakiko.com/tama/moe/hankaku08.html
http://www.freeweb2.kakiko.com/tama/moe/hankaku10.html
http://freeweb2.kakiko.com/tama/moe/hankaku09.html
http://www.freeweb2.kakiko.com/tama/moe/hankaku06.html
http://freeweb2.kakiko.com/tama/moe/hankaku05.html
http://www.freeweb2.kakiko.com/tama/moe/hankaku01.html
http://freeweb2.kakiko.com/tama/moe/hankaku02.html
http://www.freeweb2.kakiko.com/tama/moe/hankaku03.html
http://freeweb2.kakiko.com/tama/moe/hankaku04.html

デザパタは似たようなものをたくさん作ってきた奴じゃないと、
そのありがたみを知るのは難しい。

>>343
漏れはstate パターンを見て、デザインパターンの威力(?)を知ったよ。

>334
逆じゃねぇ？
『技』の勉強／研究している人を否定して、（他人の）技術力を向上するチャンスを
ツブしているようにしか見えない。

「オレはもうそんなこと知っているからデザパタなんていらねぇ。苦労して身につけたん
　だから、他人に簡単に身につけられるとメシの種がなくなっちまう」
てか？

>>329
あかん、なんかつぼにはまってﾜﾛてまった

>>345
だから、デザパタは土台だって言ってるだろ。デザパタ知ったぐらいで天井に
届いたって思い込むのはあわてんぼさん。

>>346
>>329はデザパタの肝である再利用をうまく使いこなしたってわけだ。

>>347
>>345は天井に届いたように誤解してる感じには見えないだろ。

>>349
デザパタだけじゃあメシの種になりえないわな。

世の中には二種類いるんだ。
知識を身に付ければつけるほど、発想がより自由になっていく人。
知識を身に付ければつけるほど、発想がより固定化していく人。
デザイン・パターンは前者のような人のためにある。

>>351
胆略的すぎ。お前のIQを良く表している。

>>352
胆略ってなに？
キモの戦略？

胆の戦略は liver strategy だよ。

じゃあ Strategy パターンか。

レバパタだな。

class AbstractLiver { }; // 抽象レバークラス
class ConcreteLiver1 : public AbstractLiver { }; // 具象レバーその 1
class ConcreteLiver2 : public AbstractLiver { }; // 具象レバーその 2
class ConcreteLiver3 : public AbstractLiver { }; // 具象レバーその 3

>>351
何となく分かる。
それで「あるべき論」ばかり言い出して、あちこちに矛盾をだしまくり、
設計を破綻させる「あるべき論者」。

とりあえず、if とか switch を”無様”と思うか、思わないかで、
デザインパターンの評価も異なるだろうな。

>>357
おお、胆略的すぎ。

>>358
つまり、どういうこと？
「あるべき論」というのは？

>>361
「あるくべき」の typo だろ。

世の中には二種類いるんだ。
「あれを勉強すると発想が固まる」となにも勉強しない人。
「あれを勉強すると発想が固まる」のが本当か、「あれ」を勉強してみる人。

後者はさらに二種類の結果を生むんだ。

発想が固まるどころかより自由になれるじゃん。
思ったとおり発想が固まった。もう俺は一生進歩できなくなってしまった。

> 「あれを勉強すると発想が固まる」となにも勉強しない人。

これは二種類に分かれるな。

結局進歩のない人。
自分で考えてデザインパターンと同じ物を編み出す（再発明する）鳩。

鳩じゃねー、人だ。ごめん。

>>364
同じになるといいんだけどね。
普通は、劣るよね。

既存のデザインパターンを編み出せる能力があるなら、さっさと既存の
パターンを覚えて、さらにもっと有用な誰も発明していないパターンを
発明してくれよ。

発明したら、cppll か結城さんの wiki に書き込んどくれ。

>>208
has-a を Decorator パターンで表現するような初心者には無理ぽ。

test

デザパタは初心者でも上級者と勘違いさせちゃう危険な物って
のがよくわかるな、このスレッドから。

いいからオブジェクト指向覚えろって。笑

上級者-初心者っていうカテゴライズもどうかと思うけどな。
# すれ違い下げ

次スレは
「貴様ら！オブジェクト指向を教われ！！第3章」だな

いろいろ説教たれるよりコードで見せたほうが速いと思います

>>371
デザパタが危険なんじゃなくて、無知が危険なの。

>>376
無知をベースに批判するやつも、かなり危険だよな。
己の理解している範囲=その世界の全てという馬鹿は、数ある馬鹿の
なかでも、もっとも有害な馬鹿だと思う。
大量のリソースを無意味に消費して全く価値のないものを巻き散ら
かすのは、こういうヤツラ。うちの重役とか。

>>377
>己の理解している範囲=その世界の全てという馬鹿は、数ある馬鹿のなかでも、もっとも有害な馬鹿だと思う。

デザパタを理解もしないのにデザパタを批判するやつのことでつね

アンティークなジェラートを食べるアンジェラだとはこのことだ。

>>379
灰？

ユースケースっつーか、
あのアクターとか出てくるやつがようわからん

あればっかしは文章箇条書きで書いた方が
わかりやすいと思うんだが・・・

あれか？ グローバルっつーかワールドワイドに
英語で書いとけってことか？

ユースケサンタマリア

>381

170 名前 : OOﾓﾅｰ Mail : 投稿日 : 03/03/29 00:21

>>167
ユースケースってのは要件分析だからまずは洗い出しから始まるわけよ。
で、洗い出した後は、適当な基準で分類すればOK。
適当なっていうのは、分類にはいろんな視点が考えられるから、
いつもこれが正しいってのがないんだよね。
独立したサブシステムが見えている場合は、それを基準に分類しても
問題ないと思う。
それよりも、ユーザの要求をユースケースとして可能な限り
全て抽出できているかどうかのほうがはるかに重要。
ここで漏れがあるとハッキリ言ってかなり痛いよ。
また、ここでの分類がそのままチームの作業分担に直結していく
可能性があるので、あんまりいい加減でも困るし、
逆にもう設計に入ってしまったかのような細かさでも困る。
あくまでも、開発しようとしている対象がどういうものなのかを
把握する手段であり、図を書くことが目的じゃないからね。
実際、ユースケース図ってのは、字で書く内容の方が多いだろ。

171 名前 : 仕様書無しさん Mail : 投稿日 : 03/03/29 01:00

ユースケースによる分析は、ユースケースごとのシナリオが主な成果物です。
ユースケース図は、複数のユースケースを俯瞰するための方法に過ぎません。

機能要件の一覧表を作るのもいいんだけど、ユースケース図の方が優れるのは、
　・アクターとユースケースの関連付けが簡単に分かる
　・ユースケース間の関係が簡単に分かる
　・システムの実現範囲をが簡単に分かる
ことです。

デザパタは役に立たないってことで決定だな。
結局、みんなに普及しなきゃ意味無いしね。
肯定派と反対派とどっこいどっこいだろ？
さらにデザパタ覚えた人間ですらいらねぇって考えもあるし
パターンを覚えるのも覚えさせるのも時間がかかるし
ちなみに俺のいる職場ではデザパタ普及率0。
俺しかGoF本読んだ奴いないからデザパタ使えないし。笑
はじめの広まるスピードとお手軽さが流行る条件になっているようなので
もうデザパタはものがどうであれ終了だろ。

英熟語は役に立たないってことで決定だな。
結局、みんなに普及しなきゃ意味無いしね。
肯定派と反対派とどっこいどっこいだろ？
さらに英熟語覚えた人間ですらいらねぇって考えもあるし
英熟語を覚えるのも覚えさせるのも時間がかかるし
ちなみに俺のいる職場では英熟語普及率0。
俺しか英熟語本読んだ奴いないから英熟語使えないし。笑
はじめの広まるスピードとお手軽さが流行る条件になっているようなので
もう英熟語はものがどうであれ終了だろ。

>>385
ﾜﾗﾀ。バカしかいない職場にいるバカの一人が勘違いしているだけ
ということですな。

英熟語は充分普及してるし、みんな価値を認めている。
小学生ですら英会話教室に通う時代だ。
デザパタと英会話に、何の共通点があるんだ？
これが、自分が使えると思ってる、勘違い馬鹿ってやつか？

うちの会社は syslog を逐一プリンタで印刷しているが、それと同じぐらい馬鹿だ。

デザパタは充分普及してるし、みんな価値を認めている。
ＣＯＢＯＬＥＲですらＪａｖａ教室に通う時代だ。

判った。
デザパタでオセロ書いてみろ。
話はそれからだ。

>>390
お前はオセロ以外にネタが無いのか

熟練したプログラマなら、ある業務のプログラムを設計するとなったとき、
その業務に適した、その業務固有のアーキテクチャパターンを、
自らの力で生み出せるものだ。
それらは大抵の場合、いくつものパターンが複合されて出来ている。

デザインパターンを覚えたての初心者プログラマの場合、
このパターンをどこかに適用できないかとか、
この部分にどれかのパターンが適用できないかとか、
不自然な設計手法を取るため、設計がいびつで柔軟性がない。

初心者にとってデザインパターンは、目も曇らせる元になり、
上級者にとっては元々不要なものだ。

>>329
アーキテクチャとデザイン・パターンの区別もつかないやつの言うことなんて
説得力がない。

>>392
恣意的に、「デザインパターンを知らない熟練技術者」と「デザインパターンを
勉強したばかりの初心者」と対比させている点で、「デザインパターンは不要」
といういんちきな結果を主張しているだけです。

>>392
「デザインパターンを知っている熟練技術者」と「デザインパターンを知らない
初心者」の場合でも、どうなるか比較しないとだめでしょ。

>>392
それなら、「デザインパターンを知っている熟練技術者」と「デザインパターンを知らない熟練技術者」と
「デザインパターンを知っている初心者」と「デザインパターンを知っている初心者」と
すべての場合を検討する必要がありますね。

まちがえた。

>>392 は、
「デザインパターンを知っている熟練技術者」と「デザインパターンを知らない熟練技術者」と
「デザインパターンを知っている初心者」と「デザインパターンを知らない初心者」の
すべての組み合わせで検討しないと意味がないですね。

結論:
>>392 はハッタリということですね。

デザパタを理解するのは、どんな馬鹿でも出来るけど、
経験のないプログラマが、デザパタに捕らわれないようになるまでには、
ある程度の技術的蓄積が必要。

>>399
一昔前ならそうだけど
今はデザインパターンを理解できないほどのバカも
この業界に入ってくるんだよね

>>399
いや、3 歳児の知能の人には理解できない。

そもそも世の中には初心者と熟練技術者しかいないのか？デザパタが必要なのはその中間だろうが。

デザパタを覚える奴は痛い奴ばっかりだな。
今月のCマガのOOの記事でグローバル変数は認めるは、神クラス作っちゃうは、ヒデエ設計だったな。
しかもくだらないいいわけしてるし。
デザパタでなんとかならなかったんですか？笑
神クラスは何のパターンですか？プ

Cマガ読んでないんだけど、ここで言う神クラスの定義ってなに？
・万能クラス
・独裁者クラス

・創物主クラス。ファクトリ？ビルダ？
・救世主クラス。あらゆる罪を許し、人を愛する...。
・エロ画像や動画をしかるべき板にうpするクラス。

>>392
憶えたものを無理矢理使おうとしなければいいだけの話。
何にでも言えることだが、活かせる場で使う事が大切。
本質を理解していれば、活かし方もわかるはず。

＞憶えたものを無理矢理使おうとしなければいいだけの話。

そんなこと初心者に期待して教えられると思う時点で間違い。
初心者は何でも覚えたものを使おうとする。
自分を基準に考えちゃいけない。

>>407
>初心者は何でも覚えたものを使おうとする。

ん？それがわかってるなら、そう一言言ってやりなさい。
それだけでも違んだよ。

覚えたてのものを使ってみたくなるのは
楽しいんだからしょうがない。
誰もが通ってる道じゃないか。
さりげなくフォローしてあげりゃいいのよ。

>>392の想定している初心者って言うのは、
「デザインパターンをどこに適用すべきかが分からないときは、
　無理やりに、不適切な部分に適用しちゃうけど、
　デザインパターンを使用しなければまともに設計のできる人間」
ですか？

>>403
>>404
俺も神クラスの定義が気になる
ネットで独学って生活が続いてる趣味プログラマだけど
たまには勉強のためにCマガ買ってこようかな

>>411
立ち読みで十分。

デザインパターンってリファクタリングで威力を発揮するもの
だと思ってたけど、違うんかね。設計段階から無理やり適用
せんでも、要求仕様に従って順当に設計すればいいんでは。
で、拡張なり改良なりの段になって、設計的に変な箇所だけ
洗い出して、パターンを適用したら効率化できるか検討する
だけでしょ。効率化しないならパターン使う必要ないし。

それでもパターンというものが存在するのは、過去の経験の
集大成的な経験則によって効率化、汎用化が可能だからで
あると思う。ソフトウェア設計における法則性とでも言うべきか。

>>383
＞それよりも、ユーザの要求をユースケースとして可能な限り
＞全て抽出できているかどうかのほうがはるかに重要。
＞ここで漏れがあるとハッキリ言ってかなり痛いよ。
同意。
ユースケースありきで進めて難しいのは、やはりケースの抽出が適切でなかったとき。
それに気が付かず、「そんな機能はユースケースに無いからいらない！」と機能の実装をやめさせ、
挙句、やっぱり必要だったというパターンはしばしばある。
実装者がユースケースの不備に気が付いているにも関わらず、
上位工程の人間が頭でっかちでそれを受け入れない。
これはかなり困る。

パターン使って、拡張性、メンテ性があがるとは考えにくいね。
流れ追いにくいし。シンプルな、has-aが一番拡張性、メンテ性が
しやすい。

神クラスってのは、全てのメンバー、メソッドがpublic。
しかも、サブクラスで定義すべきメンバー、メソッド満載の超スーパークラス。
ステップ数は数千〜1万以上。これさえあれば、何もいらない。
そんな感じ？

神クラスは具体的にはグローバルインスタンスホルダーかな？
面倒臭くなって設計を投げるとできるクラス。
まあ、こんなところで破綻してるぐらいだからオブジェクト指向をわかってないかな。

> グローバルインスタンスホルダー
あー、俺、やっちゃってるなあ。
どうしたらいいのかわからんのよね。
Singletonでやるべきなのか？

>>416
それ、神っつーよりも奴隷。

シングルトンはやらないほうがいい。
しっかり設計しろ。
さぼってるだけだ。
ありゃ駄目なパターンだ。
グローバル変数と何もかわらない。

>>414
方法論ばかりこだわって内容が伴ってないアリガチな感じ。
案外ユースケースに不備が多くても、風通しの良いプロジェクトなら
致命的な問題にはならないんだが。

>420
それは、おまえがSingletonをstaticで実装しているからだろ？w
他のパターンと組み合わせてみろよ。

>>288
> 「ここのデータ構造はスタックを使っていまして・・・」
> 「はい？　スタック？　なんですかそれは？　イチから説明してください。　」
> あなたはこんな奴と仕事が出来ますか？
できない。できないといえばそれは確かにそう言える。
大学で情報学を専攻していた奴ならそれくらいはしっているはずだが。

>>420
クラスをパッケージに格納して特定のパッケージ内でしかアクセスできないようにしろ。

>>422
違う馬鹿トンママヌケ
論点がズレテンダヨ。
引数で渡されたわけでもねーのにいきなりでてくんな馬鹿。
まだわかんねーのか？
シングルトンが関わったクラスはすべてシングルトンの根が生えて単体で動かなくなるじゃねーか。
引数で必要な情報だけよこしゃいいんだよ。
てめーの作ったクラスは引数に必要な情報突っ込んできちんと順番道理に初期化してやってもまだうごかねぇ。
別途でどこかにシングルトンさんが必要になるわけだが、さてマニュアルにはどうかくの？
って感じでしけてんだよお前のクラスはYo！

>>425
馬鹿はお前だ。お前の論理を突き詰めていくと、
メソッドの中ではオブジェクト一つ作れない話になるじゃねーか。

雑誌にﾃﾞｻﾞﾊﾟﾀwを適用した良いサンプルコードが
載ったことが一度でもあるのかと小一時間（ｒｙ

ホントはだれもつかっちゃいない罠。
みーんなﾊﾞｰﾁｬ(脳内）。だいたいjava自体が
ﾊﾞｰﾁｬﾙだしなw
もまいら！ﾊﾟﾀｰﾝをうまく適用できてるｵｰﾌﾟﾝｿｰｽｺｰﾄﾞﾌﾟﾛｼﾞｪｸﾄを
おしてくれませんか？(c++で）

http://homepage.mac.com/ayaya16/

>>427
そういや、まとまった成果物をみたことがないな。まあ、厨房のおいらにゃ
もともと縁の無い世界か・・・

>>427
なぜC++限定？

じゃあ、これからこのスレで作ろう

>>431
マジで応援する。是非見てみたい。ガンガレ！

で、お題はオセロとか言い出したらコロスよ

みんなが微妙に勘違いしつつ取り入れているのがデザパタ。

最近のデザパタはJavaを普及させるお手伝いと化しているな。

むしろ、みんな好き勝手に作っているということが、
デザパタという枠組みがあることで明るみにでたんだと思う。

>>425
馬鹿にも分かるように説明してやるよ。

public class Foo { public void foo() { Bar o1 = new Bar(); } }

public class Foo { public void foo() { Bar o2 = Bar.getSingleton(); } }

クラスFooから見た場合、o1とo2の本質的な違いはないだろう。
どちらも自動変数で、Fooが参照を保持するわけではない。
そもそも、SingletonはBarのみが参照を保持することが前提だから、
Bar内でインスタンスの解放タイミングだけを気をつければ、
後はどのクラスも参照の有無を気にしなくてもいい。
参照の管理をクラス内に限定できるというメリットがあるわけだ。

おまえはFooのなかでBarを使うな、つまりクラスライブラリを
使うなといってるのと同じ。

もともと、GoF本ってC++の例しか載ってなかったんじゃないか。

JavaとC++ではどっちがデザパタに馴染みやすいんだろう？
みなさまのご意見お待ちしています。

>>437
馬鹿が馬鹿にも分かるように説明するのは
卵が先か鶏が先かと同じく相互参照になり
不可能だという好例

>>439
ネットとか検索してるとコード例のほとんどがJavaだね。日本だけか？

>>440
まあ、そういうことだがw

>>437, >>440
まあまあ、少し春風にでもあたってきなされ。

>>438
Smalltalkも乗ってたろ

>>444
ほんのちょっとだけな
ちなみに最新版だと、Javaのソースも(CD-ROMのみだが)付いてくる。

java馬鹿がいきがってｺｰﾄﾞ出してんじゃねーよ。
価値ない。

考えてみれば>>425がJava厨なのが原因か。
Javaには、コンストラクタ、staticメソッド、インスタンスメソッドの
三つがあるが、Smalltalkにはクラスメソッド、インスタンスメソッド
だけだしな。SmalltalkならSingletonも違和感ないだろう。

Javaを使えない自分にとっては寂しい限りだ。かといってJavaには魅力を感じないし。

いろんな言語を知っておくのはよいことだよ？

段々オブジェクト指向が分かってきた。

>>449
分かっちゃいるけど、なんかこうワクワク感がないって言うか・・・

>>438-439
オブジェクト指向をうたっている言語なら、ほとんどどの言語でも大丈夫。
サンプルの C++ と、自分の作っている言語と両方できれば、難なく読み替えできる。

>>451
Rubyとかやってみたら？

>>453
いいね。面倒なコンパイルも必要ないし。

知ることは、非常にためになる。使うには価値無い。
javaを知ったところであなたを雇ってくれるまともな会社は無い。
上級者だろうが初級者だろうが、所詮クラスライブラリ
やAPIを利用するだけ。
ﾃﾞｻﾞﾊﾟﾀしってるからってあなたを雇ってくれるまともな会社は無い。
オブジェクト指向知ってるからってあなたを(ry

エンジニアとしてなにが必要か考えたほうがいい。
技術職だぞ。自分を医者だと思って考えて見ろ。

>>437
はぁ？そんなの何処でどうして必要なの？
俺の設計の基本として必要なものは必要なときに用意したり渡せばいいと考えてるから
そのいつまでも用がないのにアクセスの権限を与えてることが理解できない。
関数で引数として必要なときに渡せばいいように設計しなおしてくれない？
それかメンバ変数でいいならそれでいいけど。
外のオブシェクトになるなら引数でしっかり渡してくれたほうがソースを読むときわかりやすいよ。
なんでそんなトリッキーなくみかたするの？
引数で渡しにくい設計にもってっちゃった時点で駄目だかんね。

>>455
うーん・・・・スタミナ？

>>455
ｽﾚﾁｶﾞｲｶｺﾜﾙｲ

>420
使い途を考えなされ。
大域領域に置くSingletonだったら、グローバルでアクセスされる
リソースに限定すればよろし。
main関数の引数とか、アプリの設定ファイルとか……

ローカル／スコープ内のみのSingletonにするっちゅう手もあるし。

あと、オブジェクトだっちゅうことも重要だねぇ
グローバル変数だと違法な値に変更しようとするのを防ぐ手段が無いけど、
Singletonだとなんとかブロックできるからねぇ

>>456
>そんなの何処でどうして必要なの？
昔、かあちゃんにこんな感じで怒られたことがある。

そもそも、すべてをクラスとして表現するという
時点でもう破綻してるわけだ。
たとえばjavaとか。その他ではjavaとか。
あと、javaとか。
んで、ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝなんかの知恵いれちゃうと
なるほど！とかって勘違いするわけだ。
多少、頭の柔らかい奴ほど。

クラス原理主義の破綻をごまかす為の
アイデア的ハックだということにいいかげん気づけ。

>>456
> はぁ？そんなの何処でどうして必要なの？
Foo を呼び出すクラスが Bar を知らなくていい場合、
Foo を呼び出すクラスが Bar を知らなくてすむ。

>>461
君の脳が破綻している。

>>456
おまい、構造化で引数渡しがしみ込んでる香具師だろ？
それともクラスがオブジェクトじゃないと思っている香具師？
Singletonでは、クラスオブジェクトのクラス変数が同じクラスの
インスタンスなだけなんだが？
いつでもインスタンスにアクセスできるのに、わざわざ引数私香代。
じゃあ、どこからでも見れるのでクラスオブジェクトは使えないね？w
インスタンスも作れないね？ww

>>461
OOPL の文法ってのは、デザイン・パターンをやれるようにできるために、ああなっている。

http://homepage.mac.com/hitomi18/

>>465

嘘だろ。オブジェクト指向的なプログラミング
に対応してるだけだ。
ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝは後発なはず。

う〜ん・・・乗り遅れちゃった奴が約1名。ご愁傷様。

>>467
デザイン・パターンの名前がついたのは後だけど、ああいうことはやられていた。
ああいうことをやるために OOPL ができた。

C++ができる前にGoFﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝは
できてたってことか！？
ｿｰｽ出せｿｰｽ！ｗ
変な言語の話とかだすなよ。

>>470
GoF本嫁。

４８手ができる前に、全ての体位はやり尽くされていたのと同じ。

>それぞれのパターンは、私達の身の回りで何回も起きる問題
>およびそれらの問題に対する解決ポイントを記述している。

>パターンとは、優れたソフトウェア成果物
>（アーキテクチャ、分析、設計、実装、プロセスなど） を明文化したもの。

>>470
結局おまえは何が言いたいんだ？

言語ｽﾍﾟｯｸ決まる前にあったなら
ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝを適用した素敵な
ｺｰﾄﾞがごろごろ転がっていなきゃおかしいだろうよ。
どこにあるっていうんだよ！（java以外で）

>>470
俺の知らない所で明文化しやがってこんちくしょう！ってことか？

>>475
もしかして、見せて下さいお願いしますってことか？

>>475
一子相伝なんだよ。

>>475
アラン・ケイおじさんの研究所に行けば？

最近の若い人は、デザイン・パターンが新しいもんやと思ってはるんですな。

>>475
コピペしたいのか？

>>477
あるのか？

>>481
コピペするさ。ペタペタペッタンコしまくるさ。

>>482
Model-View-Controllerパターンを知らないのか？

多分にほんの少しの誤解だと思うんだ。
言語ができる前にデザインパターンはなかった。
言語ができてデザインパターンを実現できるようになった。
パターンに名前が付いたのはずっと後。
みんな日本語が不自由なだけ。

>>483
パターンはコピペできるようなものじゃねぇ

Cマガの特集はすごかったな。
オブジェクト思考でもコードの再利用は簡単ではないってのは
いいとして、コードの再利用ばかりしてたらソフトウエアの
進化が止まってしまうから、再利用しなくてもいいのだって
結論になってしまうのはびっくりした。

>>483
　　　　　　　,-､/＾＾､,-､
　 　　　　/｀　/ 　　ヽ　´ヽ
　　　　<´￣｀　　　　　´￣｀>
　 　　く 　　　認　　厨 　 　 ,>
　 　　< ＼.. 　 　　　　　 ／ >
　 　 　く /　　定　　房 　ヽ ,>
　 　　　〈__ 　 　 人 　　　__〉
　　　　　　ヽ__,.<_,､_ゝ､_ノ

>>484
てめーはsmalltalkプログラマなんだな？あ？
javaとか言うなよ。
お前はしょぼいWEBｼｽﾃﾑでも作ってりゃいいんだよ。

>>488
http://www.4gamer.net/specials/gdc24/cry.html

まあ見ておけ

Cマガも厨房認定してやってくれw


26 名前 : 名無し＠沢村 Mail : 投稿日 : 03/04/21 21:58

>>25
Cマガ５月号「オブジェクト指向２０の疑問」のQ5だが、何じゃこりゃ！？
「オブジェクト志向と書いたら叱られました。本当にこれではダメなのでしょうか？」
…これは完全にCマガ編集部のネタだね。

28 名前 : 名無し＠沢村 Mail : 投稿日 : 03/04/21 22:01

また「オブジェクト指向２０の疑問」のQ６
「オブジェクト指向プログラマの集会でC++をやってますといったら白い目で見られました。私は何か悪いことをしたのでしょうか？」
…これもジサクジエーン。

>>489
　（´Д｀;）ヾ　ﾄﾞｳﾓｽﾐﾏｾﾝ
　　　∨）　
　　　（（　

>>490
ドイツの職人芸がどうしたの？

>>487
そりゃあすばらしい（ｗ

>>494
つれた

みんな一つの言語しか使えないと思っている痛い香具師がいる
スレはここですか？

お題はシューティングね
みんながんばって

>>495
つれたｷﾀｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰ！

すげえなCマガ。
編集者もある程度はチェックしろよ

500！

>>500
ﾌﾟ(ｹﾞﾗ嘲笑下木原

>>487
いまはコードの再利用は重要ではないね。

設計は YAGNI で ad hoc に、経験を再利用。

>>502
Cマガ編集者ｷﾀｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰ！

デザイン・パターンで言う「再利用」は、コードではなくパターンの再利用のこと。

　　　　　 ＿＿○＿○＿＿
　　　　　 |　.＿＿＿　..|　　|
　　　　　 |　.|７|　|　| 　|　　|
　　　∧ ∧ .|　|７|７| 　|　　|
　 　 (　　,,) .|　|　|　| 　|　　|
　　　/　　つ￣￣￣　 |　..::|
　〜(＿＿).　°°°　|　::::|
　　 |＿＿| ￣￣￣￣ |..::::::|
　　　　||　　　 　 　 　 .|::::::::|
　　　　|| ￣￣￣￣￣￣￣￣
　　　￣￣　　|＼
　　　　　／￣　　￣￣￣￣￣￣￣￣
　　　　　|　　きてねぇよ

ところでいつからここはデザパタのスレになったんだ？

>>499
いまだにコードの再利用を信奉しているのか。

再利用できるコードっていうのは、いまは使わないかもしれない
機能を盛り込んでいるということ。
そんなコードを作るのはコストがかかる。
明日必要かもしれない機能を、今日実装するな。
今日必要な機能を、今日実装せよ。
というのがいまの常識だよ。

どうせ要らないって。 < 明日必要かもしれない機能

>>490

こりゃすげえな。
これがjava製だったら他職種に転職してもいい。

>>508

わかったから、以下の点にコメントしろよ。

「コードの再利用ばかりしてたらソフトウエアの進化が止まってしまう」

>>511
お前がコピペ厨だってことは良く分かったからもう寝ろ。

じゃ、寝るか。満足。

>>511
知らねーよ。

>>511
C マガに電話して聞けよ。

>>511
退化した頭で考えた素晴らしい結論なんじゃないの。

>>515
実は俺電話でクレーム入れた。雑誌代返せって。
そしたら、定説だっていわれたYO

>>517
古いネタやなぁ。

今日も痛い議論を繰り返してるな。
新鮮味もリアリティーもありゃしない、ヲタクの繰り言。
1〜2年前に2ちゃんで済ました議論ばっか。(当然2ちゃんの外ではもっと前に終わってる議論だけど)

結局こーゆー掲示板って、大多数の人は入れ替わるけど、極小数の粘着者が前スレの粗悪コピー作り続けるからあたかも盛り上がってるように見えるわけなのね。枯木も花の賑わい

>>517
消費者センターに電話すべし。

>>427
Java コアAPIの殆どはデザインパターンのかたまりなんだよなー。
よくJava Documentをみてみなさいってこった

>>519
ﾖｶｯﾀﾅ

>>519
そういわずに、まずはSingletonで一席ぶってくれ

>>519
君はあれか、それ言わんと寝れんのか。

>>519
気取ってろ。おまえに進化は無い。

>>519
それを知りながら棲み続けて、わかったような事を語るのも

　か　な　り　痛々しいぞ（ｗ

2分で5匹か・・・

なるほど、2年たってデザインパターンを使えない使えないといつまでも叫んでいるわけか。

デザインパターン、アーキテクチャーパターンを否定する厨房君は
まあ本当に、いつまでたっても、何歳になっても、時代遅れなジジイどもだなあ。

デザインパターンを否定する厨房君は
eXtreme Programmingという言葉もRational Unified Processという言葉も
Unified Modelling Language という言葉も手法も手段も知らないんだろーなー。
かわいそうに。

ひょっとして未だにウォーターフォールモデルなんかやってるの? ﾌﾟﾌﾟ恥ずかしい(w

>>527
2分？5匹？　数も数えられな（略

はい6匹目。

釣りやってないで、有用なコメントの一つも残してくれ。

>>519はコピペだよ。名前欄以外はね・・・

>>532
君はあれか、それ言わんと寝れんのか。

> eXtreme Programmingという言葉もRational Unified Processという言葉も
> Unified Modelling Language という言葉も手法も手段も知らないんだろーなー。

だれもつっこまなくていいのか？

>>490
すげー
なんだこりゃ
これがあれば俺にも三国無双つくれそうだ

雑魚がいっぱい釣れてる・・・。

まぁ、例のクラスとインスタンスが云々→Singletonでは云々
とかいう悲惨なフレーズを連呼しているのが、ここに常駐している粘着君だという事はわかった。

君等、毎晩こんな不毛な議論してて楽しいの?
漏れらが何もしらないうちからしこしこOOの世界を構築してきた先人と比べて、
なんかすっげーつまんない人種に見えるぞ、をまえらさー。

>>534
がんばって覚えたばかりの用語を並べてるんだから、生暖かく見てあげようよ。

Model Driven Design が抜けてるぞ(ぷ

>>536
批判ばかりしかできない君は、もっとつまらない人間だが？

それをいうならModel Driven Development(ぷ

だれか>>490みたいなのの２D版作ってよ
もちろんOOで

>>539 このスレの主張って、大体元ネタとかわかっちゃう陳腐な内容だから、つまんないの。
自らの設計なりコーディングで経験した、誰もが感じてるけど、言葉にし難い何か、
を説明できればエクセレントなんだけどね。

>>542
じゃあ、、まず君のエクセレントな経験を語ってくれないか？

>>543
エクセレントな体験などと誰も言っていないんだが。

漏れなりの体験談は、1〜2年前にネタスレの合間に散々書き散らしておいてあげたんだが、君は記憶力がないのか？

例えば、「関数型言語の部分計算のためのキャッシュを、ドメイン・スペシフィックな情報に基づいて最適化すると、オブジェクト指向と似たものになる(ような気がする)」ってのが、漏れなりのオブジェクト指向言語の機能的側面の解釈なんだけど、
これは「オブジェクト指向とは何か」という>>1の問いかけに対する答えの一つになるとは思わん会？

すべてのデザインパターンは Composite パターンに帰着する。

>>544
なんかイメージつかめない…
部分計算のためのキャッシュってのは、 call by need とかかな…
ドメイン・スペシフィックな情報ってどんなの？

>>546
ドメイン名だね。なんとか.jp とか。

CppUnitは狂ったようにパターンを使っているけど



・・・いや、ごめんなさい

>>544
全く思わん。2年も粘着してそれかよ。

そんな >>544 へ。
http://www15.big.or.jp/~kaini/image/img-box/img20030422123158.jpg

>>544
一年以上前の、便所の落書きを覚えていてもらってると思ってるなんて、
並みの自意識過剰じゃないですね、あんた。

とにかく、実体験を通して掴み取った事柄を話せよ。
そーすれば、このスレは、初心者だけでなく経験者にとっても有意義な、
共通体験を広める場として有効に機能するぜ

ユースケース図って本当に必要？

ユースケ、ナナミ、コウタ、出撃じゃ！

http://www.k-514.com/

>553
本当に必要かどうかは、それが無くなった時にしかわからない。
ってことでそのユースケース図を窓から（略

>>550
オブジェ嗜好...

>>557
ああ、やっとわかったよ。
座布団2枚だな

宗方指向ってのはどうよ？

じゃぁ、仕様書をみせてみなさい. >> 1

>>550
Delphi関連だと思っていたのにっ！！

ユースケース図いらん。
本当に必要ない

ユースケース図はあまり要らないね。
形式的すぎるきらいがある。
開発者と顧客とのやりとりは、ストーリー・カードの方が適切。親しみやすい。
開発者チーム専用（チームにいる顧客にも）にはタスク・カードで細かく砕く。

ストーリーカードって何?
なんか、作るのかなりめんどくさそうに思えるんだけど・・・
100〜200ユースケースくらいありそうなシステムにも
適用できる?

>>564
http://oita.cool.ne.jp/ja6hfa/ja6hfa/XP/xpcards.html より:

ストーリーカード＆タスクカード

最初にユーザにストーリーカードを書いてもらいます。書くべきことは、
このように運用できる、このような機能が必要だ。または満足できる
という情報です。ユーザは、この運用のしかた、適応範囲の設定などを
決定する責任を負います。

次にユーザにこのストーリーを３つに分けてもらいます。

o それなしではシステムが機能しないもの
o 多くのビジネス価値を持っているもの
o あればよいもの

ストーリーが長かったり、見積もりが出しにくいものは分割します。その後、
開発側が実装にかかる日数などを出し、ユーザにリリースするカードを選択
してもらいます。ストーリーの追加、優先度変更、見積もりの変更などは必要に
応じて適宜行われます。

ストーリーが決まったら、開発者はまず、ストーリーを分析し、数日で仕上げられる
単位（タスク）に分割し、タスクカードに記述しま す。ユースケースの外部の
システムの更新など、直接ストーリーに関係ないが、必要なものなどもタスクに
入れます。その後担当 するプログラマを決定し、見積もりを出し、コーディングを
行います。ストーリー分のタスクを全て消化したらリリースです。その後、 ストーリ
追加＆コーディング＆リリースを繰り返し、システムを完成させます。プロジェクト
の進捗管理としても、このタスクとストーリ ーは使えます。全体のタスク｜ストーリー
と現在完了しているタスク｜ストーリーをグラフにして壁に張り出します。

>>565
レスサンクスです。内容の大きさ的には、
タスク＝ユースケース
ストーリー＝業務フロー
みたいな感じなのかな?ちょっと面白そうだね。

そんな教科書みたいなケースなんか無いよ。
現実は地獄だよ　ジ・ゴ・ク

上手くいったプロジェクトもあるけどな。
良し悪しはメンバーによるよ。
地獄になるのは、口先だけの奴がのさばっているからじゃないかな？
あるいは567自身が口先だけの奴か。

>567
その通り。現実はあまりにも酷い。
だが、それを改善していく事を放棄してはいつまでも地獄のまま。

オブジェクト指向は変更に強いとよくいわれますが、これは本当でしょうか？
どうしても信じられません。本当ならどうしてですか。

実装を変えるだけで良いから。

>>570
オブジェクト指向の本を1、2冊読んでから信じられるか信じられないか決めろ。
そんなことオブジェクト指向の本の冒頭に書いてある。　
自分で調べて、自分で考えて、自分で判断しろ。

>>572
3冊読んだうえで信じられないと言っているんですが。

>>573
漏れの竿取るんじゃねーよw

>>571
インタフェースが変更されると目も当てられないということでつか？

>>573
それだけ読んだなら実践してみれば？
よほど頭の柔らかいやつでもない限り、
本を読んだだけでOOが分かるはずないし。

OO ってうまく modularize してくための方法論だと思う。
うまく modularize してあって、変更が少数の module 内で済むなら、それなりに強そう。
modularize 失敗してたり、全体に影響が出るような変更だったりすると弱そう。

>>575
そりゃ設計の失敗ですな。

つまり設計に依存するというわけで今までと何ら変わりないということですか？

>>577
モジュール化しても、モジュールに変更があった場合、
モジュールを使用している箇所に影響出るだろ？

>>578
その一言で片付けばどれだけうれしいかねぇ。

その設計を考え方こそオブジェクト指向だろ

>>577
俺もその通りだと思う。
モジュール化をうまくおこなうための方法論。それ以上のものじゃない。
構造化でうまく設計出来る人なら別にOO使う必要ない。

使えって

さげで主張し合ってやんの（藁

上手い構造化
その一つがオブジェクト指向なのだよ

モジュール化云々はあまりにも狭義のOOだと思うが。

単なるコーダーにとってはそれ以上のものじゃ無いだろうな。

クラス図はわざわざ書くものではないと思う。
ツールでソースから起こすのが正しいと思う。
ツールでクラス図からソースを起こすのはよくないと思う。
実態に即した図を常に用意すべきだと思う。
ソースも最初はスタブで一気に書き上げるし。

一言
　　　継承

ハイ、教えた（ｗ

いや多態だろ

継承や多態なんて一機能の名前じゃねぇかバーカバーカバーカ

>>592
そもそも一言で語れるわけねぇだろ。ageてまで言うことかよ

晒してやったです

情報隠蔽

Guidance from MONAR sightseeing USA Inc.

We are the japanese travel service company provides Jukai tour.
Did you lose your fortune completely?
If you got it, Please call our reservation receptionist.
Jukai is famous suicide place in japan ,near Mt.Fuji.
It's the strange place deep forest and can't use magnetic thing,
easy to lose way ,No one can find your corpse.
You can get good departure and rest in peace.

We service with satisfaction.

It can pay with your Kidney.(no anesthesia)

ヒマだな(w

http://www.k-514.com/

結局、誰もまともに答えられないのですね。
オブジェクト指向が変更に特に強いということはないと理解しました。
ありがとうございます。

>>599
おまえごときにオブジェクト指向はもったいない。
どうせ覚えてもろくな組み方しねーよ。

OO厨の捨て台詞ｶｺﾜﾙｲw

カプセル化さいこー。

>>599
ところで君は本を3冊読んで、オブジェクト指向が変更に強いわけはない、
という結論にいたったわけだよね。
なぜそう思ったのか、その理由を教えてくれよ。

>>603
オブジェクト指向における、変更に対する強さというのは、
インタフェースに対するプログラミング、別な側面からいえば
実装をモジュールの中に隠すことで得られるとされています。
しかし、この考え方はオブジェクト指向に限ったものではなく、
構造化技法においても広く認知適用されてきたものです。
そして現場における仕様変更要求が、インタフェース設計の
枠組を破壊せずに済むということは実際には難しく、
インタフェースを変更せざるを得ない局面に往々にして
遭遇します。
そうした場合、オブジェクト指向においても、そのモジュール
(OOですからオブジェクト)を使用している箇所の見直しや
修正などが発生するのは避けられません。
そういう意味では、変更に対する強さという点で、既存の
アプローチに比較してオブジェクト指向が特に優れているわけでは
ないと考えました。
最近では、YAGNI (You Are NOT Gonna Need It)などといって、
将来の変更を考慮しない設計アプローチがもてはやされていますが、
これなども結局この問題に対する逃げにしか見えません。

>>604
俺は構造化については詳しくないのだけど、
おっしゃることはその通りなのではないかと思います。
オブジェクト指向でも、当然のことながら、インターフェースが
頻繁に変更されると変更負荷が高くなります。
ただ、一言でインターフェースと言っても色々なレベルがあるはずで、
あるクラスAのインターフェースは、別のクラスBのインターフェースの
内部に隠蔽されている、Bもまた別のクラスCに隠蔽されている・・・
と言った感じできちんと隠蔽が出来るような設計がされていれば
インターフェースの変更の影響を部分的にとどめることが出来るのでは
ないかと思います。
あと、構造化には、オブジェクト指向のような抽象化の概念はありますか?
プログラムを組む時には、「よく似ているけど、微妙に違う処理」みたいな
ものが良く出てくると思うのですが、抽象化の概念をうまく使うことで
こういったものをうまく共通化できる場合があります。
共通化を推し進めれば、変更が局所化できて楽になるはずです。

>>605
早々のコメントありがとうございます。
おっしゃられていることは、インタフェースの継承のことと
考えましたが、よろしいですか。
実は、私は継承技術に関しても懐疑的なのです。
といいますのは、モジュールというのは、他のモジュールとの結合度が
弱いものほど優れたモジュールであるという一つの基準がありますが、
継承という考え方は、この原則に反していると考えるからです。
いわゆるスーパークラスとサブクラスの結合度の強さが、
変更に対する弱さにつながっていると考えています。
いわゆるスーパークラスのインタフェース変更が、サブクラスや、
さらに先まで影響を与えてしまうことはよく知られていると思います。
そういうこともあり、最近のオブジェクト指向論では継承をあまり
重視しない方向に変わってきているようですね。かわりに、
デリゲートなどの代替技術が用いられるようです。
「よく似ているけど、微妙に違う処理」には、共通部分を
モジュール化して、それを呼び出す違いを吸収したモジュールを作成、
それを使用する方法がとれると思います。オブジェクト指向とは
アプローチが逆かもしれませんね。

>604
オブジェクト指向だと、関数がデータに直接アクセスすることがないから
データ構造を変更したときもトレースしやすいんだよね。

最近の構造化プログラミングでも、オブジェクト指向的な考えを取り入れた
ものは必ずアクセッサ関数を経由してデータにアクセスするようにしている
から、オブジェクト指向言語特有のものではないけどね。

＞将来の変更を考慮しない設計アプローチがもてはやされていますが、
Generic Programmingを勉強なされ。設計の段階で何を決定すべきで
なにを制限してはいけないのか。Genericというとライブラリの話が多く
なるけど、設計そのものの考え方の勉強にもなるよ。

取りあえずは「Modern C++ Design」のまえがき、訳者まえがき、第１章あたりを
立ち読みしてみるのがいいかなぁ（けっこうそこらじゅうにあるし）

>>606
最初から、継承"重視"ではなかったのでは？
継承より合成を利用していくべきだと
昔から言われていると思いますが。

>606
>継承

たとえば「メモリ」という抽象的なグループと、PC2100のDDR-SDRAMという
具体的なメモリといった感じで、抽象化<->具体化の軸で表される関係
（いわゆるas-isの関係)を表現するのには継承が便利。
具体化されたものには抽象化されたものが全て含まれるからね。

＃最近の動向は、ようやっと継承の使い方がわかってきたということでしょうな。

>>603
横から失礼する。
激しく同意します。
構造化における共通化については、常に課題となりますね。
共通化をうまく進めるとかなり楽になるし、洗練されてくるので
性能も結果的によくなる。
そこで、誰か答えてほしいんだが
オブジェクト指向における、隠蔽化を守って設計するための
人間のアクションはどうあるべきなんだろう。
設計ミーティングが「オブジェクト座談会」になってしまうこと
が多すぎる今日この頃です。
こうすれを誰か答えてくれい。

オブジェクト指向って言葉の神通力はまだ世間に通用しますか？

>>611
通用しなくてなっています。
オブジェクト指向という言葉を聞いただけで拒絶反応を起こされて
しまうといったような神通力は、もう昔話になりつつありますね。

>>606
はい、継承技術のことを言っていました。
継承を使うとモジュールの結合度が高くなると言うのは
まったくもって同意なのですが、それに対するインターフェースの
変更の被害は、クラスをなるべく細かくわけることによって
少なくすることができると考えています。
つまり、30個のインターフェースを持った大きなクラスを継承すると、
当然変更の被害は大きくなりますが、大きなクラスというのは
だいたいに置いて過剰な責務を持たされています。
これを適切な大きさに分けて、責務を色んなオブジェクトに分配することで、
1〜2個のインターフェースを持った小さいクラスに分けます。
で、継承はそれぞれの小さなクラスに対してのみ使うようにします。

>「よく似ているけど、微妙に違う処理」には、共通部分を
>モジュール化して、それを呼び出す違いを吸収したモジュールを作成、
>それを使用する方法がとれると思います。オブジェクト指向とは
>アプローチが逆かもしれませんね。

すみません、これよく分かりません。
オブジェクト指向のアプローチとは全く同じもののように思えるのですが。

>>607
Generic Programmingって、どちらかというとコンパイラ技術と
いう感じだけどね。そもそも、SmalltalkやObjective-Cのように
ダイナミックタイピングな言語では、こんな概念は不要だし。
効率第一のC++らしいといえば、そうだが。

継承に問題があるわけじゃなくて、集約を使わないから問題がおこる。
×player.name
○player.profile.name
上だと、無駄な要素がくっついてくるから、継承のメリットは消し飛ぶね。

ビジネスロジックを実装するクラスはみんなどんな風にクラス化してます？
サーバサイドでの永遠の命題ですが。
案外、構造化一本やりで書いた方が、分かりやすいしメンテしやすいケースもある。

俺が良くやるのは、
・システムの要になるDBアクセスやビジネスロジックは、コアロジックとして別パッケージにする。
・業務行為の分析をしっかり進めた上で処理制御を分類化し、スーパークラスでテンプレート化する。
この程度。
いずれにしても、業務をしっかり分析しないとね。ユースケースの変更も視野に入れて。

　　　　　オブジェクト指向って死滅しちゃうの？

やべー、OO歴15年の俺のスキルはどうなるんだ？w

>案外、構造化一本やりで書いた方が、分かりやすいしメンテしやすいケースもある。

ぜんぜんまったくそんなことないとおもうのですが。
by 全javaソースに同じバグ入りの処理がコピペしてあるのを見て死んだ経験があるひと。

オブジェクト指向なんてとっくに破綻してます。
「どうして日本ではオブジェクト指向が広まらないか」
なんて言ってるのは日本だけ。

>>620の頭の中では構造化＝ソースコピペらしい（ｗ

>>622
すまんな。言葉を間違えた。バグ入りの「関数」がそのままコピペされてたんだよ。
ソース単体で見れば見事に「構造化」されてたのさ。それは見事にね。
しかし、インターフェイスの利用は皆無だったし、
せっかく親クラスを継承してるのに必要なメソッドは
まったく定義されてない。
ちゃんと親クラスに処理そのものを書けばバグは１個で済んだのに…。
１ファイルごとの構造化なんて邪悪なものは消え去ってくれ。頼むよ。

オブジェクト指向を勉強したかったら、
.net FrameWorkかDelphiでも使えばすぐ覚えるだろ…。

XP の once only once だな。
XP そのものを使うのは難しいだろうけど、エッセンスは知っておいて損はない。

>>624
それがそうでもないんだよ。.NETには罠がたくさんある。
たとえばUML的に書くと笑えるんだが、初心者のコードってのは、
　MyForm <>---- .net FrameWork　になってるのだよ。
MyFormの中にあらゆる処理が集約されてるのな（ｗ
イベント処理の中に、画面の書き換えもDBの更新も保存も変換も印刷も入ってる。
それでオブジェクト指向したつもりになって、
再利用が効かないとかわかりにくくて使えないとか言ってる。
もうね、アホかと馬鹿かと。とにかく各処理の本体を適切なクラスに切り分けろと。
そんな厨房を大量生産する.net FrameWork逝って良し。

>>626
それは.net FrameWorkに限らない話だろ

　　先生っ！オブジェクト指向で客が釣れません！！




　　次は、ＸＰだな。

XP,FDD,RUP、実際にきっちりとこれに従った開発した事ある人いるか？
おれは破綻したXPなら経験がある（ｗ

Java の GUI モデルだと継承とインベントリスナを使うからそういう風にはならない。
クラス数は糞増えるが、問題の切り分けが楽になるので管理はしやすい。

>>627
そうだよ。DelphiのVCLにもJavaのAWTやSwingにもあてはまるんだよ。

だからこそ>>624の主張は間違いなのですが何か？

>>630
ところがどっこい。
初心者本には、MyFormにイベントリスナを山ほど実装させて、
thisをイベントリスナに登録するように書いてあるものも結構ある。

これだとVB並みにおぞましい結果になるわけだ。
初心者はイベントリスナのメソッド名が重複するまでは
問題に気づかずthisを登録しまくる。クラスを書くよりは楽だからね。

>問題の切り分けが楽になるので管理はしやすい。

>>632に追加。
最悪なのは、JButtomのイベントリスナに、thisを登録してるコード。
サンプルの行数は短くなって、ある意味とっつきやすくなる。
しかし、ボタンを2つに増やしたくなったらどうしろというのか。

>>634

public void actionPerformed(ActionEvent e) {
if(e.getSource() == button1) {
text1.setText("ボタン１がクリックされました");
}
if(e.getSource() == button2) {
text1.setText("ボタン2がクリックされました");
}
}
みたいな（ｗ

でもまあ、サンプルソースなら良いんじゃないすか？
その前か後でイベントモデルを勉強するんだし。

あとにつづかねぇ糞コードだな。

そういえばJBuilderが吐くコードもいい加減糞だよなw

>>616
>サーバサイドでの永遠の命題ですが。
>案外、構造化一本やりで書いた方が、分かりやすいしメンテしやすいケースもある。

これは俺も同意。
ビジネスロジックの部分はオブジェクト指向が
特にうまく機能しない部分だと思う。
フレームワークみたいな、オブジェクト指向が得意な部分だけに適用を絞って、
あとは構造化でやる、と割り切ってしまうのがいいと感じている。

>>>638
ま、構造化手法で解決できるところまで問題をブレークダウンできただけでも
オブジェクト指向手法を使った甲斐があるわけで。
とはいえ、構造化手法では役者不足な程度に大きいビジネスロジックも当然
あるので、そのときはオブジェクト指向手法でやらないとね。

>>639
うーん、俺は大きなビジネスロジックになるほど、
オブジェクト指向手法の限界を感じてしまうのだけど・・・
本当に複雑なビジネスロジックって、なかなかきれいに
オブジェクト指向で、っていうわけにはいかないと思わない?
がんばればできるのかもしれないけれど、時間的な制約から
あきらめざるを得ないことが多かった。

あと、俺は技術的な面でのオブジェクト指向のメリットは
充分あると思っているのだけど、プロジェクト管理の側面から
見ると、構造化に比べて不利のように思う。
共通部分が多くなるから、人員の割り振りがしにくいし、並行作業が難しくなる。
少人数のプロジェクトならともかく、大規模プロジェクトの
ビジネスロジックの数は膨大なので、とてもじゃないが
理想的なオブジェクト指向設計なんかできそうにない。
RUPも、この辺の問題には何も回答を与えてくれていないように思える。

だから、現実的な面から見てフレームワーク部分（これはビジネスロジックに
比べるとコード量が圧倒的に少ないので適用可能）だけに適用を絞って、
ビジネスロジックは構造化で、というのがいいような気がするんだけど、どうよ?

>>617が言ってるみたいな、ロジックのテンプレート化はアリだと思う。
ただし、やっぱちゃんと分析されて無いと追うのが辛いだけになる。
何階層もに分散した実装を上に行ったり下に行ったりしながら追うのは苦痛。
逆に、ちゃんと分析されて、妥当な分類がなされていれば非常に有用。

業務分析とそのモデリング技術（というかセンス？）は経験がものを言うな。

>>641
正直に言ってしまうが、俺はビジネスロジックのテンプレート化は
危険な方法だと思っている。
現在分かっている仕様をもとにきちんと分析したとしても、将来的な
仕様変更でその分析結果が無に帰す場合がありえる。
ロジックの定型化をすることで、将来その定型部分にそぐわない
仕様変更が発生した時に破綻する可能性が高い。
多少コードが冗長になったとしても、「何も規定しない」方が
メンテナンス性は高いと思う。

>>626

同意点が多い。

>たとえばUML的に書くと笑えるんだが、初心者のコードってのは、
>MyFormの中にあらゆる処理が集約されてるのな（ｗ

今気になってるのが、MSのC系メインストリームがC++からC#に行くじゃない。
VC++時代には出来なかった「Formベースプログラミング」ともいうべきものが、
可能どころかデフォルトになってしまう。ボタンをダブルクリックするだけでコマンド
ハンドラ出来てしまう。VBやC++ Builder/Delphiと同じ。

その環境で、フォームに依存しないクラスが作れるスキルは中級〜になって
しまうのではとかね。

>>643
確かに、これはどの範囲まで適用させるかが重要だと思う。
ユースケースに出てくるようなパスはむしろ固定化させるべきで、
機能ごとにユニークな部分のみを実装させるべきと考えるので。
万が一ユースケースが変更されたら書き直しになるが、それが然るべきあり方という考え方。
一長一短ですな。

せちがない昨今、なかなか分析を十分に進める時間が無いのよね・・・。
XPにしても「そんな悠長な」ってのが多くの開発者の本音では。

XPだと生産性は半分になるからね
ﾎｼｭも半分の労力で済むけど
ウチの会社は作りっぱなしが多いからなぁ
だいたい仕事頼んできたところが
結構な割合で倒産してるし・・・

>>626
それは.NETフレームワークの問題じゃなくて、開発ツールとか
教育体制の問題じゃないのかなあ。オブジェクト指向の手法と
してのネタではないような。

ちなみに>>646

×　せちがない
○　せちがらい（世知辛い）

>>621
> 「どうして日本ではオブジェクト指向が広まらないか」
> なんて言ってるのは日本だけ。

そりゃ、アメリカやドイツや韓国では、そんなことを言っている人はいないだろうな。

まあ、アメリカはその代わりに CMM を流行らせたわけだが。

>>545
> すべてのデザインパターンは Composite パターンに帰着する。
とりあえず馬鹿は死ね

>>634
Stateパターンを使いましょう

>>653
バトル・アメリカ

>>650
日本の多くの企業のCMMレベルは殆ど1か2、またはそれ以下
日本で最近CMMレベル5を実現した企業は日本IBMのみ
これはひどいことにほとんどがレベル4を実現しているインドにまで劣る。

日本人は馬鹿だ。日本人はあまりにも愚かだ。日本人は頭が悪すぎる。
日本人は論理的思考に弱い。都合の悪いことは何でもかんでも「水に流す」で済まそうとする。
そんな馬鹿な日本人に生まれてしまったのは我々の宿命か

>>651
ハゲ！！ＣＭＭはプログラミング手法じゃねーよ！
ソフト開発の工程がちゃんとしてるかどうかを採点する方法だよ。
まあ、あってもなくてもいいものだ。

>>656
採点って、評価だけが目的なんか？

>>657
そうだ。あってもなくてもいいものだ。

CMMって何の略なん？

>>657
さわむらかたくそんかしらんがそいつにレスすんな。

>>659
ハゲ！！ＣＭＭはな、Capability Maturity Modelの略よ。
といってもおまえにはCapabilityとMaturityの意味はわからんだろう？
いいか！！ Capabilityは「能力」Maturityは「成熟」Modelは「模型」よ。
つまりソフトウエアをつくる能力がどれくらい成熟しているかを採点する模型のことよ。

今日は沢村元気だな。



というよりムキになっているのか。

つーか、頭いいやつが銀行とかいってこの業界にこないから仕方ねーじゃん。
赤字増えるより、ましかもしれんけど。

銀行＝馬鹿

ここではクラスベースの話しかしないの？

あげ

>>665
どうぞ、インスタンスベースの話をして下さい。

>>665
じゃあ、Selfの話でもしようか。


…ネタがねぇ…そのまえに知らないし

　　沢村、近藤、山崎渉は徹底放置！！



よろしく。

沢村は徹底放置！！

よろしく。

selfのほかにないんかのう

NewtonScript!

　　　　　「ＣＭＭはうんこ」


ってことで、よろしいでつか？

>>673
かつてのISOみたいに、認定とっていることで営業の道具にすることしか
考えていない、企業版「資格商法」のカモになってるバカ管理職連中は
うんこです。

>>669
沢村、山崎渉固定ハンドルは良く見かけるけど
近藤って誰よ？

>>675
うんこ

近藤って誰よ？
沢村、山崎渉固定ハンドルは良く見かけるけどな…

マ板に行けばわかる。
別に知らなくていいことだが。

ふ〜〜ん

「まあ」ってあるよね。
昔は、「まあいいよ」とか、「まあこのぐらいですね」とか、「だいたいこの程度」といった
感じを表すときによく使っていたと思うんですけど。
最近は、「これは、まあカーナビですが、車に搭載して使います」とか、
「酸素と、まあ水素が化合すると水になるわけです」とか、何が「まあ」なんだか
わからない使い方をよく聞くようになりました。
90年頃からかな。
これは、いったいなんなんでしょう……

まあというのは「間」のことよ。
ふつー「間」というのは無言で表わすわけだが、それをわざわざ言葉で表わしたのがまあというわけだ。
だからまあは「…」と同じようなものよ。

オレは子供の頃マー君て呼ばれてた。なつかしいな。

プログラまあ、でしょう。

コピペに釣られるバカに沢村に釣られるバカ。

バカを見つけるとバカと言わずにはいられないバカ。　

チャットでやってろ漏前ら

小3のある日、兄の自転車を借りて坂を下ってたら
実はブレーキがすごく甘くなってて、
ブレーキしてもどんどんスピードが上がっていって
靴のつま先で無理やりブレーキさせても靴が磨り減るだけで
仕方なく路肩の植木に身を投げたら擦り傷いっぱいでスカート破けて
そのままｴﾛﾃｨｯｸな格好で泣きながら家に帰ったら
母がいきなり
「誰にやられたの！」
と聞いて来たのでは私はお兄ちゃんの自転車で…と言うつもりが
泣きじゃくってるせいでうまくいえず
「お…お兄ちゃん…」
と呟いたら母は突然倒れてそのまま気絶してました。

Objective-Cはダメでつか？

笑われたくない！！

この擦れ立てたやつどのくらい成長したのか気になる

つい先日氏んだって話を小耳に挟んだが。

オブジェクト指向なんて関係ない。
チンコがたつのがいい男。
たたないのが駄目人間。

>>692
おいおいペレを馬鹿にするなよ

>>692
童貞がｗ

〜oノハヽo〜 　http://togoshi.ginza.st/kaorin/
　 (　＾▽＾) ＜　こンなのかございまーす♪　
http://togoshi.ginza.st/kaorin/kaorin05.html
http://www.togoshi.ginza.st/kaorin/kaorin02.html
http://togoshi.ginza.st/kaorin/kaorin06.html
http://www.togoshi.ginza.st/kaorin/kaorin08.html
http://togoshi.ginza.st/kaorin/kaorin01.html
http://www.togoshi.ginza.st/kaorin/kaorin10.html
http://togoshi.ginza.st/kaorin/kaorin04.html
http://www.togoshi.ginza.st/kaorin/kaorin03.html
http://togoshi.ginza.st/kaorin/kaorin09.html
http://www.togoshi.ginza.st/kaorin/kaorin07.html

どいつもこいつも、お気楽でいいな。

そうじゃないとやってらんないよ。そう思わん？

やっべーアプリケーションの方はまだマシだけど。
アプレットはキツイ
なんか受けつかないって感じ

メンバ変数の値を返すだけのメソッドってどういうふうに命名するのが一般的ですか?

変数名が hoge として、
Java 風： getHoge
Smalltalk 風： myHoge または hoge

Delphi風
メンバ変数 FHoge
メソッド(というかproperty) Hoge

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

＜アスペルガー症候群（自閉症スペクトラム）←脳の機能的疾患（遺伝）＞
●変化を嫌う
http://web.kyoto-inet.or.jp/org/atoz3/kado/book1/Williams-Asp.htm

●接し方のルールがわからず無邪気に周囲の人に対して迷惑なことをしてしまうことがある。人を傷つけるということには鈍感。
●パターン的行動、生真面目すぎて融通が利かない
　毎朝の通学電車では同じホームの同じ場所から、同じ時間の同じ号車に乗ることに決めていたりする。パターンを好むということは反復を厭わないことでもある。
●アスペルガー症候群の子どもは（大人も）感覚刺激に対して敏感。敏感さは聴覚、視覚、味覚、嗅覚、温痛覚などのいずれの感覚の敏感さもありえる。
●アスペルガー症候群の子ども（大人も）は予測できないことや変化に対して苦痛を感じることが多い。
http://www.autism.jp/l-02-03-aspe3.htm

●独り言を言うことが多い
●物事をいつまでも同じにしておこうとする欲求が強く、そうでないと非常に不安。いわゆる「こだわり」。
●自発的に行動することが少なく、興味の幅が狭い
●物まねをしているような不自然な言語表現
●自閉症スペクトラム全体としては一万人に91人（およそ100人に1人）。
http://www.ypdc.net/asuperugar.htm

★自閉症スペクトラムの考え方
http://www.imaizumi-web.com/030413.html　　

★アスペルガー症候群（自閉症スペクトラム）かどうかのテスト
http://twitwi.s10.xrea.com/psy/add.htm　
http://www.geocities.co.jp/Beautycare/5917/as/marksheetmake.html

http://www5e.biglobe.ne.jp/~liquor/raytrace/
ベンチマークとってみたんだが、ここの人って
なにげにオブジェクト指向してない？

過労死をさせる日本ロジテム株も大暴落の予感
佐川とロジテムどっちがひどい？
田中真紀子と親密な日本ロジテム（日清系　上場企業　みずほの融資先）の
子会社せいも素（みずほの融資先）で 　
サービス残業させすぎの過労死者を出した上、大量の不当解雇を行った社長の辻
にまた労働基準監督署の立ち入り調査があり，またも多くの勧告が出された。
http://www.samos.co.jp
http://society.2ch.net/test/read.cgi/traf/1046749189/l50
.　　　　　　／￣＼　　+.　　∧＿∧ｱﾊﾊﾊ ﾃﾝｺﾞｸﾍｲｯﾁｬｳﾖｰ　
　　ｲｸﾅﾖｰ（　´∀｀）　　　　（´∀｀　）　　
　　　　　　（つ　　つ 　　　 （つ　　つ■
.　　　+　　（　ヽノ　　　　　 （　ヽノ

Simula67

Smalltalk80

C++

Self

Eiffel

Delphi

Java

C#

スーパークラスセンシティビティという言葉について
ご存じの方教えてください。実装の継承を行う場合の弊害らしいですが、
検索しても出てこないので・・・

>>707
みこみこナース です

巫女巫女ナース？

超級戦士ちびT
ちびT(ぴたT)を着た戦士。強い。

>>707
センシビティ=敏感
多分、実装の継承をするとスーパークラスを簡単に修正できなくなることを
言ってるんじゃないのかなぁ・・・

http://yahooo.s2.x-beat.com/linkvp/linkvp.html

>>706
Objective-Cが抜けてるよ

こんな本が出てた。
「リバーシのアルゴリズム―「探索アルゴリズム」「評価関数」の設計と実装 C++&Java対応」
これを読めばOO厨もオセロ作れる？

やっぱね、オセロとかは石ひとつひとつがオブジェクトなんですよ。

・・・案外この思想で面白い思考ルーチンが作れるかもしれない

いっそ、マス一つ一つを object にしてみるとか。
そこに置けるかとか、どこの石が取れるかとか、問い合わせに答えるの。
で、石が置かれたら、周りのマスに通知して…

…でも、これは思考自体にはあんまり影響しないかも。

>>715-716
極めて素直で自然だと思いますね。
あたかも、それが画期的なことであるかのように書き込んでいますが。

>>717
よし、じゃあ早速その発想でアルゴリズムを作ってみてくれ。

アルゴリズムの話はスレ違い

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

結局誰もSingletonを書けなかったわけだが。
Java本からのパクリを載せる。

public class Singleton {
private static Singleton s = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return s;
}
}

なぜこれしきのことで騒いでいたのかと。

>>722
使わない可能性があるのにインスタンスが必ず一つ出来るのって効率悪くないですか？

>>723
使わないんなら、わざわざコード書く必要はないような気が。
722の場合、使わなくてもインスタンスは必ず一つというのは
それはそれでSingletonの定義にかなっているのではと。
あとは、他の実装例を私は不幸にして知らない。

>>724
あなたは、あるパッケージから使わないそのシングルトンを抜き出す作業を好んで行うんですか？

public class IntelligentSingleton {
private static IntelligentSingleton s = NULL;
private IntelligentSingleton() {}
public static IntelligentSingleton getInstance() {
if(s == NULL)
s = new IntelligentSingleton();
return s;
}
}

>>725
あーそーいえばそんなコードを見かけたことがあった。どこでだかは忘れたけど。

構造体とクラス（C++)の違いを教えてください。
クラスを使用することのメリットは何でしょうか？

>>727
C++的には、デフォルトのメンバアクセス制限が違う以外はまったく同じもの。
一般的には、同じところを見つけるほうが困難なほど概念からしてまったく別物で比べることもおこがましい。

クラス定義したオブジェクトは、
メモリ領域的にはどこに配置されるのですか？
作り方しだい？（例えばメモリプール）それともスタック？

ここを特定の言語のためのスレッドだと勘違いしている人が二人ほどいる模様。

>>729
ヒープまたはスタック

ヒープって何？

>>732
newしたやつが住む場所

>>723
クラスにアクセスしない限りはできません。

>>725
そのコードはスレッドセーフではない。失格。

>>734
はいはい。では次の方。

public class IntelligentSingleton {
private static IntelligentSingleton s = NULL;
private IntelligentSingleton() {}
public synchronized static IntelligentSingleton getInstance() {
if(s == NULL)
s = new IntelligentSingleton();
return s;
}
}

TABれえぇぇぇぇぇえぇぇぇぇえ

質問なんですが、インタフェースとは
「実装を持たないシグニチャのみのクラス」
でよいのですよね？
その利点は一体何なんでしょうか。

>>738
見た目が同じなら中身が全然違くてもいい事

・多重継承と違って中身が衝突しない
・常にvtblを使うのでCOMと一致

>>739＆740
ありがとうございました。

>>739
それはカプセル化と似ている気がするのですが、全然違うのですよね？

>>741
クラスにするときのカプセル化とは言葉の使いどころは違うけど概念的には同じもの。

>>742
私の持っている本には、カプセル化は「インタフェースと実装の分離」と書いてあります。
インタフェースとは所謂外面のことと考えてもよろしいでしょうか？

>>743
いいけど、分離するだけじゃカプセル化とは呼ばないよ、隠さないと。

>>744
そういえばそうですよね。わかりました。ありがとうございます。

ハゲ隠すの必死（藁

>>731 処理系依存

私も脱いでます♪探してみてね♪
http://yahooo.s2.x-beat.com/linkvp2/linkvp2.html

ロジック設計（ハード設計）にも、オブジェクト指向の設計手法はありますか？

>>749
もちろん。

>750
VHDL or Virilog HDL?

>>748
メンバに直接アクセスしたいです。

IT（情報技術）をマスターするにはオブジェクト指向が必要なんでしょうか？

http://homepage.mac.com/maki170001/

>>746
ボクのハゲもカプセル化されそうです。

（＾＾）

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン