2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

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

1 :Java太郎 ◆RxE.qPfLG2 :03/04/09 12:00
貴様ら!オブジェクト指向を教えろ!!
http://pc2.2ch.net/test/read.cgi/tech/1047696495/l50


2 :デフォルトの名無しさん:03/04/09 12:20
【夢】get

3 :デフォルトの名無しさん:03/04/09 12:21
さらに【恋】もget

4 :デフォルトの名無しさん:03/04/09 12:22
そして【星】になった・・・

5 :あぼーん:03/04/09 12:24
 ( ・∀・)< こんなのみつけたっち♪
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

6 :かおりん祭り:03/04/09 12:24
http://saitama.gasuki.com/kaorin/
〜oノハヽo〜 / ̄ ̄ ̄ ̄ ̄ ̄ ̄                
  ( ^▽^) < こんなのがございまーす♪ 
= ⊂   )   \_______
= (__/"(__) トテテテ...

7 :デフォルトの名無しさん:03/04/09 13:36
立てるのが遅いです。

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


8 :デフォルトの名無しさん:03/04/09 15:32
なんか静かだな・・・w

9 :かおりん祭り:03/04/09 15:38
http://saitama.gasuki.com/kaorin/
〜oノハヽo〜 / ̄ ̄ ̄ ̄ ̄ ̄ ̄                
  ( ^▽^) < こんなのがございまーす♪ 
= ⊂   )   \_______
= (__/"(__) トテテテ...

10 :あぼーん:03/04/09 15:38
 ( ・∀・)< こんなのみつけたっち♪
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 :デフォルトの名無しさん:03/04/09 15:44
マウスの処理をするために、リスナー登録をしますけど
通常ならやらない処理のマウスの命令まで書かなくてはなりませんよね?
そこで、アダプタを使えば無駄な命令をかかなくて すむらしいのですが
なぜ、アダプタなしの状態で無駄な処理まで書かなければならないのでしょうか?

12 :たんぱく質:03/04/09 15:46
>>11
アダプタには君の言う「無駄な処理」が書いてあるから。

13 :デフォルトの名無しさん:03/04/09 16:14
>>12
日本語がちょっとおかしいですね。
アダプタに無駄な処理が書いてるから
その後に具体的に説明しないとわかりません。

14 :デフォルトの名無しさん:03/04/09 18:31
訂正

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

15 :デフォルトの名無しさん:03/04/09 18:33
>>14
アダプタを作ったのは神じゃなくて人間だろ
お前は電波・お花畑にでも行け

16 :デフォルトの名無しさん:03/04/09 18:48
>>15
禿げしく同意!

17 :14:03/04/09 18:52
15=16

うっさい

18 :デフォルトの名無しさん:03/04/09 19:01
アダプタは神様からの贈り物だろ

19 :デフォルトの名無しさん:03/04/09 20:31
>>18
つまらん

20 :デフォルトの名無しさん:03/04/09 20:37
ageるおまえがウザイ
ウザすぎる
死ね!

21 :デフォルトの名無しさん:03/04/09 20:43
俺は爆笑だったけどな

22 :デフォルトの名無しさん:03/04/09 20:49
>>20
感情的な方ですねw
まぁ、1人位居てもいいか・・・貴重な存在ですし。

23 :デフォルトの名無しさん:03/04/09 21:01
アクターもオブジェクト?

24 :デフォルトの名無しさん:03/04/09 21:02
>>22
またageやがったな
この天邪鬼が
こうなったら透明あぼーんだ!
あと数秒でおまえなんか消えてしまう。
それも強制的にだ

25 :デフォルトの名無しさん:03/04/09 21:12
>>24
テメェ!!さげるんじゃねぇよ!!!
あぁん??

26 :デフォルトの名無しさん:03/04/09 21:14
オブジェクトが持っているオブジェクトはなんて呼ぶの?

27 :デフォルトの名無しさん:03/04/09 21:32
has-a や contains-of の関係にあるオブジェクト

28 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/09 22:29
インスタンス変数>26

29 :デフォルトの名無しさん:03/04/09 22:58
インスタンス変数 ハニャ?

30 :デフォルトの名無しさん:03/04/09 23:05
>>29
インスタンス変数くらいなら、調べましょうよ

31 :デフォルトの名無しさん:03/04/10 07:01
インスタンス変数は変数であってオブジェクトのことでは無い

32 :デフォルトの名無しさん:03/04/10 07:38
オブジェクトを変数に入れます

33 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/10 10:03
だめすぎ

34 :デフォルトの名無しさん:03/04/10 13: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 はインスタンス変数なんですよ。


35 :デフォルトの名無しさん:03/04/10 13:30
訂正
誤: static *m_Object;
正: static Singleton *m_Object;

36 :デフォルトの名無しさん:03/04/10 13:38
>>34
突っ込みどころが多すぎてどこに突っ込めばいいのかわからん

37 :デフォルトの名無しさん:03/04/10 14:09
>>36
最後の 1 行だけじゃないの? < ツッコミどころ


38 :63:03/04/10 14:30
とりあえず new の無限ループと

39 :38:03/04/10 14:31
すまん、マウスの誤操作。

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

40 :デフォルトの名無しさん:03/04/10 17:22
コンストラクタの中身を、

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

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


41 :デフォルトの名無しさん:03/04/10 17:22
間違い。if は == だね。


42 :デフォルトの名無しさん:03/04/10 17:24
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;
}
};

これが正しいのかな。


43 :デフォルトの名無しさん:03/04/10 17:32
>>40
コンストラクタがprivateじゃどうやってSingletonオブジェクトを構築するんだよ。
コンストラクタがprivateなクラスのインスタンスはそのクラス内でしか作成できないが、newが書いてあるのはそのprivateなコンストラクタの中。

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

44 :デフォルトの名無しさん:03/04/10 17:35
しかも
    if(m_Object == 0) {
      m_Object = new Singleton;
    }

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


45 :デフォルトの名無しさん:03/04/10 17:36
>>42 の GetObject を static にすれば OK かな。


46 :デフォルトの名無しさん:03/04/10 17:37
>>44
m_Object は static だから無限じゃないと。


47 :デフォルトの名無しさん:03/04/10 17:39
>>46
代入する前に次のコンストラクタが呼ばれちゃうよ。

48 :デフォルトの名無しさん:03/04/10 17:40
おお、すごいことになってる。


49 :デフォルトの名無しさん:03/04/10 17:41
結論: C++ で Singleton は無理!


50 :デフォルトの名無しさん:03/04/10 17:43
コンストラクタで new したらマズいでせう

51 :デフォルトの名無しさん:03/04/10 17:46
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;
  }
};

こうか?


52 :デフォルトの名無しさん:03/04/10 17:48
>>51 だと、GetObject() を synchronized にしないと危ないと思うんだが、
C++ だとどうすればよいでつか?


53 :デフォルトの名無しさん:03/04/10 17:49
マルチ・スレッドの場合ね < 52

54 :デフォルトの名無しさん:03/04/10 17:50
>>52
処理系依存の方法でロックするしか無いでしょう。

55 :デフォルトの名無しさん:03/04/10 17:51
>>52
Winならセマフォとかミューテックスとか

56 :デフォルトの名無しさん:03/04/10 17:52
m_Object を volatile すればいいのかにゃ?


57 :デフォルトの名無しさん:03/04/10 17:53
volatile じゃだめ。


58 :デフォルトの名無しさん:03/04/10 17:54
>>55
なんか、情報筋の伝えるところによるとミューテックスやセマフォは遅いのでクリティカルセッションを使ったほうが良いそうだ。

59 :デフォルトの名無しさん:03/04/10 18:02
たかだか十数行のソースで何故これほど意見が割れるのか。。。。


60 :デフォルトの名無しさん:03/04/10 18:06
>>58
クリティカルセッションって
そこだけ割禁で突っ走るってこと?

61 :デフォルトの名無しさん:03/04/10 18:07
このスレを見て、次のプロジェクトにC++を採用することをあきらめました。


62 :デフォルトの名無しさん:03/04/10 18:13
>>60
ゴメン。セッション→セクション。
EnterCriticalSection使うと、排他的に実行できるそうだ。


63 :60:03/04/10 18:18
>>62
ま大体同じようなもんだね

64 :デフォルトの名無しさん:03/04/10 18:20
if(m_Object == 0) の if 文に突入してから終了するまでに、別のスレッドが m_Object
を参照できなくなればいいんですよね。


65 :デフォルトの名無しさん:03/04/10 18:22
クリセクでできそうな気がするんだけど、だめなの?


66 :デフォルトの名無しさん:03/04/10 18:26
クリティカルセクションを使ったマルチスレッド対応版をうpしてみてくれ。

67 :デフォルトの名無しさん:03/04/10 18:45
>>66
LokiPortあたりを見てくれ

68 :デフォルトの名無しさん:03/04/10 19:48
ああ、なんてJavaは簡単なんだ。

69 :デフォルトの名無しさん:03/04/10 21:55
十進BASIC
http://hp.vector.co.jp/authors/VA008683/

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


70 :デフォルトの名無しさん:03/04/10 23:26
>>69
誘導
http://tako.2ch.net/denpa/index2.html

71 :デフォルトの名無しさん:03/04/11 04:59
前スレはクソスレなりに面白い話も飛び交って、結構面白かったんだけどな。
このスレは終わらせちゃうの?前スレみたいに途中から軌道修正して面白い
スレになってくれることを期待しつつsage

72 :デフォルトの名無しさん:03/04/11 05:00
ちなみにクラスが持ってるオブジェクトの変数はクラス変数と呼ぶのでは。
インスタンス変数だとnew したもの全部そうだし。あ、配列なんかは違うのか?

73 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/11 10:38
・クラス変数はオブジェクトの外
・Javaでは配列はオブジェクト

74 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/11 11:07
インドの電気屋の話

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

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


75 :デフォルトの名無しさん:03/04/11 11:28
すべての作業をやってくれるが日給一万円の人間を一人使うより
単純作業しかできないがその作業を完璧にこなす日給千円の人間を五人使うのは間違っちゃいない。

76 :デフォルトの名無しさん:03/04/11 11:54
class Singleton {
  static std::auto_ptr<Singleton> inst;
  Singleton() {}
public:
  static inline Singleton* GetObject() {
    return inst;
  }
}
std::auto_ptr<Singleton> Singleton::inst( new Singleton() );

77 :76:03/04/11 11:56
return inst.get();
だた。

78 :デフォルトの名無しさん:03/04/11 12:45
・クラス変数はオブジェクトの外
・Javaでは配列はオブジェタト



79 :デフォルトの名無しさん:03/04/11 13:02
オブジェクト=クラス?
オブジェクト=インスタンス?

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

80 :デフォルトの名無しさん:03/04/11 13:08
オブジェクトってのは、クラスとインスタンスが分離する前に使われてた言葉です。


81 :デフォルトの名無しさん:03/04/11 14:35
>>79
クラスじゃなくてもオブジェクト。
int a;
の a はオブジェクトです。


82 :デフォルトの名無しさん:03/04/11 14:39
>>81
a をオブジェクトというような状況では int をクラスと呼ぶんじゃないか?

83 :デフォルトの名無しさん:03/04/11 14:42
>>82
クラス型のオブジェクトじゃなくて、プリミティブ型のオブジェクトでろ。


84 :デフォルトの名無しさん:03/04/11 15:01
プリミティブ型ってなんだYO?

85 :デフォルトの名無しさん:03/04/11 15:04
>>84
intのこと

86 :デフォルトの名無しさん:03/04/11 15:15
で、それだとなんでクラスじゃなくなるの?

87 :デフォルトの名無しさん:03/04/11 15:24
C++なら、classキーワードを使って定義されたものじゃないから。

88 :デフォルトの名無しさん:03/04/11 15:26
classキーワードじゃなくてもクラスはクラスだと思うんだけどな。

89 :デフォルトの名無しさん:03/04/11 15:27
OOPの考案者は誰?

90 :デフォルトの名無しさん:03/04/11 15:57
C でも int a; の a はオブジェクトですよ。「プログラミング言語 C 第2版」。

91 :デフォルトの名無しさん:03/04/11 15:58
struct a{...}b;

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


92 :デフォルトの名無しさん:03/04/11 16:02
>>88
思うだけ。


93 :デフォルトの名無しさん:03/04/11 16:28
>>92
C++ではstructとclassの違いはデフォルトのメンバのアクセス制限だけなんだが、
それでもclassはクラスでstructはクラスでは無いと?

94 :デフォルトの名無しさん:03/04/11 16:29
>>93
structは構造体

95 :デフォルトの名無しさん:03/04/11 16:31
>>94
構造体とクラスの違いは?

96 :95:03/04/11 16:33
すまん。つい調子に乗ってとてつもなく阿呆な質問をしてしまった。

97 :95:03/04/11 16:33
>>96
うざ

98 :デフォルトの名無しさん:03/04/11 16:35
intはクラスなの?

99 :デフォルトの名無しさん:03/04/11 16:36
>>93
int はクラスじゃないよ。


100 :デフォルトの名無しさん:03/04/11 16:42
>>98
intはC++などのclassキーワードで定義されるクラスではないけど
広い意味での型を意味するクラスだよ。

101 :デフォルトの名無しさん:03/04/11 16:46
クラスでもクラスじゃなくても、int a; の a はオブジェクト。


102 :デフォルトの名無しさん:03/04/11 18:25
オブジェクト指向のオブジェクトではないが。

103 :デフォルトの名無しさん:03/04/11 18:27
C#だとそうでもない

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

105 :デフォルトの名無しさん:03/04/11 18:54
>>102
「オブジェクト指向のオブジェクト」というのも変な言い方ですが、
オブジェクト指向なんてなかったころから、型の実体のことをオブジェクト
と言ってきている。
クラス型のオブジェクトがオブジェクトのすべてだという誤解をしているのでは。


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

107 :106:03/04/11 19:13
補足。
なんか例が悪かったなぁ。特定の一つってのは別にSingletonの唯一のインスタンスって意味じゃなくて、

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

108 :デフォルトの名無しさん:03/04/11 19:22
>>105
英単語と専門用語の違いだよ。

109 :bloom:03/04/11 19:27
http://www2.leverage.jp/start/

