757コメント243KB

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

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

0001Java太郎 ◆RxE.qPfLG2

NGNG

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

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

NGNG

【夢】get

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

NGNG

さらに【恋】もget

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

NGNG

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

0005あぼーん

NGNG

0006かおりん祭り

NGNG

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

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

NGNG

立てるのが遅いです。

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

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

NGNG

なんか静かだな・・・ｗ

0009かおりん祭り

NGNG

0010あぼーん

NGNG

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

NGNG

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

0012たんぱく質

NGNG

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

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

NGNG

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

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

NGNG

訂正

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

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

NGNG

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

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

NGNG

>>15
禿げしく同意！

0017１４

NGNG

１５＝１６

うっさい

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

NGNG

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

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

NGNG

>>18
つまらん

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

NGNG

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

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

NGNG

俺は爆笑だったけどな

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

0028プロの逝って良しの１ ◆MvRbZL6NeQ

NGNG

インスタンス変数>26

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

0033プロの逝って良しの１ ◆MvRbZL6NeQ

NGNG

だめすぎ

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

NGNG

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 はインスタンス変数なんですよ。

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

NGNG

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

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

NGNG

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

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

NGNG

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

003863

NGNG

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

003938

NGNG

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

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

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

NGNG

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

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

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

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

NGNG

間違い。if は == だね。

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

NGNG

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

これが正しいのかな。

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

NGNG

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

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

こうか？

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

volatile じゃだめ。

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

006360

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

0073プロの逝って良しの１ ◆MvRbZL6NeQ

NGNG

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

0074プロの逝って良しの１ ◆MvRbZL6NeQ

NGNG

インドの電気屋の話

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

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

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

NGNG

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

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

NGNG

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

007776

NGNG

return inst.get();
だた。

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

>>84
intのこと

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

OOPの考案者は誰？

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

NGNG

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

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

NGNG

struct a{...}b;

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

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

NGNG

>>88
思うだけ。

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

NGNG

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

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

NGNG

>>93
structは構造体

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

NGNG

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

009695

NGNG

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

009795

NGNG

>>96
うざ

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

NGNG

intはクラスなの？

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

C#だとそうでもない

010479

NGNG

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

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

NGNG

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

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

NGNG

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

0107106

NGNG

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

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

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

NGNG

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

0109bloom

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

こうかい？

0117プロの逝って良しの１ ◆MvRbZL6NeQ

NGNG

まあ、簡単に言うと

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

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

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

NGNG

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

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

NGNG

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

0120119

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

　　　（　　ド・ド・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. トヾ､.ﾞ｀ｨ'' ´ヽ､///　＼二|｀＼ｰ‐‐'´
　　　,､- '´　ヽ､ﾞ､　　 {　｀＞"､　 !　 ! ! 　 |　｀>-､　|　|､　＿＿＿＿＿＿＿_∧＿＿＿＿__
　　/＼＼　　　　',　　 }　　 //｀ヽ|　 ',.!ﾞ､　!／／ﾞ!/　 ! （　　　誰に～も遠慮はいりません

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

NGNG

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

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

NGNG

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

0127122

NGNG

>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は良く解らんですな。

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

NGNG

>>127

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

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

0129122

NGNG

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

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

0130122

NGNG

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

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

NGNG

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

ってことですね。

0132122

NGNG

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

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

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

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

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

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

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

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

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

NGNG

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

0134山崎渉

NGNG

（＾＾）

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

NGNG

age

0136　

NGNG

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

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

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

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

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

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

0149山崎渉

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

あぁ。馬鹿ばっかだよ。

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

0160159

NGNG

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

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

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

NGNG

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

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

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

NGNG

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

0163山崎渉

NGNG

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

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

NGNG

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

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

NGNG

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

0166動画直リン

NGNG

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

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

NGNG

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

と、

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

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

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

NGNG

>136
こらまた極論だなぁ

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

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

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

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

>>176
そうだよ。

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

Ｔｏｍ●

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

0186(´д｀;)ﾊｧﾊｧ

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

0192生涯一職人

NGNG

俺流

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

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

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

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

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

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

NGNG

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

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

NGNG

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

0201198

NGNG

>>200

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

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

NGNG

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

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

0203197

NGNG

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

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

>>202
で？

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

NGNG

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

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

NGNG

>>197

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

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

NGNG

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

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

NGNG

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

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

0208198

NGNG

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

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

0209プロの逝って良しの１ ◆MvRbZL6NeQ

NGNG

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

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

NGNG

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

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

0218198

NGNG

>>210

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

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

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

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

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

0222198

NGNG

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

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

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

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

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

NGNG

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

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

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

NGNG

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

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

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

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

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

NGNG

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

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

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

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

NGNG

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

よっぽどの天才以外は。

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

0236189

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

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

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

NGNG

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

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

0241235

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

＞土台と思っている人

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

そういうことではない？

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

NGNG

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

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

NGNG

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

0259258

NGNG

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

0260247

NGNG

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

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

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

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

NGNG

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

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

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

NGNG

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

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

0270268

NGNG

化けた...鬱

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

NGNG

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

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

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

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

NGNG

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

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

NGNG

>>269

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

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

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

NGNG

>>273

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

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

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

NGNG

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

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

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

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

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

ウソ。

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

NGNG

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

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

NGNG

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

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

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

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

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

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

NGNG

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

スレ違いです、多分。

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

＞＞馬鹿だなあ。

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

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

NGNG

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

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

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

NGNG

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

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

NGNG

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

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

NGNG

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

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

>>320
必死だな。

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

NGNG

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

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

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

NGNG

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

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

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

NGNG

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

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

0337335

NGNG

また化けた！safariめぇっ！

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

NGNG

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

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

NGNG

死のう...

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

NGNG

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

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

NGNG

マカーよ、Cocomonarを使え。

0342あぼーん

NGNG

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

胆の戦略は liver strategy だよ。

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

NGNG

じゃあ Strategy パターンか。

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

NGNG

レバパタだな。

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

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

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

NGNG

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

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

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

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

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

NGNG

test

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

NGNG

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

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

NGNG

いいからオブジェクト指向覚えろって。笑

0373デフォルトの名無しさん

NGNG

上級者-初心者っていうカテゴライズもどうかと思うけどな。
# すれ違い下げ

0374デフォルトの名無しさん

NGNG

次スレは
「貴様ら！オブジェクト指向を教われ！！第3章」だな

0375名無し

NGNG

いろいろ説教たれるよりコードで見せたほうが速いと思います

0376デフォルトの名無しさん

NGNG

>>371
デザパタが危険なんじゃなくて、無知が危険なの。

0377デフォルトの名無しさん

NGNG

>>376
無知をベースに批判するやつも、かなり危険だよな。
己の理解している範囲=その世界の全てという馬鹿は、数ある馬鹿の
なかでも、もっとも有害な馬鹿だと思う。
大量のリソースを無意味に消費して全く価値のないものを巻き散ら
かすのは、こういうヤツラ。うちの重役とか。

0378デフォルトの名無しさん

NGNG

>>377
>己の理解している範囲=その世界の全てという馬鹿は、数ある馬鹿のなかでも、もっとも有害な馬鹿だと思う。

デザパタを理解もしないのにデザパタを批判するやつのことでつね

0379デフォルトの名無しさん

NGNG

アンティークなジェラートを食べるアンジェラだとはこのことだ。

0380デフォルトの名無しさん

NGNG

>>379
灰？

0381デフォルトの名無しさん

NGNG

ユースケースっつーか、
あのアクターとか出てくるやつがようわからん

あればっかしは文章箇条書きで書いた方が
わかりやすいと思うんだが・・・

あれか？グローバルっつーかワールドワイドに
英語で書いとけってことか？

0382デフォルトの名無しさん

NGNG

ユースケサンタマリア

0383デフォルトの名無しさん

NGNG

>381

170 名前 : OOﾓﾅｰ Mail : 投稿日 : 03/03/29 00:21

>>167
ユースケースってのは要件分析だからまずは洗い出しから始まるわけよ。
で、洗い出した後は、適当な基準で分類すればOK。
適当なっていうのは、分類にはいろんな視点が考えられるから、
いつもこれが正しいってのがないんだよね。
独立したサブシステムが見えている場合は、それを基準に分類しても
問題ないと思う。
それよりも、ユーザの要求をユースケースとして可能な限り
全て抽出できているかどうかのほうがはるかに重要。
ここで漏れがあるとハッキリ言ってかなり痛いよ。
また、ここでの分類がそのままチームの作業分担に直結していく
可能性があるので、あんまりいい加減でも困るし、
逆にもう設計に入ってしまったかのような細かさでも困る。
あくまでも、開発しようとしている対象がどういうものなのかを
把握する手段であり、図を書くことが目的じゃないからね。
実際、ユースケース図ってのは、字で書く内容の方が多いだろ。

171 名前 : 仕様書無しさん Mail : 投稿日 : 03/03/29 01:00

ユースケースによる分析は、ユースケースごとのシナリオが主な成果物です。
ユースケース図は、複数のユースケースを俯瞰するための方法に過ぎません。

機能要件の一覧表を作るのもいいんだけど、ユースケース図の方が優れるのは、
　・アクターとユースケースの関連付けが簡単に分かる
　・ユースケース間の関係が簡単に分かる
　・システムの実現範囲をが簡単に分かる
ことです。

0384デフォルトの名無しさん

NGNG

デザパタは役に立たないってことで決定だな。
結局、みんなに普及しなきゃ意味無いしね。
肯定派と反対派とどっこいどっこいだろ？
さらにデザパタ覚えた人間ですらいらねぇって考えもあるし
パターンを覚えるのも覚えさせるのも時間がかかるし
ちなみに俺のいる職場ではデザパタ普及率0。
俺しかGoF本読んだ奴いないからデザパタ使えないし。笑
はじめの広まるスピードとお手軽さが流行る条件になっているようなので
もうデザパタはものがどうであれ終了だろ。

0385デフォルトの名無しさん

NGNG

英熟語は役に立たないってことで決定だな。
結局、みんなに普及しなきゃ意味無いしね。
肯定派と反対派とどっこいどっこいだろ？
さらに英熟語覚えた人間ですらいらねぇって考えもあるし
英熟語を覚えるのも覚えさせるのも時間がかかるし
ちなみに俺のいる職場では英熟語普及率0。
俺しか英熟語本読んだ奴いないから英熟語使えないし。笑
はじめの広まるスピードとお手軽さが流行る条件になっているようなので
もう英熟語はものがどうであれ終了だろ。

0386デフォルトの名無しさん

NGNG

>>385
ﾜﾗﾀ。バカしかいない職場にいるバカの一人が勘違いしているだけ
ということですな。

0387デフォルトの名無しさん

NGNG