110 :デフォルトの名無しさん:03/04/11 23:25
 ̄ ̄| ̄ ̄| ̄|
 ̄| ̄ ̄| ̄ ̄|ヽ_∧
 ̄ ̄| ̄ ̄| ̄|´・ω・`) ヨカッタナ
 ̄| ̄ ̄| ̄ ̄| /U
 ̄ ̄| ̄ ̄| ̄| |
 ̄| ̄ ̄| ̄ ̄| ∪
^^^^^^^^^^^^^^^^^^^

 ̄ ̄| ̄ ̄| ̄|
 ̄| ̄ ̄| ̄ ̄|
 ̄ ̄| ̄ ̄| ̄|彡
 ̄| ̄ ̄| ̄ ̄| ショボン
 ̄ ̄| ̄ ̄| ̄|
 ̄| ̄ ̄| ̄ ̄|
^^^^^^^^^^^^^^^^^^^


111 :デフォルトの名無しさん:03/04/11 23:30
>>76
auto_ptrを使ったら駄目だよ!!

112 :デフォルトの名無しさん:03/04/12 00:39
オブジェクトと言えば、Cコンパイルした時の.oファイルを思い浮かべるんですが。

113 :デフォルトの名無しさん:03/04/12 01:08
同じ言葉で違う意味を指す言葉が大杉

114 :デフォルトの名無しさん:03/04/12 09:13
.o はリロケータブル・オブジェクト・モジュール。


115 :デフォルトの名無しさん:03/04/12 09:22
C++ならboostに同期用のオブジェクトがあるからそれ使え

116 :デフォルトの名無しさん:03/04/12 09:58
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;
  }
};

こうかい?


117 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/12 23:46
まあ、簡単に言うと

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

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

118 :デフォルトの名無しさん:03/04/12 23:51
モジュールってなに? .o のこと?


119 :デフォルトの名無しさん:03/04/12 23:52
boost インスコしたら200MBくらい食ってしもた。
こんなサイズでかいの?

120 :119:03/04/13 00:14
スマソ、スレ違いだった。

121 :デフォルトの名無しさん:03/04/13 02:25
>>111
なんで?
なんで使っちゃ駄目なの?

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


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

124 :デフォルトの名無しさん:03/04/14 17:13

   (  ド・ド・DQNの大爆笑〜
    `ー‐―V―――――――――――――――――――――――――――――
           ;:'´ (   糞スレ立ててる>1さんを
        _....._{{ 〃`ー―――――V―――――――――――――――――――
      , - ' ,..、、.ヾ{{フ'⌒`ヽ、        (   笑ってちょ〜だい今日もまた
    /  ,:', -‐‐` ´ '´⌒ヽ ヾ:、   _....、、、、`ー――――V―――――――――――‐
.   ,'   ,'´ ,ィ ,ィ ,' ,   `ヽ',  ',-<´ ,     `ヽ.      ______        ..._
    ,'   .i  /|. /.| { i,  i,  }.  }_,,)) lニ二二ミヽ.、 ':, ,.: '´ ,_.....__`ヽ、    ,..-‐-、),...._
   ! |  ! .,'-.{ ! !|; |`、.}゙!.! |.  ! ヽ.l ./ ,!  ,,`ヾ:、 ':,  ./'´ ̄`ヾ、、ヽ,.:'´ ,:‐:、 ,.-、 ヽ.
   ', ', |Vァ=、゙、 `゙、!-_:ト,リ', l ! |   ゙レ__,〃_/リ  !.'; .} ./l_|___ノ! l `、 ',  / //`''} }.'; ',
    ヽ、', l:!Kノ}.     f:_.)i゙i: リ ! l ル' ̄`` ´-、,ノノ l l .!,;:=、`:.`:>=、.j,} |__人(( _ノノノ  |
     | l!iヾ- ' ,   .!__:ノ ゙ ,リ l リ'´ .|' ̄ヽ   __ `><ノ | {;:'ノ ノtrテ;、.Y ! ,--、   __`彡 ノ
.     ',|!!、    r‐┐   ` ノ' /,イ  !   __ , ⌒'/!| |  !.`ー‐'´, ゙じ' ノ ! h.   ._: ´ ソ).(
      'i!゙、ヽ、 ゙ー'  _, ィ,:',:''´ !  !、  ー'  ノイ ! | | !、  !フ `フ'リ ! ル'ヽ.._ _..、(ン ノ )
      ゙:、ィ、jヾー::: 'iヘ ノ',リ./! .| |ー`┬、' ´ 〃 l. トヾ、.゙`ィ'' ´ヽ、/// \二|`\ー‐‐'´
   ,、- '´ ヽ、゙、   { `>"、  !  ! !   | `>-、 | |、 ________∧______
  /\\    ',   }   //`ヽ|  ',.!゙、 !// ゙!/  ! (   誰に〜も遠慮はいりません



125 :デフォルトの名無しさん:03/04/14 21:06
>>76 のコードはコンストラクタが走る前に
GetObject()が呼ばれる可能性がある。 バグを発見しづらい危険なコードだ。


126 :デフォルトの名無しさん:03/04/14 21:34
>>122
>GetObject()でinst をreturnした瞬間にinstがNULLクリアされるから。
NULLクリア?何がNULLになるんだ?
つーか、STL使ったことあるか?大丈夫か?


127 :122:03/04/15 02:12
>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は良く解らんですな。




128 :デフォルトの名無しさん:03/04/15 16:06
>>127

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

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

129 :122:03/04/16 01:45
>128
いや、まあそうなんだけど、大域領域に晒しておくもんだし、
そんなに貧弱でいいのかな、と。
#普通、NULLチェックして再生成しない?

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

130 :122:03/04/16 02:00
追記
Modern C++ Designを読むのが一番てっとり早いな。
Singletonのところ。

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

ってことですね。

132 :122:03/04/17 01:52
>131
ん〜違う……といっても説明していないんだけど。

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

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

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

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

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

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

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

133 :デフォルトの名無しさん:03/04/17 10:25
>>131
そういう書き込みする時は、
相手が言った言葉以外の言葉を勝手に補っちゃだめだし、
相手のレス番を明記しておかなきゃ。

134 :山崎渉:03/04/17 15:29
(^^)

135 :デフォルトの名無しさん:03/04/19 08:22
age

136 : :03/04/19 21:20
関係ないが、パターンは非常に危険。

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

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

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

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

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

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

137 :デフォルトの名無しさん:03/04/20 01:32
>>136
反対視する専門家って、具体的に誰?


138 :デフォルトの名無しさん:03/04/20 01:33
>>136
継承を前提とした画期的設計って、MFC もそうだよね。


139 :デフォルトの名無しさん:03/04/20 01:42
>>136
フレームワークも否定されますか?

140 :デフォルトの名無しさん:03/04/20 02:10
俺は136に賛成。
いうと叩かれるから言わなかったけどデザパタはロクな設計じゃない気がする。
OO信者な俺には耐えられない。

141 :デフォルトの名無しさん:03/04/20 02:13
>>140
気がするだけじゃ。
ねえ。
気分で設計する上役がいると仕事やりにくい。


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

143 :デフォルトの名無しさん:03/04/20 02:42
良くわからんな・・・
実装のことを考えずに、何を設計するの?

144 :デフォルトの名無しさん:03/04/20 02:46
>>142
ある抽象レベルで話をしているのに、いきなり抽象レベルの違う
話題が出てくるとか?


145 :デフォルトの名無しさん:03/04/20 02:46
142 じゃないが。
設計と実装を分けて考えられない人っていない?
自分で書いておきながら人に説明できないプログラムを書く人というか。

146 :デフォルトの名無しさん:03/04/20 02:48
>>143
いや、オブジェクト指向がわからない人って共通してこれがわからないっつーのはわかるよ。
ただ、ちょっと考えてほしいんだよね。
コーダーなんかで終わらない為に。

147 :デフォルトの名無しさん:03/04/20 02:51
>>146
説明が下手ってこと?


148 :デフォルトの名無しさん:03/04/20 02:52
シンプルに考えられないってことか?


149 :山崎渉:03/04/20 02:53
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

150 :デフォルトの名無しさん:03/04/20 02:54
>>149
それじゃわからん。


151 :デフォルトの名無しさん:03/04/20 02:59
>>142
要するに、何がわからないのかわからないってことか。


152 :デフォルトの名無しさん:03/04/20 02:59
どうしてもいいたいことがわからない・・・
あるロジックを組む時に、それをどういうクラスの、どういうメソッド
を使って実現するのか考えることがオブジェクト指向設計ではないの?
ロジック単位で設計の話をしても、少しもおかしいとは思えない。



153 :デフォルトの名無しさん:03/04/20 03:01
>>152
こういう人、いるね。


154 :デフォルトの名無しさん:03/04/20 03:03
あぁ。馬鹿ばっかだよ。

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


156 :デフォルトの名無しさん:03/04/20 03:04
>>155
と説明しても、わかんねーんだよな。


157 :デフォルトの名無しさん:03/04/20 03:06
アクセル・ペダルを踏むと前進する、という要求定義に、
ガソリン・エンジンにするのか、モーターの配線はどうするのか、
蒸気機関の燃料はどうするのかは関係のない話だから。


158 :デフォルトの名無しさん:03/04/20 03:09
>>152 のようなやり方も OO ではありだけど、それ専用の
クラスになっちゃうからね。


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


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

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

161 :デフォルトの名無しさん:03/04/20 03:29
>>159
インターフェースと方式とをごっちゃにしちゃいけないですね。
それはそれ、これはこれで設計する。

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

162 :デフォルトの名無しさん:03/04/20 03:31
>>160
うん、ロジック・レベルで OO 設計したら、ロジックを見えなくするような
クラスにラップする。
どうすればそのクラスを使えるかだけわかるようにして、そのクラスが
どうやっているかは関係がなくなるようにしておく。


163 :山崎渉:03/04/20 03:32
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

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


165 :デフォルトの名無しさん:03/04/20 03:38
そして、>>164 での動力部分の設計は、自動車クラスに影響を与えない。
もしくは、最小限の変更ですむようにする。


166 :動画直リン:03/04/20 03:38
http://www.agemasukudasai.com/movie/

167 :デフォルトの名無しさん:03/04/20 03:41
MotiveDevice md = new GasEngine;
md.pushAccelPedal(10); // どうやっているかは知らない

と、

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

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


168 :デフォルトの名無しさん:03/04/20 04:16
>136
こらまた極論だなぁ

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

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

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

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

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


169 :デフォルトの名無しさん:03/04/20 04:19
>>168
その考えがいまの時代にあわんというに。

170 :デフォルトの名無しさん:03/04/20 04:21
>>168
デザパタはただひたすらヘタクソなだけなんだが。

171 :デフォルトの名無しさん:03/04/20 04:30
>>170
下手なら練習すればいい。


172 :デフォルトの名無しさん:03/04/20 04:33
>>169
合うか合わないか知らないが、ガタガタ言わずにとにかく習得する
努力をしているやつからいい仕事ができるようになってくる。


173 :デフォルトの名無しさん:03/04/20 04:34
>169
漏れもそうおもう。会社は社員を『交換可能な部品』にしたがっているから、
職人なんてウザイだけなんだろうなぁ


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


174 :デフォルトの名無しさん:03/04/20 04:35
デザパタは便利なツールだと思うんだが。UML と組み合わせて使うと。

175 :デフォルトの名無しさん:03/04/20 04:39
もう説明するのも面倒臭いな。
勝手にすれば。笑
これだけはいっとくけどデザパタはオブジェクト指向ができない人が作ったものだ。
間違いなく。

176 :デフォルトの名無しさん:03/04/20 04:40
当然のことをもっともらしく書いてるのがデザパタ。

177 :デフォルトの名無しさん:03/04/20 04:46
>>175
反対視する専門家って、具体的に言うと誰?

>>176
そうだよ。


178 :デフォルトの名無しさん:03/04/20 04:47
いや、あれはただわかってないやつが書いただけ。

179 :デフォルトの名無しさん:03/04/20 04:47
冷蔵庫に牛乳があたかもしれない。


180 :デフォルトの名無しさん:03/04/20 04:48
>>175
なんかの記事の受け売りか。


181 :デフォルトの名無しさん:03/04/20 04:50
OOPL の文法は、デザイン・パターンに書いてあることができるようにするために
ああなっているんだよ。


182 :デフォルトの名無しさん:03/04/20 04:51
>>176
ちゃんとした言葉で整理したってとこは評価できる。

183 :デフォルトの名無しさん:03/04/20 05:18
175はその文章からしてデザパタを理解していないので無視してください。

184 :デフォルトの名無しさん:03/04/20 05:20
ではでは次のお手紙です。

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

185 :デフォルトの名無しさん:03/04/20 05:20
ちょっと感情的になってしまいましたか終わりです。今回はWIZARDとの出
会いを書かせて頂きました。最後ですが僕の名はTomです。この名だけは覚えて
おいて下さいね。読みずらい文章ですが(だっていつも国語と英語は2だモン!)
ここ迄読んで下さった人ありがとうございます。それと文章を打ち込んでくれた方
汚い字ですみません。(これは紙に書いているのでウエストサイドの人がパチパチ
と打ち込んでる訳さ!
ちなみにこの手紙レポート用紙に書いているんだ、だって便せん無いんだもん)で
は、皆さん、さよなら、さよなら、さよなら

Tom●

う〜んひさびさに壮烈な文章です。自分は3ヶ月前迄コピーユーザーだったこと
を宣言してるくせに堂々とコピーユーザーをけなしている・・・ほんでもって「頭
丸めろ」だって・・・Tomさんは頭丸めましたか?WIZARD2つ3つ買って
くれましたか?(つっこむ、つっこむ)これからもお手紙は下さい。それは有難い
事です。ハイ。

186 :(´д`;)ハァハァ :03/04/20 05:49
http://homepage3.nifty.com/coco-nut/

187 :デフォルトの名無しさん:03/04/20 06:03
>>177
はぁ?何?専門家って?いるの?そんなの。
俺じゃないんだけど、それいったの。

188 :デフォルトの名無しさん:03/04/20 11:21
デザインパターンの考え自体を否定しているのか、
例えば 「GoF パターンのこれ」 といった各々のパターンの出来についていってるのか、
どっちなんだ?

189 :デフォルトの名無しさん:03/04/20 14:08
>>188
考え自体駄目。
だいたいオブジェクト指向じゃないじゃん。
絶対、オブジェクト指向だけをちゃんと覚えた方が楽だって。
いらないでしょデザパタなんて。
かなり腐ったパターンもあるし、絶対、これ作った奴怪しいって。

190 :デフォルトの名無しさん:03/04/20 14:11
俺は型にはまるのはいやだ。

191 :デフォルトの名無しさん:03/04/20 14:15
>>189
実装経験のないカタワ馬鹿いってよし。


192 :生涯一職人:03/04/20 14:19
俺流

193 :デフォルトの名無しさん:03/04/20 14:20
なぜデザパタが生まれたか、勉強してください

194 :デフォルトの名無しさん:03/04/20 14:22
>>189
議論したいなら具体例示せよ。
例えば、どのパターンのどの部分がオブジェクト指向じゃないの?
で、おまえの言っているオブジェクト指向って何?
なんか、かなーり狭い意味でのオブジェクト指向に固執しているような
気がするんだけど。


195 :デフォルトの名無しさん:03/04/20 14:23
>>189
「腐ったパターンもあるし」ってことは、>>189が「腐ったパターン」であることを
具体的に示せるパターンもあるのだろうな。それがなんなのか、ぜひ知りたいものだ。




196 :デフォルトの名無しさん:03/04/20 14:25
デザパタを適用できるのは全ソースの5%が限度。そう考えてる自分は
勉強不足ですか?

197 :デフォルトの名無しさん:03/04/20 14:32
>>196
何を根拠に「5%が限度」なんて言うのだろう。
5%ってどう言うことなんだろう。

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

198 :デフォルトの名無しさん:03/04/20 14:35
複数クラスの関連は、デコレーターと継承しかない。オブジェクト
指向習得は、この二つをどうやって使い分けるかに始まる。

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

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

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

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

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

199 :デフォルトの名無しさん:03/04/20 14:37
>>197
いえ、全くの主観です。いろいろと試してみた結果こういう考えに至りました。
はっきりとした根拠は示せません。ごめんなさい。
ごめんなさいついでに、あなたはどれくらいの範囲に適用できてますか?

200 :デフォルトの名無しさん:03/04/20 14:38
>>198
そか...デコレータしか理解できなかったんだね。

201 :198:03/04/20 14:44
>>200

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

202 :デフォルトの名無しさん:03/04/20 14:46
>>197は厨房と認定されました。

       ,-、/^^、,-、
      /` /   ヽ ´ヽ
    <´ ̄`     ´ ̄`>
    く    認  厨     ,>
    < \..         / >
     く /  定  房  ヽ ,>
     〈__     人    __〉
      ヽ__,.<_,、_ゝ、_ノ

203 :197:03/04/20 14:52
>>199
「どれくらいの範囲に」なんて、考えたことも無かったよ。

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

>>202
で?

204 :デフォルトの名無しさん:03/04/20 14:54
>>198
has-a関係は継承で表現するの?デコレータで表現するの?

205 :デフォルトの名無しさん:03/04/20 14:54
>>197

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


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

207 :デフォルトの名無しさん:03/04/20 14:55
それぞれのパターンは、私達の身の回りで何回も起きる問題
およびそれらの問題に対する解決ポイントを記述している。

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

208 :198:03/04/20 14:57
has-a = デコレータ
is-a = 継承

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

209 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/20 14:57
オブジェクト指向はワークシェアリングの一種です。

210 :デフォルトの名無しさん:03/04/20 14:58
>複数クラスの関連は、デコレーターと継承しかない。

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

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


211 :デフォルトの名無しさん:03/04/20 15:00
>>207
俺はそれを手馴れと呼びたい。

212 :デフォルトの名無しさん:03/04/20 15:02
あ、プい1が来ちゃった。んじゃ。

213 :デフォルトの名無しさん:03/04/20 15:03
ソフトウェアパターンとは、優れたソフトウェア成果物(アーキテクチャ、分析、設計、実装、プロセスなど)
を明文化したもの。

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

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

214 :デフォルトの名無しさん:03/04/20 15:03
デコレート(装飾)じゃなくて、デレゲート(委譲)じゃないのかな。

215 :デフォルトの名無しさん:03/04/20 15:05
>>211
不特定多数の手馴れを文書化して、後からくる人にオナジ苦労を
させないようにするっていうのは、賢い知恵だと思うがな。

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

216 :デフォルトの名無しさん:03/04/20 15:06
>>213
名前がついた途端、そのものの進化が止まる。

217 :デフォルトの名無しさん:03/04/20 15:06
用語を提供するのがソフトウェアパターン。

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

218 :198:03/04/20 15:08
>>210

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

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

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

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

219 :デフォルトの名無しさん:03/04/20 15:09
>>215
その苦労は労働生産性に多大な影響を与えるほどのものではない。
むしろ、後からくる人が考える機会を逸することこそ問題だ。

220 :デフォルトの名無しさん:03/04/20 15:09
ソフトウェアパターンは注目度が高まり、もはや必須の知識になってきた。
しかし一方で「どうもソフトウェアパターンは好きになれない」という声も聞く。

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

221 :デフォルトの名無しさん:03/04/20 15:12
確かにソフトウェアパターンしいうのは当たりまえのことを並べたに過ぎないもの。

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

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

222 :198:03/04/20 15:15
上見ると、カタログ化が有益に感じる人とそうでない人が
いるみたい。

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

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

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

223 :デフォルトの名無しさん:03/04/20 15:16
>>216
名前がつくからこそ、進化が進む。

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

224 :デフォルトの名無しさん:03/04/20 15:21
>10年以上の歳月をかけて熟成されてきたModel-View-Controllerパターンを
>ゼロの知識段階で数ヶ月で唸り出せるものだろうか?

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

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

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

225 :デフォルトの名無しさん:03/04/20 15:21
デザインパターンは素敵派
・名前付けによって知識の共有が行える派
・名前付けが進歩を促すよ派
・直感的には思い付かないパターンも含まれているよ派


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


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

226 :デフォルトの名無しさん:03/04/20 15:21
パターンを使うことで創造性が阻害されるという意見もあるが
しかし「今までになかったものを作り出す」、「今までに無かったアプローチで成果物を作り出す」
という創造性を発揮するには、今までに存在していたものを知らなければならない。

よっぽどの天才以外は。

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

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

227 :デフォルトの名無しさん:03/04/20 15:22
>>218
その「有用な概念」に名前がついていると、会話が楽なんだよね。
その名前だけで話が通じるから。
協働で開発作業をしない人には、そういうボキャブラリは意味がないの
かもしれないですねえ〜。

228 :デフォルトの名無しさん:03/04/20 15:22
名前はそれが表す実態の変化(進化)を拒む。

229 :デフォルトの名無しさん:03/04/20 15:23
>>224
・・・最後の2行の例はテクニックというべきものではない

230 :デフォルトの名無しさん:03/04/20 15:23
>名前もついていないものの議論なんかできないっしょ?

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

231 :デフォルトの名無しさん:03/04/20 15:24
>>224
>マイクロソフトのビュー・ドキュメントとか知ってれば、

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


232 :デフォルトの名無しさん:03/04/20 15:26
「守破離」という言葉があるが、「守」ができてないのに
「破離」をしたがる奴は、どの世界でも大成しないな。

233 :デフォルトの名無しさん:03/04/20 15:27
知識の共有ってことでいえば、名前の乱立を避けるために
RFCを管理してる機関みたいなのが必要な気がするな。

234 :デフォルトの名無しさん:03/04/20 15:28
ビュードキュメントなんて、MVCが「発明」されるずっと
前からあるし、MSが作った概念なわけでもないことは呼んだこと
ある。おそれく、画面系インタフェイスが実現されてるシステムは
みんな多かれ少なかれ遥か前から使われているテクニック。

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


235 :デフォルトの名無しさん:03/04/20 15:29
「四十八手集を読んでみたんだけどその殆どは、自分であみ出したものと一緒だった。
  残りいくつかは、体位に無理があり過ぎた。」



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

237 :デフォルトの名無しさん:03/04/20 15:30
>>234
MVC分離ってのは、その「皆が知っていた」概念に名前付けただけですよ。
罠でもなんでもないでしょが。

238 :デフォルトの名無しさん:03/04/20 15:31
まあ、俺としては新人君がデザパタ知ってりゃOKなんてことにさえならなきゃ
どうでもいいや。

239 :デフォルトの名無しさん:03/04/20 15:31
>>230
だったらあなたは名前をつけては駄目だというのか?

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

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

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

240 :デフォルトの名無しさん:03/04/20 15:32
サッカのフェイントのテクニックとかパスワークのテクニックを
分類すれば、いくつかできるだろうな。

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

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

242 :デフォルトの名無しさん:03/04/20 15:33
>>236
だから、パターンは優れた設計の基礎だって

243 :デフォルトの名無しさん:03/04/20 15:34
>>241
あんた! いいこといった!

244 :デフォルトの名無しさん:03/04/20 15:34
>>232
デザパタは「守」の全てではない。一部をカタログ化したものにすぎない。

245 :デフォルトの名無しさん:03/04/20 15:35
>>242
それが全てだな。
土台と思っている人と、天井と思っている馬鹿の会話は成立しない罠。

246 :デフォルトの名無しさん:03/04/20 15:36
俺の親父は多分3パターンくらいしか知らないと思うが
ちゃんと俺を生んでくれたぞ。

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

247 :デフォルトの名無しさん:03/04/20 15:36
>>240
パスにしたって、特別な名前のあるパスってのがある。
たとえば「センタリング」。
(つか、サッカー詳しくないから、名前付きのパスってこれしか知らないのだけど。)

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

248 :デフォルトの名無しさん:03/04/20 15:37
まあ、子供の出来と体位パターンとの相関は多分ないだろうからな。

249 :デフォルトの名無しさん:03/04/20 15:37
>土台と思っている人

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

250 :デフォルトの名無しさん:03/04/20 15:37
「デザパタは最低限のエチケットです」には賛成。

251 :デフォルトの名無しさん:03/04/20 15:41
>>249
他の頭が良い人が作ってくれた土台だ。 それを使うことを恥には思わない。

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

252 :デフォルトの名無しさん:03/04/20 15:43
>>247みたいな、「会話と語彙の基礎」をいちいち説明してやらないと
理解できないとは、やっぱりこの業界ってカタワがおおいんだなあ。
藻前ら、技術者同士のコミュニケーションどうやっているんだよ?
もしかして、そういうことはしない、ヒキーですか?

253 :デフォルトの名無しさん:03/04/20 15:46
なんか、パターンに名前を付けるのがいいかどうかっていう話、
もうどうでもよくない?答えなんてでないだろうよ。
それよりも、>>198

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

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

254 :デフォルトの名無しさん:03/04/20 15:48
よーーーし、次はサイドから中に入れる奴いってみよう。

255 :デフォルトの名無しさん:03/04/20 15:48
>>253
ソフトウェアパターンの第一のメリットは開発者に共通の「用語(ボキャブラリ)」を提供できること。
ソフトウェアパターンの最大の価値は、個々のパターンに「名前」がついていること。


256 :デフォルトの名無しさん:03/04/20 15:56
ピッチャーが
「次は速球と同じスピードのボールでありながら、プレート付近でわずかに変化するボールを投げるよ」

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

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

そういうことではない?

257 :デフォルトの名無しさん:03/04/20 15:59
>>256
そだね。デザパタはそれにつきるよ。

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

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

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

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

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

261 :デフォルトの名無しさん:03/04/20 16:03
>>258
そしてそのバカがスーパーグレートカットファストボールを作っちゃったりする。

262 :デフォルトの名無しさん:03/04/20 16:05
結局、全部のメソッドをパブリックにしちゃって、やたら滅多ら
継承したがるレベルの輩(実は少なくない)にChain of Responsibility
を教えるほど怖いものはないな。

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

263 :デフォルトの名無しさん:03/04/20 16:06
カーブだのシュートだのフォークだのの投げ方は、
素直に人に教わった方が速い。
誰もが大リーグボールを発明できるわけではない。

264 :デフォルトの名無しさん:03/04/20 16:09
クラスの作りの本質を学ぶのがオブジェクト指向では最も大事。

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

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

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

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

266 :デフォルトの名無しさん:03/04/20 16:12
工夫する奴はどんな環境に置かれても工夫する。デザパタに出会ったからって
創造性が阻害されるものでもない。「へ〜そんなやり方あるんだ〜」で終わり。

267 :デフォルトの名無しさん:03/04/20 16:15
俺、シングルトンを知らずに、インスタンスの数を2つまで
しか作れないクラス作ったけど、それって発明になるのかな。

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

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

268 :デフォルトの名無しさん:03/04/20 16:23
>>267
1- ?????????????????????????????
2- ???????????????????????????
3- GoF????????????
4- ????????????????????????????????
5- Java?static{} ????????????
6- ???(      )

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

269 :デフォルトの名無しさん:03/04/20 16:23
>>267
static領域を使って、インスタンス個数を有限個に制限するのは
すべてSingletonパターンの派生といえる。つうかGoFバイブルにも
書いてある。みんなやってることということだな。

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


270 :268:03/04/20 16:24
化けた...鬱

271 :デフォルトの名無しさん:03/04/20 16:26
>創造性が阻害されるものでもない。「へ〜そんなやり方あるんだ〜」で終わり。

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

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

272 :デフォルトの名無しさん:03/04/20 16:28
SAXをの設計を否定している方がいるが、他にどういう設計ならよかったのだ?



273 :デフォルトの名無しさん:03/04/20 16:29
>>269

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

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

274 :デフォルトの名無しさん:03/04/20 16:29
結局、こんなの命名されなくたって知ってるってのと、複雑すぎて避けたい
ってのと両極端なんじゃない?かゆいところに届いてるのが少ないって
やつ。



275 :デフォルトの名無しさん:03/04/20 16:32
>>273
何でそういう突っ込みになるの?>>267にレスしただけ。

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

276 :デフォルトの名無しさん:03/04/20 16:33
>>271
有機本しか読んでないけど、少なくともそれには
「いつ、どれを使うべきか」に関する直感的な説明があった。
そゆのでは不足なのかな。

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

277 :デフォルトの名無しさん:03/04/20 16:34
>>273

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

278 :デフォルトの名無しさん:03/04/20 16:34
>>272
インターフェイスと実装の分離も、ポリモーフィズム実現の為の
継承も、「複雑だ」とぬかすアホがいるからな。会話するだけ無駄。

279 :デフォルトの名無しさん:03/04/20 16:37
将棋やるんでも、いきなり定石を覚えるよりも、最初は定石知らずに
やって、ある程度打てるようになったら、徐々に自分なりに使えそうな
定石を覚えていくもの。

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

280 :デフォルトの名無しさん:03/04/20 16:46
SAXとDOMを比べたら、SAXのほうが100倍ましだろ。

281 :デフォルトの名無しさん:03/04/20 17:13
>>198
> 複数クラスの関連は、デコレーターと継承しかない。オブジェクト
> 指向習得は、この二つをどうやって使い分けるかに始まる。

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


282 :デフォルトの名無しさん:03/04/20 17:16
おもいっきりOOがわかってないところもみどころだな。

283 :デフォルトの名無しさん:03/04/20 17:29
>>236
> デザパタの考えが根本的に死んでることを理解するには
> まずオブジェクト指向を覚えなきゃ話にならない。

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


284 :デフォルトの名無しさん:03/04/20 17:31

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

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

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

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


286 :デフォルトの名無しさん:03/04/20 17:56
>>236
デザインパターンを学べばオブジェクト指向も必然的に身についてくるだろうよ。
どういう言語を使っているか、どういうデザインパターンの本をよんでいるかにもよるが。

287 :デフォルトの名無しさん:03/04/20 18:15
>>284
でも、それって素敵なことだと思うんだ。

288 :デフォルトの名無しさん:03/04/20 18:21
パターンはこれから知ってて当然のモノになる。
というか、そうならないと困る。
ここの部分の設計はステートパターンです。と一言で説明できるのがどんなに楽か。

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

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

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


289 :デフォルトの名無しさん:03/04/20 18:22
オブジェクト指向=クラス使用 ではない。

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

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

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

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

290 :デフォルトの名無しさん:03/04/20 18:24
>パターンはこれから知ってて当然のモノになる。

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

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



292 :デフォルトの名無しさん:03/04/20 18:30
>>289
> デザパタはクラスの相関パターンを示すもの。

ウソ。


293 :デフォルトの名無しさん:03/04/20 18:34
>>136 は、「反対視する専門家」が誰なのかいまだ示していない。
>>136 の書き込みがウソであるのに、あたかも本当であるかのように権威付け
するために、反対視する専門家という架空の存在を持ち出しているに過ぎない。
反論があるなら、誰なのか示せ。


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

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

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

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

295 :デフォルトの名無しさん:03/04/20 18:35
>>289
> オブジェクト指向=クラス使用 ではない。

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


296 :デフォルトの名無しさん:03/04/20 18:37
>>294
馬鹿だなあ。この文脈で、デザイン・パターンは OO のデザイン・パターンの
ことだよ。



297 :デフォルトの名無しさん:03/04/20 18:38
>>294
> ものづくりをする人には細かい「スタイル」にネーミングすることは
> 元来好まない。

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


298 :デフォルトの名無しさん:03/04/20 18:40
>>294
> たとえば、曲でも内輪で「ジミヘン的」曲みたいな呼び方をされるが、
> 公式にはその様な名称はなく、せいぜいロック、サンバなどの
> 大まかなスタイルを示すにとどまる。

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


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


300 :デフォルトの名無しさん:03/04/20 18:42
>>294
> ゆえに、この経験則の寄せ集めな「デザイン集」を学ぶことが
> 肌に合わないと感じる技術者が多いのは至極物づくり集団として
> は自然なことなのだ。

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

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


301 :デフォルトの名無しさん:03/04/20 18:45
えっと、今更なんですが。


スレ違いです、多分。

302 :デフォルトの名無しさん:03/04/20 18:45
コード進行とかを知らないギタリスト。いやだな。

303 :デフォルトの名無しさん:03/04/20 18:46
>>294
音楽と工学の区別もつかないやつに、工学の OO がわかるわけがない。

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


304 :デフォルトの名無しさん:03/04/20 18:47
>>294
漏れも、294のような壮大な釣りのできる人間になりたいです。

305 :デフォルトの名無しさん:03/04/20 18:48
>>300
ヘタに相手を馬鹿にした発言をとると、相手はよけい意固地になってしまう可能性がある。

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

306 :デフォルトの名無しさん:03/04/20 18:50
>>303
最後の喩え分かりにくいです...

307 :デフォルトの名無しさん:03/04/20 18:52
>>306
蕎麦:芸術
うどん:工学
OO:讃岐うどん
非OO:稲庭うどん

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

308 :デフォルトの名無しさん:03/04/20 18:52
俺はデザパタの受け売りで、複雑なクラス作りしまくる奴よりも、

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

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

309 :デフォルトの名無しさん:03/04/20 18:54
>>308
馬鹿だなあ。どんなデザイン・パターンを使ってもことが複雑になるようなときに
わざわざデザイン・パターンを使うのは、デザイン・パターンをわかっているとは
言わないんだよ。



310 :デフォルトの名無しさん:03/04/20 18:55
デザイン・パターンは、使うと設計がシンプルになるときに使う。
たとえば Java のストリームとか。


311 :デフォルトの名無しさん:03/04/20 18:55
>>308
漏れはデザインパターンを知ってる奴の方がシンプルなコードを書くと思うんだけどな。
>>308の言うシンプルなコードって言うのは、ポリモルフィズムを期待せず、
Switch-case や if-elseif の入り乱れたコードのことかい?

312 :デフォルトの名無しさん:03/04/20 18:55
>>308
じゃあ、あなたはJavaを使えないですね

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

313 :デフォルトの名無しさん:03/04/20 18:56
>>馬鹿だなあ。

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

314 :デフォルトの名無しさん:03/04/20 18:57
>>308
> シンプルかつ「動く」設計できる奴を取るな。

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


315 :デフォルトの名無しさん:03/04/20 18:58
>>308
> シンプルかつ「動く」設計できる奴を取るな。

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


316 :デフォルトの名無しさん:03/04/20 19:00
>>308
> シンプルかつ「動く」設計できる奴を取るな。

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


317 :デフォルトの名無しさん:03/04/20 19:00
つか、308が言いたかったのは
「受け売りで」の部分に集約されてると思うんだけど。
「理解できないものを使うよりは、理解できてるものを使え」
ってことじゃないか。

318 :デフォルトの名無しさん:03/04/20 19:01
>>315-316
デザイン・パターンを知っている人にはシンプルになっている。


319 :デフォルトの名無しさん:03/04/20 19:02
デザパタ狂信者を見てると、猫の手でも借りたく、自分の
プログラミング能力を必死に補おうとしてると、結論付け
せずにはいられないな。

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

320 :デフォルトの名無しさん:03/04/20 19:04
>>136 は、「反対視する専門家」が誰なのかいまだ示していない。
>>136 の書き込みがウソであるのに、あたかも本当であるかのように権威付け
するために、反対視する専門家という架空の存在を持ち出しているに過ぎない。
反論があるなら、誰なのか示せ。

321 :デフォルトの名無しさん:03/04/20 19:05
>>309 の訂正
>>308
どんなデザイン・パターンを使ってもことが複雑になるようなときに
わざわざデザイン・パターンを使うのは、デザイン・パターンをわかっているとは
言わないんだよ。

322 :デフォルトの名無しさん:03/04/20 19:06
>JUnit や CppUnit なんかはデザイン・パターンを使っているけどそうなっている。
>SAX もそうなっている。

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

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

323 :デフォルトの名無しさん:03/04/20 19:07
>>319
なんにせよ、狂信者ってのはまともには見えんよ。

324 :デフォルトの名無しさん:03/04/20 19:08
>>322
SAX が完成形なんて君が言ってるんじゃないの。
だって、xpath があるし。


325 :デフォルトの名無しさん:03/04/20 19:10
>>320
必死だな。

326 :デフォルトの名無しさん:03/04/20 19:10
>>322
> TestUnit系の設計って動的なクラス名の引渡し

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


327 :デフォルトの名無しさん:03/04/20 19:11
>>322
> TestUnit系の設計って動的なクラス名の引渡し

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


328 :デフォルトの名無しさん:03/04/20 19:13
非デザパタ狂信者を見てると、自分の勉強不足を棚に上げて
他の人が前に進もうとするのを、必死になってくい止めようとしてると
結論付けせずにはいられないな。

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


329 :デフォルトの名無しさん:03/04/20 19:13
Q. 「あたかも」を使って簡単な文を作りなさい。

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


330 :デフォルトの名無しさん:03/04/20 19:14
>>326
動的なクラス名の引き渡し...
prototypeパターンとかは駄目なの?

331 :デフォルトの名無しさん:03/04/20 19:15
結論:デザパタ知ってて悪いことはない。


332 :デフォルトの名無しさん:03/04/20 19:15
狂信的なだけならいい。押しつけてくるから始末におえない。
OO、デザパタ、Delphi どのカテゴリにもいる。

333 :デフォルトの名無しさん:03/04/20 19:16
>>330
テスト・ケースがどんなクラス名で作られるのか、フレームワークを作った人は
知らないから、無理でしょ。


334 :デフォルトの名無しさん:03/04/20 19:19
デザパタ狂信者を見てると、自分の能力不足を棚に上げて
他の人が賢く前に進もうとするのを、必死になってくい邪魔しようとしてると
結論付けせずにはいられないな。

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

335 :デフォルトの名無しさん:03/04/20 19:19
>333
???????????????????????????

336 :デフォルトの名無しさん:03/04/20 19:21
まあ、とりあえずデザパタの勉強はしとけと 損はしないよ

337 :335:03/04/20 19:21
また化けた!safariめぇっ!

338 :デフォルトの名無しさん:03/04/20 19:24
>>333
?????...??????????????????????????????
???????????????????????????



339 :デフォルトの名無しさん:03/04/20 19:25
死のう...

340 :デフォルトの名無しさん:03/04/20 19:25
http://yahooo.s2.x-beat.com/linkvp/linkvp.html

341 :デフォルトの名無しさん:03/04/20 19:28
マカーよ、Cocomonarを使え。

342 :あぼーん:03/04/20 19:28
( ´∀`)/< 先生!!こんなのを見つけました。
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 :デフォルトの名無しさん:03/04/20 20:13
デザパタは似たようなものをたくさん作ってきた奴じゃないと、
そのありがたみを知るのは難しい。

344 :デフォルトの名無しさん:03/04/20 20:19
>>343
漏れはstate パターンを見て、デザインパターンの威力(?)を知ったよ。


345 :デフォルトの名無しさん:03/04/20 20:34
>334
逆じゃねぇ?
『技』の勉強/研究している人を否定して、(他人の)技術力を向上するチャンスを
ツブしているようにしか見えない。

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


346 :デフォルトの名無しさん:03/04/20 20:40
>>329
あかん、なんかつぼにはまってワロてまった

347 :デフォルトの名無しさん:03/04/20 20:44
>>345
だから、デザパタは土台だって言ってるだろ。デザパタ知ったぐらいで天井に
届いたって思い込むのはあわてんぼさん。


348 :デフォルトの名無しさん:03/04/20 20:46
>>346
>>329はデザパタの肝である再利用をうまく使いこなしたってわけだ。

349 :デフォルトの名無しさん:03/04/20 20:49
>>347
>>345は天井に届いたように誤解してる感じには見えないだろ。


350 :デフォルトの名無しさん:03/04/20 21:09
>>349
デザパタだけじゃあメシの種になりえないわな。

351 :デフォルトの名無しさん:03/04/20 21:12
世の中には二種類いるんだ。
知識を身に付ければつけるほど、発想がより自由になっていく人。
知識を身に付ければつけるほど、発想がより固定化していく人。
デザイン・パターンは前者のような人のためにある。

352 :デフォルトの名無しさん:03/04/20 21:14
>>351
胆略的すぎ。お前のIQを良く表している。

353 :デフォルトの名無しさん:03/04/20 21:18
>>352
胆略ってなに?
キモの戦略?


354 :デフォルトの名無しさん:03/04/20 21:19
胆の戦略は liver strategy だよ。


355 :デフォルトの名無しさん:03/04/20 21:19
じゃあ Strategy パターンか。


356 :デフォルトの名無しさん:03/04/20 21:20
レバパタだな。


357 :デフォルトの名無しさん:03/04/20 21:22
class AbstractLiver { }; // 抽象レバークラス
class ConcreteLiver1 : public AbstractLiver { }; // 具象レバーその 1
class ConcreteLiver2 : public AbstractLiver { }; // 具象レバーその 2
class ConcreteLiver3 : public AbstractLiver { }; // 具象レバーその 3


358 :デフォルトの名無しさん:03/04/20 21:22
>>351
何となく分かる。
それで「あるべき論」ばかり言い出して、あちこちに矛盾をだしまくり、
設計を破綻させる「あるべき論者」。

359 :デフォルトの名無しさん:03/04/20 21:23
とりあえず、if とか switch を”無様”と思うか、思わないかで、
デザインパターンの評価も異なるだろうな。

360 :デフォルトの名無しさん:03/04/20 21:23
>>357
おお、胆略的すぎ。


361 :デフォルトの名無しさん:03/04/20 21:24
>>358
つまり、どういうこと?
「あるべき論」というのは?


362 :デフォルトの名無しさん:03/04/20 21:26
>>361
「あるくべき」の typo だろ。

363 :デフォルトの名無しさん:03/04/20 21:29
世の中には二種類いるんだ。
「あれを勉強すると発想が固まる」となにも勉強しない人。
「あれを勉強すると発想が固まる」のが本当か、「あれ」を勉強してみる人。

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

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


364 :デフォルトの名無しさん:03/04/20 21:32
> 「あれを勉強すると発想が固まる」となにも勉強しない人。

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

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


365 :デフォルトの名無しさん:03/04/20 21:32
鳩じゃねー、人だ。ごめん。


366 :デフォルトの名無しさん:03/04/20 21:35
>>364
同じになるといいんだけどね。
普通は、劣るよね。

367 :デフォルトの名無しさん:03/04/20 21:40
既存のデザインパターンを編み出せる能力があるなら、さっさと既存の
パターンを覚えて、さらにもっと有用な誰も発明していないパターンを
発明してくれよ。


368 :デフォルトの名無しさん:03/04/20 21:41
発明したら、cppll か結城さんの wiki に書き込んどくれ。


369 :デフォルトの名無しさん:03/04/20 21:47
>>208
has-a を Decorator パターンで表現するような初心者には無理ぽ。


370 :デフォルトの名無しさん:03/04/20 21:47
test

371 :デフォルトの名無しさん:03/04/20 22:08
デザパタは初心者でも上級者と勘違いさせちゃう危険な物って
のがよくわかるな、このスレッドから。

372 :デフォルトの名無しさん:03/04/20 22:10
いいからオブジェクト指向覚えろって。笑

373 :デフォルトの名無しさん:03/04/20 22:12
上級者-初心者っていうカテゴライズもどうかと思うけどな。
# すれ違い下げ

374 :デフォルトの名無しさん:03/04/20 22:13
次スレは
「貴様ら!オブジェクト指向を教われ!!第3章」だな

375 :名無し:03/04/20 22:36
いろいろ説教たれるよりコードで見せたほうが速いと思います

376 :デフォルトの名無しさん:03/04/20 22:38
>>371
デザパタが危険なんじゃなくて、無知が危険なの。


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

378 :デフォルトの名無しさん:03/04/20 23:58
>>377
>己の理解している範囲=その世界の全てという馬鹿は、数ある馬鹿のなかでも、もっとも有害な馬鹿だと思う。

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

379 :デフォルトの名無しさん:03/04/21 00:02
アンティークなジェラートを食べるアンジェラだとはこのことだ。


380 :デフォルトの名無しさん:03/04/21 00:10
>>379
灰?

381 :デフォルトの名無しさん:03/04/21 01:02
ユースケースっつーか、
あのアクターとか出てくるやつがようわからん

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

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

382 :デフォルトの名無しさん:03/04/21 01:44
ユースケサンタマリア


383 :デフォルトの名無しさん:03/04/21 02:37
>381

170 名前 : OOモナー Mail : 投稿日 : 03/03/29 00:21

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

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

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

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


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

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


386 :デフォルトの名無しさん:03/04/21 03:01
>>385
ワラタ。バカしかいない職場にいるバカの一人が勘違いしているだけ
ということですな。

387 :デフォルトの名無しさん:03/04/21 03:17
英熟語は充分普及してるし、みんな価値を認めている。
小学生ですら英会話教室に通う時代だ。
デザパタと英会話に、何の共通点があるんだ?
これが、自分が使えると思ってる、勘違い馬鹿ってやつか?

388 :デフォルトの名無しさん:03/04/21 03:29
うちの会社は syslog を逐一プリンタで印刷しているが、それと同じぐらい馬鹿だ。


389 :デフォルトの名無しさん:03/04/21 04:26
デザパタは充分普及してるし、みんな価値を認めている。
COBOLERですらJava教室に通う時代だ。


390 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/21 04:50
判った。
デザパタでオセロ書いてみろ。
話はそれからだ。


391 :デフォルトの名無しさん:03/04/21 05:02
>>390
お前はオセロ以外にネタが無いのか

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

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

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

393 :デフォルトの名無しさん:03/04/21 06:20
>>329
アーキテクチャとデザイン・パターンの区別もつかないやつの言うことなんて
説得力がない。


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


395 :デフォルトの名無しさん:03/04/21 06:28
>>392
「デザインパターンを知っている熟練技術者」と「デザインパターンを知らない
初心者」の場合でも、どうなるか比較しないとだめでしょ。

396 :デフォルトの名無しさん:03/04/21 06:29
>>392
それなら、「デザインパターンを知っている熟練技術者」と「デザインパターンを知らない熟練技術者」と
「デザインパターンを知っている初心者」と「デザインパターンを知っている初心者」と
すべての場合を検討する必要がありますね。


397 :デフォルトの名無しさん:03/04/21 06:30
まちがえた。

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


398 :デフォルトの名無しさん:03/04/21 06:32
結論:
>>392 はハッタリということですね。

399 :デフォルトの名無しさん:03/04/21 06:45
デザパタを理解するのは、どんな馬鹿でも出来るけど、
経験のないプログラマが、デザパタに捕らわれないようになるまでには、
ある程度の技術的蓄積が必要。

400 :デフォルトの名無しさん:03/04/21 06:51
>>399
一昔前ならそうだけど
今はデザインパターンを理解できないほどのバカも
この業界に入ってくるんだよね

401 :デフォルトの名無しさん:03/04/21 06:54
>>399
いや、3 歳児の知能の人には理解できない。


402 :デフォルトの名無しさん:03/04/21 07:35
そもそも世の中には初心者と熟練技術者しかいないのか?デザパタが必要なのはその中間だろうが。

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

404 :デフォルトの名無しさん:03/04/21 08:35
Cマガ読んでないんだけど、ここで言う神クラスの定義ってなに?
・万能クラス
・独裁者クラス


405 :デフォルトの名無しさん:03/04/21 09:21
・創物主クラス。ファクトリ?ビルダ?
・救世主クラス。あらゆる罪を許し、人を愛する...。
・エロ画像や動画をしかるべき板にうpするクラス。

406 :デフォルトの名無しさん:03/04/21 10:02
>>392
憶えたものを無理矢理使おうとしなければいいだけの話。
何にでも言えることだが、活かせる場で使う事が大切。
本質を理解していれば、活かし方もわかるはず。

407 :デフォルトの名無しさん:03/04/21 10:24
>憶えたものを無理矢理使おうとしなければいいだけの話。

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


408 :デフォルトの名無しさん:03/04/21 11:50
>>407
>初心者は何でも覚えたものを使おうとする。

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

409 :デフォルトの名無しさん:03/04/21 12:28
覚えたてのものを使ってみたくなるのは
楽しいんだからしょうがない。
誰もが通ってる道じゃないか。
さりげなくフォローしてあげりゃいいのよ。

410 :デフォルトの名無しさん:03/04/21 12:51
>>392の想定している初心者って言うのは、
「デザインパターンをどこに適用すべきかが分からないときは、
 無理やりに、不適切な部分に適用しちゃうけど、
 デザインパターンを使用しなければまともに設計のできる人間」
ですか?

411 :デフォルトの名無しさん:03/04/21 13:39
>>403
>>404
俺も神クラスの定義が気になる
ネットで独学って生活が続いてる趣味プログラマだけど
たまには勉強のためにCマガ買ってこようかな

412 :デフォルトの名無しさん:03/04/21 14:21
>>411
立ち読みで十分。

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

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

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

415 :デフォルトの名無しさん:03/04/21 20:47
パターン使って、拡張性、メンテ性があがるとは考えにくいね。
流れ追いにくいし。シンプルな、has-aが一番拡張性、メンテ性が
しやすい。

416 :デフォルトの名無しさん:03/04/21 20:56
神クラスってのは、全てのメンバー、メソッドがpublic。
しかも、サブクラスで定義すべきメンバー、メソッド満載の超スーパークラス。
ステップ数は数千〜1万以上。これさえあれば、何もいらない。
そんな感じ?

417 :デフォルトの名無しさん:03/04/21 21:34
神クラスは具体的にはグローバルインスタンスホルダーかな?
面倒臭くなって設計を投げるとできるクラス。
まあ、こんなところで破綻してるぐらいだからオブジェクト指向をわかってないかな。

418 :デフォルトの名無しさん:03/04/21 21:49
> グローバルインスタンスホルダー
あー、俺、やっちゃってるなあ。
どうしたらいいのかわからんのよね。
Singletonでやるべきなのか?

419 :デフォルトの名無しさん:03/04/21 22:00
>>416
それ、神っつーよりも奴隷。

420 :デフォルトの名無しさん:03/04/21 22:10
シングルトンはやらないほうがいい。
しっかり設計しろ。
さぼってるだけだ。
ありゃ駄目なパターンだ。
グローバル変数と何もかわらない。

421 :デフォルトの名無しさん:03/04/21 22:15
>>414
方法論ばかりこだわって内容が伴ってないアリガチな感じ。
案外ユースケースに不備が多くても、風通しの良いプロジェクトなら
致命的な問題にはならないんだが。

422 :デフォルトの名無しさん:03/04/21 22:17
>420
それは、おまえがSingletonをstaticで実装しているからだろ?w
他のパターンと組み合わせてみろよ。

423 :デフォルトの名無しさん:03/04/21 22:40
>>288
> 「ここのデータ構造はスタックを使っていまして・・・」
> 「はい? スタック? なんですかそれは? イチから説明してください。 」
> あなたはこんな奴と仕事が出来ますか?
できない。できないといえばそれは確かにそう言える。
大学で情報学を専攻していた奴ならそれくらいはしっているはずだが。

424 :デフォルトの名無しさん:03/04/21 22:41
>>420
クラスをパッケージに格納して特定のパッケージ内でしかアクセスできないようにしろ。

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


426 :デフォルトの名無しさん:03/04/21 22:55
>>425
馬鹿はお前だ。お前の論理を突き詰めていくと、
メソッドの中ではオブジェクト一つ作れない話になるじゃねーか。


427 :デフォルトの名無しさん:03/04/21 23:04
雑誌にデザパタwを適用した良いサンプルコードが
載ったことが一度でもあるのかと小一時間(ry

ホントはだれもつかっちゃいない罠。
みーんなバーチャ(脳内)。だいたいjava自体が
バーチャルだしなw
もまいら!パターンをうまく適用できてるオープンソースコードプロジェクトを
おしてくれませんか?(c++で)

428 :bloom:03/04/21 23:06
http://homepage.mac.com/ayaya16/

429 :デフォルトの名無しさん:03/04/21 23:22
>>427
そういや、まとまった成果物をみたことがないな。まあ、厨房のおいらにゃ
もともと縁の無い世界か・・・

430 :デフォルトの名無しさん:03/04/21 23:24
>>427
なぜC++限定?

431 :名無し:03/04/21 23:24
じゃあ、これからこのスレで作ろう

432 :デフォルトの名無しさん:03/04/21 23:25
>>431
マジで応援する。是非見てみたい。ガンガレ!

433 :デフォルトの名無しさん:03/04/21 23:26
で、お題はオセロとか言い出したらコロスよ

434 :デフォルトの名無しさん:03/04/21 23:27
みんなが微妙に勘違いしつつ取り入れているのがデザパタ。

435 :デフォルトの名無しさん:03/04/21 23:30
最近のデザパタはJavaを普及させるお手伝いと化しているな。

436 :デフォルトの名無しさん:03/04/21 23:30
むしろ、みんな好き勝手に作っているということが、
デザパタという枠組みがあることで明るみにでたんだと思う。

437 :デフォルトの名無しさん:03/04/21 23:32
>>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を使うな、つまりクラスライブラリを
使うなといってるのと同じ。

438 :デフォルトの名無しさん:03/04/21 23:36
もともと、GoF本ってC++の例しか載ってなかったんじゃないか。

439 :デフォルトの名無しさん:03/04/21 23:39
JavaとC++ではどっちがデザパタに馴染みやすいんだろう?
みなさまのご意見お待ちしています。

440 :デフォルトの名無しさん:03/04/21 23:39
>>437
馬鹿が馬鹿にも分かるように説明するのは
卵が先か鶏が先かと同じく相互参照になり
不可能だという好例

441 :デフォルトの名無しさん:03/04/21 23:40
>>439
ネットとか検索してるとコード例のほとんどがJavaだね。日本だけか?

442 :デフォルトの名無しさん:03/04/21 23:41
>>440
まあ、そういうことだがw

443 :デフォルトの名無しさん:03/04/21 23:41
>>437, >>440
まあまあ、少し春風にでもあたってきなされ。

444 :デフォルトの名無しさん:03/04/21 23:46
>>438
Smalltalkも乗ってたろ

445 :デフォルトの名無しさん:03/04/21 23:55
>>444
ほんのちょっとだけな
ちなみに最新版だと、Javaのソースも(CD-ROMのみだが)付いてくる。

446 :デフォルトの名無しさん:03/04/21 23:57
java馬鹿がいきがってコード出してんじゃねーよ。
価値ない。



447 :デフォルトの名無しさん:03/04/21 23:57
考えてみれば>>425がJava厨なのが原因か。
Javaには、コンストラクタ、staticメソッド、インスタンスメソッドの
三つがあるが、Smalltalkにはクラスメソッド、インスタンスメソッド
だけだしな。SmalltalkならSingletonも違和感ないだろう。

448 :デフォルトの名無しさん:03/04/21 23:57
Javaを使えない自分にとっては寂しい限りだ。かといってJavaには魅力を感じないし。

449 :デフォルトの名無しさん:03/04/22 00:02
いろんな言語を知っておくのはよいことだよ?

450 :デフォルトの名無しさん:03/04/22 00:10
段々オブジェクト指向が分かってきた。

451 :デフォルトの名無しさん:03/04/22 00:11
>>449
分かっちゃいるけど、なんかこうワクワク感がないって言うか・・・

452 :デフォルトの名無しさん:03/04/22 00:12
>>438-439
オブジェクト指向をうたっている言語なら、ほとんどどの言語でも大丈夫。
サンプルの C++ と、自分の作っている言語と両方できれば、難なく読み替えできる。


453 :デフォルトの名無しさん:03/04/22 00:15
>>451
Rubyとかやってみたら?

454 :デフォルトの名無しさん:03/04/22 00:16
>>453
いいね。面倒なコンパイルも必要ないし。

455 :デフォルトの名無しさん:03/04/22 00:16
知ることは、非常にためになる。使うには価値無い。
javaを知ったところであなたを雇ってくれるまともな会社は無い。
上級者だろうが初級者だろうが、所詮クラスライブラリ
やAPIを利用するだけ。
デザパタしってるからってあなたを雇ってくれるまともな会社は無い。
オブジェクト指向知ってるからってあなたを(ry

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

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

457 :デフォルトの名無しさん:03/04/22 00:17
>>455
うーん・・・・スタミナ?

458 :デフォルトの名無しさん:03/04/22 00:19
>>455
スレチガイカコワルイ

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

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

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


460 :デフォルトの名無しさん:03/04/22 00:27
>>456
>そんなの何処でどうして必要なの?
昔、かあちゃんにこんな感じで怒られたことがある。

461 :デフォルトの名無しさん:03/04/22 00:33
そもそも、すべてをクラスとして表現するという
時点でもう破綻してるわけだ。
たとえばjavaとか。その他ではjavaとか。
あと、javaとか。
んで、デザインパターンなんかの知恵いれちゃうと
なるほど!とかって勘違いするわけだ。
多少、頭の柔らかい奴ほど。

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

462 :デフォルトの名無しさん:03/04/22 00:33
>>456
> はぁ?そんなの何処でどうして必要なの?
Foo を呼び出すクラスが Bar を知らなくていい場合、
Foo を呼び出すクラスが Bar を知らなくてすむ。

463 :デフォルトの名無しさん:03/04/22 00:34
>>461
君の脳が破綻している。


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

465 :デフォルトの名無しさん:03/04/22 00:35
>>461
OOPL の文法ってのは、デザイン・パターンをやれるようにできるために、ああなっている。


466 :動画直リン:03/04/22 00:35
http://homepage.mac.com/hitomi18/

467 :デフォルトの名無しさん:03/04/22 00:41
>>465

嘘だろ。オブジェクト指向的なプログラミング
に対応してるだけだ。
デザインパターンは後発なはず。

468 :デフォルトの名無しさん:03/04/22 00:43
う〜ん・・・乗り遅れちゃった奴が約1名。ご愁傷様。

469 :デフォルトの名無しさん:03/04/22 00:43
>>467
デザイン・パターンの名前がついたのは後だけど、ああいうことはやられていた。
ああいうことをやるために OOPL ができた。



470 :デフォルトの名無しさん:03/04/22 00:48
C++ができる前にGoFデザインパターンは
できてたってことか!?
ソース出せソース!w
変な言語の話とかだすなよ。

471 :デフォルトの名無しさん:03/04/22 00:50
>>470
GoF本嫁。

472 :デフォルトの名無しさん:03/04/22 00:53
48手ができる前に、全ての体位はやり尽くされていたのと同じ。

473 :デフォルトの名無しさん:03/04/22 00:54
>それぞれのパターンは、私達の身の回りで何回も起きる問題
>およびそれらの問題に対する解決ポイントを記述している。

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


474 :デフォルトの名無しさん:03/04/22 00:54
>>470
結局おまえは何が言いたいんだ?

475 :デフォルトの名無しさん:03/04/22 00:56
言語スペック決まる前にあったなら
デザインパターンを適用した素敵な
コードがごろごろ転がっていなきゃおかしいだろうよ。
どこにあるっていうんだよ!(java以外で)

476 :デフォルトの名無しさん:03/04/22 00:57
>>470
俺の知らない所で明文化しやがってこんちくしょう!ってことか?

477 :デフォルトの名無しさん:03/04/22 00:58
>>475
もしかして、見せて下さいお願いしますってことか?

478 :デフォルトの名無しさん:03/04/22 00:59
>>475
一子相伝なんだよ。

479 :デフォルトの名無しさん:03/04/22 00:59
>>475
アラン・ケイおじさんの研究所に行けば?


480 :デフォルトの名無しさん:03/04/22 01:00
最近の若い人は、デザイン・パターンが新しいもんやと思ってはるんですな。


481 :デフォルトの名無しさん:03/04/22 01:00
>>475
コピペしたいのか?

482 :デフォルトの名無しさん:03/04/22 01:01
>>477
あるのか?

483 :デフォルトの名無しさん:03/04/22 01:03
>>481
コピペするさ。ペタペタペッタンコしまくるさ。

484 :デフォルトの名無しさん:03/04/22 01:05
>>482
Model-View-Controllerパターンを知らないのか?

485 :デフォルトの名無しさん:03/04/22 01:05
多分にほんの少しの誤解だと思うんだ。
言語ができる前にデザインパターンはなかった。
言語ができてデザインパターンを実現できるようになった。
パターンに名前が付いたのはずっと後。
みんな日本語が不自由なだけ。

486 :デフォルトの名無しさん:03/04/22 01:06
>>483
パターンはコピペできるようなものじゃねぇ

487 :デフォルトの名無しさん:03/04/22 01:08
Cマガの特集はすごかったな。
オブジェクト思考でもコードの再利用は簡単ではないってのは
いいとして、コードの再利用ばかりしてたらソフトウエアの
進化が止まってしまうから、再利用しなくてもいいのだって
結論になってしまうのはびっくりした。

488 :デフォルトの名無しさん:03/04/22 01:09
>>483
       ,-、/^^、,-、
      /` /   ヽ ´ヽ
    <´ ̄`     ´ ̄`>
    く    認  厨     ,>
    < \..         / >
     く /  定  房  ヽ ,>
     〈__     人    __〉
      ヽ__,.<_,、_ゝ、_ノ

489 :デフォルトの名無しさん:03/04/22 01:10
>>484
てめーはsmalltalkプログラマなんだな?あ?
javaとか言うなよ。
お前はしょぼいWEBシステムでも作ってりゃいいんだよ。

490 :デフォルトの名無しさん:03/04/22 01:12
>>488
http://www.4gamer.net/specials/gdc24/cry.html

まあ見ておけ

491 :デフォルトの名無しさん:03/04/22 01:12
Cマガも厨房認定してやってくれw


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

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

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

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



492 :デフォルトの名無しさん:03/04/22 01:14
>>489
 (´Д`;)ヾ ドウモスミマセン
   ∨) 
   (( 

493 :デフォルトの名無しさん:03/04/22 01:15
>>490
ドイツの職人芸がどうしたの?

494 :デフォルトの名無しさん:03/04/22 01:16
>>487
そりゃあすばらしい(w

495 :デフォルトの名無しさん:03/04/22 01:16
>>494
つれた

496 :デフォルトの名無しさん:03/04/22 01:17
みんな一つの言語しか使えないと思っている痛い香具師がいる
スレはここですか?

497 :431:03/04/22 01:19
お題はシューティングね
みんながんばって

498 :デフォルトの名無しさん:03/04/22 01:20
>>495
つれたキターーーーーーーーーーーーーーーーーー!

499 :デフォルトの名無しさん:03/04/22 01:20
すげえなCマガ。
編集者もある程度はチェックしろよ

500 :デフォルトの名無しさん:03/04/22 01:22
500!

501 :デフォルトの名無しさん:03/04/22 01:23
>>500
プ(ゲラ嘲笑下木原

502 :デフォルトの名無しさん:03/04/22 01:24
>>487
いまはコードの再利用は重要ではないね。


503 :デフォルトの名無しさん:03/04/22 01:26
設計は YAGNI で ad hoc に、経験を再利用。


504 :デフォルトの名無しさん:03/04/22 01:26
>>502
Cマガ編集者キターーーーーーーーーーーーーーーーーー!

505 :デフォルトの名無しさん:03/04/22 01:27
デザイン・パターンで言う「再利用」は、コードではなくパターンの再利用のこと。


506 :デフォルトの名無しさん:03/04/22 01:28
      __○_○__
      | .___ ..|  |
      | .|7| | |  |  |
   ∧ ∧ .| |7|7|  |  |
    (  ,,) .| | | |  |  |
   /  つ ̄ ̄ ̄  | ..::|
 〜(__). °°° | ::::|
   |__|  ̄ ̄ ̄ ̄ |..::::::|
    ||          .|::::::::|
    ||  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
    ̄ ̄  |\
     / ̄   ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
     |  きてねぇよ

507 :デフォルトの名無しさん:03/04/22 01:29
ところでいつからここはデザパタのスレになったんだ?

508 :デフォルトの名無しさん:03/04/22 01:29
>>499
いまだにコードの再利用を信奉しているのか。

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


509 :デフォルトの名無しさん:03/04/22 01:30
どうせ要らないって。 < 明日必要かもしれない機能


510 :デフォルトの名無しさん:03/04/22 01:32
>>490

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

511 :デフォルトの名無しさん:03/04/22 01:32
>>508

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

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


512 :デフォルトの名無しさん:03/04/22 01:35
>>511
お前がコピペ厨だってことは良く分かったからもう寝ろ。

513 :デフォルトの名無しさん:03/04/22 01:36
じゃ、寝るか。満足。

514 :デフォルトの名無しさん:03/04/22 01:37
>>511
知らねーよ。


515 :デフォルトの名無しさん:03/04/22 01:38
>>511
C マガに電話して聞けよ。


516 :デフォルトの名無しさん:03/04/22 01:40
>>511
退化した頭で考えた素晴らしい結論なんじゃないの。

517 :デフォルトの名無しさん:03/04/22 01:41
>>515
実は俺電話でクレーム入れた。雑誌代返せって。
そしたら、定説だっていわれたYO

518 :デフォルトの名無しさん:03/04/22 01:42
>>517
古いネタやなぁ。

519 :DesignPattern厨とかしつこく言われてた者ですが:03/04/22 01:42
今日も痛い議論を繰り返してるな。
新鮮味もリアリティーもありゃしない、ヲタクの繰り言。
1〜2年前に2ちゃんで済ました議論ばっか。(当然2ちゃんの外ではもっと前に終わってる議論だけど)

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


520 :デフォルトの名無しさん:03/04/22 01:42
>>517
消費者センターに電話すべし。


521 :デフォルトの名無しさん:03/04/22 01:42
>>427
Java コアAPIの殆どはデザインパターンのかたまりなんだよなー。
よくJava Documentをみてみなさいってこった

522 :デフォルトの名無しさん:03/04/22 01:43
>>519
ヨカッタナ


523 :デフォルトの名無しさん:03/04/22 01:44
>>519
そういわずに、まずはSingletonで一席ぶってくれ

524 :デフォルトの名無しさん:03/04/22 01:45
>>519
君はあれか、それ言わんと寝れんのか。

525 :デフォルトの名無しさん:03/04/22 01:45
>>519
気取ってろ。おまえに進化は無い。

526 :デフォルトの名無しさん:03/04/22 01:45
>>519
それを知りながら棲み続けて、わかったような事を語るのも

 か な り 痛々しいぞ(w

527 :デフォルトの名無しさん:03/04/22 01:46
2分で5匹か・・・

528 :デフォルトの名無しさん:03/04/22 01:47
なるほど、2年たってデザインパターンを使えない使えないといつまでも叫んでいるわけか。

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

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

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

529 :デフォルトの名無しさん:03/04/22 01:48
>>527
2分?5匹? 数も数えられな(略

530 :デフォルトの名無しさん:03/04/22 01:51
はい6匹目。

531 :デフォルトの名無しさん:03/04/22 01:54
釣りやってないで、有用なコメントの一つも残してくれ。

532 :デフォルトの名無しさん:03/04/22 01:56
>>519はコピペだよ。名前欄以外はね・・・

533 :デフォルトの名無しさん:03/04/22 01:59
>>532
君はあれか、それ言わんと寝れんのか。

534 :デフォルトの名無しさん:03/04/22 02:01
> eXtreme Programmingという言葉もRational Unified Processという言葉も
> Unified Modelling Language という言葉も手法も手段も知らないんだろーなー。

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

535 :名無し:03/04/22 02:05
>>490
すげー
なんだこりゃ
これがあれば俺にも三国無双つくれそうだ

536 :デフォルトの名無しさん:03/04/22 02:06
雑魚がいっぱい釣れてる・・・。

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

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



537 :デフォルトの名無しさん:03/04/22 02:07
>>534
がんばって覚えたばかりの用語を並べてるんだから、生暖かく見てあげようよ。

538 :デフォルトの名無しさん:03/04/22 02:09
Model Driven Design が抜けてるぞ(ぷ



539 :デフォルトの名無しさん:03/04/22 02:10
>>536
批判ばかりしかできない君は、もっとつまらない人間だが?

540 :デフォルトの名無しさん:03/04/22 02:10
それをいうならModel Driven Development(ぷ



541 :名無し:03/04/22 02:12
だれか>>490みたいなのの2D版作ってよ
もちろんOOで

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


543 :デフォルトの名無しさん:03/04/22 02:16
>>542
じゃあ、、まず君のエクセレントな経験を語ってくれないか?

544 :デフォルトの名無しさん:03/04/22 02:33
>>543
エクセレントな体験などと誰も言っていないんだが。

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

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



545 :デフォルトの名無しさん:03/04/22 05:13
すべてのデザインパターンは Composite パターンに帰着する。


546 :デフォルトの名無しさん:03/04/22 06:17
>>544
なんかイメージつかめない…
部分計算のためのキャッシュってのは、 call by need とかかな…
ドメイン・スペシフィックな情報ってどんなの?

547 :デフォルトの名無しさん:03/04/22 08:07
>>546
ドメイン名だね。なんとか.jp とか。

548 :デフォルトの名無しさん:03/04/22 09:24
CppUnitは狂ったようにパターンを使っているけど



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

549 :デフォルトの名無しさん:03/04/22 21:15
>>544
全く思わん。2年も粘着してそれかよ。

550 :デフォルトの名無しさん:03/04/22 23:01
そんな >>544 へ。
http://www15.big.or.jp/~kaini/image/img-box/img20030422123158.jpg


551 :デフォルトの名無しさん:03/04/22 23:18
>>544
一年以上前の、便所の落書きを覚えていてもらってると思ってるなんて、
並みの自意識過剰じゃないですね、あんた。

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

553 :デフォルトの名無しさん:03/04/23 04:48
ユースケース図って本当に必要?

554 :デフォルトの名無しさん:03/04/23 06:40
ユースケ、ナナミ、コウタ、出撃じゃ!


555 :(´д`;)ハァハァ :03/04/23 06:53
http://www.k-514.com/

556 :デフォルトの名無しさん:03/04/23 09:10
>553
本当に必要かどうかは、それが無くなった時にしかわからない。
ってことでそのユースケース図を窓から(略

557 :デフォルトの名無しさん:03/04/23 12:05
>>550
オブジェ嗜好...

558 :デフォルトの名無しさん:03/04/23 12:25
>>557
ああ、やっとわかったよ。
座布団2枚だな

559 :デフォルトの名無しさん:03/04/23 19:20
宗方指向ってのはどうよ?

560 :デフォルトの名無しさん:03/04/23 19:27
じゃぁ、仕様書をみせてみなさい. >> 1

561 :デフォルトの名無しさん:03/04/23 19:30
>>550
Delphi関連だと思っていたのにっ!!

562 :デフォルトの名無しさん:03/04/23 21:33
ユースケース図いらん。
本当に必要ない

563 :デフォルトの名無しさん:03/04/23 21:46
ユースケース図はあまり要らないね。
形式的すぎるきらいがある。
開発者と顧客とのやりとりは、ストーリー・カードの方が適切。親しみやすい。
開発者チーム専用(チームにいる顧客にも)にはタスク・カードで細かく砕く。


564 :デフォルトの名無しさん:03/04/23 21:54
ストーリーカードって何?
なんか、作るのかなりめんどくさそうに思えるんだけど・・・
100〜200ユースケースくらいありそうなシステムにも
適用できる?

565 :デフォルトの名無しさん:03/04/24 00:50
>>564
http://oita.cool.ne.jp/ja6hfa/ja6hfa/XP/xpcards.html より:

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

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

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

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

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

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


566 :デフォルトの名無しさん:03/04/24 01:06
>>565
レスサンクスです。内容の大きさ的には、
タスク=ユースケース
ストーリー=業務フロー
みたいな感じなのかな?ちょっと面白そうだね。

567 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/24 03:13
そんな教科書みたいなケースなんか無いよ。
現実は地獄だよ ジ・ゴ・ク


568 :デフォルトの名無しさん:03/04/24 03:31
上手くいったプロジェクトもあるけどな。
良し悪しはメンバーによるよ。
地獄になるのは、口先だけの奴がのさばっているからじゃないかな?
あるいは567自身が口先だけの奴か。

569 :デフォルトの名無しさん:03/04/24 12:25
>567
その通り。現実はあまりにも酷い。
だが、それを改善していく事を放棄してはいつまでも地獄のまま。

570 :デフォルトの名無しさん:03/04/26 15:30
オブジェクト指向は変更に強いとよくいわれますが、これは本当でしょうか?
どうしても信じられません。本当ならどうしてですか。

571 :デフォルトの名無しさん:03/04/26 15:40
実装を変えるだけで良いから。

572 :デフォルトの名無しさん:03/04/26 15:43
>>570
オブジェクト指向の本を1、2冊読んでから信じられるか信じられないか決めろ。
そんなことオブジェクト指向の本の冒頭に書いてある。 
自分で調べて、自分で考えて、自分で判断しろ。

573 :デフォルトの名無しさん:03/04/26 15:59
>>572
3冊読んだうえで信じられないと言っているんですが。

574 :デフォルトの名無しさん:03/04/26 16:02
>>573
漏れの竿取るんじゃねーよw

575 :デフォルトの名無しさん:03/04/26 16:04
>>571
インタフェースが変更されると目も当てられないということでつか?

576 :デフォルトの名無しさん:03/04/26 18:05
>>573
それだけ読んだなら実践してみれば?
よほど頭の柔らかいやつでもない限り、
本を読んだだけでOOが分かるはずないし。


577 :デフォルトの名無しさん:03/04/26 18:27
OO ってうまく modularize してくための方法論だと思う。
うまく modularize してあって、変更が少数の module 内で済むなら、それなりに強そう。
modularize 失敗してたり、全体に影響が出るような変更だったりすると弱そう。

578 :デフォルトの名無しさん:03/04/26 19:05
>>575
そりゃ設計の失敗ですな。

579 :デフォルトの名無しさん:03/04/26 20:49
つまり設計に依存するというわけで今までと何ら変わりないということですか?

580 :デフォルトの名無しさん:03/04/26 21:01
>>577
モジュール化しても、モジュールに変更があった場合、
モジュールを使用している箇所に影響出るだろ?

581 :デフォルトの名無しさん:03/04/26 21:02
>>578
その一言で片付けばどれだけうれしいかねぇ。

582 :デフォルトの名無しさん:03/04/26 21:54
その設計を考え方こそオブジェクト指向だろ

583 :デフォルトの名無しさん:03/04/26 22:25
>>577
俺もその通りだと思う。
モジュール化をうまくおこなうための方法論。それ以上のものじゃない。
構造化でうまく設計出来る人なら別にOO使う必要ない。


584 :デフォルトの名無しさん:03/04/27 00:11
使えって

585 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/27 00:34
さげで主張し合ってやんの(藁

586 :デフォルトの名無しさん:03/04/27 00:35
上手い構造化
その一つがオブジェクト指向なのだよ

587 :デフォルトの名無しさん:03/04/27 00:39
モジュール化云々はあまりにも狭義のOOだと思うが。

588 :デフォルトの名無しさん:03/04/27 00:40
単なるコーダーにとってはそれ以上のものじゃ無いだろうな。

589 :デフォルトの名無しさん:03/04/27 01:02
クラス図はわざわざ書くものではないと思う。
ツールでソースから起こすのが正しいと思う。
ツールでクラス図からソースを起こすのはよくないと思う。
実態に即した図を常に用意すべきだと思う。
ソースも最初はスタブで一気に書き上げるし。

590 :デフォルトの名無しさん:03/04/27 03:16
一言
   継承

ハイ、教えた(w

591 :デフォルトの名無しさん:03/04/27 03:30
いや多態だろ

592 :デフォルトの名無しさん:03/04/27 03:38
継承や多態なんて一機能の名前じゃねぇかバーカバーカバーカ

593 :デフォルトの名無しさん:03/04/27 03:40
>>592
そもそも一言で語れるわけねぇだろ。ageてまで言うことかよ

594 :592:03/04/27 03:45
晒してやったです

595 :デフォルトの名無しさん:03/04/27 04:38
情報隠蔽

596 :プロの逝って良しの1 ◆MvRbZL6NeQ :03/04/27 04:47
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)


597 :デフォルトの名無しさん:03/04/27 05:34
ヒマだな(w

598 :デフォルトの名無しさん:03/04/27 06:34
http://www.k-514.com/

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

600 :デフォルトの名無しさん:03/04/27 09:36
>>599
おまえごときにオブジェクト指向はもったいない。
どうせ覚えてもろくな組み方しねーよ。

601 :デフォルトの名無しさん:03/04/27 10:07
OO厨の捨て台詞カコワルイw

602 :デフォルトの名無しさん:03/04/27 10:12
カプセル化さいこー。

603 :デフォルトの名無しさん:03/04/27 10:51
>>599
ところで君は本を3冊読んで、オブジェクト指向が変更に強いわけはない、
という結論にいたったわけだよね。
なぜそう思ったのか、その理由を教えてくれよ。



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

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


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

607 :デフォルトの名無しさん:03/04/27 12:49
>604
オブジェクト指向だと、関数がデータに直接アクセスすることがないから
データ構造を変更したときもトレースしやすいんだよね。

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

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

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


608 :デフォルトの名無しさん:03/04/27 12:52
>>606
最初から、継承"重視"ではなかったのでは?
継承より合成を利用していくべきだと
昔から言われていると思いますが。


609 :デフォルトの名無しさん:03/04/27 13:24
>606
>継承

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

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


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


611 :デフォルトの名無しさん:03/04/27 13:26
オブジェクト指向って言葉の神通力はまだ世間に通用しますか?

612 :デフォルトの名無しさん:03/04/27 13:34
>>611
通用しなくてなっています。
オブジェクト指向という言葉を聞いただけで拒絶反応を起こされて
しまうといったような神通力は、もう昔話になりつつありますね。

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

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

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


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

615 :デフォルトの名無しさん:03/04/27 15:22
継承に問題があるわけじゃなくて、集約を使わないから問題がおこる。
×player.name
○player.profile.name
上だと、無駄な要素がくっついてくるから、継承のメリットは消し飛ぶね。

616 :デフォルトの名無しさん:03/04/27 19:22
ビジネスロジックを実装するクラスはみんなどんな風にクラス化してます?
サーバサイドでの永遠の命題ですが。
案外、構造化一本やりで書いた方が、分かりやすいしメンテしやすいケースもある。

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

618 :デフォルトの名無しさん:03/04/27 20:35

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


619 :デフォルトの名無しさん:03/04/27 20:50
やべー、OO歴15年の俺のスキルはどうなるんだ?w

620 :デフォルトの名無しさん:03/04/27 20:59
>案外、構造化一本やりで書いた方が、分かりやすいしメンテしやすいケースもある。

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

621 :デフォルトの名無しさん:03/04/27 21:01
オブジェクト指向なんてとっくに破綻してます。
「どうして日本ではオブジェクト指向が広まらないか」
なんて言ってるのは日本だけ。

622 :デフォルトの名無しさん:03/04/27 21:10
>>620の頭の中では構造化=ソースコピペらしい(w

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

624 :デフォルトの名無しさん:03/04/27 21:24
オブジェクト指向を勉強したかったら、
.net FrameWorkかDelphiでも使えばすぐ覚えるだろ…。

625 :デフォルトの名無しさん:03/04/27 21:27
XP の once only once だな。
XP そのものを使うのは難しいだろうけど、エッセンスは知っておいて損はない。

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

627 :デフォルトの名無しさん:03/04/27 21:45
>>626
それは.net FrameWorkに限らない話だろ

628 :デフォルトの名無しさん:03/04/27 22:01

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




  次は、XPだな。


629 :デフォルトの名無しさん:03/04/27 22:03
XP,FDD,RUP、実際にきっちりとこれに従った開発した事ある人いるか?
おれは破綻したXPなら経験がある(w

630 :デフォルトの名無しさん:03/04/27 22:07
Java の GUI モデルだと継承とインベントリスナを使うからそういう風にはならない。
クラス数は糞増えるが、問題の切り分けが楽になるので管理はしやすい。

631 :デフォルトの名無しさん:03/04/27 22:07
>>627
そうだよ。DelphiのVCLにもJavaのAWTやSwingにもあてはまるんだよ。

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

632 :デフォルトの名無しさん:03/04/27 22:11
>>630
ところがどっこい。
初心者本には、MyFormにイベントリスナを山ほど実装させて、
thisをイベントリスナに登録するように書いてあるものも結構ある。

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

633 :デフォルトの名無しさん:03/04/27 22:13
>問題の切り分けが楽になるので管理はしやすい。

634 :デフォルトの名無しさん:03/04/27 22:15
>>632に追加。
最悪なのは、JButtomのイベントリスナに、thisを登録してるコード。
サンプルの行数は短くなって、ある意味とっつきやすくなる。
しかし、ボタンを2つに増やしたくなったらどうしろというのか。

635 :デフォルトの名無しさん:03/04/27 22:40
>>634

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

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

636 :デフォルトの名無しさん:03/04/27 23:23
あとにつづかねぇ糞コードだな。

637 :デフォルトの名無しさん:03/04/27 23:27
そういえばJBuilderが吐くコードもいい加減糞だよなw

638 :デフォルトの名無しさん:03/04/28 00:20
>>616
>サーバサイドでの永遠の命題ですが。
>案外、構造化一本やりで書いた方が、分かりやすいしメンテしやすいケースもある。

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




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

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

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

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

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

642 :デフォルトの名無しさん:03/04/28 02:07
業務分析とそのモデリング技術(というかセンス?)は経験がものを言うな。


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

644 :デフォルトの名無しさん:03/04/28 02:16
>>626

同意点が多い。

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

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

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

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

646 :デフォルトの名無しさん:03/04/28 02:37
せちがない昨今、なかなか分析を十分に進める時間が無いのよね・・・。
XPにしても「そんな悠長な」ってのが多くの開発者の本音では。

647 :デフォルトの名無しさん:03/04/28 03:09
XPだと生産性は半分になるからね
ホシュも半分の労力で済むけど
ウチの会社は作りっぱなしが多いからなぁ
だいたい仕事頼んできたところが
結構な割合で倒産してるし・・・

648 :デフォルトの名無しさん:03/04/28 04:37
>>626
それは.NETフレームワークの問題じゃなくて、開発ツールとか
教育体制の問題じゃないのかなあ。オブジェクト指向の手法と
してのネタではないような。

649 :デフォルトの名無しさん:03/04/28 04:37
ちなみに>>646

× せちがない
○ せちがらい(世知辛い)

650 :デフォルトの名無しさん:03/04/28 13:47
>>621
> 「どうして日本ではオブジェクト指向が広まらないか」
> なんて言ってるのは日本だけ。

そりゃ、アメリカやドイツや韓国では、そんなことを言っている人はいないだろうな。


651 :デフォルトの名無しさん:03/04/28 19:55
まあ、アメリカはその代わりに CMM を流行らせたわけだが。

652 :デフォルトの名無しさん:03/04/28 20:23
>>545
> すべてのデザインパターンは Composite パターンに帰着する。
とりあえず馬鹿は死ね

653 :デフォルトの名無しさん:03/04/28 20:25
>>634
Stateパターンを使いましょう

654 :デフォルトの名無しさん:03/04/28 20:28
>>653
バトル・アメリカ

655 :デフォルトの名無しさん:03/04/28 20:28
>>650
日本の多くの企業のCMMレベルは殆ど1か2、またはそれ以下
日本で最近CMMレベル5を実現した企業は日本IBMのみ
これはひどいことにほとんどがレベル4を実現しているインドにまで劣る。

日本人は馬鹿だ。日本人はあまりにも愚かだ。日本人は頭が悪すぎる。
日本人は論理的思考に弱い。都合の悪いことは何でもかんでも「水に流す」で済まそうとする。
そんな馬鹿な日本人に生まれてしまったのは我々の宿命か

656 :名無し@沢村:03/04/28 20:42
>>651
ハゲ!!CMMはプログラミング手法じゃねーよ!
ソフト開発の工程がちゃんとしてるかどうかを採点する方法だよ。
まあ、あってもなくてもいいものだ。

657 :デフォルトの名無しさん:03/04/28 21:04
>>656
採点って、評価だけが目的なんか?

658 :名無し@沢村:03/04/28 21:43
>>657
そうだ。あってもなくてもいいものだ。

659 :デフォルトの名無しさん:03/04/28 21:44
CMMって何の略なん?

660 :デフォルトの名無しさん:03/04/28 21:45
>>657
さわむらかたくそんかしらんがそいつにレスすんな。

661 :名無し@沢村:03/04/28 21:53
>>659
ハゲ!!CMMはな、Capability Maturity Modelの略よ。
といってもおまえにはCapabilityとMaturityの意味はわからんだろう?
いいか!! Capabilityは「能力」Maturityは「成熟」Modelは「模型」よ。
つまりソフトウエアをつくる能力がどれくらい成熟しているかを採点する模型のことよ。


662 :デフォルトの名無しさん:03/04/28 21:55
今日は沢村元気だな。



というよりムキになっているのか。

663 :デフォルトの名無しさん:03/04/28 21:55
つーか、頭いいやつが銀行とかいってこの業界にこないから仕方ねーじゃん。
赤字増えるより、ましかもしれんけど。

664 :デフォルトの名無しさん:03/04/28 21:57
銀行=馬鹿

665 :デフォルトの名無しさん:03/04/29 00:15
ここではクラスベースの話しかしないの?

666 :デフォルトの名無しさん:03/04/29 00:16
あげ

667 :デフォルトの名無しさん:03/04/29 00:39
>>665
どうぞ、インスタンスベースの話をして下さい。

668 :デフォルトの名無しさん:03/04/29 09:49
>>665
じゃあ、Selfの話でもしようか。


…ネタがねぇ…そのまえに知らないし

669 :デフォルトの名無しさん:03/04/29 13:23


  沢村、近藤、山崎渉は徹底放置!!



よろしく。

670 :名無し@沢村:03/04/29 20:37
沢村は徹底放置!!

よろしく。

671 :デフォルトの名無しさん:03/04/29 22:55
selfのほかにないんかのう

672 :デフォルトの名無しさん:03/04/29 23:25
NewtonScript!

673 :デフォルトの名無しさん:03/04/30 15:12


     「CMMはうんこ」


ってことで、よろしいでつか?

674 :デフォルトの名無しさん:03/05/03 17:23
>>673
かつてのISOみたいに、認定とっていることで営業の道具にすることしか
考えていない、企業版「資格商法」のカモになってるバカ管理職連中は
うんこです。


675 :デフォルトの名無しさん:03/05/03 17:53
>>669
沢村、山崎渉固定ハンドルは良く見かけるけど
近藤って誰よ?


676 :デフォルトの名無しさん:03/05/03 17:58
>>675
うんこ

677 :名無し@沢村:03/05/03 18:06
近藤って誰よ?
沢村、山崎渉固定ハンドルは良く見かけるけどな…

678 :デフォルトの名無しさん:03/05/05 22:31
マ板に行けばわかる。
別に知らなくていいことだが。

679 :デフォルトの名無しさん:03/05/12 06:53
ふ〜〜ん

680 :デフォルトの名無しさん:03/05/13 14:26
「まあ」ってあるよね。
昔は、「まあいいよ」とか、「まあこのぐらいですね」とか、「だいたいこの程度」といった
感じを表すときによく使っていたと思うんですけど。
最近は、「これは、まあカーナビですが、車に搭載して使います」とか、
「酸素と、まあ水素が化合すると水になるわけです」とか、何が「まあ」なんだか
わからない使い方をよく聞くようになりました。
90年頃からかな。
これは、いったいなんなんでしょう……

681 :名無し@沢村:03/05/13 15:00
まあというのは「間」のことよ。
ふつー「間」というのは無言で表わすわけだが、それをわざわざ言葉で表わしたのがまあというわけだ。
だからまあは「…」と同じようなものよ。

682 :デフォルトの名無しさん:03/05/13 15:03
オレは子供の頃マー君て呼ばれてた。なつかしいな。

683 :デフォルトの名無しさん:03/05/13 15:06
プログラまあ、でしょう。

684 :デフォルトの名無しさん:03/05/13 15:06
コピペに釣られるバカに沢村に釣られるバカ。

685 :デフォルトの名無しさん:03/05/13 15:09
バカを見つけるとバカと言わずにはいられないバカ。 

686 :デフォルトの名無しさん:03/05/13 15:49
チャットでやってろ漏前ら

687 :デフォルトの名無しさん:03/05/13 22:17
小3のある日、兄の自転車を借りて坂を下ってたら
実はブレーキがすごく甘くなってて、
ブレーキしてもどんどんスピードが上がっていって
靴のつま先で無理やりブレーキさせても靴が磨り減るだけで
仕方なく路肩の植木に身を投げたら擦り傷いっぱいでスカート破けて
そのままエロティックな格好で泣きながら家に帰ったら
母がいきなり
「誰にやられたの!」
と聞いて来たのでは私はお兄ちゃんの自転車で…と言うつもりが
泣きじゃくってるせいでうまくいえず
「お…お兄ちゃん…」
と呟いたら母は突然倒れてそのまま気絶してました。


688 :デフォルトの名無しさん:03/05/15 02:36
Objective-Cはダメでつか?

689 :デフォルトの名無しさん:03/05/15 08:28
笑われたくない!!

690 :デフォルトの名無しさん:03/05/15 13:31
この擦れ立てたやつどのくらい成長したのか気になる

691 :デフォルトの名無しさん:03/05/15 13:36
つい先日氏んだって話を小耳に挟んだが。

692 :r:03/05/16 23:27
オブジェクト指向なんて関係ない。
チンコがたつのがいい男。
たたないのが駄目人間。

693 :デフォルトの名無しさん:03/05/17 00:30
>>692
おいおいペレを馬鹿にするなよ

694 :デフォルトの名無しさん:03/05/19 16:37
>>692
童貞がw

695 :かおりん祭り:03/05/19 16:40
〜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

696 :デフォルトの名無しさん:03/05/20 03:47
どいつもこいつも、お気楽でいいな。

697 :デフォルトの名無しさん:03/05/20 08:17
そうじゃないとやってらんないよ。そう思わん?

698 :デフォルトの名無しさん:03/05/23 16:34
やっべーアプリケーションの方はまだマシだけど。
アプレットはキツイ
なんか受けつかないって感じ

699 :デフォルトの名無しさん:03/05/28 00:00
メンバ変数の値を返すだけのメソッドってどういうふうに命名するのが一般的ですか?


700 :デフォルトの名無しさん:03/05/28 00:08
変数名が hoge として、
Java 風: getHoge
Smalltalk 風: myHoge または hoge

701 :デフォルトの名無しさん:03/05/28 06:03
Delphi風
メンバ変数 FHoge
メソッド(というかproperty) Hoge

702 :山崎渉:03/05/28 12:33
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉

703 :100人に1人(変化を嫌うのが特徴):03/05/30 12:11
<アスペルガー症候群(自閉症スペクトラム)←脳の機能的疾患(遺伝)>
●変化を嫌う
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





704 :デフォルトの名無しさん:03/05/30 12:49
http://www5e.biglobe.ne.jp/~liquor/raytrace/
ベンチマークとってみたんだが、ここの人って
なにげにオブジェクト指向してない?

705 :デフォルトの名無しさん:03/05/30 13:41
過労死をさせる日本ロジテム株も大暴落の予感
佐川とロジテムどっちがひどい?
田中真紀子と親密な日本ロジテム(日清系 上場企業 みずほの融資先)の
子会社せいも素(みずほの融資先)で  
サービス残業させすぎの過労死者を出した上、大量の不当解雇を行った社長の辻
にまた労働基準監督署の立ち入り調査があり,またも多くの勧告が出された。
http://www.samos.co.jp
http://society.2ch.net/test/read.cgi/traf/1046749189/l50
.      / ̄\  +.  ∧_∧アハハハ テンゴクヘイッチャウヨー 
  イクナヨー( ´∀`)    (´∀` )  
      (つ  つ     (つ  つ■
.   +  ( ヽノ      ( ヽノ

706 :オブジェクト指向言語の歴史:03/06/05 07:22
Simula67

Smalltalk80

C++

Self

Eiffel

Delphi

Java

C#

707 :デフォルトの名無しさん:03/06/12 13:28
スーパークラスセンシティビティという言葉について
ご存じの方教えてください。実装の継承を行う場合の弊害らしいですが、
検索しても出てこないので・・・

708 :デフォルトの名無しさん:03/06/13 00:55
>>707
みこみこナース です

709 :デフォルトの名無しさん:03/06/17 14:53
巫女巫女ナース?

710 :デフォルトの名無しさん:03/06/17 17:21
超級戦士ちびT
ちびT(ぴたT)を着た戦士。強い。

711 :デフォルトの名無しさん:03/06/18 01:13
>>707
センシビティ=敏感
多分、実装の継承をするとスーパークラスを簡単に修正できなくなることを
言ってるんじゃないのかなぁ・・・

712 :サンプルです:03/06/18 01:15
http://yahooo.s2.x-beat.com/linkvp/linkvp.html

713 :デフォルトの名無しさん:03/06/18 01:17
>>706
Objective-Cが抜けてるよ

714 :デフォルトの名無しさん:03/06/28 15:11
こんな本が出てた。
「リバーシのアルゴリズム―「探索アルゴリズム」「評価関数」の設計と実装 C++&Java対応」
これを読めばOO厨もオセロ作れる?

715 :デフォルトの名無しさん:03/06/28 17:23
やっぱね、オセロとかは石ひとつひとつがオブジェクトなんですよ。

・・・案外この思想で面白い思考ルーチンが作れるかもしれない

716 :デフォルトの名無しさん:03/06/28 19:04
いっそ、マス一つ一つを object にしてみるとか。
そこに置けるかとか、どこの石が取れるかとか、問い合わせに答えるの。
で、石が置かれたら、周りのマスに通知して…

…でも、これは思考自体にはあんまり影響しないかも。

717 :デフォルトの名無しさん:03/07/02 02:45
>>715-716
極めて素直で自然だと思いますね。
あたかも、それが画期的なことであるかのように書き込んでいますが。

718 :デフォルトの名無しさん:03/07/03 00:06
>>717
よし、じゃあ早速その発想でアルゴリズムを作ってみてくれ。

719 :デフォルトの名無しさん:03/07/04 13:31
アルゴリズムの話はスレ違い


720 :山崎 渉:03/07/15 10:27

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

721 :山崎 渉:03/07/15 14:16

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

722 :デフォルトの名無しさん:03/07/18 20:02
結局誰もSingletonを書けなかったわけだが。
Java本からのパクリを載せる。

public class Singleton {
private static Singleton s = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return s;
}
}

なぜこれしきのことで騒いでいたのかと。

723 :デフォルトの名無しさん:03/07/19 09:46
>>722
使わない可能性があるのにインスタンスが必ず一つ出来るのって効率悪くないですか?


724 :デフォルトの名無しさん:03/07/19 13:01
>>723
使わないんなら、わざわざコード書く必要はないような気が。
722の場合、使わなくてもインスタンスは必ず一つというのは
それはそれでSingletonの定義にかなっているのではと。
あとは、他の実装例を私は不幸にして知らない。

725 :デフォルトの名無しさん:03/07/19 18:30
>>724
あなたは、あるパッケージから使わないそのシングルトンを抜き出す作業を好んで行うんですか?

public class IntelligentSingleton {
private static IntelligentSingleton s = NULL;
private IntelligentSingleton() {}
public static IntelligentSingleton getInstance() {
if(s == NULL)
s = new IntelligentSingleton();
return s;
}
}

726 :デフォルトの名無しさん:03/07/19 18:36
>>725
あーそーいえばそんなコードを見かけたことがあった。どこでだかは忘れたけど。

727 :デフォルトの名無しさん:03/07/24 03:32
構造体とクラス(C++)の違いを教えてください。
クラスを使用することのメリットは何でしょうか?

728 :デフォルトの名無しさん:03/07/24 03:42
>>727
C++的には、デフォルトのメンバアクセス制限が違う以外はまったく同じもの。
一般的には、同じところを見つけるほうが困難なほど概念からしてまったく別物で比べることもおこがましい。

729 :デフォルトの名無しさん:03/07/24 03:57
クラス定義したオブジェクトは、
メモリ領域的にはどこに配置されるのですか?
作り方しだい?(例えばメモリプール)それともスタック?

730 :デフォルトの名無しさん:03/07/24 04:11
ここを特定の言語のためのスレッドだと勘違いしている人が二人ほどいる模様。

731 :デフォルトの名無しさん:03/07/24 04:15
>>729
ヒープまたはスタック

732 :デフォルトの名無しさん:03/07/24 04:36
ヒープって何?

733 :デフォルトの名無しさん:03/07/24 04:53
>>732
newしたやつが住む場所

734 :デフォルトの名無しさん:03/07/24 06:31
>>723
クラスにアクセスしない限りはできません。

>>725
そのコードはスレッドセーフではない。失格。

735 :デフォルトの名無しさん:03/07/24 06:45
>>734
はいはい。では次の方。

736 :デフォルトの名無しさん:03/07/24 06:49
public class IntelligentSingleton {
private static IntelligentSingleton s = NULL;
private IntelligentSingleton() {}
public synchronized static IntelligentSingleton getInstance() {
if(s == NULL)
s = new IntelligentSingleton();
return s;
}
}

737 :デフォルトの名無しさん:03/07/24 17:35
TABれえぇぇぇぇぇえぇぇぇぇえ

738 :デフォルトの名無しさん:03/07/24 21:02
質問なんですが、インタフェースとは
「実装を持たないシグニチャのみのクラス」
でよいのですよね?
その利点は一体何なんでしょうか。

739 :デフォルトの名無しさん:03/07/24 21:04
>>738
見た目が同じなら中身が全然違くてもいい事

740 :デフォルトの名無しさん:03/07/24 21:04
・多重継承と違って中身が衝突しない
・常にvtblを使うのでCOMと一致

741 :738:03/07/24 21:09
>>739&740
ありがとうございました。

>>739
それはカプセル化と似ている気がするのですが、全然違うのですよね?

742 :デフォルトの名無しさん:03/07/24 21:12
>>741
クラスにするときのカプセル化とは言葉の使いどころは違うけど概念的には同じもの。

743 :738:03/07/24 21:15
>>742
私の持っている本には、カプセル化は「インタフェースと実装の分離」と書いてあります。
インタフェースとは所謂外面のことと考えてもよろしいでしょうか?

744 :デフォルトの名無しさん:03/07/24 21:22
>>743
いいけど、分離するだけじゃカプセル化とは呼ばないよ、隠さないと。

745 :738:03/07/24 21:24
>>744
そういえばそうですよね。わかりました。ありがとうございます。

746 :デフォルトの名無しさん:03/07/24 21:45
ハゲ隠すの必死(藁

747 :デフォルトの名無しさん:03/07/24 22:10
>>731 処理系依存

748 :デフォルトの名無しさん:03/07/24 22:12
私も脱いでます♪探してみてね♪
http://yahooo.s2.x-beat.com/linkvp2/linkvp2.html


749 :デフォルトの名無しさん:03/07/24 22:48
ロジック設計(ハード設計)にも、オブジェクト指向の設計手法はありますか?


750 :デフォルトの名無しさん:03/07/24 22:48
>>749
もちろん。

751 :749:03/07/24 22:50
>750
VHDL or Virilog HDL?

752 :デフォルトの名無しさん:03/07/25 08:18
>>748
メンバに直接アクセスしたいです。

753 :デフォルトの名無しさん:03/07/25 21:35
IT(情報技術)をマスターするにはオブジェクト指向が必要なんでしょうか?

754 :直リン:03/07/25 21:38
http://homepage.mac.com/maki170001/

755 :デフォルトの名無しさん:03/07/26 04:31
>>746
ボクのハゲもカプセル化されそうです。

756 :山崎 渉:03/08/02 02:19
(^^)

757 :山崎 渉:03/08/15 16:30
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)