英熟語は充分普及してるし、みんな価値を認めている。
小学生ですら英会話教室に通う時代だ。
デザパタと英会話に、何の共通点があるんだ？
これが、自分が使えると思ってる、勘違い馬鹿ってやつか？

0388デフォルトの名無しさん

NGNG

うちの会社は syslog を逐一プリンタで印刷しているが、それと同じぐらい馬鹿だ。

0389デフォルトの名無しさん

NGNG

デザパタは充分普及してるし、みんな価値を認めている。
ＣＯＢＯＬＥＲですらＪａｖａ教室に通う時代だ。

0390プロの逝って良しの１ ◆MvRbZL6NeQ

NGNG

判った。
デザパタでオセロ書いてみろ。
話はそれからだ。

0391デフォルトの名無しさん

NGNG

>>390
お前はオセロ以外にネタが無いのか

0392デフォルトの名無しさん

NGNG

熟練したプログラマなら、ある業務のプログラムを設計するとなったとき、
その業務に適した、その業務固有のアーキテクチャパターンを、
自らの力で生み出せるものだ。
それらは大抵の場合、いくつものパターンが複合されて出来ている。

デザインパターンを覚えたての初心者プログラマの場合、
このパターンをどこかに適用できないかとか、
この部分にどれかのパターンが適用できないかとか、
不自然な設計手法を取るため、設計がいびつで柔軟性がない。

初心者にとってデザインパターンは、目も曇らせる元になり、
上級者にとっては元々不要なものだ。

0393デフォルトの名無しさん

NGNG

>>329
アーキテクチャとデザイン・パターンの区別もつかないやつの言うことなんて
説得力がない。

0394デフォルトの名無しさん

NGNG

>>392
恣意的に、「デザインパターンを知らない熟練技術者」と「デザインパターンを
勉強したばかりの初心者」と対比させている点で、「デザインパターンは不要」
といういんちきな結果を主張しているだけです。

0395デフォルトの名無しさん

NGNG

>>392
「デザインパターンを知っている熟練技術者」と「デザインパターンを知らない
初心者」の場合でも、どうなるか比較しないとだめでしょ。

0396デフォルトの名無しさん

NGNG

>>392
それなら、「デザインパターンを知っている熟練技術者」と「デザインパターンを知らない熟練技術者」と
「デザインパターンを知っている初心者」と「デザインパターンを知っている初心者」と
すべての場合を検討する必要がありますね。

0397デフォルトの名無しさん

NGNG

まちがえた。

>>392 は、
「デザインパターンを知っている熟練技術者」と「デザインパターンを知らない熟練技術者」と
「デザインパターンを知っている初心者」と「デザインパターンを知らない初心者」の
すべての組み合わせで検討しないと意味がないですね。

0398デフォルトの名無しさん

NGNG

結論:
>>392 はハッタリということですね。

0399デフォルトの名無しさん

NGNG

デザパタを理解するのは、どんな馬鹿でも出来るけど、
経験のないプログラマが、デザパタに捕らわれないようになるまでには、
ある程度の技術的蓄積が必要。

0400デフォルトの名無しさん

NGNG

>>399
一昔前ならそうだけど
今はデザインパターンを理解できないほどのバカも
この業界に入ってくるんだよね

0401デフォルトの名無しさん

NGNG

>>399
いや、3 歳児の知能の人には理解できない。

0402デフォルトの名無しさん

NGNG

そもそも世の中には初心者と熟練技術者しかいないのか？デザパタが必要なのはその中間だろうが。

0403デフォルトの名無しさん

NGNG

デザパタを覚える奴は痛い奴ばっかりだな。
今月のCマガのOOの記事でグローバル変数は認めるは、神クラス作っちゃうは、ヒデエ設計だったな。
しかもくだらないいいわけしてるし。
デザパタでなんとかならなかったんですか？笑
神クラスは何のパターンですか？プ

0404デフォルトの名無しさん

NGNG

Cマガ読んでないんだけど、ここで言う神クラスの定義ってなに？
・万能クラス
・独裁者クラス

0405デフォルトの名無しさん

NGNG

・創物主クラス。ファクトリ？ビルダ？
・救世主クラス。あらゆる罪を許し、人を愛する...。
・エロ画像や動画をしかるべき板にうpするクラス。

0406デフォルトの名無しさん

NGNG

>>392
憶えたものを無理矢理使おうとしなければいいだけの話。
何にでも言えることだが、活かせる場で使う事が大切。
本質を理解していれば、活かし方もわかるはず。

0407デフォルトの名無しさん

NGNG

＞憶えたものを無理矢理使おうとしなければいいだけの話。

そんなこと初心者に期待して教えられると思う時点で間違い。
初心者は何でも覚えたものを使おうとする。
自分を基準に考えちゃいけない。

0408デフォルトの名無しさん

NGNG

>>407
>初心者は何でも覚えたものを使おうとする。

ん？それがわかってるなら、そう一言言ってやりなさい。
それだけでも違んだよ。

0409デフォルトの名無しさん

NGNG

覚えたてのものを使ってみたくなるのは
楽しいんだからしょうがない。
誰もが通ってる道じゃないか。
さりげなくフォローしてあげりゃいいのよ。

0410デフォルトの名無しさん

NGNG

>>392の想定している初心者って言うのは、
「デザインパターンをどこに適用すべきかが分からないときは、
　無理やりに、不適切な部分に適用しちゃうけど、
　デザインパターンを使用しなければまともに設計のできる人間」
ですか？

0411デフォルトの名無しさん

NGNG

>>403
>>404
俺も神クラスの定義が気になる
ネットで独学って生活が続いてる趣味プログラマだけど
たまには勉強のためにCマガ買ってこようかな

0412デフォルトの名無しさん

NGNG

>>411
立ち読みで十分。

0413デフォルトの名無しさん

NGNG

デザインパターンってリファクタリングで威力を発揮するもの
だと思ってたけど、違うんかね。設計段階から無理やり適用
せんでも、要求仕様に従って順当に設計すればいいんでは。
で、拡張なり改良なりの段になって、設計的に変な箇所だけ
洗い出して、パターンを適用したら効率化できるか検討する
だけでしょ。効率化しないならパターン使う必要ないし。

それでもパターンというものが存在するのは、過去の経験の
集大成的な経験則によって効率化、汎用化が可能だからで
あると思う。ソフトウェア設計における法則性とでも言うべきか。

0414デフォルトの名無しさん

NGNG

>>383
＞それよりも、ユーザの要求をユースケースとして可能な限り
＞全て抽出できているかどうかのほうがはるかに重要。
＞ここで漏れがあるとハッキリ言ってかなり痛いよ。
同意。
ユースケースありきで進めて難しいのは、やはりケースの抽出が適切でなかったとき。
それに気が付かず、「そんな機能はユースケースに無いからいらない！」と機能の実装をやめさせ、
挙句、やっぱり必要だったというパターンはしばしばある。
実装者がユースケースの不備に気が付いているにも関わらず、
上位工程の人間が頭でっかちでそれを受け入れない。
これはかなり困る。

0415デフォルトの名無しさん

NGNG

パターン使って、拡張性、メンテ性があがるとは考えにくいね。
流れ追いにくいし。シンプルな、has-aが一番拡張性、メンテ性が
しやすい。

0416デフォルトの名無しさん

NGNG

神クラスってのは、全てのメンバー、メソッドがpublic。
しかも、サブクラスで定義すべきメンバー、メソッド満載の超スーパークラス。
ステップ数は数千～1万以上。これさえあれば、何もいらない。
そんな感じ？

0417デフォルトの名無しさん

NGNG

神クラスは具体的にはグローバルインスタンスホルダーかな？
面倒臭くなって設計を投げるとできるクラス。
まあ、こんなところで破綻してるぐらいだからオブジェクト指向をわかってないかな。

0418デフォルトの名無しさん

NGNG

> グローバルインスタンスホルダー
あー、俺、やっちゃってるなあ。
どうしたらいいのかわからんのよね。
Singletonでやるべきなのか？

0419デフォルトの名無しさん

NGNG

>>416
それ、神っつーよりも奴隷。

0420デフォルトの名無しさん

NGNG

シングルトンはやらないほうがいい。
しっかり設計しろ。
さぼってるだけだ。
ありゃ駄目なパターンだ。
グローバル変数と何もかわらない。

0421デフォルトの名無しさん

NGNG

>>414
方法論ばかりこだわって内容が伴ってないアリガチな感じ。
案外ユースケースに不備が多くても、風通しの良いプロジェクトなら
致命的な問題にはならないんだが。

0422デフォルトの名無しさん

NGNG

>420
それは、おまえがSingletonをstaticで実装しているからだろ？w
他のパターンと組み合わせてみろよ。

0423デフォルトの名無しさん

NGNG

>>288
> 「ここのデータ構造はスタックを使っていまして・・・」
> 「はい？　スタック？　なんですかそれは？　イチから説明してください。　」
> あなたはこんな奴と仕事が出来ますか？
できない。できないといえばそれは確かにそう言える。
大学で情報学を専攻していた奴ならそれくらいはしっているはずだが。

0424デフォルトの名無しさん

NGNG

>>420
クラスをパッケージに格納して特定のパッケージ内でしかアクセスできないようにしろ。

0425デフォルトの名無しさん

NGNG

>>422
違う馬鹿トンママヌケ
論点がズレテンダヨ。
引数で渡されたわけでもねーのにいきなりでてくんな馬鹿。
まだわかんねーのか？
シングルトンが関わったクラスはすべてシングルトンの根が生えて単体で動かなくなるじゃねーか。
引数で必要な情報だけよこしゃいいんだよ。
てめーの作ったクラスは引数に必要な情報突っ込んできちんと順番道理に初期化してやってもまだうごかねぇ。
別途でどこかにシングルトンさんが必要になるわけだが、さてマニュアルにはどうかくの？
って感じでしけてんだよお前のクラスはYo！

0426デフォルトの名無しさん

NGNG

>>425
馬鹿はお前だ。お前の論理を突き詰めていくと、
メソッドの中ではオブジェクト一つ作れない話になるじゃねーか。

0427デフォルトの名無しさん

NGNG

雑誌にﾃﾞｻﾞﾊﾟﾀwを適用した良いサンプルコードが
載ったことが一度でもあるのかと小一時間（ｒｙ

ホントはだれもつかっちゃいない罠。
みーんなﾊﾞｰﾁｬ(脳内）。だいたいjava自体が
ﾊﾞｰﾁｬﾙだしなw
もまいら！ﾊﾟﾀｰﾝをうまく適用できてるｵｰﾌﾟﾝｿｰｽｺｰﾄﾞﾌﾟﾛｼﾞｪｸﾄを
おしてくれませんか？(c++で）

0428bloom

NGNG

http://homepage.mac.com/ayaya16/

0429デフォルトの名無しさん

NGNG

>>427
そういや、まとまった成果物をみたことがないな。まあ、厨房のおいらにゃ
もともと縁の無い世界か・・・

0430デフォルトの名無しさん

NGNG

>>427
なぜC++限定？

0431名無し

NGNG

じゃあ、これからこのスレで作ろう

0432デフォルトの名無しさん

NGNG

>>431
マジで応援する。是非見てみたい。ガンガレ！

0433デフォルトの名無しさん

NGNG

で、お題はオセロとか言い出したらコロスよ

0434デフォルトの名無しさん

NGNG

みんなが微妙に勘違いしつつ取り入れているのがデザパタ。

0435デフォルトの名無しさん

NGNG

最近のデザパタはJavaを普及させるお手伝いと化しているな。

0436デフォルトの名無しさん

NGNG

むしろ、みんな好き勝手に作っているということが、
デザパタという枠組みがあることで明るみにでたんだと思う。

0437デフォルトの名無しさん

NGNG

>>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を使うな、つまりクラスライブラリを
使うなといってるのと同じ。

0438デフォルトの名無しさん

NGNG

もともと、GoF本ってC++の例しか載ってなかったんじゃないか。

0439デフォルトの名無しさん

NGNG

JavaとC++ではどっちがデザパタに馴染みやすいんだろう？
みなさまのご意見お待ちしています。

0440デフォルトの名無しさん

NGNG

>>437
馬鹿が馬鹿にも分かるように説明するのは
卵が先か鶏が先かと同じく相互参照になり
不可能だという好例

0441デフォルトの名無しさん

NGNG

>>439
ネットとか検索してるとコード例のほとんどがJavaだね。日本だけか？

0442デフォルトの名無しさん

NGNG

>>440
まあ、そういうことだがw

0443デフォルトの名無しさん

NGNG

>>437, >>440
まあまあ、少し春風にでもあたってきなされ。

0444デフォルトの名無しさん

NGNG

>>438
Smalltalkも乗ってたろ

0445デフォルトの名無しさん

NGNG

>>444
ほんのちょっとだけな
ちなみに最新版だと、Javaのソースも(CD-ROMのみだが)付いてくる。

0446デフォルトの名無しさん

NGNG

java馬鹿がいきがってｺｰﾄﾞ出してんじゃねーよ。
価値ない。

0447デフォルトの名無しさん

NGNG

考えてみれば>>425がJava厨なのが原因か。
Javaには、コンストラクタ、staticメソッド、インスタンスメソッドの
三つがあるが、Smalltalkにはクラスメソッド、インスタンスメソッド
だけだしな。SmalltalkならSingletonも違和感ないだろう。

0448デフォルトの名無しさん

NGNG

Javaを使えない自分にとっては寂しい限りだ。かといってJavaには魅力を感じないし。

0449デフォルトの名無しさん

NGNG

いろんな言語を知っておくのはよいことだよ？

0450デフォルトの名無しさん

NGNG

段々オブジェクト指向が分かってきた。

0451デフォルトの名無しさん

NGNG

>>449
分かっちゃいるけど、なんかこうワクワク感がないって言うか・・・

0452デフォルトの名無しさん

NGNG

>>438-439
オブジェクト指向をうたっている言語なら、ほとんどどの言語でも大丈夫。
サンプルの C++ と、自分の作っている言語と両方できれば、難なく読み替えできる。

0453デフォルトの名無しさん

NGNG

>>451
Rubyとかやってみたら？

0454デフォルトの名無しさん

NGNG

>>453
いいね。面倒なコンパイルも必要ないし。

0455デフォルトの名無しさん

NGNG

知ることは、非常にためになる。使うには価値無い。
javaを知ったところであなたを雇ってくれるまともな会社は無い。
上級者だろうが初級者だろうが、所詮クラスライブラリ
やAPIを利用するだけ。
ﾃﾞｻﾞﾊﾟﾀしってるからってあなたを雇ってくれるまともな会社は無い。
オブジェクト指向知ってるからってあなたを(ry

エンジニアとしてなにが必要か考えたほうがいい。
技術職だぞ。自分を医者だと思って考えて見ろ。

0456デフォルトの名無しさん

NGNG

>>437
はぁ？そんなの何処でどうして必要なの？
俺の設計の基本として必要なものは必要なときに用意したり渡せばいいと考えてるから
そのいつまでも用がないのにアクセスの権限を与えてることが理解できない。
関数で引数として必要なときに渡せばいいように設計しなおしてくれない？
それかメンバ変数でいいならそれでいいけど。
外のオブシェクトになるなら引数でしっかり渡してくれたほうがソースを読むときわかりやすいよ。
なんでそんなトリッキーなくみかたするの？
引数で渡しにくい設計にもってっちゃった時点で駄目だかんね。

0457デフォルトの名無しさん

NGNG

>>455
うーん・・・・スタミナ？

0458デフォルトの名無しさん

NGNG

>>455
ｽﾚﾁｶﾞｲｶｺﾜﾙｲ

0459デフォルトの名無しさん

NGNG

>420
使い途を考えなされ。
大域領域に置くSingletonだったら、グローバルでアクセスされる
リソースに限定すればよろし。
main関数の引数とか、アプリの設定ファイルとか……

ローカル／スコープ内のみのSingletonにするっちゅう手もあるし。

あと、オブジェクトだっちゅうことも重要だねぇ
グローバル変数だと違法な値に変更しようとするのを防ぐ手段が無いけど、
Singletonだとなんとかブロックできるからねぇ

0460デフォルトの名無しさん

NGNG

>>456
>そんなの何処でどうして必要なの？
昔、かあちゃんにこんな感じで怒られたことがある。

0461デフォルトの名無しさん

NGNG

そもそも、すべてをクラスとして表現するという
時点でもう破綻してるわけだ。
たとえばjavaとか。その他ではjavaとか。
あと、javaとか。
んで、ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝなんかの知恵いれちゃうと
なるほど！とかって勘違いするわけだ。
多少、頭の柔らかい奴ほど。

クラス原理主義の破綻をごまかす為の
アイデア的ハックだということにいいかげん気づけ。

0462デフォルトの名無しさん

NGNG

>>456
> はぁ？そんなの何処でどうして必要なの？
Foo を呼び出すクラスが Bar を知らなくていい場合、
Foo を呼び出すクラスが Bar を知らなくてすむ。

0463デフォルトの名無しさん

NGNG

>>461
君の脳が破綻している。

0464デフォルトの名無しさん

NGNG

>>456
おまい、構造化で引数渡しがしみ込んでる香具師だろ？
それともクラスがオブジェクトじゃないと思っている香具師？
Singletonでは、クラスオブジェクトのクラス変数が同じクラスの
インスタンスなだけなんだが？
いつでもインスタンスにアクセスできるのに、わざわざ引数私香代。
じゃあ、どこからでも見れるのでクラスオブジェクトは使えないね？w
インスタンスも作れないね？ww

0465デフォルトの名無しさん

NGNG

>>461
OOPL の文法ってのは、デザイン・パターンをやれるようにできるために、ああなっている。

0466動画直リン

NGNG

http://homepage.mac.com/hitomi18/

0467デフォルトの名無しさん

NGNG

>>465

嘘だろ。オブジェクト指向的なプログラミング
に対応してるだけだ。
ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝは後発なはず。

0468デフォルトの名無しさん

NGNG

う～ん・・・乗り遅れちゃった奴が約1名。ご愁傷様。

0469デフォルトの名無しさん

NGNG

>>467
デザイン・パターンの名前がついたのは後だけど、ああいうことはやられていた。
ああいうことをやるために OOPL ができた。

0470デフォルトの名無しさん

NGNG

C++ができる前にGoFﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝは
できてたってことか！？
ｿｰｽ出せｿｰｽ！ｗ
変な言語の話とかだすなよ。

0471デフォルトの名無しさん

NGNG

>>470
GoF本嫁。

0472デフォルトの名無しさん

NGNG

４８手ができる前に、全ての体位はやり尽くされていたのと同じ。

0473デフォルトの名無しさん

NGNG

>それぞれのパターンは、私達の身の回りで何回も起きる問題
>およびそれらの問題に対する解決ポイントを記述している。

>パターンとは、優れたソフトウェア成果物
>（アーキテクチャ、分析、設計、実装、プロセスなど）を明文化したもの。

0474デフォルトの名無しさん

NGNG

>>470
結局おまえは何が言いたいんだ？

0475デフォルトの名無しさん

NGNG

言語ｽﾍﾟｯｸ決まる前にあったなら
ﾃﾞｻﾞｲﾝﾊﾟﾀｰﾝを適用した素敵な
ｺｰﾄﾞがごろごろ転がっていなきゃおかしいだろうよ。
どこにあるっていうんだよ！（java以外で）

0476デフォルトの名無しさん

NGNG

>>470
俺の知らない所で明文化しやがってこんちくしょう！ってことか？

0477デフォルトの名無しさん

NGNG

>>475
もしかして、見せて下さいお願いしますってことか？

0478デフォルトの名無しさん

NGNG

>>475
一子相伝なんだよ。

0479デフォルトの名無しさん

NGNG

>>475
アラン・ケイおじさんの研究所に行けば？

0480デフォルトの名無しさん

NGNG

最近の若い人は、デザイン・パターンが新しいもんやと思ってはるんですな。

0481デフォルトの名無しさん

NGNG

>>475
コピペしたいのか？

0482デフォルトの名無しさん

NGNG

>>477
あるのか？

0483デフォルトの名無しさん

NGNG

>>481
コピペするさ。ペタペタペッタンコしまくるさ。

0484デフォルトの名無しさん

NGNG

>>482
Model-View-Controllerパターンを知らないのか？

0485デフォルトの名無しさん

NGNG

多分にほんの少しの誤解だと思うんだ。
言語ができる前にデザインパターンはなかった。
言語ができてデザインパターンを実現できるようになった。
パターンに名前が付いたのはずっと後。
みんな日本語が不自由なだけ。

0486デフォルトの名無しさん

NGNG

>>483
パターンはコピペできるようなものじゃねぇ

0487デフォルトの名無しさん

NGNG

Cマガの特集はすごかったな。
オブジェクト思考でもコードの再利用は簡単ではないってのは
いいとして、コードの再利用ばかりしてたらソフトウエアの
進化が止まってしまうから、再利用しなくてもいいのだって
結論になってしまうのはびっくりした。

0488デフォルトの名無しさん

NGNG

>>483
　　　　　　　,-､/＾＾､,-､
　　　　　/｀　/ 　　ヽ　´ヽ
　　　　<´￣｀　　　　　´￣｀>
　　　く　　　認　　厨　　 ,>
　　　< ＼.. 　　　　　　／ >
　　　く /　　定　　房　ヽ ,>
　　　　〈__ 　　人　　　__〉
　　　　　　ヽ__,.<_,､_ゝ､_ノ

0489デフォルトの名無しさん

NGNG

>>484
てめーはsmalltalkプログラマなんだな？あ？
javaとか言うなよ。
お前はしょぼいWEBｼｽﾃﾑでも作ってりゃいいんだよ。

0490デフォルトの名無しさん

NGNG

>>488
http://www.4gamer.net/specials/gdc24/cry.html

まあ見ておけ

0491デフォルトの名無しさん

NGNG

Cマガも厨房認定してやってくれw

26 名前 : 名無し＠沢村 Mail : 投稿日 : 03/04/21 21:58

>>25
Cマガ５月号「オブジェクト指向２０の疑問」のQ5だが、何じゃこりゃ！？
「オブジェクト志向と書いたら叱られました。本当にこれではダメなのでしょうか？」
…これは完全にCマガ編集部のネタだね。

28 名前 : 名無し＠沢村 Mail : 投稿日 : 03/04/21 22:01

また「オブジェクト指向２０の疑問」のQ６
「オブジェクト指向プログラマの集会でC++をやってますといったら白い目で見られました。私は何か悪いことをしたのでしょうか？」
…これもジサクジエーン。

0492デフォルトの名無しさん

NGNG

>>489
　（´Д｀;）ヾ　ﾄﾞｳﾓｽﾐﾏｾﾝ
　　　∨）　
　　　（（　

0493デフォルトの名無しさん

NGNG

>>490
ドイツの職人芸がどうしたの？

0494デフォルトの名無しさん

NGNG

>>487
そりゃあすばらしい（ｗ

0495デフォルトの名無しさん

NGNG

>>494
つれた

0496デフォルトの名無しさん

NGNG

みんな一つの言語しか使えないと思っている痛い香具師がいる
スレはここですか？

0497431

NGNG

お題はシューティングね
みんながんばって

0498デフォルトの名無しさん

NGNG

>>495
つれたｷﾀｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰ！

0499デフォルトの名無しさん

NGNG

すげえなCマガ。
編集者もある程度はチェックしろよ

0500デフォルトの名無しさん

NGNG

500！

0501デフォルトの名無しさん

NGNG

>>500
ﾌﾟ(ｹﾞﾗ嘲笑下木原

0502デフォルトの名無しさん

NGNG

>>487
いまはコードの再利用は重要ではないね。

0503デフォルトの名無しさん

NGNG

設計は YAGNI で ad hoc に、経験を再利用。

0504デフォルトの名無しさん

NGNG

>>502
Cマガ編集者ｷﾀｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰ！

0505デフォルトの名無しさん

NGNG

デザイン・パターンで言う「再利用」は、コードではなくパターンの再利用のこと。

0506デフォルトの名無しさん

NGNG

　　　　　＿＿○＿○＿＿
　　　　　 |　.＿＿＿　..|　　|
　　　　　 |　.|７|　|　| 　|　　|
　　　∧ ∧ .|　|７|７| 　|　　|
　　 (　　,,) .|　|　|　| 　|　　|
　　　/　　つ￣￣￣　 |　..::|
　～(＿＿).　°°°　|　::::|
　　 |＿＿| ￣￣￣￣ |..::::::|
　　　　||　　　　　　 .|::::::::|
　　　　|| ￣￣￣￣￣￣￣￣
　　　￣￣　　|＼
　　　　　／￣　　￣￣￣￣￣￣￣￣
　　　　　|　　きてねぇよ

0507デフォルトの名無しさん

NGNG

ところでいつからここはデザパタのスレになったんだ？

0508デフォルトの名無しさん

NGNG

>>499
いまだにコードの再利用を信奉しているのか。

再利用できるコードっていうのは、いまは使わないかもしれない
機能を盛り込んでいるということ。
そんなコードを作るのはコストがかかる。
明日必要かもしれない機能を、今日実装するな。
今日必要な機能を、今日実装せよ。
というのがいまの常識だよ。

0509デフォルトの名無しさん

NGNG

どうせ要らないって。 < 明日必要かもしれない機能

0510デフォルトの名無しさん

NGNG

>>490

こりゃすげえな。
これがjava製だったら他職種に転職してもいい。

0511デフォルトの名無しさん

NGNG

>>508

わかったから、以下の点にコメントしろよ。

「コードの再利用ばかりしてたらソフトウエアの進化が止まってしまう」

0512デフォルトの名無しさん

NGNG

>>511
お前がコピペ厨だってことは良く分かったからもう寝ろ。

0513デフォルトの名無しさん

NGNG

じゃ、寝るか。満足。

0514デフォルトの名無しさん

NGNG

>>511
知らねーよ。

0515デフォルトの名無しさん

NGNG

>>511
C マガに電話して聞けよ。

0516デフォルトの名無しさん

NGNG

>>511
退化した頭で考えた素晴らしい結論なんじゃないの。

0517デフォルトの名無しさん

NGNG

>>515
実は俺電話でクレーム入れた。雑誌代返せって。
そしたら、定説だっていわれたYO

0518デフォルトの名無しさん

NGNG

>>517
古いネタやなぁ。

0519DesignPattern厨とかしつこく言われてた者ですが

NGNG

今日も痛い議論を繰り返してるな。
新鮮味もリアリティーもありゃしない、ヲタクの繰り言。
1～2年前に2ちゃんで済ました議論ばっか。(当然2ちゃんの外ではもっと前に終わってる議論だけど)

結局こーゆー掲示板って、大多数の人は入れ替わるけど、極小数の粘着者が前スレの粗悪コピー作り続けるからあたかも盛り上がってるように見えるわけなのね。枯木も花の賑わい

0520デフォルトの名無しさん

NGNG

>>517
消費者センターに電話すべし。

0521デフォルトの名無しさん

NGNG

>>427
Java コアAPIの殆どはデザインパターンのかたまりなんだよなー。
よくJava Documentをみてみなさいってこった

0522デフォルトの名無しさん

NGNG

>>519
ﾖｶｯﾀﾅ

0523デフォルトの名無しさん

NGNG

>>519
そういわずに、まずはSingletonで一席ぶってくれ

0524デフォルトの名無しさん

NGNG

>>519
君はあれか、それ言わんと寝れんのか。

0525デフォルトの名無しさん

NGNG

>>519
気取ってろ。おまえに進化は無い。

0526デフォルトの名無しさん

NGNG

>>519
それを知りながら棲み続けて、わかったような事を語るのも

　か　な　り　痛々しいぞ（ｗ

0527デフォルトの名無しさん

NGNG

2分で5匹か・・・

0528デフォルトの名無しさん

NGNG

なるほど、2年たってデザインパターンを使えない使えないといつまでも叫んでいるわけか。

デザインパターン、アーキテクチャーパターンを否定する厨房君は
まあ本当に、いつまでたっても、何歳になっても、時代遅れなジジイどもだなあ。

デザインパターンを否定する厨房君は
eXtreme Programmingという言葉もRational Unified Processという言葉も
Unified Modelling Language という言葉も手法も手段も知らないんだろーなー。
かわいそうに。

ひょっとして未だにウォーターフォールモデルなんかやってるの? ﾌﾟﾌﾟ恥ずかしい(w

0529デフォルトの名無しさん

NGNG

>>527
2分？5匹？　数も数えられな（略

0530デフォルトの名無しさん

NGNG

はい6匹目。

0531デフォルトの名無しさん

NGNG

釣りやってないで、有用なコメントの一つも残してくれ。

0532デフォルトの名無しさん

NGNG

>>519はコピペだよ。名前欄以外はね・・・

0533デフォルトの名無しさん

NGNG

>>532
君はあれか、それ言わんと寝れんのか。

0534デフォルトの名無しさん

NGNG

> eXtreme Programmingという言葉もRational Unified Processという言葉も
> Unified Modelling Language という言葉も手法も手段も知らないんだろーなー。

だれもつっこまなくていいのか？

0535名無し

NGNG

>>490
すげー
なんだこりゃ
これがあれば俺にも三国無双つくれそうだ

0536デフォルトの名無しさん

NGNG

雑魚がいっぱい釣れてる・・・。

まぁ、例のクラスとインスタンスが云々→Singletonでは云々
とかいう悲惨なフレーズを連呼しているのが、ここに常駐している粘着君だという事はわかった。

君等、毎晩こんな不毛な議論してて楽しいの?
漏れらが何もしらないうちからしこしこOOの世界を構築してきた先人と比べて、
なんかすっげーつまんない人種に見えるぞ、をまえらさー。

0537デフォルトの名無しさん

NGNG

>>534
がんばって覚えたばかりの用語を並べてるんだから、生暖かく見てあげようよ。

0538デフォルトの名無しさん

NGNG

Model Driven Design が抜けてるぞ(ぷ

0539デフォルトの名無しさん

NGNG

>>536
批判ばかりしかできない君は、もっとつまらない人間だが？

0540デフォルトの名無しさん

NGNG

それをいうならModel Driven Development(ぷ

0541名無し

NGNG

だれか>>490みたいなのの２D版作ってよ
もちろんOOで

0542デフォルトの名無しさん

NGNG

>>539 このスレの主張って、大体元ネタとかわかっちゃう陳腐な内容だから、つまんないの。
自らの設計なりコーディングで経験した、誰もが感じてるけど、言葉にし難い何か、
を説明できればエクセレントなんだけどね。

0543デフォルトの名無しさん

NGNG

>>542
じゃあ、、まず君のエクセレントな経験を語ってくれないか？

0544デフォルトの名無しさん

NGNG

>>543
エクセレントな体験などと誰も言っていないんだが。

漏れなりの体験談は、1～2年前にネタスレの合間に散々書き散らしておいてあげたんだが、君は記憶力がないのか？

例えば、「関数型言語の部分計算のためのキャッシュを、ドメイン・スペシフィックな情報に基づいて最適化すると、オブジェクト指向と似たものになる(ような気がする)」ってのが、漏れなりのオブジェクト指向言語の機能的側面の解釈なんだけど、
これは「オブジェクト指向とは何か」という>>1の問いかけに対する答えの一つになるとは思わん会？

0545デフォルトの名無しさん

NGNG

すべてのデザインパターンは Composite パターンに帰着する。

0546デフォルトの名無しさん

NGNG

>>544
なんかイメージつかめない…
部分計算のためのキャッシュってのは、 call by need とかかな…
ドメイン・スペシフィックな情報ってどんなの？

0547デフォルトの名無しさん

NGNG

>>546
ドメイン名だね。なんとか.jp とか。

0548デフォルトの名無しさん

NGNG

CppUnitは狂ったようにパターンを使っているけど

・・・いや、ごめんなさい

0549デフォルトの名無しさん

NGNG

>>544
全く思わん。2年も粘着してそれかよ。

0550デフォルトの名無しさん

NGNG

そんな >>544 へ。
http://www15.big.or.jp/~kaini/image/img-box/img20030422123158.jpg

0551デフォルトの名無しさん

NGNG

>>544
一年以上前の、便所の落書きを覚えていてもらってると思ってるなんて、
並みの自意識過剰じゃないですね、あんた。

0552544

NGNG

とにかく、実体験を通して掴み取った事柄を話せよ。
そーすれば、このスレは、初心者だけでなく経験者にとっても有意義な、
共通体験を広める場として有効に機能するぜ

0553デフォルトの名無しさん

NGNG

ユースケース図って本当に必要？

0554デフォルトの名無しさん

NGNG

ユースケ、ナナミ、コウタ、出撃じゃ！

0555(´д｀;)ﾊｧﾊｧ

NGNG

http://www.k-514.com/

0556デフォルトの名無しさん

NGNG

>553
本当に必要かどうかは、それが無くなった時にしかわからない。
ってことでそのユースケース図を窓から（略

0557デフォルトの名無しさん

NGNG

>>550
オブジェ嗜好...

0558デフォルトの名無しさん

NGNG

>>557
ああ、やっとわかったよ。
座布団2枚だな

0559デフォルトの名無しさん

NGNG

宗方指向ってのはどうよ？

0560デフォルトの名無しさん

NGNG

じゃぁ、仕様書をみせてみなさい. >> 1

0561デフォルトの名無しさん

NGNG

>>550
Delphi関連だと思っていたのにっ！！

0562デフォルトの名無しさん

NGNG

ユースケース図いらん。
本当に必要ない

0563デフォルトの名無しさん

NGNG

ユースケース図はあまり要らないね。
形式的すぎるきらいがある。
開発者と顧客とのやりとりは、ストーリー・カードの方が適切。親しみやすい。
開発者チーム専用（チームにいる顧客にも）にはタスク・カードで細かく砕く。

0564デフォルトの名無しさん

NGNG

ストーリーカードって何?
なんか、作るのかなりめんどくさそうに思えるんだけど・・・
100～200ユースケースくらいありそうなシステムにも
適用できる?

0565デフォルトの名無しさん

NGNG

>>564
http://oita.cool.ne.jp/ja6hfa/ja6hfa/XP/xpcards.html より:

ストーリーカード＆タスクカード

最初にユーザにストーリーカードを書いてもらいます。書くべきことは、
このように運用できる、このような機能が必要だ。または満足できる
という情報です。ユーザは、この運用のしかた、適応範囲の設定などを
決定する責任を負います。

次にユーザにこのストーリーを３つに分けてもらいます。

o それなしではシステムが機能しないもの
o 多くのビジネス価値を持っているもの
o あればよいもの

ストーリーが長かったり、見積もりが出しにくいものは分割します。その後、
開発側が実装にかかる日数などを出し、ユーザにリリースするカードを選択
してもらいます。ストーリーの追加、優先度変更、見積もりの変更などは必要に
応じて適宜行われます。

ストーリーが決まったら、開発者はまず、ストーリーを分析し、数日で仕上げられる
単位（タスク）に分割し、タスクカードに記述します。ユースケースの外部の
システムの更新など、直接ストーリーに関係ないが、必要なものなどもタスクに
入れます。その後担当するプログラマを決定し、見積もりを出し、コーディングを
行います。ストーリー分のタスクを全て消化したらリリースです。その後、ストーリ
追加＆コーディング＆リリースを繰り返し、システムを完成させます。プロジェクト
の進捗管理としても、このタスクとストーリーは使えます。全体のタスク｜ストーリー
と現在完了しているタスク｜ストーリーをグラフにして壁に張り出します。

0566デフォルトの名無しさん

NGNG

>>565
レスサンクスです。内容の大きさ的には、
タスク＝ユースケース
ストーリー＝業務フロー
みたいな感じなのかな?ちょっと面白そうだね。

0567プロの逝って良しの１ ◆MvRbZL6NeQ

NGNG

そんな教科書みたいなケースなんか無いよ。
現実は地獄だよ　ジ・ゴ・ク

0568デフォルトの名無しさん

NGNG

上手くいったプロジェクトもあるけどな。
良し悪しはメンバーによるよ。
地獄になるのは、口先だけの奴がのさばっているからじゃないかな？
あるいは567自身が口先だけの奴か。

0569デフォルトの名無しさん

NGNG

>567
その通り。現実はあまりにも酷い。
だが、それを改善していく事を放棄してはいつまでも地獄のまま。

0570デフォルトの名無しさん

NGNG

オブジェクト指向は変更に強いとよくいわれますが、これは本当でしょうか？
どうしても信じられません。本当ならどうしてですか。

0571デフォルトの名無しさん

NGNG

実装を変えるだけで良いから。

0572デフォルトの名無しさん

NGNG

>>570
オブジェクト指向の本を1、2冊読んでから信じられるか信じられないか決めろ。
そんなことオブジェクト指向の本の冒頭に書いてある。　
自分で調べて、自分で考えて、自分で判断しろ。

0573デフォルトの名無しさん

NGNG

>>572
3冊読んだうえで信じられないと言っているんですが。

0574デフォルトの名無しさん

NGNG

>>573
漏れの竿取るんじゃねーよw

0575デフォルトの名無しさん

NGNG

>>571
インタフェースが変更されると目も当てられないということでつか？

0576デフォルトの名無しさん

NGNG

>>573
それだけ読んだなら実践してみれば？
よほど頭の柔らかいやつでもない限り、
本を読んだだけでOOが分かるはずないし。

0577デフォルトの名無しさん

NGNG

OO ってうまく modularize してくための方法論だと思う。
うまく modularize してあって、変更が少数の module 内で済むなら、それなりに強そう。
modularize 失敗してたり、全体に影響が出るような変更だったりすると弱そう。

0578デフォルトの名無しさん

NGNG

>>575
そりゃ設計の失敗ですな。

0579デフォルトの名無しさん

NGNG

つまり設計に依存するというわけで今までと何ら変わりないということですか？

0580デフォルトの名無しさん

NGNG

>>577
モジュール化しても、モジュールに変更があった場合、
モジュールを使用している箇所に影響出るだろ？

0581デフォルトの名無しさん

NGNG

>>578
その一言で片付けばどれだけうれしいかねぇ。

0582デフォルトの名無しさん

NGNG

その設計を考え方こそオブジェクト指向だろ

0583デフォルトの名無しさん

NGNG

>>577
俺もその通りだと思う。
モジュール化をうまくおこなうための方法論。それ以上のものじゃない。
構造化でうまく設計出来る人なら別にOO使う必要ない。

0584デフォルトの名無しさん

NGNG

使えって

0585プロの逝って良しの１ ◆MvRbZL6NeQ

NGNG

さげで主張し合ってやんの（藁

0586デフォルトの名無しさん

NGNG

上手い構造化
その一つがオブジェクト指向なのだよ

0587デフォルトの名無しさん

NGNG

モジュール化云々はあまりにも狭義のOOだと思うが。

0588デフォルトの名無しさん

NGNG

単なるコーダーにとってはそれ以上のものじゃ無いだろうな。

0589デフォルトの名無しさん

NGNG

クラス図はわざわざ書くものではないと思う。
ツールでソースから起こすのが正しいと思う。
ツールでクラス図からソースを起こすのはよくないと思う。
実態に即した図を常に用意すべきだと思う。
ソースも最初はスタブで一気に書き上げるし。

0590デフォルトの名無しさん

NGNG

一言
　　　継承

ハイ、教えた（ｗ

0591デフォルトの名無しさん

NGNG

いや多態だろ

0592デフォルトの名無しさん

NGNG

継承や多態なんて一機能の名前じゃねぇかバーカバーカバーカ

0593デフォルトの名無しさん

NGNG

>>592
そもそも一言で語れるわけねぇだろ。ageてまで言うことかよ

0594592

NGNG

晒してやったです

0595デフォルトの名無しさん

NGNG

情報隠蔽

0596プロの逝って良しの１ ◆MvRbZL6NeQ

NGNG

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)

0597デフォルトの名無しさん

NGNG

ヒマだな(w

0598デフォルトの名無しさん

NGNG

http://www.k-514.com/

0599570

NGNG

結局、誰もまともに答えられないのですね。
オブジェクト指向が変更に特に強いということはないと理解しました。
ありがとうございます。

0600デフォルトの名無しさん

NGNG

>>599
おまえごときにオブジェクト指向はもったいない。
どうせ覚えてもろくな組み方しねーよ。

0601デフォルトの名無しさん

NGNG

OO厨の捨て台詞ｶｺﾜﾙｲw

0602デフォルトの名無しさん

NGNG

カプセル化さいこー。

0603デフォルトの名無しさん

NGNG

>>599
ところで君は本を3冊読んで、オブジェクト指向が変更に強いわけはない、
という結論にいたったわけだよね。
なぜそう思ったのか、その理由を教えてくれよ。

0604599

NGNG

>>603
オブジェクト指向における、変更に対する強さというのは、
インタフェースに対するプログラミング、別な側面からいえば
実装をモジュールの中に隠すことで得られるとされています。
しかし、この考え方はオブジェクト指向に限ったものではなく、
構造化技法においても広く認知適用されてきたものです。
そして現場における仕様変更要求が、インタフェース設計の
枠組を破壊せずに済むということは実際には難しく、
インタフェースを変更せざるを得ない局面に往々にして
遭遇します。
そうした場合、オブジェクト指向においても、そのモジュール
(OOですからオブジェクト)を使用している箇所の見直しや
修正などが発生するのは避けられません。
そういう意味では、変更に対する強さという点で、既存の
アプローチに比較してオブジェクト指向が特に優れているわけでは
ないと考えました。
最近では、YAGNI (You Are NOT Gonna Need It)などといって、
将来の変更を考慮しない設計アプローチがもてはやされていますが、
これなども結局この問題に対する逃げにしか見えません。

0605603

NGNG

>>604
俺は構造化については詳しくないのだけど、
おっしゃることはその通りなのではないかと思います。
オブジェクト指向でも、当然のことながら、インターフェースが
頻繁に変更されると変更負荷が高くなります。
ただ、一言でインターフェースと言っても色々なレベルがあるはずで、
あるクラスAのインターフェースは、別のクラスBのインターフェースの
内部に隠蔽されている、Bもまた別のクラスCに隠蔽されている・・・
と言った感じできちんと隠蔽が出来るような設計がされていれば
インターフェースの変更の影響を部分的にとどめることが出来るのでは
ないかと思います。
あと、構造化には、オブジェクト指向のような抽象化の概念はありますか?
プログラムを組む時には、「よく似ているけど、微妙に違う処理」みたいな
ものが良く出てくると思うのですが、抽象化の概念をうまく使うことで
こういったものをうまく共通化できる場合があります。
共通化を推し進めれば、変更が局所化できて楽になるはずです。

0606604

NGNG

>>605
早々のコメントありがとうございます。
おっしゃられていることは、インタフェースの継承のことと
考えましたが、よろしいですか。
実は、私は継承技術に関しても懐疑的なのです。
といいますのは、モジュールというのは、他のモジュールとの結合度が
弱いものほど優れたモジュールであるという一つの基準がありますが、
継承という考え方は、この原則に反していると考えるからです。
いわゆるスーパークラスとサブクラスの結合度の強さが、
変更に対する弱さにつながっていると考えています。
いわゆるスーパークラスのインタフェース変更が、サブクラスや、
さらに先まで影響を与えてしまうことはよく知られていると思います。
そういうこともあり、最近のオブジェクト指向論では継承をあまり
重視しない方向に変わってきているようですね。かわりに、
デリゲートなどの代替技術が用いられるようです。
「よく似ているけど、微妙に違う処理」には、共通部分を
モジュール化して、それを呼び出す違いを吸収したモジュールを作成、
それを使用する方法がとれると思います。オブジェクト指向とは
アプローチが逆かもしれませんね。

0607デフォルトの名無しさん

NGNG

>604
オブジェクト指向だと、関数がデータに直接アクセスすることがないから
データ構造を変更したときもトレースしやすいんだよね。

最近の構造化プログラミングでも、オブジェクト指向的な考えを取り入れた
ものは必ずアクセッサ関数を経由してデータにアクセスするようにしている
から、オブジェクト指向言語特有のものではないけどね。

＞将来の変更を考慮しない設計アプローチがもてはやされていますが、
Generic Programmingを勉強なされ。設計の段階で何を決定すべきで
なにを制限してはいけないのか。Genericというとライブラリの話が多く
なるけど、設計そのものの考え方の勉強にもなるよ。

取りあえずは「Modern C++ Design」のまえがき、訳者まえがき、第１章あたりを
立ち読みしてみるのがいいかなぁ（けっこうそこらじゅうにあるし）

0608デフォルトの名無しさん

NGNG

>>606
最初から、継承"重視"ではなかったのでは？
継承より合成を利用していくべきだと
昔から言われていると思いますが。

0609デフォルトの名無しさん

NGNG

>606
>継承

たとえば「メモリ」という抽象的なグループと、PC2100のDDR-SDRAMという
具体的なメモリといった感じで、抽象化<->具体化の軸で表される関係
（いわゆるas-isの関係)を表現するのには継承が便利。
具体化されたものには抽象化されたものが全て含まれるからね。

＃最近の動向は、ようやっと継承の使い方がわかってきたということでしょうな。

0610デフォルトの名無しさん

NGNG

>>603
横から失礼する。
激しく同意します。
構造化における共通化については、常に課題となりますね。
共通化をうまく進めるとかなり楽になるし、洗練されてくるので
性能も結果的によくなる。
そこで、誰か答えてほしいんだが
オブジェクト指向における、隠蔽化を守って設計するための
人間のアクションはどうあるべきなんだろう。
設計ミーティングが「オブジェクト座談会」になってしまうこと
が多すぎる今日この頃です。
こうすれを誰か答えてくれい。

0611デフォルトの名無しさん

NGNG

オブジェクト指向って言葉の神通力はまだ世間に通用しますか？

0612デフォルトの名無しさん

NGNG

>>611
通用しなくてなっています。
オブジェクト指向という言葉を聞いただけで拒絶反応を起こされて
しまうといったような神通力は、もう昔話になりつつありますね。

0613603

NGNG

>>606
はい、継承技術のことを言っていました。
継承を使うとモジュールの結合度が高くなると言うのは
まったくもって同意なのですが、それに対するインターフェースの
変更の被害は、クラスをなるべく細かくわけることによって
少なくすることができると考えています。
つまり、30個のインターフェースを持った大きなクラスを継承すると、
当然変更の被害は大きくなりますが、大きなクラスというのは
だいたいに置いて過剰な責務を持たされています。
これを適切な大きさに分けて、責務を色んなオブジェクトに分配することで、
1～2個のインターフェースを持った小さいクラスに分けます。
で、継承はそれぞれの小さなクラスに対してのみ使うようにします。

>「よく似ているけど、微妙に違う処理」には、共通部分を
>モジュール化して、それを呼び出す違いを吸収したモジュールを作成、
>それを使用する方法がとれると思います。オブジェクト指向とは
>アプローチが逆かもしれませんね。

すみません、これよく分かりません。
オブジェクト指向のアプローチとは全く同じもののように思えるのですが。

0614デフォルトの名無しさん

NGNG

>>607
Generic Programmingって、どちらかというとコンパイラ技術と
いう感じだけどね。そもそも、SmalltalkやObjective-Cのように
ダイナミックタイピングな言語では、こんな概念は不要だし。
効率第一のC++らしいといえば、そうだが。

0615デフォルトの名無しさん

NGNG

継承に問題があるわけじゃなくて、集約を使わないから問題がおこる。
×player.name
○player.profile.name
上だと、無駄な要素がくっついてくるから、継承のメリットは消し飛ぶね。

0616デフォルトの名無しさん

NGNG

ビジネスロジックを実装するクラスはみんなどんな風にクラス化してます？
サーバサイドでの永遠の命題ですが。
案外、構造化一本やりで書いた方が、分かりやすいしメンテしやすいケースもある。

0617デフォルトの名無しさん

NGNG

俺が良くやるのは、
・システムの要になるDBアクセスやビジネスロジックは、コアロジックとして別パッケージにする。
・業務行為の分析をしっかり進めた上で処理制御を分類化し、スーパークラスでテンプレート化する。
この程度。
いずれにしても、業務をしっかり分析しないとね。ユースケースの変更も視野に入れて。

0618デフォルトの名無しさん

NGNG

　　　　　オブジェクト指向って死滅しちゃうの？

0619デフォルトの名無しさん

NGNG

やべー、OO歴15年の俺のスキルはどうなるんだ？w

0620デフォルトの名無しさん

NGNG

>案外、構造化一本やりで書いた方が、分かりやすいしメンテしやすいケースもある。

ぜんぜんまったくそんなことないとおもうのですが。
by 全javaソースに同じバグ入りの処理がコピペしてあるのを見て死んだ経験があるひと。

0621デフォルトの名無しさん

NGNG

オブジェクト指向なんてとっくに破綻してます。
「どうして日本ではオブジェクト指向が広まらないか」
なんて言ってるのは日本だけ。

0622デフォルトの名無しさん

NGNG

>>620の頭の中では構造化＝ソースコピペらしい（ｗ

0623デフォルトの名無しさん

NGNG

>>622
すまんな。言葉を間違えた。バグ入りの「関数」がそのままコピペされてたんだよ。
ソース単体で見れば見事に「構造化」されてたのさ。それは見事にね。
しかし、インターフェイスの利用は皆無だったし、
せっかく親クラスを継承してるのに必要なメソッドは
まったく定義されてない。
ちゃんと親クラスに処理そのものを書けばバグは１個で済んだのに…。
１ファイルごとの構造化なんて邪悪なものは消え去ってくれ。頼むよ。

0624デフォルトの名無しさん

NGNG

オブジェクト指向を勉強したかったら、
.net FrameWorkかDelphiでも使えばすぐ覚えるだろ…。

0625デフォルトの名無しさん

NGNG

XP の once only once だな。
XP そのものを使うのは難しいだろうけど、エッセンスは知っておいて損はない。

0626デフォルトの名無しさん

NGNG

>>624
それがそうでもないんだよ。.NETには罠がたくさんある。
たとえばUML的に書くと笑えるんだが、初心者のコードってのは、
　MyForm <>---- .net FrameWork　になってるのだよ。
MyFormの中にあらゆる処理が集約されてるのな（ｗ
イベント処理の中に、画面の書き換えもDBの更新も保存も変換も印刷も入ってる。
それでオブジェクト指向したつもりになって、
再利用が効かないとかわかりにくくて使えないとか言ってる。
もうね、アホかと馬鹿かと。とにかく各処理の本体を適切なクラスに切り分けろと。
そんな厨房を大量生産する.net FrameWork逝って良し。

0627デフォルトの名無しさん

NGNG

>>626
それは.net FrameWorkに限らない話だろ

0628デフォルトの名無しさん

NGNG

　　先生っ！オブジェクト指向で客が釣れません！！

　　次は、ＸＰだな。

0629デフォルトの名無しさん

NGNG

XP,FDD,RUP、実際にきっちりとこれに従った開発した事ある人いるか？
おれは破綻したXPなら経験がある（ｗ

0630デフォルトの名無しさん

NGNG

Java の GUI モデルだと継承とインベントリスナを使うからそういう風にはならない。
クラス数は糞増えるが、問題の切り分けが楽になるので管理はしやすい。

0631デフォルトの名無しさん

NGNG

>>627
そうだよ。DelphiのVCLにもJavaのAWTやSwingにもあてはまるんだよ。

だからこそ>>624の主張は間違いなのですが何か？

0632デフォルトの名無しさん

NGNG

>>630
ところがどっこい。
初心者本には、MyFormにイベントリスナを山ほど実装させて、
thisをイベントリスナに登録するように書いてあるものも結構ある。

これだとVB並みにおぞましい結果になるわけだ。
初心者はイベントリスナのメソッド名が重複するまでは
問題に気づかずthisを登録しまくる。クラスを書くよりは楽だからね。

0633デフォルトの名無しさん

NGNG

>問題の切り分けが楽になるので管理はしやすい。

0634デフォルトの名無しさん

NGNG

>>632に追加。
最悪なのは、JButtomのイベントリスナに、thisを登録してるコード。
サンプルの行数は短くなって、ある意味とっつきやすくなる。
しかし、ボタンを2つに増やしたくなったらどうしろというのか。

0635デフォルトの名無しさん

NGNG

>>634

public void actionPerformed(ActionEvent e) {
if(e.getSource() == button1) {
text1.setText("ボタン１がクリックされました");
}
if(e.getSource() == button2) {
text1.setText("ボタン2がクリックされました");
}
}
みたいな（ｗ

でもまあ、サンプルソースなら良いんじゃないすか？
その前か後でイベントモデルを勉強するんだし。

0636デフォルトの名無しさん

NGNG

あとにつづかねぇ糞コードだな。

0637デフォルトの名無しさん

NGNG

そういえばJBuilderが吐くコードもいい加減糞だよなw

0638デフォルトの名無しさん

NGNG

>>616
>サーバサイドでの永遠の命題ですが。
>案外、構造化一本やりで書いた方が、分かりやすいしメンテしやすいケースもある。

これは俺も同意。
ビジネスロジックの部分はオブジェクト指向が
特にうまく機能しない部分だと思う。
フレームワークみたいな、オブジェクト指向が得意な部分だけに適用を絞って、
あとは構造化でやる、と割り切ってしまうのがいいと感じている。

0639デフォルトの名無しさん

NGNG

>>>638
ま、構造化手法で解決できるところまで問題をブレークダウンできただけでも
オブジェクト指向手法を使った甲斐があるわけで。
とはいえ、構造化手法では役者不足な程度に大きいビジネスロジックも当然
あるので、そのときはオブジェクト指向手法でやらないとね。

0640デフォルトの名無しさん

NGNG

>>639
うーん、俺は大きなビジネスロジックになるほど、
オブジェクト指向手法の限界を感じてしまうのだけど・・・
本当に複雑なビジネスロジックって、なかなかきれいに
オブジェクト指向で、っていうわけにはいかないと思わない?
がんばればできるのかもしれないけれど、時間的な制約から
あきらめざるを得ないことが多かった。

あと、俺は技術的な面でのオブジェクト指向のメリットは
充分あると思っているのだけど、プロジェクト管理の側面から
見ると、構造化に比べて不利のように思う。
共通部分が多くなるから、人員の割り振りがしにくいし、並行作業が難しくなる。
少人数のプロジェクトならともかく、大規模プロジェクトの
ビジネスロジックの数は膨大なので、とてもじゃないが
理想的なオブジェクト指向設計なんかできそうにない。
RUPも、この辺の問題には何も回答を与えてくれていないように思える。

だから、現実的な面から見てフレームワーク部分（これはビジネスロジックに
比べるとコード量が圧倒的に少ないので適用可能）だけに適用を絞って、
ビジネスロジックは構造化で、というのがいいような気がするんだけど、どうよ?

0641デフォルトの名無しさん

NGNG

>>617が言ってるみたいな、ロジックのテンプレート化はアリだと思う。
ただし、やっぱちゃんと分析されて無いと追うのが辛いだけになる。
何階層もに分散した実装を上に行ったり下に行ったりしながら追うのは苦痛。
逆に、ちゃんと分析されて、妥当な分類がなされていれば非常に有用。

0642デフォルトの名無しさん

NGNG

業務分析とそのモデリング技術（というかセンス？）は経験がものを言うな。

0643デフォルトの名無しさん

NGNG

>>641
正直に言ってしまうが、俺はビジネスロジックのテンプレート化は
危険な方法だと思っている。
現在分かっている仕様をもとにきちんと分析したとしても、将来的な
仕様変更でその分析結果が無に帰す場合がありえる。
ロジックの定型化をすることで、将来その定型部分にそぐわない
仕様変更が発生した時に破綻する可能性が高い。
多少コードが冗長になったとしても、「何も規定しない」方が
メンテナンス性は高いと思う。

0644デフォルトの名無しさん

NGNG

>>626

同意点が多い。

>たとえばUML的に書くと笑えるんだが、初心者のコードってのは、
>MyFormの中にあらゆる処理が集約されてるのな（ｗ

今気になってるのが、MSのC系メインストリームがC++からC#に行くじゃない。
VC++時代には出来なかった「Formベースプログラミング」ともいうべきものが、
可能どころかデフォルトになってしまう。ボタンをダブルクリックするだけでコマンド
ハンドラ出来てしまう。VBやC++ Builder/Delphiと同じ。

その環境で、フォームに依存しないクラスが作れるスキルは中級～になって
しまうのではとかね。

0645デフォルトの名無しさん

NGNG

>>643
確かに、これはどの範囲まで適用させるかが重要だと思う。
ユースケースに出てくるようなパスはむしろ固定化させるべきで、
機能ごとにユニークな部分のみを実装させるべきと考えるので。
万が一ユースケースが変更されたら書き直しになるが、それが然るべきあり方という考え方。
一長一短ですな。

0646デフォルトの名無しさん

NGNG

せちがない昨今、なかなか分析を十分に進める時間が無いのよね・・・。
XPにしても「そんな悠長な」ってのが多くの開発者の本音では。

0647デフォルトの名無しさん

NGNG

XPだと生産性は半分になるからね
ﾎｼｭも半分の労力で済むけど
ウチの会社は作りっぱなしが多いからなぁ
だいたい仕事頼んできたところが
結構な割合で倒産してるし・・・

0648デフォルトの名無しさん

NGNG

>>626
それは.NETフレームワークの問題じゃなくて、開発ツールとか
教育体制の問題じゃないのかなあ。オブジェクト指向の手法と
してのネタではないような。

0649デフォルトの名無しさん

NGNG

ちなみに>>646

×　せちがない
○　せちがらい（世知辛い）

0650デフォルトの名無しさん

NGNG

>>621
> 「どうして日本ではオブジェクト指向が広まらないか」
> なんて言ってるのは日本だけ。

そりゃ、アメリカやドイツや韓国では、そんなことを言っている人はいないだろうな。

0651デフォルトの名無しさん

NGNG

まあ、アメリカはその代わりに CMM を流行らせたわけだが。

0652デフォルトの名無しさん

NGNG

>>545
> すべてのデザインパターンは Composite パターンに帰着する。
とりあえず馬鹿は死ね

0653デフォルトの名無しさん

NGNG

>>634
Stateパターンを使いましょう

0654デフォルトの名無しさん

NGNG

>>653
バトル・アメリカ

0655デフォルトの名無しさん

NGNG

>>650
日本の多くの企業のCMMレベルは殆ど1か2、またはそれ以下
日本で最近CMMレベル5を実現した企業は日本IBMのみ
これはひどいことにほとんどがレベル4を実現しているインドにまで劣る。

日本人は馬鹿だ。日本人はあまりにも愚かだ。日本人は頭が悪すぎる。
日本人は論理的思考に弱い。都合の悪いことは何でもかんでも「水に流す」で済まそうとする。
そんな馬鹿な日本人に生まれてしまったのは我々の宿命か

0656名無し＠沢村

NGNG

>>651
ハゲ！！ＣＭＭはプログラミング手法じゃねーよ！
ソフト開発の工程がちゃんとしてるかどうかを採点する方法だよ。
まあ、あってもなくてもいいものだ。

0657デフォルトの名無しさん

NGNG

>>656
採点って、評価だけが目的なんか？

0658名無し＠沢村

NGNG

>>657
そうだ。あってもなくてもいいものだ。

0659デフォルトの名無しさん

NGNG

CMMって何の略なん？

0660デフォルトの名無しさん

NGNG

>>657
さわむらかたくそんかしらんがそいつにレスすんな。

0661名無し＠沢村

NGNG

>>659
ハゲ！！ＣＭＭはな、Capability Maturity Modelの略よ。
といってもおまえにはCapabilityとMaturityの意味はわからんだろう？
いいか！！ Capabilityは「能力」Maturityは「成熟」Modelは「模型」よ。
つまりソフトウエアをつくる能力がどれくらい成熟しているかを採点する模型のことよ。

0662デフォルトの名無しさん

NGNG

今日は沢村元気だな。

というよりムキになっているのか。

0663デフォルトの名無しさん

NGNG

つーか、頭いいやつが銀行とかいってこの業界にこないから仕方ねーじゃん。
赤字増えるより、ましかもしれんけど。

0664デフォルトの名無しさん

NGNG

銀行＝馬鹿

0665デフォルトの名無しさん

NGNG

ここではクラスベースの話しかしないの？

0666デフォルトの名無しさん

NGNG

あげ

0667デフォルトの名無しさん

NGNG

>>665
どうぞ、インスタンスベースの話をして下さい。

0668デフォルトの名無しさん

NGNG

>>665
じゃあ、Selfの話でもしようか。

…ネタがねぇ…そのまえに知らないし

0669デフォルトの名無しさん

NGNG

　　沢村、近藤、山崎渉は徹底放置！！

よろしく。

0670名無し＠沢村

NGNG

沢村は徹底放置！！

よろしく。

0671デフォルトの名無しさん

NGNG

selfのほかにないんかのう

0672デフォルトの名無しさん

NGNG

NewtonScript!

0673デフォルトの名無しさん

NGNG

　　　　　「ＣＭＭはうんこ」

ってことで、よろしいでつか？

0674デフォルトの名無しさん

NGNG

>>673
かつてのISOみたいに、認定とっていることで営業の道具にすることしか
考えていない、企業版「資格商法」のカモになってるバカ管理職連中は
うんこです。

0675デフォルトの名無しさん

NGNG

>>669
沢村、山崎渉固定ハンドルは良く見かけるけど
近藤って誰よ？

0676デフォルトの名無しさん

NGNG

>>675
うんこ

0677名無し＠沢村

NGNG

近藤って誰よ？
沢村、山崎渉固定ハンドルは良く見かけるけどな…

0678デフォルトの名無しさん

NGNG

マ板に行けばわかる。
別に知らなくていいことだが。

0679デフォルトの名無しさん

NGNG

ふ～～ん

0680デフォルトの名無しさん

NGNG

「まあ」ってあるよね。
昔は、「まあいいよ」とか、「まあこのぐらいですね」とか、「だいたいこの程度」といった
感じを表すときによく使っていたと思うんですけど。
最近は、「これは、まあカーナビですが、車に搭載して使います」とか、
「酸素と、まあ水素が化合すると水になるわけです」とか、何が「まあ」なんだか
わからない使い方をよく聞くようになりました。
90年頃からかな。
これは、いったいなんなんでしょう……

0681名無し＠沢村

NGNG

まあというのは「間」のことよ。
ふつー「間」というのは無言で表わすわけだが、それをわざわざ言葉で表わしたのがまあというわけだ。
だからまあは「…」と同じようなものよ。

0682デフォルトの名無しさん

NGNG

オレは子供の頃マー君て呼ばれてた。なつかしいな。

0683デフォルトの名無しさん

NGNG

プログラまあ、でしょう。

0684デフォルトの名無しさん

NGNG

コピペに釣られるバカに沢村に釣られるバカ。

0685デフォルトの名無しさん

NGNG

バカを見つけるとバカと言わずにはいられないバカ。　

0686デフォルトの名無しさん

NGNG

チャットでやってろ漏前ら

0687デフォルトの名無しさん

NGNG

小3のある日、兄の自転車を借りて坂を下ってたら
実はブレーキがすごく甘くなってて、
ブレーキしてもどんどんスピードが上がっていって
靴のつま先で無理やりブレーキさせても靴が磨り減るだけで
仕方なく路肩の植木に身を投げたら擦り傷いっぱいでスカート破けて
そのままｴﾛﾃｨｯｸな格好で泣きながら家に帰ったら
母がいきなり
「誰にやられたの！」
と聞いて来たのでは私はお兄ちゃんの自転車で…と言うつもりが
泣きじゃくってるせいでうまくいえず
「お…お兄ちゃん…」
と呟いたら母は突然倒れてそのまま気絶してました。

0688デフォルトの名無しさん

NGNG

Objective-Cはダメでつか？

0689デフォルトの名無しさん

NGNG

笑われたくない！！

0690デフォルトの名無しさん

NGNG

この擦れ立てたやつどのくらい成長したのか気になる

0691デフォルトの名無しさん

NGNG

つい先日氏んだって話を小耳に挟んだが。

0692r

NGNG

オブジェクト指向なんて関係ない。
チンコがたつのがいい男。
たたないのが駄目人間。

0693デフォルトの名無しさん

NGNG

>>692
おいおいペレを馬鹿にするなよ

0694デフォルトの名無しさん

NGNG

>>692
童貞がｗ

0695かおりん祭り

NGNG

0696デフォルトの名無しさん

NGNG

どいつもこいつも、お気楽でいいな。

0697デフォルトの名無しさん

NGNG

そうじゃないとやってらんないよ。そう思わん？

0698デフォルトの名無しさん

NGNG

やっべーアプリケーションの方はまだマシだけど。
アプレットはキツイ
なんか受けつかないって感じ

0699デフォルトの名無しさん

NGNG

メンバ変数の値を返すだけのメソッドってどういうふうに命名するのが一般的ですか?

0700デフォルトの名無しさん

NGNG

変数名が hoge として、
Java 風： getHoge
Smalltalk 風： myHoge または hoge

0701デフォルトの名無しさん

NGNG

Delphi風
メンバ変数 FHoge
メソッド(というかproperty) Hoge

0702山崎渉

NGNG

　　　　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾）＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

0703100人に1人（変化を嫌うのが特徴）

NGNG

＜アスペルガー症候群（自閉症スペクトラム）←脳の機能的疾患（遺伝）＞
●変化を嫌う
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

0704デフォルトの名無しさん

NGNG

http://www5e.biglobe.ne.jp/~liquor/raytrace/
ベンチマークとってみたんだが、ここの人って
なにげにオブジェクト指向してない？

0705デフォルトの名無しさん

NGNG

過労死をさせる日本ロジテム株も大暴落の予感
佐川とロジテムどっちがひどい？
田中真紀子と親密な日本ロジテム（日清系　上場企業　みずほの融資先）の
子会社せいも素（みずほの融資先）で　
サービス残業させすぎの過労死者を出した上、大量の不当解雇を行った社長の辻
にまた労働基準監督署の立ち入り調査があり，またも多くの勧告が出された。
http://www.samos.co.jp
http://society.2ch.net/test/read.cgi/traf/1046749189/l50
.　　　　　　／￣＼　　+.　　∧＿∧ｱﾊﾊﾊﾃﾝｺﾞｸﾍｲｯﾁｬｳﾖｰ　
　　ｲｸﾅﾖｰ（　´∀｀）　　　　（´∀｀　）　　
　　　　　　（つ　　つ　　　（つ　　つ■
.　　　+　　（　ヽノ　　　　　（　ヽノ

0706オブジェクト指向言語の歴史

NGNG

Simula67

Smalltalk80

C++

Self

Eiffel

Delphi

Java

C#

0707デフォルトの名無しさん

NGNG

スーパークラスセンシティビティという言葉について
ご存じの方教えてください。実装の継承を行う場合の弊害らしいですが、
検索しても出てこないので・・・

0708デフォルトの名無しさん

NGNG

>>707
みこみこナースです

0709デフォルトの名無しさん

NGNG

巫女巫女ナース？

0710デフォルトの名無しさん

NGNG

超級戦士ちびT
ちびT(ぴたT)を着た戦士。強い。

0711デフォルトの名無しさん

NGNG

>>707
センシビティ=敏感
多分、実装の継承をするとスーパークラスを簡単に修正できなくなることを
言ってるんじゃないのかなぁ・・・

0712サンプルです

NGNG

http://yahooo.s2.x-beat.com/linkvp/linkvp.html

0713デフォルトの名無しさん

NGNG

>>706
Objective-Cが抜けてるよ

0714デフォルトの名無しさん

NGNG

こんな本が出てた。
「リバーシのアルゴリズム―「探索アルゴリズム」「評価関数」の設計と実装 C++&Java対応」
これを読めばOO厨もオセロ作れる？

0715デフォルトの名無しさん

NGNG

やっぱね、オセロとかは石ひとつひとつがオブジェクトなんですよ。

・・・案外この思想で面白い思考ルーチンが作れるかもしれない

0716デフォルトの名無しさん

NGNG

いっそ、マス一つ一つを object にしてみるとか。
そこに置けるかとか、どこの石が取れるかとか、問い合わせに答えるの。
で、石が置かれたら、周りのマスに通知して…

…でも、これは思考自体にはあんまり影響しないかも。

0717デフォルトの名無しさん

NGNG

>>715-716
極めて素直で自然だと思いますね。
あたかも、それが画期的なことであるかのように書き込んでいますが。

0718デフォルトの名無しさん

NGNG

>>717
よし、じゃあ早速その発想でアルゴリズムを作ってみてくれ。

0719デフォルトの名無しさん

NGNG

アルゴリズムの話はスレ違い

0720山崎渉

NGNG

　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

0721山崎渉

NGNG

　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

0722デフォルトの名無しさん

NGNG

結局誰もSingletonを書けなかったわけだが。
Java本からのパクリを載せる。

public class Singleton {
private static Singleton s = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return s;
}
}

なぜこれしきのことで騒いでいたのかと。

0723デフォルトの名無しさん

NGNG

>>722
使わない可能性があるのにインスタンスが必ず一つ出来るのって効率悪くないですか？

0724デフォルトの名無しさん

NGNG

>>723
使わないんなら、わざわざコード書く必要はないような気が。
722の場合、使わなくてもインスタンスは必ず一つというのは
それはそれでSingletonの定義にかなっているのではと。
あとは、他の実装例を私は不幸にして知らない。

0725デフォルトの名無しさん

NGNG

>>724
あなたは、あるパッケージから使わないそのシングルトンを抜き出す作業を好んで行うんですか？

public class IntelligentSingleton {
private static IntelligentSingleton s = NULL;
private IntelligentSingleton() {}
public static IntelligentSingleton getInstance() {
if(s == NULL)
s = new IntelligentSingleton();
return s;
}
}

0726デフォルトの名無しさん

NGNG

>>725
あーそーいえばそんなコードを見かけたことがあった。どこでだかは忘れたけど。

0727デフォルトの名無しさん

NGNG

構造体とクラス（C++)の違いを教えてください。
クラスを使用することのメリットは何でしょうか？

0728デフォルトの名無しさん

NGNG

>>727
C++的には、デフォルトのメンバアクセス制限が違う以外はまったく同じもの。
一般的には、同じところを見つけるほうが困難なほど概念からしてまったく別物で比べることもおこがましい。

0729デフォルトの名無しさん

NGNG

クラス定義したオブジェクトは、
メモリ領域的にはどこに配置されるのですか？
作り方しだい？（例えばメモリプール）それともスタック？

0730デフォルトの名無しさん

NGNG

ここを特定の言語のためのスレッドだと勘違いしている人が二人ほどいる模様。

0731デフォルトの名無しさん

NGNG

>>729
ヒープまたはスタック

0732デフォルトの名無しさん

NGNG

ヒープって何？

0733デフォルトの名無しさん

NGNG

>>732
newしたやつが住む場所

0734デフォルトの名無しさん

NGNG

>>723
クラスにアクセスしない限りはできません。

>>725
そのコードはスレッドセーフではない。失格。

0735デフォルトの名無しさん

NGNG

>>734
はいはい。では次の方。

0736デフォルトの名無しさん

NGNG

public class IntelligentSingleton {
private static IntelligentSingleton s = NULL;
private IntelligentSingleton() {}
public synchronized static IntelligentSingleton getInstance() {
if(s == NULL)
s = new IntelligentSingleton();
return s;
}
}

0737デフォルトの名無しさん

NGNG

TABれえぇぇぇぇぇえぇぇぇぇえ

0738デフォルトの名無しさん

NGNG

質問なんですが、インタフェースとは
「実装を持たないシグニチャのみのクラス」
でよいのですよね？
その利点は一体何なんでしょうか。

0739デフォルトの名無しさん

NGNG

>>738
見た目が同じなら中身が全然違くてもいい事

0740デフォルトの名無しさん

NGNG

・多重継承と違って中身が衝突しない
・常にvtblを使うのでCOMと一致

0741738

NGNG

>>739＆740
ありがとうございました。

>>739
それはカプセル化と似ている気がするのですが、全然違うのですよね？

0742デフォルトの名無しさん

NGNG

>>741
クラスにするときのカプセル化とは言葉の使いどころは違うけど概念的には同じもの。

0743738

NGNG

>>742
私の持っている本には、カプセル化は「インタフェースと実装の分離」と書いてあります。
インタフェースとは所謂外面のことと考えてもよろしいでしょうか？

0744デフォルトの名無しさん

NGNG

>>743
いいけど、分離するだけじゃカプセル化とは呼ばないよ、隠さないと。

0745738

NGNG

>>744
そういえばそうですよね。わかりました。ありがとうございます。

0746デフォルトの名無しさん

NGNG

ハゲ隠すの必死（藁

0747デフォルトの名無しさん

NGNG

>>731 処理系依存

0748デフォルトの名無しさん

NGNG

私も脱いでます♪探してみてね♪
http://yahooo.s2.x-beat.com/linkvp2/linkvp2.html

0749デフォルトの名無しさん

NGNG

ロジック設計（ハード設計）にも、オブジェクト指向の設計手法はありますか？

0750デフォルトの名無しさん

NGNG

>>749
もちろん。

0751749

NGNG

>750
VHDL or Virilog HDL?

0752デフォルトの名無しさん

NGNG

>>748
メンバに直接アクセスしたいです。

0753デフォルトの名無しさん

NGNG

IT（情報技術）をマスターするにはオブジェクト指向が必要なんでしょうか？

0754直リン

NGNG

http://homepage.mac.com/maki170001/

0755デフォルトの名無しさん

NGNG

>>746
ボクのハゲもカプセル化されそうです。

0756山崎渉

NGNG

（＾＾）

0757山崎渉

NGNG

　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

■ このスレッドは過去ログ倉庫に格納されています