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

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

オブジェクト指向 Part2

1 :デフォルトの名無しさん:01/10/08 15:41
・オブジェクト指向についての疑問、応答
・OOP言語、UML、分散オブジェクト、デザインパターン等

などなど、オブジェクト指向についての「技術的な」スレッド。

前スレ
オブジェクト指向スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001275287

2 :やる気なしメタリンク:01/10/08 15:51
オブジェクト指向
http://www.google.com/search?sourceid=navclient&q=%83I%83u%83W%83F%83N%83g%8Ew%8C%FC

デザインパターン
http://www.google.com/search?sourceid=navclient&q=%83f%83U%83C%83%93%83p%83%5E%81%5B%83%93

eXtreme Programming
http://www.google.com/search?hl=ja&q=extreme+programming&btnG=Google+%8C%9F%8D%F5&lr=lang_ja

リファクタリング
http://www.google.com/search?hl=ja&q=%83%8A%83t%83@%83N%83%5E%83%8A%83%93%83O&lr=

3 :デフォルトの名無しさん:01/10/08 16:14
早すぎ。

ここだ!2番ゲットォォォォ!!
 ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄       (´´
     ∧∧   )      (´⌒(´
  ⊂(゚Д゚⊂⌒`つ≡≡≡(´⌒;;;≡≡≡
        ̄ ̄  (´⌒(´⌒;;
      ズザーーーーーッ

4 :やる気なしメタリンク:01/10/08 16:15
>>1
死ねよ

5 :やる気なしメタリンク:01/10/08 16:17
は!名前を変えるのを忘れてしまった…鬱

6 :デフォルトの名無しさん:01/10/08 16:24
>OOスレは必ず揉めます。それは何故か?実は…
答えが決まらん抽象論になるからだろ。Aにとって正解でもBにとって
間違いって問題が多い。多重継承なんか典型じゃないか?どの言語を使
ってるか、どのライブラリを使ってるか、一緒に開発してるやつのレベ
ルとかで使うかどうかは変えるだろ?

7 :デフォルトの名無しさん:01/10/08 16:26
>>4-5
そのネタもう秋田

8 :1300万:01/10/08 16:30
>>6
確かにそうですよね
ところで、みなさんはどんなオブジェクト思考言語をお使いですか?
私はプログラマーではないので、JAVAとC++ぐらいしか使わないのですが

9 :デフォルトの名無しさん:01/10/08 17:03
>>8
自作言語

10 :デフォルトの名無しさん:01/10/08 17:12
>>8
おれもLISP系の自作言語

11 :デフォルトの名無しさん:01/10/08 17:26
日本語OOPLコンパイラ?開発中
プリコンパイルでC++に
変換するだけだが・・・

12 :デフォルトの名無しさん:01/10/08 17:30
>>8
マイナーすぎてとても言えません‥‥。

13 :デフォルトの名無しさん:01/10/08 17:39
あーう、自作言語オタが一杯・・・。

エラーメッセージちゃんと出るのですか?

14 :デフォルトの名無しさん:01/10/08 18:46
構文解析や構造解析ちゃんとやってエラー出力するコンパイラと
ろくにエラー判定しないコンパイラは月とすっぽんぐらい違います。
つまらん言語自作してオナニーするのは止めましょう。

15 :デフォルトの名無しさん:01/10/08 18:48
>>14
やってるけど・・・。
まじめにエラー出力しないと自分で使う気にもならないし・・・。

16 :sage:01/10/08 18:48
解決したい問題に特化した言語を作るのは間違いではないぞ。

C++(かjava)とlispが有れば大体足りると思うがな。

17 :デフォルトの名無しさん:01/10/08 18:53
14はつまらん人間

18 :デフォルトの名無しさん:01/10/08 18:53
XMLで新しい言語作ってみた

19 :デフォルトの名無しさん:01/10/08 18:55
新しいDTDを作った
とどうちがうの?それ.

20 :デフォルトの名無しさん:01/10/08 18:58
オブジェクト指向の次は何だろう?
エージェント指向は重そうだし、
コンポーネント指向なのかな。

コンポーネントでビジュアルに設計とか。

21 :デフォルトの名無しさん:01/10/08 19:00
Smalltkの時代

22 :デフォルトの名無しさん:01/10/08 19:01
九大病院の件は片付いたのか?>Smalltalk

23 :デフォルトの名無しさん:01/10/08 19:02
<> </> が無いのが違う。

24 :デフォルトの名無しさん:01/10/08 19:08
オブジェクト指向の次とか言う前に、
オブジェクト指向が使えるように教育するほうが先。

25 :デフォルトの名無しさん:01/10/08 19:11
オブジェクト指向の次とか言ってるやつは
大抵オブジェクト指向を分かっていない

26 :20:01/10/08 19:13
OOは十年前から極めていていますが何か?

27 :デフォルトの名無しさん:01/10/08 19:36
20=14

28 :デフォルトの名無しさん:01/10/08 19:50
エージェント指向はオブジェクト指向と同列に扱ってもらいたいようだが、
あれはオブジェクト同士の関連の一形態に過ぎない。

29 :デフォルトの名無しさん:01/10/08 22:43
オブジェクト指向を批判する奴はOOを理解できない馬鹿。
そんな奴はプログラマー辞めるべき。

30 :デフォルトの名無しさん:01/10/08 22:48
Smalltalkってよく聞きますが、
もう過去の物ですか?

31 :デフォルトの名無しさん:01/10/08 22:53
>>30
行き過ぎたオブジェクト指向。
それはもう、すべてがめんどくさいほど

32 :sage:01/10/08 23:07
実際に自分の関わってる開発にOOを適用して苦労した経験も持たずに
礼賛だけするのはダメ。

33 :>32:01/10/08 23:08
妄想で仮想敵でっち上げて批判しないよーに

34 :デフォルトの名無しさん:01/10/08 23:10
OOで仕事して、バランスの取れた責任分担に腐心して、
クラスの名前を考えるだけで何日も悩み、
それでもコンスタントに月間0.5MBのソースが書けることに喜びを見出し、
そしてまた後々のメンテのしやすさに感謝している漏れは礼賛しちゃいけませんか。

35 :デフォルトの名無しさん:01/10/08 23:11
>>34
>クラスの名前を考えるだけで何日も悩み、
俺がプロジェクトリーダーならクビにする

36 :デフォルトの名無しさん:01/10/08 23:12
>>35
納期は守ってるよー。

37 :デフォルトの名無しさん:01/10/08 23:14
>>36
クラスの名前を考えるだけで、何日も悩んでるのに?
嘘つけ。

38 :デフォルトの名無しさん:01/10/08 23:15
>>37
嘘じゃないよー。
たまにはそういうこともあるという話。

39 :デフォルトの名無しさん:01/10/08 23:18
>>38
まあ、そこまでいうなら、話半分信じてやろう

40 :デフォルトの名無しさん:01/10/08 23:19
>>39
なんにも嘘ついてないのに・・・。泣くぞ(/_;)

41 :sage:01/10/08 23:19
いやべつに敵を作ってるわけじゃないってばよ。
おれ、OOP好きだし。

ソースをバイト数で言われても困るんだけど、
蓄積したコードに対するメンテが少なければ少ないほど
よいコードだと思うんだよな。

ただそれがOOPに基づいた所以なのか
OOPでなくてもメンテ性の高いコードが書けるのか、
過去を振り返ってみたとき、
なんか結局どっちでも同じような気がしてくるんだよね。

どちらでも同じ品質でモノが書けるなら、
OOPをわざわざしらんでも、だれでもメンテできる
ふつうのコードの方が、よかったんじゃないかって考える。

え、OOPじゃなくてOOの話しをしてるって?

42 :デフォルトの名無しさん:01/10/08 23:25
経験からいって、オーバーライドでメンテは不可能に近い。

43 :デフォルトの名無しさん:01/10/08 23:30
漏れはハイソな仕事にゃありつけない市井のプログラマだから
OOPとかOOとか区別されてもピンとは来ないんだけどさ。
でも、クラス単位で考えるって絶対に楽。
関数単位での実装が前提だと過度に小回りを利かせようとして
ざくっと割り切った視点で考えられなくなっちゃいがちなんだよね。
OOだったら基本単位がクラス=意味上のまとまりだから
プログラムの意味を自然と大切にしながら書けるのが気持ちいい。
もちろん、その中で意味のパターンみたいなものが見えてきて
こんな漏れにもそれなりのノウハウが蓄積できるのが嬉しい。
OOに感謝感謝。

44 :デフォルトの名無しさん:01/10/08 23:32
ソースのバイト数って?

main(){
byte data=new byte[0x100000000];

なんか処理〜。
}

45 :デフォルトの名無しさん:01/10/08 23:33
あ、ソースね
 寝る

46 :デフォルトの名無しさん:01/10/08 23:34
>>43
OOの最大の利点は、オブジェクトの独立性にある。この点は、実務でも十分な利
益が得られる。問題は継承まわり。

47 :1:01/10/08 23:37
うぎょーん。なんか雑談スレになってる。
OOの有用性・啓蒙ネタはもういいよ。

48 :デフォルトの名無しさん:01/10/08 23:38
継承はOOPの話。
OOP嫌い。

49 :デフォルトの名無しさん:01/10/08 23:39
生産性をソースのバイト数でいうか、普通?
日曜プログラマじゃないのか?

50 :デフォルトの名無しさん:01/10/08 23:40
>>47
こんなスレ作らんかったらよかったんや

51 :デフォルトの名無しさん:01/10/08 23:42
>>1は責任とって割腹。

52 :デフォルトの名無しさん:01/10/08 23:44
解りやすいように言ったんだろうね>バイト数
正確に言うと進捗率。

53 :通りすがりの日曜プログラマ:01/10/08 23:45
>>49
プロが使う生産性の指標ってどんなものなんですか?

54 :sage:01/10/08 23:46
>>53
テスト項目をつぶした数、というのが最近のはやりかも。

55 :デフォルトの名無しさん:01/10/08 23:47
>>53
俺んとこは、クラス数とステップ数

56 :デフォルトの名無しさん:01/10/08 23:49
テストの時は、完了数/テストケース数

57 :デフォルトの名無しさん:01/10/08 23:49
漏れ、43。
平均して、3ヶ月でソフト1本
年間4本のペースで作らされてるよー。
納期とソフトの規模が大体一定してるんで
目方で進み具合を量る癖がついた。
一本辺りソースのみで1.5MB、
リソース込みで2MB〜3MBになったら完成。
ちなみに漏れは在宅のパッケ屋。

58 :デフォルトの名無しさん:01/10/08 23:59
>>46
ポインタを使いこなすにはメモリに対する正しい知識が必要なのと同じように、
継承を使いこなすには、デザパタを読んで理解できるくらいの理解が必要。
ポインタを使いこなすのも、継承を使いこなすのも、本人次第だろ。
批判する前に勉強しろよ。

59 :通りすがりの日曜プログラマ:01/10/09 00:00
業界標準みたいなものがあるのかと思ってました。
色々あるんですね。勉強になりました。
スレ違いな質問をしてしまってすいません。

60 :デフォルトの名無しさん:01/10/09 00:02
勉強したよ。
低レベルプログラマーなら感動して使うだろうね。

61 :デフォルトの名無しさん:01/10/09 00:03
>>58
うーん、もう聞き飽きたよ。

批判されると、相手の知識不足に問題をすり替えて、
優越感に浸って気分良いんだろうけど、言ってることは
非論理的な根性論なんだよね。

62 :非58:01/10/09 00:07
>>61
貴方が理解できていないようだから「知識を身に付ければ?」と
言われてるのに、「努力したくない」「理解できそうもない」から、
「知識不足だから勉強しろ = 根性論」にすりかえようとしている
ように思えてならない。
問題のすりかえをしているのは、どっちだ?

63 :デフォルトの名無しさん:01/10/09 00:08
>>58
妄想君だねぇ
相手はデザパタ理解できない馬鹿ねぇ

>継承を使いこなすには、デザパタを読んで理解できるくらいの理解が必要。
ここに書き込むには、日本語が理解できるぐらいの理解が(w)必要だよ

64 :デフォルトの名無しさん:01/10/09 00:11
>>62
おまえ58だろ。
継承に問題があると聞いただけで、なんで理解できてないと分かる?
明らかに、問題をすり替えてるだろ。
言ってること理解できるか?

65 :非58:01/10/09 00:12
>>64
いや、ほんとに58じゃないんだけど。
継承に問題があるんじゃなくて
継承の使い方を知らないんじゃないの?

66 :デフォルトの名無しさん:01/10/09 00:12
>>62

残念だけど、いってる事に根拠がないよ。妄想といわれてもしかたない・・

67 :デフォルトの名無しさん:01/10/09 00:14
>>65
継承の使い方を知らないんじゃないの?
明らかにもうそう
どこ書き込みでこう思ったの??

68 :非58:01/10/09 00:17
>>67
いや、実はほとんど見てないんだわ。
単に俺は継承が便利ってだけ。
問題あるなら使わなければー?

69 :sage:01/10/09 00:17
そんなのほっとけよ。

それよりOOPやったことない人に、いかに短期間で
自分の設計を理解してもらうかで頭痛いんだから..

70 :デフォルトの名無しさん:01/10/09 00:18
OOが出来てから20年以上経っているのに開発現場でデファクトスタンダードを
とれていない事実に不信感を抱くプログラマが多いのだと思うね。

71 :sage:01/10/09 00:21
なんか、俺はこうやってOOを広めた!
みたいなケースって、ある?

72 :デフォルトの名無しさん:01/10/09 00:22
>>68

継承好きなのに、批判されたら気に入らないよね、よね、よね

でもキレないで、相手の矛盾を理論でうち破ってよ、破ってよ。破ってよ

73 :デフォルトの名無しさん:01/10/09 00:22
>>69
障害になるなら採用しなきゃいいじゃんか。
頭固いのね。

74 :非58:01/10/09 00:22
>>72
めんどいのでお断り〜♪
俺が便利に使えればそれでいいわ。
アホくさ。

75 :デフォルトの名無しさん:01/10/09 00:22
>>70
覚える暇がないってのもあるんじゃない?

76 :デフォルトの名無しさん:01/10/09 00:24
>>75
また根性論・・・

77 :デフォルトの名無しさん:01/10/09 00:26
>>76
いや、会社でそんな雰囲気に頭に来てるんだけど。
歴史のある会社はむずいやね。

78 :デフォルトの名無しさん:01/10/09 00:27
>>74
説明できないなら最初から黙ってればいいのに

79 :>70:01/10/09 00:30
>開発現場でデファクトスタンダードをとれていない
OOPに関しては
カプセル化->継承->多態->コンポーネント
と確実に浸透していると思う。

ただ、それより上位の設計・手法に関しては
OOA, OOD, UML,デザパタ、XP、リファクタリング(無茶苦茶な並べ方だけど)
と確かに乱立してるね。

ここらへんの取捨選択の判断基準ってどういうものなんだろうね。

80 :デフォルトの名無しさん:01/10/09 00:30
ネット関係はオブジェクト指向知らないと
仕事できないような気がするが。
これからますます重要になるぞ。

81 :sage:01/10/09 00:34
最低限の知識共有としてドキュメント化ははずせないと思うんで、
UMLだけは、なんとか、押さえておきたいなあ。

他は、やりたい人が勝手にやればいい感じ。(←乱暴

82 :デフォルトの名無しさん:01/10/09 00:35
>>80
ある程度知った上で、問題点と運用方法
在るべき方法論について、議論しようとしてるんだけど
なんで問題点を指摘すると、相手の理解不足にしたがるの?

83 :70:01/10/09 00:37
>>75
教育コストが馬鹿高いのが問題だよな。

オブジェクト指向はクラスがあってメソッドがあって、
というだけならまあ覚えるのにそんなに時間はかからないだろう。
が、実は分析や設計の方法論であり、UMLを使えデザインパターンを使え
何とかさんの何とか法を使えとなると、
実際にやるプログラミングとは少し離れた抽象思考の世界に入ってしまう。
(UMLやデザインパターンは世間のコンセンサスを得たものだからまだ分かりやすいが、
そうでない分析や設計の方法論なんかは妙な哲学にしか見えないものが多い)
で、その方法論でクラスを作るにはどうしたらいいの?
の答えは、自分で考えろ。だからね。

その点、言ってることが分かりやすいXPには期待してる。

84 :デフォルトの名無しさん:01/10/09 00:38
>>79
そうか?
XP→リファクタリング→デザパタ→仕様書→UML

85 :デフォルトの名無しさん:01/10/09 00:38
>>81
最低限の妥協点としてUMLをフローチャートに書きなおして
持ってきて欲しい。

86 :デフォルトの名無しさん:01/10/09 00:40
>>83
>実際にやるプログラミングとは少し離れた抽象思考の世界に入ってしまう。
少し離れたというよりベクトルとしては真逆だと思う

87 :デフォルトの名無しさん:01/10/09 00:40
>>83
>世間のコンセンサス

宣伝の結果に過ぎない。

88 :デフォルトの名無しさん:01/10/09 00:40
フローチャートでは書けないからUML作ったんじゃないっけ?

あまり情けないこと言うなよ。>>85

89 :デフォルトの名無しさん:01/10/09 00:44
UML書くまでは、よく分かってる人がやればいいよ。

それ以外の兵隊は、UMLだけ読めればよし。

90 :デフォルトの名無しさん:01/10/09 00:45
実際の開発で採用した設計・開発手法はどんなものがありますか?
私がいま使っているのは
UML(一部)、UnitTest、リファクタリング、デザインパターン
くらいですね。割と小規模(三人)なので。
少人数なのでペアプログラミングっぽくなりますがちょっと違うかも...
代わりに書いたソースのレビューはやってます。

91 :デフォルトの名無しさん:01/10/09 00:45
設計の人間が内輪でコンセンサス作って出来あがった糞デザインを
実装に「下げる」。
問題点を指摘すると「オブジェクト指向を理解出来ない奴」という
レッテルを貼られて切られる。
設計サイドはそりゃ楽だわな。

92 :デフォルトの名無しさん:01/10/09 00:46
実際?
画面イメージと簡単なフローチャートをSEが持ってきて
実際の設計はPGがやる。

93 :デフォルトの名無しさん:01/10/09 00:46
>>91
OOやるまえから設計する人間はそんなもんでしたがなにか?

94 :802:01/10/09 00:47
やっぱJavaユーザーはDelphiユーザーとは違うね

95 :デフォルトの名無しさん:01/10/09 00:48
>>93
そういえばそうですね。問題無いですね。何か?

96 :デフォルトの名無しさん:01/10/09 00:49
>>94


97 :802:01/10/09 00:49
君たち数学もコンピューターサイエンスも知らないくせに
何を偉そうに語ってるんですか?
とにかく、あんま調子んのらんどけや。

98 :802:01/10/09 00:52
情報科の優秀な奴はプログラマーなんかにはならんのだよ。
難しい数学を使う偉い仕事につくのだよ。
君達は敗北者だからプログラマーやってるわけ、わかるか?
だいたい偉い人が作ったライブラリ使っとればアルゴリズムなんかしらんでもいいだろ。
お前らオートマトンとかわかってる?
数学基礎論わかるか?
アルゴリズムの計算量考えて作ってる?
あほはあほなりにがんばってるとは思うけどさ。
ああ、感情的になってしまったか。
わりいわりい、くだらんすれがあがるのがゆるせんだけなんだけどさ。
とにかく、あんま調子んのらんどけや

99 :デフォルトの名無しさん:01/10/09 00:52
>>97
2元方程式までなら知ってるよ?

100 :デフォルトの名無しさん:01/10/09 00:53
802ネタはもうお腹いっぱいだからやめて・・・

101 :デフォルトの名無しさん:01/10/09 00:53
Delギコスレからの輸出品なので廃棄処分でよろしく。<802

102 :デフォルトの名無しさん:01/10/09 00:54
>>97-98藁た
ブラックユーモア(・∀・)イイ!

103 :デフォルトの名無しさん:01/10/09 00:54
おもろいけどネタか

104 :デフォルトの名無しさん:01/10/09 00:56
数学の話題は数学板でどうぞ。
ここはどっちかっていうと実務に近い人たちが
書き込むところです。ごめんなw

実務も抽象的に考えれば理論的に説明できるかもしれないのだけど
こっちはコストって概念まず一番にある世界なんだよな。
そこを分かってくれ。

105 :デフォルトの名無しさん:01/10/09 00:59
104
書き忘れたけど、デキの悪いおれがここにいるのもその
コストを考えられた上での話なんだな。

106 :デフォルトの名無しさん:01/10/09 01:00
>>98
そんな貴方にコレ。せめて人に見せられるもん書けや。
http://www.shiro.dreamhost.com/scheme/trans/gigo-1997-03-j.html

107 :802:01/10/09 01:00
僕は童貞です。でも知識はあります。

108 :デフォルトの名無しさん:01/10/09 01:01
>>104−105
何言ってるか分かりませんけど何か?

109 :デフォルトの名無しさん:01/10/09 04:54
>>97
オートマトンぐらいなら知ってるぞ。

110 :デフォルトの名無しさん:01/10/09 05:05
自動羊肉?

111 :デフォルトの名無しさん:01/10/09 06:59
C言語が難しいってんでVBが大流行している現状では、
オブジェクト指向が理解できる奴が少なくてもしょうがないか。

112 :デフォルトの名無しさん:01/10/09 07:21
>C言語が難しいってんでVBが大流行している現状
それはあんま関係ないような・・・

113 :デフォルトの名無しさん:01/10/09 08:00
>>110
毎回でるようなことだけに
ワラタ

114 :デフォルトの名無しさん:01/10/09 08:06
VBはオブジェクト指向取り入れだしたよね。
ていうか、C言語よりVBの文法の方が客観的に見て難しいよね・・・

115 :デフォルトの名無しさん:01/10/09 08:38
頭の中が抽象的思考になるにつれ
英文ライクを目指した言語の方が文法は難しく

116 :デフォルトの名無しさん:01/10/09 09:24
また駄スレになってきた……。

117 :デフォルトの名無しさん:01/10/09 10:32
SQLってなんであーなんだ?
英文ライクらしいがあれよりもっといいもの作れただろ。
まったく、、、

118 :デフォルトの名無しさん:01/10/09 10:39
OOとカンケーなくなってきたかも。

119 :名無しヘタぐらまさん:01/10/09 11:59
>>70
オブジェクト指向技術を使っている方の大半が
その技術をよくわかっていらっしゃらないからなのでは?

よくわかっていないために破綻してしまっている現状を
現場の人間は見ているので敬遠してしまうのかも.

…って,あんまり他人のことは言えないのですが.
恥ずかしながら最近ここに来るまでデザインパターンって知りませんでしたし
デザインパターンの本を読み始めて己の勉強不足を痛感してます.

120 :デフォルトの名無しさん:01/10/09 12:22
以下、
「オブジェクト指向イッショニ勉強スレ」
というマターリな方向へもっていってはどうか?
OOの有用性、生産性批判の議論はもう飽きたYO。

121 :デフォルトの名無しさん:01/10/09 13:45
賛成

122 :デフォルトの名無しさん:01/10/09 16:51
>OOの有用性、生産性批判の議論はもう飽きたYO。
確かに
自分がOOを理解していると勘違いしている人が多いのは事実
そういう人にOOが駄目だって言われても・・・
根本的なとこで、エラーが出てるわけだからね

もっと具体的な話でもしましょう
例えば、Javaでスレッドを使うとき
どういう場合にrunnableをインプリメントして
どういう場合にThreadを継承するか?
とかさ

123 :デフォルトの名無しさん:01/10/09 17:01
>>122
漏れはほとんどいつもRunnableを使う。内部無名クラスとしての場合が
多いけど。

124 :デフォルトの名無しさん:01/10/09 17:20
別の処理シーケンスには実態としてのクラスを割り当てたく
なるのはヘタレですか?

125 :デフォルトの名無しさん:01/10/09 17:31
>>122
Javaやってないから今まで知らなかったんだけど、検索かけて
理解した。面白いね、Java。
たぶん自分で使うなら、>>123さんと同じくRunnableを使うと思う。

126 :デフォルトの名無しさん:01/10/09 23:44
今作っているツールの「オプション」の設定を
セーブしたり反映させたりするのに
いい設計かパターンかないかな?
レジストリ読んでくるときも同じことで悩みます。

127 :デフォルトの名無しさん:01/10/10 00:17
せっかくオブジェクト指向でくくってるのにJavaローカルの話題ださんでもいいじゃん。
Javaでスレッドがinterfaceとクラス継承の両方で実現できるのは多重継承が出来ない、
Mix-inもできない結果なんで。

128 :125:01/10/10 00:21
>>127
多重継承できればオレもmix-inにするな。
mix-in派としてはインターフェース継承(runnable)がわかりやすひ。

129 :デフォルトの名無しさん:01/10/10 00:24
>>126
メメントパターソだたかな?
デザパタ勉強中につき、うろおぼえなり。

130 :デフォルトの名無しさん:01/10/10 00:27
Javaスレ他にもあるから駄目。
OOを徹底的に叩くスレ。

131 :デフォルトの名無しさん:01/10/10 00:29
>>130
違うだろっ!!

132 :デフォルトの名無しさん:01/10/10 00:33
>>129
ちょっと勉強してみます。さんく。

133 :デフォルトの名無しさん:01/10/10 00:35
>126
言語による。なに使ってんの?

>129
ちょっと違うような。OO、デザパタはあんま関係なさそう。

134 :デフォルトの名無しさん:01/10/10 00:38
>>129
メメントはアンドゥ、リドゥの管理を自分でやらずに他人に任せるパターン。
>>126のどこに使えるのだろうか?
俺には想像できない。

135 :デフォルトの名無しさん:01/10/10 00:39
みーめんとー
と読んでいたのは僕です。

136 :129:01/10/10 00:40
恥。逝ってきますっ!!

137 :デフォルトの名無しさん:01/10/10 00:51
>>126
特別な設計はいらないのでは。
オプションウィンドウを開くときに、
各モジュールが持つ状態を収集してウィンドウを構築。
閉じるときに各モジュールへ反映。
単純にこれでいいと思う。

オプション項目とモジュールの関連は抽象化されないけど。
オプションウィンドウに表示される項目が
動的に生成されて動的に並べられるものでもない限り、
具体的にならざるを得ないのでは。

138 :デフォルトの名無しさん:01/10/10 01:10
>>126
情報を持っている各モジュールに保存、復帰に相当するインタフェースをもたせる。
このとき状態を記録するためのオブジェクトを引数にとることにする。
保存、復帰に相当するメソッド内からは引数に渡されたオブジェクトのメソッド
(書き込み、読み込み相当)を利用して情報を記録オブジェクトから出し入れする。
各モジュールをリストかなんかにいれてイテレータで順次、保存、復帰メソッドをコール。
どの情報を記録するかはそれぞれのオブジェクトに委ねられる点が良いような気が。

139 :デフォルトの名無しさん:01/10/10 01:13
>どの情報を記録するかはそれぞれのオブジェクトに委ねられる点が良いような気が。

それで、オプションウィンドウのUIはどうなるのでしょうか?

140 :133:01/10/10 01:14
>オプション項目とモジュールの関連は抽象化されないけど。
>具体的にならざるを得ないのでは。
まともなRTTIのある言語なら
例えばコントロールの変数名などをキーにしてやれば、
ほぼ自動化できるよ。それが出来るかどうかは言語による。

141 :デフォルトの名無しさん:01/10/10 01:15
それってRTTI?

142 :デフォルトの名無しさん:01/10/10 01:17
>>140

>オプションウィンドウに表示される項目が
>動的に生成されて動的に並べられるものでもない限り、
ここを抜くなよ。

143 :138:01/10/10 01:21
>>139
ウィンドウの左側に各モジュールのリストを表示し、リストがクリックされたら
そのモジュールのプリファレンス表示メソッドをコールって具合にすれば、
UIもモジュール内に分散させられる気がします。
どっかでみたようなインターフェースですが。

144 :デフォルトの名無しさん:01/10/10 01:30
>>133
言語はc++っす。
みなさん、いろいろ案ありがとうございます。

145 :デフォルトの名無しさん:01/10/10 01:35
>>138みたいな方法ってパターン名でいうと何になるんでしょうか?
>デザパタのえらい人。

146 :デフォルトの名無しさん:01/10/10 01:37
継承

147 :デフォルトの名無しさん:01/10/10 01:38
メメント。

148 :デフォルトの名無しさん:01/10/10 01:41
>>145
mementoの中途半端版

149 :デフォルトの名無しさん:01/10/10 01:46
この>>126のような場合、メメントは有効なんでしょうか?
他のパターンの適合は?

150 :デフォルトの名無しさん:01/10/10 03:04
思うんだけど、OOってコンソールかGUIかに限らずアプリを
作る時に処理を切り分けしやすいから良いんだけど、机上で
設計した後それを実践(実装)する時に困ることが多いと思う。
理想と現実ってとこかな。

一番広く使われてるのはC++だと思うけど、「C++FAQ」は
この妥協点を踏まえて書かれてて参考になった。多重継承
は漏れも好きじゃないけど、単一継承、それも純粋仮想クラス
は結構意味があると思う。

みんなは設計する時にどうやってる?UMLで書く?紙に丸とか
四角とか並べてる?漏れはいきなりソースのインターフェイス
(C++ならヘッダファイル)だけを書いてしまうことが多いの
だけど。。。

151 :デフォルトの名無しさん:01/10/10 06:40
>>150
>設計した後それを実践(実装)する時に困ることが多い

どういうことで困るのか具体的に語ってよ。掘り下げてこそ面白い。

152 :デフォルトの名無しさん:01/10/10 07:37
>>150
UML書きますね。
でも、UIはいきなり実装が多いかな。
実装依存の場合が多いですもんね。

153 :デフォルトの名無しさん:01/10/10 08:08
>>149
オブジェクトのカプセル化を壊さないという点からみれば
メメントを使うのは一つの方法かも。
あとはCompositeが使ってあればメッセージを行き渡らせるのが楽かな?

154 :デフォルトの名無しさん:01/10/10 08:34
>>150
オレは逆かな?
設計するときに、どのくらいの粒度でオブジェクトに切り分けるか悩む。
実装は既存クラスを再利用しながらサクサク進む。

155 :デフォルトの名無しさん:01/10/10 09:43
>>154
それは、オブジェクト指向がわかっていないから。

156 :デフォルトの名無しさん:01/10/10 10:08
>>155
すっきりと設計できるようになるまでの過渡期みたいなもんあるし、
あまり冷たい言い方はせんでイイよ。

157 :デフォルトの名無しさん:01/10/10 15:28
継承を使うより、
オブジェクトコンポジションを使え!

ってな書籍が少ないと思いませんka.

あと、オブジェクト指向たらC++だか言ってる本が多い割には、
現実のコーディング場面で考慮するべきことがあんまり載ってない。

ソースファイル(.cpp)やヘッダ(.h)間の依存関係とかさぁ

158 :157:01/10/10 15:31
なんかお勧めの本ってあります?
漏れ的には、
「大規模C++ソフトウェアデザイン」
http://www.pearsoned.co.jp/washo/prog/wa_pro15-j.html
が(・∀・)イイ!って思ったんだけど。

159 :デフォルトの名無しさん:01/10/10 23:10
>>158
http://www.amazon.co.jp/exec/obidos/ASIN/475611895X/ref=pd_sim_b_dp_1_3/250-2856788-2389052
http://www.amazon.co.jp/exec/obidos/ASIN/4756118089/ref%3Dpd%5Fsim%5Fb%5Fdp%5F1%5F1/250-2856788-2389052
http://www.amazon.co.jp/exec/obidos/ASIN/4756118534/ref=pd_sim_b_dp_1_1/250-2856788-2389052
http://www.amazon.co.jp/exec/obidos/ASIN/4881356194/ref=pd_sim_b_dp_1_2/250-2856788-2389052
http://www.amazon.co.jp/exec/obidos/tg/detail/glance/-/books/4797311126/qid=1002722823/ref=sr_sp_re_1_2/250-2856788-2389052
これらをまだ持ってないとは言わせない。

160 :158:01/10/10 23:46
おお〜〜♪>>159
憂鬱な〜は持ってない(大学生協で立ち読み程度
そんなに良い本だったのか!!

けど、残り4つは持ってる/全部読んだヨ。

特に「デザインパターン」は漏れの今までのOOに対する認識を一新したね!!
あれ読まずにOOPするなって感じ。

161 :158:01/10/10 23:49
「リファクタリング」も外せないですne.

162 :デフォルトの名無しさん:01/10/10 23:50
>>159
Javaでいいのはない?
自分はC++わからないので

163 :デフォルトの名無しさん:01/10/10 23:55
憂鬱本は入門講座。他の本の内容が理解できるなら不要かもしれない。
それでも他の本には載っていない状態遷移について詳しいから、
自分でそこが弱いと思うなら読む価値はある。
UML関係の本も一緒に読むといいよ。

164 :デフォルトの名無しさん:01/10/10 23:56
>>159
Javaは解らない…。C++しか知らない。

165 :デフォルトの名無しさん:01/10/10 23:57
>>162
http://www.hyuki.com/dp/index.html

166 :デフォルトの名無しさん:01/10/10 23:58
ほ〜。
なんか過去ログ宗教論争ばっかだったけどさ

名スレダネ

167 :デフォルトの名無しさん:01/10/11 00:05
>>166
>名スレダネ
どこが?

168 :スレ違いかな:01/10/11 00:08
MFCでDoc/Viewのちょっとしたプログラムを組み始めたんですが

AppWizardが吐いてるコードは、なんか全てのクラスが
CxxxAppクラスを知ってる(#includeしてる)のが気に入らなくて、
それらをCxxxAppから独立させて(絶縁して)組んでます
あとCxxxViewがDocを知ってるのも気に入らない。

こういう組み方してる人っています?実務レベルで.
どうなんだろ.

169 :166:01/10/11 00:10
>>167少なくとも、マトモな本読んでる人がいるってコトで.

170 :デフォルトの名無しさん:01/10/11 00:12
>>169
なるほど、本の紹介ね。

171 :デフォルトの名無しさん:01/10/11 00:13
Doc/View構造ってデザインパターンに含まれてなかったよね?

172 :sage:01/10/11 00:14
>>171
observer petterがそれだ、と指摘を受けタ

173 :デフォルトの名無しさん:01/10/11 00:18
>>171
Doc ->Subject
View->Observer

ってことか.

174 :デフォルトの名無しさん:01/10/11 00:19
Model/View/Controllerってデザインパターンに含まれてなかったよね?

175 :171:01/10/11 00:22
>>172
そうだったのか。

>>168
というわけで、デザパタの本でObserverパターンを確認してください。

176 :デフォルトの名無しさん:01/10/11 00:24
>>174それなに?

177 :168:01/10/11 00:38
なるほど…勉強になります
とりあえずMFCスレにでも逝ってきますです…

178 :デフォルトの名無しさん:01/10/11 00:57
馬鹿がデザパタと聞いて「勉強」だってさ ぷぷw

179 :デフォルトの名無しさん:01/10/11 01:04
802師匠のお通りです。童貞喪失者は道をあけろ!

180 :(;´Д`):01/10/11 01:12
>>178
802ってのは良く知らんけど、あんたがそうなのか.
そういうあんたは>>158,>>159,>>165の本のどれかひとつでも
理解できてるんか、と問い詰めたい。小一時間問い詰めたい。

181 :伝説のPG:01/10/11 01:15
私の設計はそこらのデザパタ本など足元にも及ばないほど高度でかつ
洗練されておる。

語れ。

182 :デフォルトの名無しさん:01/10/11 01:18
>>178
設計で一番重要なのは、クライアントとまともに
話せることなのよ。これが出来ないと、分析も要
件定義もない。一生コーダーならいいけどさ。

183 :伝説のPG :01/10/11 01:23
依頼主に会う前に相手の事は徹底的に調べておく。
用件は聞かなくても解る。

それから私の背後から近づかない方が良い。
報酬は指定したスイス銀行にアメリカドルで振りこんでくれ。

184 :デフォルトの名無しさん:01/10/11 01:24
>>182
確かにねー
業務知識じゃ勝てないからねー
イヤな爺の話も聞かなきゃならない(-o-)

185 :デフォルトの名無しさん:01/10/11 01:28
>>181>>183
802師匠童貞3流大学情報科院生低レベル厨房にしてはつまらないネタですね。

もしかして、童貞喪失者ですか。これは失敬。

802師匠の低レベル書き込みを拝見するならココ!
         (;;´∀`)        
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1002111261

186 :デフォルトの名無しさん:01/10/11 01:31
イタイ人だということがわかった。

187 :デフォルトの名無しさん:01/10/11 01:34
>設計で一番重要なのは、クライアントとまともに
>話せることなのよ。これが出来ないと、分析も要
>件定義もない。一生コーダーならいいけどさ。
なんでこのスレにはこんな無内容な事しか話せない
糞厨房が後から後から湧いてくるのかねぇ?

しかも本人は結構気の利いたことを
言ってるように思い込んじゃってるのが余計に痛々しい。

188 :デフォルトの名無しさん:01/10/11 01:35
>187
あんたも一生コーダーの口だね。

189 :デフォルトの名無しさん:01/10/11 01:38
>>187
気の利いたこと、っつーよりヴァカを叩く目的だから問題なしかと思われ。

>>188
あまり反応しすぎないほうが良い。オレモナー

190 :sage:01/10/11 01:38
煽りはほっとけ

191 :デフォルトの名無しさん:01/10/11 01:39
本の紹介するヤツ
本の紹介をありがたがるヤツ
802ネタだすヤツ
関係ない話するヤツ
煽るだけのヤツ

やっぱOOスレはこうなるのね

192 :デフォルトの名無しさん:01/10/11 01:41
>>191まぁそう言うなって。マターリ。

193 :182:01/10/11 01:44
>>187
不快に感じたのなら、謝るよ。なお、188 は私じ
ゃないよ。

194 :デフォルトの名無しさん:01/10/11 01:46
>182
不快云々よりスレ違いですよ。
正直このスレでその手の話題は食傷気味です。。。

195 :デフォルトの名無しさん:01/10/11 01:47
>>191
最終的には手段だってことをどうしても忘れてしまうんだよね。
これが俺のイタさの原因。一応2chでも気をつけてはいるつもりだよ。

196 :182:01/10/11 01:49
>>194
キチンとした会話は、SEとして必須だよと、言
いたかっただけだけど、まずかったみたいね。以
後気をつけるよ。

197 :伝説のPG :01/10/11 01:50
吉野屋のメニューはOOである。
基本クラスは牛皿だ。
他は全て派生クラスだ。

語れ。

198 :デフォルトの名無しさん:01/10/11 01:51
>>195
イタイのはお互い様
特にこのスレは(w

199 :192:01/10/11 01:51
[C++]「インターフェイスと実装の分離」
つうことで、こんなのはいかがか。

--Class.h--
class Class
{
virtual void func1() = 0;
virtual void func2() = 0;
static Class* create();
};

--Class.cpp--
#include "Class.h"

class ClassImpl : public Class
{
virtual void func1(); // func1実装
virtual void func2(); // func2実装

//メンバ変数など
};

void ClassImpl::func1() {
...
}

void ClassImpl::func2() {
...
}

Class* Class::create()
{
return new ClassImpl();
}

Factoryクラスを用意するまでもないとき、こんなのはどうでしょう?

200 :デフォルトの名無しさん:01/10/11 01:51
つーかなんで折れのほうが上なんだって優劣をつけたいわけ?
どうせみんな本に教えてもらってるんじゃん。

201 :デフォルトの名無しさん:01/10/11 01:52
無理がある

202 :デフォルトの名無しさん:01/10/11 01:54
童貞の802師匠と200をゲットしたのにそれに気がつかない>>200
どちらが優秀かというと
劣等なのは802師匠がぶっちぎりだ。それに何か問題があるのか?

203 :デフォルトの名無しさん:01/10/11 01:55
>>200
回答−>真に実力のないプログラマの性
真の実力者なら、自分でいわなくても、他人が認めてくれる

204 :192:01/10/11 01:56
>>200
だよな。全部の本を一度に読むにはムリがあるし。
その点2chでは本当の評価が聞けて良い。

205 :デフォルトの名無しさん:01/10/11 01:56
>200-203
そ〜ゆ〜話題も食傷気味でちゅ

206 :デフォルトの名無しさん:01/10/11 01:57
>>203
うむ、実力の中途半端な奴ほど回りに良く見られたがるよね。
他人の自分に対する評価もやけに気にする。

207 :192:01/10/11 01:58
ていうか>>199はどうよ?
「無理がある」で終わりかYO!

208 :デフォルトの名無しさん:01/10/11 01:58
>>203
あ、それ漏れだよ(T_T)

209 :201:01/10/11 02:00
ごめん >>197向けに書いたのが誤爆。

どうみても牛皿は基底クラスに向かない。設計ミスだ。
の意味。

210 :デフォルトの名無しさん:01/10/11 02:01
>>209チョトワラタ

211 :デフォルトの名無しさん:01/10/11 02:02
OOを実践すると
290円でシステムを作らなければいけなくなる。

212 :デフォルトの名無しさん:01/10/11 02:03
public:
virtual Discount();
virtual Price() const;

213 :デフォルトの名無しさん:01/10/11 02:04
オブジェクトをどのレベルで捉えるかってのを
もっと段階的に論じてるものなんて読んだことある?
これがあるなら1000円ぐらい出してもいいな。

214 :199:01/10/11 02:06
思いついた当時は結構あたまひねった記憶があるんだが。>>199
なんか普通の考えにみえるな…

215 :デフォルトの名無しさん:01/10/11 02:06
データベースの設計における正規化のように、
クラス分けの正規化のようなモノがあってもよいと
考えたことはある。

216 :デフォルトの名無しさん:01/10/11 02:07
>213
>これがあるなら1000円ぐらい出してもいいな。
もう少しだせよ(W

217 :1000円…:01/10/11 02:07
>>213お。どゆいみ?例を挙げてくだされい。

218 :デフォルトの名無しさん:01/10/11 02:14
>215こっちも興味ありいい

219 :デフォルトの名無しさん:01/10/11 02:20
>>213
何だか曖昧でよく分からないが、
適切な粒度と役割でクラスを切り出せる方法論はあるかってこと?

有名どころでは
ビジネスロジック向きの「アナリシスパターン」
http://www.rational.co.jp/products/books/bk_14.html
リアルタイムシステム向きの「オクトパス」
http://www.tech-arts.co.jp/oo/octopus.html
などがあるね。やたら難しいけど。

220 :デフォルトの名無しさん:01/10/11 02:25
>>215
こんなのとか?
http://home.catv.ne.jp/dd/chiba/ken/Java/JavaStream.html

221 :デフォルトの名無しさん:01/10/11 02:33
>>213
1000円は誰に払えばいいんですか?


考えていたのとは違うけど「アナリシスパターン」は
目次見て面白そうだから今度立ち読みしてみます。

222 :デフォルトの名無しさん:01/10/11 02:34
ごめん、213は>>219の間違い。

だめだ、もう寝る。

223 :デフォルトの名無しさん:01/10/11 02:37
>>219それ読んだことあるけど難しすぎ…
少なくとも趣味レベルからOOを習得しようとしてる漏れには
理解できんかった…(鬱

>>220何か違うような。

224 :デフォルトの名無しさん:01/10/11 02:37
>221
Dare Ni Harau Ki Dattan Da ?

225 :デフォルトの名無しさん:01/10/11 02:50
>>224
おれ自慢じゃないがパソコンの本なんて4冊しか持ってない。
あとは全部Web。これ最強。おれにとっての話ね。

226 :デフォルトの名無しさん:01/10/11 02:54
パソコンの本って…「できるWindows」「超図解Excel」とか?

227 :デフォルトの名無しさん:01/10/11 03:00
いや、仕事に関係する全て
読みたいものは全て立ち読みか
会社に買わせる。

228 :(・∀・)イイナー:01/10/11 03:08
>>227それ最強だね!!

229 :デフォルトの名無しさん:01/10/11 03:11
俺は読むときに蛍光ペン引きまくるから私物でないと駄目なんだよな…

230 :デフォルトの名無しさん:01/10/11 03:13
それわかる〜〜〜>>223

231 :デフォルトの名無しさん:01/10/11 05:18
ネタふり
http://jcp.org/jsr/detail/26.jsp

232 :デフォルトの名無しさん:01/10/11 13:07
>>223
「アナリシスパターン」は、プロでも頭を抱えるような難物だから無理はないと
思う。後半の実装に近い部分は大体理解できるのだけど、前半は本当に難解。
1回通読しただけで理解できる人はあまりいないと思う。

233 :デフォルトの名無しさん:01/10/11 13:14
http://www.ogis-ri.co.jp/otc/hiroba/specials/img/Booch.gif
(´-`).。oO(なでてあげたい・・・)

234 :デフォルトの名無しさん:01/10/11 16:01
>>199
どういう利点があるのか説明きぼんぬ。
ふつうにNewとあまり差を感じないのですけど。

235 :デフォルトの名無しさん:01/10/11 16:14
>>197
class GYUDON extends DONBURIMESHI implements BENISYOGA

あ、牛皿が基底クラスになってない‥‥。

236 :デフォルトの名無しさん:01/10/11 21:39
牛皿を基底クラスにするのは却下。
なぜなら牛丼とは並盛のことであり、
大盛、特盛は牛丼から派生している。

1980年代にブーチ博士が出版した
「Object-Oriented Yoshinoya And Donburi」
(邦題・オブジェクト指向吉野家とドンブリ)によると、
牛丼一筋80年という観測結果から
継承階層が1段階に限られていることが証明できるとあるのだ。

しかしこの本の内容は今となってはやや古臭い。
その後の研究で牛丼一筋100年ではないことが通説となり、
それを機にブーチは松屋法のヤコブソン、すき屋法のランボーと協力して
Unified Gudon Language(統一牛丼言語)を開発、発表している。
これによりどのお店でも「特盛」や「つゆだく」が通じるようになり、
今年8月には並盛り280円を達成するという目覚しい効果をあげている。

237 :デフォルトの名無しさん:01/10/11 21:45
ワラワラ

238 :デフォルトの名無しさん:01/10/11 22:03
今日のお題は、吉野家のメニューのクラス設計ですか。

239 :デフォルトの名無しさん:01/10/11 22:45
>>236
激ワラタ。

240 :デフォルトの名無しさん:01/10/11 23:13
そしてクソスレへ…

241 :デフォルトの名無しさん:01/10/11 23:25
>>236

牛丼設計方法論の前途洋洋かと思われたその前途に突如立ちはだかったのがXP(邦訳:狂牛病)、ってことでしょうか?

自分が明日狂牛病に発病するかどうかなんて事前に判らない!というのが、
XP一派の主張らしいです。

242 :デフォルトの名無しさん:01/10/11 23:39
>>241
狂牛病だけにヤコブソンの松屋法はダメージが大きいですよ。
松屋は改装工事でおしゃれになってアベックでも入店しやすくなり、
ペアテイスティングを積極的に取り入れていますけどね。
カレーギュウの質が落ちたことについては残念ではありますが。

243 :デフォルトの名無しさん:01/10/11 23:43
>>242
多重継承は駄目だという実例だな。

244 :デフォルトの名無しさん:01/10/11 23:45
ちなみにヤコブソンが提唱するユースケースによって
顧客の要求を分析することで、松屋は他の牛丼屋にない
豊富なメニューを取り揃えています。
お客、店員だけでなく、自動食券販売機をアクターとみなしたことは
画期的な偉業だと言われています。

それにしても彼ら3人をスリーいらっしゃいズと呼んでいる人は
本当にいるのでしょうか?
彼らがそう呼んで欲しいだけのような気がするのは
私だけなのでしょうか。

245 :デフォルトの名無しさん:01/10/11 23:45
他重軽傷って、牛+ウイルスのこと?(w

246 :デフォルトの名無しさん:01/10/11 23:52
他重軽傷は自分自身の派生クラスを継承すると起こります。

247 :デフォルトの名無しさん:01/10/12 00:04
>>242
は、ペアプログラミングのことで多重継承は関係ないのでは?

248 :デフォルトの名無しさん:01/10/12 00:20
何時も通りの糞スレなのら〜
暇な3流大学生の溜まり場なのら〜
ら〜〜〜〜♪

249 :デフォルトの名無しさん:01/10/12 00:41
今日は人が少ないのか‥‥。

250 :デフォルトの名無しさん:01/10/12 00:41
>>234
例えば、privateメンバをClassImplに記述することで、
インターフェイスClass.hに見える部分をpublicメンバだけに制限できる。

っていうかそれくらい知っとけ。

#ていうか今日、Effective C++読んでたら同じやり方を見つけてショック(藁

251 :デフォルトの名無しさん:01/10/12 00:53
>>250
> っていうかそれくらい知っとけ。
目くそ鼻くそ・・・
そう思ったの、漏れだけじゃないよね?ね?

252 :デフォルトの名無しさん:01/10/12 01:01
ただの抽象クラス??

253 :デフォルトの名無しさん:01/10/12 01:06
がーーん<(゚o゚)>
OO理解できないアホとか、
デザパタ理解できないバカとかいってた人って、
もしかしてこのレベル?
もう、ここ来るのやめよ

254 :デフォルトの名無しさん:01/10/12 01:08
>>252
にもなってない(T_T)

255 :デフォルトの名無しさん:01/10/12 01:11
さすが、Effective C++読んでるだけのことはある(藁

256 :デフォルトの名無しさん:01/10/12 01:16
皆さんデザパタ初めて読んだとき、既に使っていたパターンがいくつありました?
私は7つかな。(多少変形ありで。)

257 :(;´Д`) :01/10/12 01:21
>もしかしてこのレベル?

ってどのレベルだよ…
そんなにレベル低いのか…?

>>255
何読んでる?

258 :デフォルトの名無しさん:01/10/12 01:27
レベル低いレスと高いレスの番号を挙げてもらえると、
僕みたいなへたれには勉強になるのですが。

259 :デフォルトの名無しさん:01/10/12 01:33
>>258
このスレは捨ててニュースグループへ逝きましょう

260 :デフォルトの名無しさん:01/10/12 01:34
>>256
そんなの数えて意味あるの?自慢?
パターンはいままであるものに名前を付けてるんだから
使ってて当然だろ。
変形あり・・・ってそのまま適用する方が少なくねーか?
そりゃ変形するだろ。銀の弾じゃねぇって書いてるだろ。

261 :おれ:01/10/12 01:36
>>257
やっぱりCマガの「ローテク講座」じゃないでしょうか。

262 :258:01/10/12 01:37
>>259
了解。

263 :(;´Д`):01/10/12 01:38
mata-ri

264 :デフォルトの名無しさん:01/10/12 01:39
>>260
銀の弾と書く(書いてきた)人には注意
ストレスたまってます

265 :デフォルトの名無しさん:01/10/12 01:41
>>261
もしかしてアノ人ですか・・・?

266 :デフォルトの名無しさん:01/10/12 01:43
もしかして例のアレを何したアノ人ですか?

267 :デフォルトの名無しさん:01/10/12 01:47
銀の玉玉検索してみました(俺って物好き?)
確かにヒステリー気味です 最低3日2chから離れましょう

268 :デフォルトの名無しさん:01/10/12 01:55
誰かキレられないネタふってよ
何故このスレは・・・・

269 :(;´Д`) :01/10/12 02:22
>>268胴衣・・・・

270 :デフォルトの名無しさん:01/10/12 02:40
>>257
>ってどのレベルだよ…
>そんなにレベル低いのか…?
このソースの良い点/悪い点を解説してちょ

271 :199:01/10/12 02:53
>>199について。
[目的]実装とインターフェイスを分離する。

大雑把に言えば、外部から見える.hファイルには
public:セクションしか置きたくないってことです。
この方法を使えば、データメンバやクラス内でしか
使わないメンバ関数などは
すべて実装側に記述することができます。

問題となる点としては
1.全てのメンバ関数がvirtualとなる。
このことによって
(1).関数呼び出しのオーバーヘッドが(わずかながら)増す。
(2).全てのメンバ関数が派生クラスで再定義されうる。

2.目的のクラスをnew演算子によって構築することができない。(悪い点?)
だから例のstatic 関数があります…

3.クラスの継承階層が一段階多くなるのでクラス階層の複雑さが増す。

4.friendを使う場合の問題。

272 :199:01/10/12 02:54
っていうか何ら真新しいものじゃないんだけどさ…

273 :270:01/10/12 02:58
(;´Д`)さんの解説をきぼん

274 :270:01/10/12 03:01
199さんの気づいてない悪い点も教えてあげて

275 :199:01/10/12 03:04
>>273
いや漏れなんだけど

もっと言えば、いちいち他から参照されないprotected/privateメンバ関数や
データメンバを追加するたびに必要だった、
依存するモジュールの再コンパイルが必要無くなる。
publicインターフェイスが変更されるときだけ、
再コンパイルされる。
中・大規模プロジェクトでは結構無視できないと思われ。

276 :199:01/10/12 03:06
ホントEffectiveC++で見つけたときは力抜けました。
結構頭ひねったつもりだったんだけど…

277 :デフォルトの名無しさん:01/10/12 03:09
interfaceを宣言できないC++では、実装を隠す為には>>199のように
するしかない。
似たような感じで他にもバリエーションあり。
大規模どーたらという本にも載ってたかも。
Efectiveにものってたか?

278 :デフォルトの名無しさん:01/10/12 03:18
>>277それ今日買ってきた。今読んでます…
上のほうで紹介されてたもんで。
中々良い感じです、
「C++に関する本は、ほとんどが論理デザインを取り上げている。」
大規模プロジェクトでは、ソースファイル同士の依存とかも
十分考慮に入れないと、大変なことになる。
そういった「実装デザイン」についても言及してます
でも高かった.

279 :デフォルトの名無しさん:01/10/12 03:21
事実上、大規模プロジェクトでは、>>199みたいなことしないと開発
出来ないよね。
ベースクラスの方で、いちいち実装が変わってフルコンパイルかかったりすると、切れるね。

280 :デフォルトの名無しさん:01/10/12 03:26
>>275-279
同じ人物が必死になってる気がするが。
ハッ、これは禁句?

281 :デフォルトの名無しさん:01/10/12 03:27
お。プロの方ですかな
開発環境はなに使ってる?VC?>>279

282 :通りすがり:01/10/12 03:28
1つバグがある
あと、継承先が1つなら、普通やらん

283 :たしかに自演ぽいことしてるけど:01/10/12 03:29
(;´Д`) =278=281="199"
それ以外は知らない。

284 :199で統一するか…:01/10/12 03:30
デストラクタ関連?>>282

285 :270:01/10/12 03:35
がびーん
同じ人だったの
はずかし

286 :270:01/10/12 03:39
あ、はずかしいのは、私ね

287 :199:01/10/12 03:43
紛らわしくてスマソ.>>270

>あと、継承先が1つなら、普通やらん
そういうもんなのかな…
あまりにも多くのクラスが「知っている」クラスはこれやっといたほうが
変更が効くと、思うんだけど
いかがなもんでしょ.

あとなにがバグなのかわからん.

288 :デフォルトの名無しさん:01/10/12 04:06
確かにメンバ変数などのprivate部分をちょっと変えただけでも
全コンパイルに近い状態になるのはかなり邪魔くさいので
(C++Builderはコンパイルが遅い!)
うちもでかくなってくると自衛的に二段構えにしてるな。

VCだとDebugビルドだとあんまり気にしなくて済んでるかな。

289 :デフォルトの名無しさん:01/10/12 04:19
要はコンパイルの手間の話だよね?
どちらも場合でも、publicメンバを変更しなければ、
使用しているクラスのソース変更はない。

通常の継承との混在はイヤだな。
使用頻度の低いクラスには、
ソースを複雑にするマイナスの方が大きい。
そう考えると、使用場面は限られてくる。

ポリモの為の抽象クラスほど、有用ではないな。

290 :デフォルトの名無しさん:01/10/12 04:22
もしかしてバグって、1行足りないって事かな?

291 :デフォルトの名無しさん:01/10/12 04:22
クラスのメンバ変数をヘッダに書かなくちゃいけないのが辛い。
C++の場合仕方のないことではあるけど
メンバ変数の宣言を実装側に切り離せれば楽なのに。
いちいち純粋仮想関数並べたインターフェース作るのもうざい。

292 :デフォルトの名無しさん:01/10/12 04:28
>>199のバグか…
public:がないYO!(笑)

293 :デフォルトの名無しさん:01/10/12 04:30
つーかC++固有の瑣末的な問題回避の話だな。
ぜんぜんオブジェクト指向と関係ない(笑)

294 :デフォルトの名無しさん:01/10/12 04:34
これをインターフェイスの分離というのは間違いでは?
インターフェイスのファイルの分離でしょう。

295 :デフォルトの名無しさん:01/10/12 04:39
やはりソースを出してもらうと、話が具体的になって良い。

296 :デフォルトの名無しさん:01/10/12 04:48
そこから更に継承するときは、
ヘッダとソースを両方インクルードするのね。
なんか変。

297 :デフォルトの名無しさん:01/10/12 04:49
>>296
いや、そーすだけだよ
さらにへんだが

298 :デフォルトの名無しさん:01/10/12 04:51
書籍を真に受けると,こういう事もあるってオチで.

299 :デフォルトの名無しさん:01/10/12 04:55
はぁ?誰が書籍を真に受けてるんだ?

300 :デフォルトの名無しさん:01/10/12 04:56
>>298
本人は、自分で考えたと言っている。
>>299
まぁ、抑えていきましょう。

301 :デフォルトの名無しさん:01/10/12 05:01
書籍に洗脳される→OOを使いまくる→失敗を繰り返しながらも経験を積む→
OOを使いこなせるようになる→ウマー

書籍に洗脳されるやつは馬鹿だと主張して本を読まない→OO使えない→OO使ってる
やつの足を引っ張る→迷惑がられる→差をつけられる→マズー

あなたはどちらの道を選びますか?

302 :デフォルトの名無しさん:01/10/12 05:01
次のネタ誰か出してちょ

303 :302:01/10/12 05:03
>>301
そのネタはやめようよ

304 :デフォルトの名無しさん:01/10/12 06:08
>>289
>どちらも場合でも、publicメンバを変更しなければ、
>使用しているクラスのソース変更はない。

以下はC++の話。
public以外の実装(内部処理)を変更するときにもヘッダファイルを
変更しないといけないでしょ?
インタフェース(のようなもの)と、内部実装を切り離しておけば、
そのクラスを使う場合に、利用元の変更が波及しにくくなる。

>>294
>つーかC++固有の瑣末的な問題回避の話だな。
>ぜんぜんオブジェクト指向と関係ない(笑)

確かにそうですね。

>>296
>そこから更に継承するときは、
>ヘッダとソースを両方インクルードするのね。

ヘッダファイルだけでいいよ。

305 :デフォルトの名無しさん:01/10/12 06:11
>>304
289と296についてはもう一度考えてみると良い

306 :デフォルトの名無しさん:01/10/12 06:13
>>305
おかしいところがあれば、具体的に指摘してくれませんか?

307 :デフォルトの名無しさん:01/10/12 06:14
>>306
少し考えてからにしてはどうか?
その後に説明する

308 :デフォルトの名無しさん:01/10/12 06:20
うーん。
>>289では、クラスのソース変更はpublicメンバの変更があるときだと
言ってますよね。
これはそうではないと思います。

>>296
ソースをインクルードする必要があるということですか?

309 :デフォルトの名無しさん:01/10/12 06:24
>>308
>public以外の実装(内部処理)を変更するときにもヘッダファイルを
>変更しないといけないでしょ?
この場合に、コンパイル以外の違いは何か?

>ヘッダファイルだけでいいよ。
public以外のメンバはどうなる?

310 :デフォルトの名無しさん:01/10/12 06:28
>>309
>この場合に、コンパイル以外の違いは何か?

うーん、質問の意味がわかりません。

>public以外のメンバはどうなる?

これもわからない。「どうなる」って何がでしょうか?
ソースファイルをインクルードする必要はないと思いますけど・・・。

311 :デフォルトの名無しさん:01/10/12 06:36
>>310
たとえヘッダファイルか更新されても、
publicメンバ以外の変更であれば、
再コンパイル以外の処理は発生しない。

継承時は、protectedやprivateも必要になる。
これは、Class.cppに記述されている。

312 :デフォルトの名無しさん:01/10/12 06:40
>>311
>たとえヘッダファイルか更新されても、
>publicメンバ以外の変更であれば、
>再コンパイル以外の処理は発生しない。

その再コンパイルを防ごうという話なんですけど・・・。
かっこよく、うさんくさく言えば、インタフェースと実装の分離。

>継承時は、protectedやprivateも必要になる。
>これは、Class.cppに記述されている。


それをClassImplで実装しましょうという話なんですけど・・・。

313 :デフォルトの名無しさん:01/10/12 06:43
>>312
>その再コンパイルを防ごうという話なんですけど・・・。
無論、分かっている。
つまり、使用クラス側のソース変更はない。

>それをClassImplで実装しましょうという話なんですけど・・・。
継承時には、その実装ファイル(Class.cpp)のインクルードが必要。
Class.hは必要ない。

314 :デフォルトの名無しさん:01/10/12 06:47
つまりこれは、インターフェイスの分離ではなく、
インターフェイスのファイルを分離して、
再コンパイルを少なくするという事。

315 :デフォルトの名無しさん:01/10/12 07:03
広義的にはインターフェイスの分離といえるか。

316 :デフォルトの名無しさん:01/10/12 07:05
あぁ、やっとわかりました。>>289を誤読してました。

しかし、インタフェースの分離か否かというのは、見解の相違という
ところに落ち着くと思います。

ベースクラスのインタフェースの変更が無い限り、それを使用する
ユーザはベースクラスの変更に無頓着でいいのですから、その
意味ではインタフェースが分離されているとも言えます。

ところで、Class.cppのインクルードは必要ないと思いますけど、
何か勘違いしてるでしょうか?

317 :デフォルトの名無しさん:01/10/12 08:31
>>316
>ユーザはベースクラスの変更に無頓着でいいのですから、その
コンパイルの速度が速くなるだけだよ。プログラムはビルドしなおし。ユーザーは
影響を受ける。
それでもファイルが分離された分、少しはインターフェイスが分離されたと言える。

318 :デフォルトの名無しさん:01/10/12 08:48
>>316
OOよりも、まずプログラミングの基礎を勉強すべし

319 :デフォルトの名無しさん:01/10/12 09:23
>>316
> ところで、Class.cppのインクルードは必要ないと思いますけど、
ClassImplを継承せずにClassを実装した別のクラスを作るんなら必要ないけど。

ちなみにXtはCで書かれてるけど、使用のためのインターフェースと継承のた
めのインターフェースが分かれてる。たとえばXawのダイアログなら

 X11/Xaw/Dialog.h 公開インターフェース
 X11/Xaw/DialogP.h クラス実装定義

という風になっていて、Dialogを使うときにはDialog.h、継承したクラスを作
るときにはDialogP.hをインクルードする(PはたぶんPrivateのP)。

320 :デフォルトの名無しさん:01/10/12 09:31
荒れてるな。
牛丼の話に戻さないと・・・。

321 :デフォルトの名無しさん:01/10/12 10:21
>>317
>コンパイルの速度が速くなるだけだよ。プログラムはビルドしなおし。ユーザーは
コンパイル速度の問題だけじゃない。
変更したのがライブラリクラスで多くの組織でそれを使ってる場合にそれぞれの組織に
再コンパイルを頼むのはコストがかかる。

322 :デフォルトの名無しさん:01/10/12 12:56
OOでいう「インターフェースと実装の分離」っていうのは、
アブストラクトクラスとかJavaのインターフェース継承とか
のことだと思ってたんだけどなぁ。

323 :デフォルトの名無しさん:01/10/12 14:50
>>317
>コンパイルの速度が速くなるだけだよ。プログラムはビルドしなおし。ユーザーは
>影響を受ける。

スタティックリンクの場合はリンクのみ必要。
ダイナミックリンクの場合は何も必要なし。
でしょ?勘違いしてるかな?

>>319
>ClassImplを継承せずにClassを実装した別のクラスを作るんなら必要ないけど。

あぁ、ここで食い違ってたんですね。
ClassImpleはClassの内部実装なのですから、class Classだけで閉じています。
というか、そのようにします。
継承も参照も保有もそうですけど、class Class以外のクラスは、Class.h
しか使いません。

>>322
>>199のようなコードは、ABCにせざるを得ませんから、その意味でも
インタフェースと言ってもいいんじゃないかと思います。まぁこの点は
異論があるかとも思いますけれど。

324 :199:01/10/12 16:49
僕的には:
インターフェイス継承の場合はClass.hをインクルード
実装継承の場合は、ClassImplクラスの定義を(class{};の部分を)、
新たにClassImpl.hに移して、(はじめからそうしておけば良いんだけど)
そのClassImpl.hをインクルード。

てな感じでどうですか

#.cppをインクルードするのは禁じ手かと。

325 :199:01/10/12 16:53
結局>>319と同じことなんだけど…

326 :デフォルトの名無しさん:01/10/12 17:11
クラス同士はうまくやれば独立に出来るけどさ、
クラスの中はスパゲッティーになること多くない?

あの関数とこの関数が依存しすぎ、とか。
これって漏れが下手なんかな?

他の人はどう?

327 :199:01/10/12 17:13
というかClassインターフェイスを持つ実装が複数ある場合は、
Factoryクラスでもつくって、
そいつに具象クラスの生成をさせると良いと思う。
というか、それが一般的なのか?

結局漏れが言いたいのは、newで生成する側はクラスの実装の詳細を
知らないといけないから、
それをstatic Class* create()みたいに宣言して、
定義をClassImplと同じスコープに置いた、
こりゃどうでしょ、ということ

328 :デフォルトの名無しさん:01/10/12 17:15
>>327
abstract factoryじゃだめ?

329 :199:01/10/12 17:15
>>326
>あの関数とこの関数が依存しすぎ、とか。
どゆいみ?

330 :199:01/10/12 17:16
>>328 そのとおり。(だと思う)

331 :デフォルトの名無しさん:01/10/12 17:38
>>329
あの関数の処理を変更するとこっちの関数も直さないと
だめでこっちの関数を直すとそっちの関数も...

みたいな.逝ってよし?

332 :デフォルトの名無しさん:01/10/12 17:43
とりあえず、複数人数共同開発出来ないコードだね>>331

333 :デフォルトの名無しさん:01/10/12 17:52
>>332
え?332のところって一つのクラスを複数の人間でコーディング
するの?ふつうクラスごとに割り振るんじゃないの?

あ、もちろんクラスのインターフェイスでは整合性を取ってるよ.
>>331はローカル関数の事ね.

334 :199:01/10/12 17:59
>>331
とりあえず構造化が必要じゃないのかな
それぞれの関数の役割を明確にしておけば、
その中身の振る舞いを多少変えても大丈夫、みたいな。

「リファクタリング」とかが良い例かも。
メソッドの移動、とか.

335 :199:01/10/12 18:01
>>334と、えらそうなことを言ってみたけど
「構造化」とか言ってる時点で
なんかおかしい様な気がしてきた…

336 :VB厨房:01/10/12 18:05
>>326
のクラスにやたら関数が入ってるのは、そのクラスを管理するクラス
(マネージャクラス)が無いんじゃないの?

参照スパゲッティは怖かもしれんが、やたらとプライベート関数詰め込むと
誰かにfinalにされるぞ(藁

337 :デフォルトの名無しさん:01/10/12 18:07
>>335
いや、意見産休。
やっぱりどうも自分が下手な気がしてきた。
まだまだ経験不足なのかも。

338 :デフォルトの名無しさん:01/10/12 18:10
>>336
うーん、なんていうか、マネージャクラスに対する
インターフェイスを整備しようとしてローカル関数が
そうなっちゃう場合が多い気がする。

自分だけならあんまりならない。

339 :デフォルトの名無しさん:01/10/12 18:12
ClassImplを実装継承するってどんな場合なんでしょうか?
僕はこれをやらないので、「.cppをインクルードする必要がある」
という意見が理解できないのです。

340 :199:01/10/12 18:14
>>338
C++ならマネージャクラスをフレンドにしとけば
マネージャのためだけにインターフェイスを準備しなくて済むのでは?

…どうなんだろ。

341 :199:01/10/12 18:18
>>339
いや、
「.cppをインクルードする必要がある」
というのは、もとに挙げた>>199の例が悪いっす。スマソ。
前にも書いたけど、class ClassImpl{…};の部分だけ新ヘッダに
移してそれをインクルードすれば良いと。

実装継承は…チョト自信ないけど、
「ClassImplの一部の動作を変更して再利用」みたいになるのかな…

342 :VB厨房:01/10/12 18:20
>>338
それはユーティリティークラスとして別のパッケージに追いやってでも
クラスを簡素化すべき。クラスは寂しいくらい簡素な方がヨイ。

ただテストはたまったもんじゃないだろうが。バグの追跡も。

343 :デフォルトの名無しさん:01/10/12 18:26
>>341
>実装継承は…チョト自信ないけど、
>「ClassImplの一部の動作を変更して再利用」みたいになるのかな…

それってClassImplをpublic継承して動作を変えるんでしょうか?
うーむ、デザインパターンを知らないんですが、そういうことって
よくやるんでしょうか。
Classを継承するのと何が違うのか良く分かりません(汗

344 :デフォルトの名無しさん:01/10/12 23:19
たった今入った情報によると、このスレにビンラディンの工作員が紛れ込んでいる。
さりげない会話の中で彼らの日本でのテロ開始の指示が行われようとしている。
開始のキーワードだけは解っている。
それは「生産性」だ。
決してこの単語を書きこんではいけない。

345 :デフォルトの名無しさん:01/10/12 23:23
Javaやればオブジェクト思考なんて自然に見に付く
swingをデザインパターン併せて勉強しろ
糞のままでいたくなかったら普遍的な知識を見に付けろ
オブジェクト思考はやっといて損はない
アーキテクチャとかアルゴリズムとかも忘れんどけや

346 :デフォルトの名無しさん:01/10/12 23:24
344の糞房は私ではないのでよろしく

347 :デフォルトの名無しさん:01/10/12 23:31
345は考えが浅い。

348 :デフォルトの名無しさん:01/10/12 23:46
>>347
なぜ?
反論するんならきちんとしてくれな

349 :デフォルトの名無しさん:01/10/12 23:51
>Javaやればオブジェクト思考なんて自然に見に付く
それはない
オブジェクト指向できないと、くそコードしかかけないだけ
自分がくそコード書いてる事に気づかないと・・・

>swingをデザインパターン併せて勉強しろ
同意
デザパタできなきゃswing使いこなせない

>糞のままでいたくなかったら普遍的な知識を見に付けろ
>オブジェクト思考はやっといて損はない
>アーキテクチャとかアルゴリズムとかも忘れんどけや
ライバル増やさないでー
他にできる奴がいないから、俺らは2千万以上稼げるんだから
年収1千万以下でPGとかSEとか言ってる人は
かわいくていいよ

350 :デフォルトの名無しさん:01/10/12 23:52
>>348
じゃあ、
>Javaやればオブジェクト思考なんて自然に見に付く
なんて思ってるとは考えが浅い。
で、どう?(w

351 :デフォルトの名無しさん:01/10/12 23:54
正直、Javaを勉強するとオブジェクト指向の勉強になる、に一票。

352 :デフォルトの名無しさん:01/10/12 23:55
生産性、反対から読んでも・・・

353 :デフォルトの名無しさん:01/10/13 00:12
携帯Javaやってもオブジェクト指向は身につかんな。
JavaScriptやってもオブジェクト指向は身につかんな。

354 :デフォルトの名無しさん:01/10/13 00:16
>携帯Javaやってもオブジェクト指向は身につかんな
自分でライブラリーとか作らないと・・・
ライブラリーを使ってるうちは身につかないと思うよ

>JavaScriptやってもオブジェクト指向は身につかんな。
おもしろい
ところで、JavaScriptってプログラミングって
言えるようなものなの?

355 :デフォルトの名無しさん:01/10/13 00:18
>>354
上段
作るのはいくらでも出来ますが
ライブラリを置くスペースがありません。

下段
プログラミングと言えるようなものではありません。
というか、あれはJavaでもなんでもありません。

356 :デフォルトの名無しさん:01/10/13 00:29
>ライブラリを置くスペースがありません
10kbだっけ?
まあ、確かにそうだね(笑)
ライブラリを書かなきゃいけない・・・
要するにポリモーフィズムとかを使ったライブラリを
(別にライブラリじゃなくてもいいんだけど、
巨大なプログラムって複数人でつくるから設計できない人にはやらせてくれないよね)
設計する機会がないとオブジェクト指向は身につかないんだよね
携帯で動かすくらいのプログラムにオブジェクト指向は必要ないかもね
iアプリとかのサーバークライアントのプログラム作る時がくれば
サーバー側はいろいろと複雑だから、それまでに身につけとかないとね
オブジェクト指向は設計フェーズの話だからね

やっぱ,JavaScriptはプログラミングってもんじゃないんだ
使う機会無さそうだし
JavaScriptでできることって
全部サンプルプログラムになっちゃってる気が

357 :デフォルトの名無しさん:01/10/13 14:44
ああ、OO厨に荒らされて下がるばかり・・・。

358 :デフォルトの名無しさん:01/10/14 03:33
>>357
お前の方が荒らし。

359 :199:01/10/14 07:11
まぁまぁ。
てなわけで新しいネタきぼんぬ。

360 :デフォルトの名無しさん:01/10/14 08:29
一気にレベルが下がった……。
マトモな人たちはこのスレを見捨てたようだ。

361 :デフォルトの名無しさん:01/10/14 12:18
357=360は消えてください。

362 :デフォルトの名無しさん:01/10/14 15:50
publicとprotectedについて
どう使い分けるかについて話しませんか?

363 :デフォルトの名無しさん:01/10/14 16:06
んなもん話す余地なし

364 :デフォルトの名無しさん:01/10/14 16:30
C++で戻り値がオーバーライド出来ないのって
設計した後の実装の時辛い事あるよね。

id型とかを持つ言語なら大丈夫なんだろうけど、
これだと型チェックが甘くなるし・・・

365 :デフォルトの名無しさん:01/10/14 16:55
おれ、実装って意味わかんねーンダ。
頼むから一回分かりやすく説明してから
使い放題にしてクレ

366 :デフォルトの名無しさん:01/10/14 17:13
>>364
covariantのこと?

367 :デフォルトの名無しさん:01/10/14 17:41
>>364
Javaでも、オーバーライドしたメソッドの戻り値の型は、変更できない。
確かに変更したいときもあるけど、それを許すとポリモーフィズムに影響
がでる。
Javaでメソッドを区別するシグナチャは、メソッド名とパラメータの並びで
戻り値の型とアクセス修飾子は含まれないけど、オーバーライドする場合は、
アクセス修飾子は狭くなる方には変更できないし、戻り値の型は変えられない
という制約がある。
結局、その方がオブジェクト指向に適合しているということだよね。

368 :デフォルトの名無しさん:01/10/14 17:46
>>365
ごめん漏れの言葉の使い方がおかしいのかもしれない
漏れは概念的に設計した後の実際のコーディングの事を実装って
呼んでる。C++で実装、Javaで実装とか。

>>366
あ、うん。
多分これのことだと思うんだけど、よく知らないので酢。良かったら
教えてください。資料がほとんど無いので・・・
C++相談スレへ逝ったほうが良いかな?

369 :368:01/10/14 17:52
>>367
適合してるのかどうかは漏れには分からないけど、
例えば、ファイルを扱うCFileというクラスがあったとして
CFile::Load()の戻り値はファイル形式によって色々あっても
良さそうじゃない。テキストファイルなら
CText * CFile::Load()だし、画像ファイルなら
CImage * CFile::Load()だし。
CFileのサブクラスで実装するにしても、インターフェイスで
型が決められてしまうとこれが出来ないでしょ?

370 :デフォルトの名無しさん:01/10/14 17:57
ばかばかしくてやる気も起きないけど、
そういうクラスがほしいのだったら、

CText, CImageの基底クラスを作ってそれを読み書きするんでないの?

class CFileImage;
class CText : public CFileImage {}
class CImage : public CFileImage {}

CFileImage* CFile::Load();

なぜばかばかしいかはじっくり考えてくれ

371 :デフォルトの名無しさん:01/10/14 18:06
>>370
それはわかるんだけど、それだとCFileから返ってくる物は
全部メタクラスから派生した方でなきゃいけないでしょ?

外部ライブラリを使った時なんかはそれが出来ない事もあるわけ。

372 :デフォルトの名無しさん:01/10/14 18:08
外部ライブラリはadapter patternでなんとかすれ。

373 :371:01/10/14 18:11
>>372
やっぱりそうなるだよね・・・
それがすっきしなくて好きじゃないから>>364と書いたのだが

374 :デフォルトの名無しさん:01/10/14 18:16
>>373

class CLoadableImage {
public:
bool Load(CFile &f);
};

class CText : public CLoadableImage {}
class CImage : public CLoadableImage {}

こっちでいいんでないの?
パターンなんて言うか忘れた。

375 :デフォルトの名無しさん:01/10/14 18:17
なにが「すっきしない」のかな?
ていうか>>370いうところのばかばかしい理由をじっくり
考えて300字以内にまとめる事。>>371

376 :デフォルトの名無しさん:01/10/14 18:33
こういう事がやりたいんじゃないの?

class CImage;
class CText;

class CFile {
public:
void load() {};
};

class CImageFile : public CFile {
public:
void load(string name, CImage *img) {/*...*/}
}
class CTextFile : public CFile {
public:
void load(string name, CText *img) {/*...*/}
}

CFile file;
CImage *img;
CText *txt;
file.load("filename1", img);
file.load("filename2", txt);

377 :デフォルトの名無しさん:01/10/14 18:36
>>376
気持ちは分かるが、それおかしすぎ。

378 :デフォルトの名無しさん:01/10/14 18:39
ゴメソ、俺OO厨房なんだけど>>376のような時って
どうやるのが定石なの?

379 :デフォルトの名無しさん:01/10/14 18:40
>>378
>>374が正解だと思う。

380 :376:01/10/14 18:43
間違えた・・・
これじゃコンパイルエラーじゃん藁

CImageFile ifile;
CTextFile tfile;
ifile.load("filename1", img);
tfile.load("filename2", txt);

381 :デフォルトの名無しさん:01/10/14 18:45
>>380
それも気持ちは分かるが、それおかしすぎ。

382 :378:01/10/14 18:47
>>379
つまりOO的にはloadはファイルの仕事じゃないって事?

383 :デフォルトの名無しさん:01/10/14 18:50
バイト単位の(低レベルなI/O)はCFile
バイトの並びを知っているのは各オブジェクト。

各オブジェクトがCFileに依存する形で書くのが
OO的にスマートだろ。

だが376, 380は、それ以前におかしい。

384 :378:01/10/14 18:56
>>383
ゴメソ・・まだよく理解してないんだけど、ファイルをオープン
するのはCFileで、そのなかのデータを画像として扱うのは
CImage、ということ?

385 :デフォルトの名無しさん:01/10/14 18:58
>>384
うん。

386 :デフォルトの名無しさん:01/10/14 19:01
でも、当初の368の逝っているケースだと
CFileが、それぞれのバイトの並びを知らなければいけない。
(もしくは、CImage, CTextなどの末端のオブジェクトを知らなくてはいけない)

CFileは、CImageやCTextに対する責任を負うべきではない。

というのは、わかるよね?

387 :378:01/10/14 19:02
>>385
サンキュ
なんとなくワカタヨ

388 :デフォルトの名無しさん:01/10/14 23:58
<<367
>Javaでも、オーバーライドしたメソッドの戻り値の型は、変更できない。
>確かに変更したいときもあるけど、それを許すとポリモーフィズムに影響
>がでる。

戻り値をcovariantにしてもポリモーフィズムに影響がでないというのが定説。

389 :367:01/10/15 01:32
>>388
>戻り値をcovariantにしてもポリモーフィズムに影響がでないというのが定説。
言われてみれば確かにそう。367での発言は、covariantの場合は当てはまらない。
sunのサイトで調べてみたら、javaでもcovarinatのサポートが検討されている
ようだし。
勉強不足、反省して逝きます。

390 :199:01/10/15 14:57
>>374
Loadableよりも「Serializable」の方がOO的に良いと思われ。

…蛇足ですが。

391 :体育会系SE:01/10/17 00:48
OOなんかいらねー!
プログラムは根性で作るものだ!
理屈こねてんじゃねーぞ!!!

392 :デフォルトの名無しさん:01/10/17 00:50
あんたが上司じゃなくてよかったよ

393 :デフォルトの名無しさん:01/10/17 02:21
そして、部下でもなくてよかったよ

394 :体育会系SE :01/10/17 02:22
実は同僚。

395 :デフォルトの名無しさん:01/10/17 02:27
生産性のアップには設計と実装の二人三脚が必要です
っつーか、設計なんてしてないから関係ないかw

396 :デフォルトの名無しさん:01/10/17 02:32
体育会系だろうがなんだろうがちゃんとやれる人はいる。
>>391は体育会系の人に失礼

397 :デフォルトの名無しさん:01/10/17 03:09
そんな事より1よ、ちょいと聞いてくれよ。スレとあんま関係ないけどさ。

このあいだ、久しぶりにシステム設計したんです。システム設計。
そしたらなんか設計会議にに人がめちゃくちゃいっぱいで座れないんです。
で、よく見たらなんかホワイトボードに書きこみがしてあって、「ハード仕様、言語未定」、
とか書いてあるんです。
もうね、アホかと。馬鹿かと。

お前らな、設計会議でハードの仕様未定でどーすんだよ、ボケが。
システム設計だよ、システム設計。
なんか発注元のSEとかも来てるし。発注元4人で途方に暮れてるのか。おめでてーな。
よーし、OO使って納期守っちゃうぞー、とか言ってるの。もう見てらんない。
お前らな、俺の寝袋やるからその席空けろと。
システム設計ってのはな、もっと殺伐としてるべきなんだよ。
開発中にいつ大幅な仕様変更が来てもおかしくない、
誰に責任をなすりつけるか、自分だけは助かろう、そんな雰囲気がいいんじゃねーか。
OOオタは、すっこんでろ。

で、やっと座れたかと思ったら、隣の奴が、んじゃインターフェースで、とか言ってるんです。
そこでまたぶち切れですよ。
あのな、インターフェースなんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、んじゃインターフェース、だ。
お前は本当にインターフェースでプログラム組みたいのかと問いたい。問い詰めたい。小1時間問い詰めたい。
お前、実際に仕様が固まったらそのインターフェースじゃおっつかないじゃないんかと。

システム設計通の俺から言わせてもらえば今、システム設計通の間での最新流行は
提案設計、これだね。
仕様より先に作っちまって提案。これが通のシステム設計のし方。
提案設計てのこちらの都合が多めに入ってる。そん代わり発注元の希望が少な目。これ。
で、発注先の担当者に催眠術かけて誘導。これ最強。

しかしこれは発注元が気付いたら信用を失うという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前、1は、VCでWINアプリでもつくってなさいってことだ。

398 :デフォルトの名無しさん:01/10/17 03:23
ほ〜。

399 :デフォルトの名無しさん :01/10/17 15:41
このスレって、他でデザパタ論議してる人とは
違う人達だよね?。
皆さん学生さんだよね?。
そうだと言って下さい! (´Д`;)
まともなOOなんか一生させてくれない気がして来た...

400 :デフォルトの名無しさん:01/10/17 15:53
ビジネスモデリングというものに興味があるやつはいるかい?

401 :デフォルトの名無しさん:01/10/17 22:00
OOの学習はまず、OOの絶対性、無謬性を知る事から始めます。

「ある町に2つの会社がありました。
 頭の良い社員の集まったA社と頭の悪い社員の集まったB社です。
 あるとき、頭の良いA社の社員はOOを採用する事に決めました。
 頭の悪い社員のいるB社は従来の設計手法のままでした。

 やがて日本の景気が悪くなってきました。
 業界にも冬がやって来たのです。
 以前からせっせとOOを取り入れていたA社は高い生産性によって
 注文が減るどころか、むしろ増えていました。

 一方、OOを採用しなかったB社は仕事が減って会社が火の車に
 なっていました。・・・・・・」

 小学生向けOO思想普及パンフレットより。

402 :デフォルトの名無しさん:01/10/17 22:05
まずは適材適所を知れ。

403 :デフォルトの名無しさん:01/10/17 22:31
OO <-これなによ?、

404 :デフォルトの名無しさん:01/10/17 22:37
OO=ObjectOrientedの略 オブジェクト指向

405 :デフォルトの名無しさん:01/10/17 22:38
>>404
ども、隠語かと思った(w

406 :デフォルトの名無しさん:01/10/18 00:33
Fileの話。

Fileという大雑把な言い方だから混乱するんじゃないかな。
Fileには機能的に二つの面があって、
1つはファイル名とかを扱う部分、もう1つはファイルの「中身」だ。
後者についてはSerializableとかStreamとかMarshalとかいう呼び名を
使うケースが多いね。

で、TextとかImageとかに必要なのは、まず絶対にStream経由での中身、
そして時として必要となるファイル名(拡張子連動とかで使う)。

分けて考えたほうがいいよ。
FileオブジェクトからStreamを取得して、Streamを使って中身を読み書きする、とかね。

407 :デフォルトの名無しさん:01/10/18 02:46
Java房はなんで只のファイル読み書きをStreamとか言ってんの?

408 :デフォルトの名無しさん:01/10/18 02:52
だってJava房なんだもん

409 :デフォルトの名無しさん:01/10/18 15:26
言語機能によらず処理が必要なデータの受け渡し。
これをストリームと呼ぼう。
とするとFileの読み書きはStreamの一種といえそうだ。

410 :デフォルトの名無しさん:01/10/18 15:49
>>409
>これをストリームと呼ぼう。

新しい俺用語の誕生ですか。
Streamという言葉にはもっとまともな定義がある筈ですが?

411 :デフォルトの名無しさん:01/10/18 17:12
>>410
連続性を持ったデータの並び、だっけ?

412 :デフォルトの名無しさん:01/10/18 17:54
>>410
>新しい俺用語の誕生ですか。
当然だ。俺が作るライブラリだからな!!ガハハ

413 :デフォルトの名無しさん:01/10/19 00:28
>>411
辞書にはそうでてるかも知れないけど、普通は、受け取り側の都合も考えずに
ドンドンやってくるデーターの事を言うような・・・。
連続性なんて言ったら殆どのデーターが該当するような・・・。

414 :趣味プロオタドキュソグラマ:01/10/19 05:51
>>397
あんた人間に対してOOPしてる。ダークサイドだ。こえー。
>>OO信者様
C++にはnamespaceとtemplateがあるんだぜ。カッコつけんなよ。
OOPなところはsusieとかPhotoShop etc.

415 :デフォルトの名無しさん:01/10/20 20:19
http://www.atmarkit.co.jp/fdotnet/opinion/kawamata/2001_10.html

この人の言っていることって
正しいのですか?

>  一方、筆者が別れざるを得なくなったのがオブジェクト指向である。オブジェクト指向
> といえば、クラスの再利用性が重要といわれるが、筆者の経験からいえば、再利用を意識
> したクラスを作ると、当面必要のない機能まで書き込む必要が生じて、時間と手間を食う。
> しかも、手間を掛けてもそのまま再利用できるケースはほとんどない。そのうえ、使わな
> い機能がソースコード上にあることで、ソースの分かりやすさは低下する。再利用を意識
> しても、結局よいことはあまりない。
>
>  また、現実のモノになぞらえたモデリングを行うあまり、何重にもクラスの継承を重ね
> ることもあるが、これも問題になる。このようなクラスは、メソッド呼び出し1つでも、
> いったいどのクラスのメソッドが呼び出されるのか分かりにくい。モノになぞらえるより
> も、継承の数を減らした方が、ずっとソースコードが分かりやすくなる。1980年代には、
> goto文がプログラムを分かりにくくする悪とされたが、継承は21世紀のgoto文といえるか
> もしれない。

416 :デフォルトの名無しさん:01/10/20 20:31
まあ、GOTO文は馬鹿には理解出来ない高度に抽象的なプログラミング
テクニックですから、落ちこぼれてそう言う事を言う人も居ますが
気にしないで下さい。

417 :デフォルトの名無しさん:01/10/20 20:56
>>415
なぜオブジェクト指向と継承や再利用が同義であるかのごとくに語られているのか。

418 :名無しヘタぐらまさん:01/10/21 00:06
>>417
ページ,読んできましたが,
この方,オブジェクト指向,全然否定してません.
彼の主張は
「再利用性を考えるあまりに複雑な継承をやるくらいなら
使い捨ての短いプログラムをさっと作ってしまった方がいいじゃん」
ってことなのではないかと.

彼の『オブジェクト指向』の言葉の使い方は間違っていると思いますが
主張自体は一理あるかなと思います.
確かになんでもかんでも継承にすることの問題点は
γさんとかが書いたデザインパターンの本でも指摘されていますし.
今作っているプログラムがクラスの設計でドツボにはまっているところだったので
いろいろ考えさせられてしまいました.



ただ,挙げられていたサンプル,Delphiで書けば

1: TSample1 = class
2: private
3: FSampleData: integer;
4: public
5: property SampleData: integer read FSampleData write FSampleData;
6: // 続く
7: end;

『隠蔽』をちゃんとやっても七行で済んでしまうのですが(笑).
彼にDelphiを教えてあげたい.

419 :デフォルトの名無しさん:01/10/21 00:21
やっぱDelphiはスゴイや!

420 :デフォルトの名無しさん:01/10/21 00:26
Ruby だと3行やね。smalltalk だとどうだろう。

class Sample
attr_accessor :sample_data
end

421 :デフォルトの名無しさん:01/10/21 02:37
彼はオブジェクト指向がよくわかっていないのではないですか?

  オブジェクト指向=複雑な継承

という式しか成り立っていないので
複雑な継承をやめる=オブジェクト指向を否定
と勘違いしているのでは?

何でも"短いプログラムがよい"という
決め付けは言語が変われば状況が変わるのに
そういう事が彼には理解できないのではないでしょうか。

定型的なメンバーアクセスメソッドを書くと行数が多いから
読みにくくてだめなコードという判断は
どう考えても、おかしいと思います。

優れたライブラリを使えば
ソースコードが短くて済み、その事は大変よいことでしょうが

そのライブラリを作っている人が
OO志向を否定して、メンバー変数をPublicばかりに
しているようなものは使えるものには
ならないと思うのですが、どうなのでしょう。

422 :デフォルトの名無しさん:01/10/21 02:46
OOでやらんでいいことをOOでやって、ダメだというのはどんなものか?

423 :デフォルトの名無しさん:01/10/21 03:04
>>421
どこにも「複雑な継承」の話は出てきてませんけど・・・。

>何でも"短いプログラムがよい"という
>決め付けは言語が変われば状況が変わるのに

そうですか?

>定型的なメンバーアクセスメソッドを書くと行数が多いから
>読みにくくてだめなコードという判断は

という話も出てきてません。
短いプログラムが正しいという前提だとすると、セクセッサを
使わないコードの方が「正しいということになってしまう」と書いてます。

XPでも「必要ないアクセッサを今インプリメントするな(YAGNI)」
というのがありますね。

424 :デフォルトの名無しさん:01/10/21 03:16
>短いプログラムが正しいという前提
短くて分かりやすくて意図した通りに正しく動くプログラムが正しい

氏は言葉をはしょり過ぎ。肉を減らして言葉を増やせといいたい。

425 :デフォルトの名無しさん:01/10/21 03:17
編集段階で削られている可能性あるね。

記事は鵜呑みにしないようにね。

426 :デフォルトの名無しさん:01/10/21 03:34
> また、現実のモノになぞらえたモデリングを行うあまり、何重にもクラスの継承を重ねることもあるが、これも問題になる。

>>423
これを複雑な継承という風に解釈したのですが?違いますか?

>>何でも"短いプログラムがよい"という
>>決め付けは言語が変われば状況が変わるのに
>そうですか?

そうでしょう、実際、DelphiやRubyの話も出ているようですが?

短いプログラムがよいという決め付けなら
アクセスメソッドを簡単に定義できる言語なら定義するのはよくて
C++ではメンバーはアクセスメソッドを付けない
のが正解なのですか?

実際、本人もC#はコードが短くなるからよいという事を書いていますけど


>>定型的なメンバーアクセスメソッドを書くと行数が多いから
>>読みにくくてだめなコードという判断は
>という話も出てきてません。

出ているでしょ。どこを読んでいます?

>短いプログラムが正しいという前提だとすると、セクセッサを
>使わないコードの方が「正しいということになってしまう」と書いてます。

前提という言葉があれば、どんな意見でもまかりとおるわけではないでしょう。
彼はオブジェクト指向より、短いソース志向が優れていると主張しているわけですよね。

XPは良い理論だと思いますが
彼の意見は短絡的で何も考えられてないと思います。
コードのリファクタリングは小さなプログラムを作れという指示ではないでしょう。

427 :デフォルトの名無しさん:01/10/21 03:42
そんな文意をねじ曲げかねない
編集の仕方はしないでしょう。


>短いプログラムでは複雑な処理ができないではないか、と思う人もいるだろう。
>もちろん、そのとおりである。本当に必要な機能に絞り込んで短いプログラムに仕上げれば、
>単機能のプログラムになるのは必然である。


つまり、多機能ライブラリを作れないし作っている奴の事は除外して
自分だけの狭い世界でだけ通用する前提について
この人は語っているのですか?

428 :デフォルトの名無しさん:01/10/21 03:45
必要なものを絞って、小さく書こう、といっているんだろ。

429 :デフォルトの名無しさん:01/10/21 03:47
『XP本三部作と「UNIXという考え方」を読んでくれ』 の一行で済む内容だな。

430 :デフォルトの名無しさん:01/10/21 03:51
なんか議論するのもアホらしいけど

>彼はオブジェクト指向がよくわかっていないのではないですか?
>
>  オブジェクト指向=複雑な継承
>
>という式しか成り立っていないので
>複雑な継承をやめる=オブジェクト指向を否定
>と勘違いしているのでは?

と誤読しておいて、自分の読解能力を露ほども疑わない、
そんな無邪気な君に乾杯。

君は筆者を貶めたい、ただそれだけちゃうんかと。小1時間問い詰めたい。

431 :デフォルトの名無しさん:01/10/21 03:55
age

.NET会議室の馴れ合い連中が
牛ノ屋関連で流れ着いてデブ擁護?

>君は筆者を貶めたい、ただそれだけちゃうんかと。小1時間問い詰めたい。

質の悪い記事を書いたら
叩かれるのは当たり前でしょう。

432 :デフォルトの名無しさん:01/10/21 03:55
でもたいした問題じゃないよな。
ソースが長くて見難いたって、アクセサ程度じゃどうってことない。
アクセサならなにやってるかも名前で一目瞭然だしな。
時間がかかるってのもデバッグの時間に比べれば屁でもない。(w

433 :430:01/10/21 03:58
>>431
>.NET会議室の馴れ合い連中が
>牛ノ屋関連で流れ着いてデブ擁護?

電波受信?
言ってることがさっぱりわからん。

>質の悪い記事を書いたら
>叩かれるのは当たり前でしょう。

マトモな批判ならOK。
426は論理的な思考も読解力も無いアホだから、議論するのも無駄。

434 :デフォルトの名無しさん:01/10/21 04:16
吉野家inプログラマ板
http://mentai.2ch.net/test/read.cgi?bbs=prog&key=1002008783

まあお前、433は、このスレの115番でも読んでなさいってこった。

人のことアホ呼ばわりするなら
もっとまともな反論しろよ。
あなたこそ、誤読がとか読解能力がとかしか言ってないでしょ。

あーヤダヤダ。核心つかれるとすぐ怒るから。

435 :430:01/10/21 06:13
んじゃー、ちょっとだけ。

>>421
>  オブジェクト指向=複雑な継承

>という式しか成り立っていないので

と君が読み取っただけだね。どこにもそんなこと書いてない。

>複雑な継承をやめる=オブジェクト指向を否定
>と勘違いしているのでは?

どこにオブジェクト指向を否定してる記述があるんだ?

>何でも"短いプログラムがよい"という
>決め付けは言語が変われば状況が変わるのに

あのさー、記事全部読んでる?
「決め付け」なんてしてないだろ。

>そういう事が彼には理解できないのではないでしょうか。

「そういう事」って何を指してる?
また、DelphiやRubyでアクセッサを簡潔に書けることと、あの記事は
どういう関係がある?

>読みにくくてだめなコードという判断は

ダメだなんて判断してないでしょ。してると言うんだったら、該当箇所を引用しなさい。

>そのライブラリを作っている人が
>OO志向を否定して、メンバー変数をPublicばかりに
>しているようなものは使えるものには
>ならないと思うのですが、どうなのでしょう。

日本語おかしいね。何言ってるかわかりません。
どうなのでしょうって、何が?

そもそも、筆者が「OOを否定している」なんて思い込んでいるから、
記事の内容を読み取れないんだよ。

436 :430:01/10/21 06:29
>>434
>あーヤダヤダ。核心つかれるとすぐ怒るから。

君って筆者の略歴にコンプレックスもって、筆者に粘着してるだけなんでしょ。

・・・なんて書かれたら、もう有効な反論は出来ないでしょ。
そんな低レベルなことは止めようや。

437 :デフォルトの名無しさん:01/10/21 06:30
426は極端に曲解してるところがあるというのはその通りだし、
430は正しいのだが、揚げ足取りの感があるなあ。
430の指摘は枝葉末節だろう。

438 :430:01/10/21 06:31
どこにそんなこと書いてる?
誤読だろ?

と言われたら、自分がそう判断した根拠を提示すればよろしい。
それをしないから非難されるのだ。

それに、筆者がよそで何をやろうと関係ないでしょ。
あのコラムの内容で閉じた話をしよう。

それともあの筆者について語りたいのか?

439 :430:01/10/21 06:36
ジサクジエーンとか書かれそうだが(藁

>>437
>426は極端に曲解してるところがあるというのはその通りだし、
>430は正しいのだが、揚げ足取りの感があるなあ。
>430の指摘は枝葉末節だろう。

うん、その通り。揚げ足取りだよ。
426がちゃんとした対話をする知性を持ち合わしているのかどうか、試してるだけなんだ。

なぜ426が、絶大な自信を持ってるのかも知りたい。
怖いもの見たさっていうか・・・(藁

440 :デフォルトの名無しさん:01/10/21 06:37
くだらねぇ争いだなぁ。
次行こうぜ。

441 :430:01/10/21 06:39
>>440
おっけー。もうやめる。
ごめーん。

442 :デフォルトの名無しさん:01/10/21 06:41
なんか話そうよ

443 :430:01/10/21 06:42
IIOSSの本買ったよ。これから読むとこ。

444 :デフォルトの名無しさん:01/10/21 06:54
俺もアクセサごときで見難いだの面倒だの言ってるのは間違ってると思うな。
継承のし過ぎは確かに良くないが、それはオブジェクト指向批判には
結びつかないと思うのだが。「別れざるを得ない」の理由にならないのは
言うに及ばず。

445 :デフォルトの名無しさん:01/10/21 07:06
誰か「OO志向」につっこんでやれよ。

446 :デフォルトの名無しさん:01/10/21 07:25
再利用性はプログラミングの生命線だぞ。
これが駄目ならOOは駄目つうことだ。
それが判らん奴はただの言語ヲタ。
日経あたりの提灯記事を見ぬけないのは技術者とは言えない。

447 :デフォルトの名無しさん:01/10/21 07:34
>>446
誰もOOでは再利用性が駄目だと言ってないだろ?
どこからそんな話になるんだ?

448 :デフォルトの名無しさん:01/10/21 08:47
OOは再利用性が駄目ってのは多くの経験者の結論。
関連スレ読み返すべし。

449 :デフォルトの名無しさん:01/10/21 08:56
唐突な話だな。
出てきたとしてもずっと昔だろう。
ま、俺としてはOOを使うと再利用性が上がるのは当然と思うがな。

450 :デフォルトの名無しさん:01/10/21 09:04
>>448
??
OOの再利用性が低いっていうのは、どこのレベルでのプログラミング
の話しですのん?
C++使っててクラスライブラリを使わない人っているのン?

451 :デフォルトの名無しさん:01/10/21 09:18
川俣さんはC#の(たのまれもしない)守護神なんですよ。
これまでは大体、Java逝ってよし→C#イイ!って感じでしたが、
(OldProgrammerの地が出て)GUI,OOP逝ってよし→C#イイ!
ってことになっただけですよ。

452 :デフォルトの名無しさん:01/10/21 09:43
あのスクロールのクソ遅いMSX版DQ2を移植したのはコイツ
だたのか‥‥。逝ってよしっ!

453 :デフォルトの名無しさん:01/10/21 11:17
ライブラリって再利用にカウントするんだw

454 :デフォルトの名無しさん:01/10/21 11:18
OO信者の言ってる「再利用」ってのはそれだったのか。
やっぱ只のライブラリヲタが騒いでるだけだったのね。
納得。

455 :デフォルトの名無しさん:01/10/21 12:10
>>456,454
クラスライブラリを利用してるときはOOの恩恵をさんざん
受けてる癖に自分が再利用できるクラスを構築できないから
「OOは再利用性が低い」って言ってるようにしか聞こえませ
んが何か?

456 :デフォルトの名無しさん:01/10/21 12:14
>454
ライブラリなんてOOじゃ無くてもあるしね

457 :デフォルトの名無しさん:01/10/21 12:17
ついでに言っとくと自分でプログラムするときは,
再利用できそうな部分と使い捨ての部分を切り分けて
クラス設計してるよ。
再利用しそうなほうはもちろん,アクセサを丁寧に用
意するし,はなから使い捨てのほうは必要最低限のメ
ソッドしか用意しない。
仕様変更が起こりそうな部分は継承せずに委譲して
ブラックボックス再利用。
ああOOって便利……。

458 :457:01/10/21 12:18
457=450ね。

459 :デフォルトの名無しさん:01/10/21 12:21
>>456
あらら,自分はOOの恩恵を受けてないと思ってる人がまた
ひとり。
ま,そうゆー人は,APIをずらずら並べるプログラミング
してたらいいんじゃないの?(w

460 :456:01/10/21 12:23
いや455のレスに適当な発言をしただけですよん

461 :デフォルトの名無しさん:01/10/21 14:26
OOの継承は再利用そのものだと思うが。

462 :sage:01/10/21 14:28
再利用性の高い実用クラスの設計と実装にはコストがかかる
という話しだと思われ。

463 :デフォルトの名無しさん:01/10/21 14:36
でも、再利用することによって、それ以上にコストが浮くんだけども。

464 :デフォルトの名無しさん:01/10/21 14:40
ようするに、「面倒だから再利用性の高いクラスを作らない」ってのは、
「面倒だから勉強は身に付けない」って言ってる受験生と同じだな。
勉強しておけば将来いい思いが出来るのにね。(藁

465 :デフォルトの名無しさん:01/10/21 15:00
川俣はC#の守護神ではなくて、C#の寄生虫だろう。
あんな奴についていったらC#はわけわからない言語になりさがる。
川俣C#はDelphiでいう所の吉田翁以下だよ

C#入門 第13回 言語に内蔵されたイベント機能
http://www.atmarkit.co.jp/fdotnet/csharp_abc/csharp_abc_013/csharp_abc01.html
イベント機能をCUIで利用するなんていうバカ見たことないな
それをサンプルにしてしまうのも、非常にセンスなし
イベントドリブンは元々ウィンドウプログラムから発生した機能だから
ユーザーの入力がないのにイベントを発生させて何が面白いのだ?

>>444そうそう。

>>455その通り。

>>457それは当たり前だが、川俣はそういうのも理解していないだろうな。
全部使い捨て

466 :デフォルトの名無しさん:01/10/21 15:13
利用されるクラスを書くのと、再利用もにらんだクラスは違うぞ。
クラスライブラリは前者。
ごっちゃに議論すると話がややこしくなる。

467 :デフォルトの名無しさん:01/10/21 15:14
>>465
C#ネタはC#スレでやってくれ。

468 :デフォルトの名無しさん:01/10/21 15:25
>>466 どう違うのでしょうか。

自分は再利用をにらんだクラスを作る時には
クラスライブラリを作っているつもりや
クラスライブラリを拡張している気になって作ってしまうのです。

469 :デフォルトの名無しさん:01/10/21 16:02
>>468
究極的に言えば、クラスライブラリは再利用性なんか考えなくて良い。
過不足無く要求仕様を満たせばそれで良し。

再利用をにらんだクラスは、要求仕様+αが必要。
(必要ないかもしれない)抽象度を高めたり、独立性を高めたり、
今は必要ないリファクタリングをしたりする必要がある。

470 :デフォルトの名無しさん:01/10/21 16:24
>>469
部品屋さん、と、アプリ構築屋さんの違いでは?

再利用性を考える=要求仕様を満たす

という状況もあります。+αが確実な要求仕様になるのです。
>(必要ないかもしれない)抽象度を高めたり、独立性を高めたり、

程度の問題ではありますが
これが要求仕様になるのですよ。


話題は異なりますが
XPのいくつかの理論はアプリ構築の為の方法論であり
元々XPを導入しなくてもスキルがあり生産性の十分高い部品屋には
通じない事もあると思います。

471 :sage:01/10/21 16:48
結局、今の納期と将来の納期を見比べて、どこまで作り込むかという
話しに帰結するだろ。

とりあえず今をしのぐために手早く確実に作り込むか、
将来楽をしたいからしっかり作り込むのか、の違いなんだよ。

どちらかというと、後者の方が失敗(予測見積もり)したときの
リスクが大きいから、企業活動としてやるなら
とりあえず「そこまではやらんでいい」のだ。

些末すぎてあのペ−ジに書いてある例は議論の対象にもならんと思うが、ね。

472 :デフォルトの名無しさん:01/10/21 16:51
ではあの文章は駄文で
K川俣は堕デブということでよろしいですか?>>471

473 :sage:01/10/21 16:54
川俣の本、何冊か呼んで、結構ためになってるからなあ。

後で本当にオブジェクト指向を消化したうえで、
もういちど読み直しとけばいいよ。
だが、毒にもならんし薬にもなってはない、と思う。

474 :sage:01/10/21 17:10
と思ったら、ぜんぜん別人だった。
どれも読まなくていい本。

>>472でよろしい。

475 :名無しヘタぐらまさん:01/10/21 17:55
>>465
私はDelphiのコンソールプログラムでもクラスを作ってイベント定義してます.
イベントをフック,コールバック関数のようなものと考えれば
利用する場面は結構多いとように思うのですがどうでしょう.

たとえばある種のデータを処理するクラスで
時間の掛かるエンコードやデコードを行うメソッドがあるとすると
進行状況を表示する手段としてイベントを用意するのは有効だと思います.

476 :デフォルトの名無しさん:01/10/21 17:56
どんなやつかと思ってたらただのデブオタか

477 :デフォルトの名無しさん:01/10/21 18:07
>>474
ワラタ

水俣?
http://www.autumn.org/selfint.html#NOTPROGRAMMER

プログラマではないのは結構なのだが
それなら知ったかぶりして技術駄文をwebサイトで執筆する

という行為はやめてもらいたい。

478 :デフォルトの名無しさん:01/10/21 18:24
>>475
そのイベントの使い方は正しいですが
その利点があの川俣氏のサンプルでわかりますか?

ウィンドウプログラムのイベントドリブンだけが
イベントの利点だと思われたのならスマソ。書き方が悪かった。

しかし、コンソールベースでも隠蔽などの事を考えなければ
イベントなどは必要なく単にコールバック関数を指定すれば
いいわけなので、それほど利点になるわけではないと思います。
やはりイベントドリブン系のUIを持つ所での
使用が主として役に立つのではないかと、私は思います。

川俣氏の理論でいうと
イベント定義するより関数を直接呼んだ方が
短いプログラムになるはずですが、

それについてどう思いますか?

479 :デフォルトの名無しさん:01/10/21 18:30
その機能が実際の開発でどのように使われているかなんて
奴に書けるわけがない。
だって奴は実際の開発なんてやってないんだから。

責任は人選誤った編集部にある。
奴を責めるのはかわいそうだ。

480 :デフォルトの名無しさん:01/10/21 18:39
>>477
のリンク先を見ていて思うのだが
自分のことを天才(と周囲に思われている)という人間が書く文章は
どうして凡才以下の文章になるのだろうか?

不思議でならない。

あの一連の記事を読む限り天才さの微塵も感じないばかりが
技術者としてダメな所ばかり目立つ反面教師の姿しか見えない。

太った奴はあつかましくて自己中という事なのだろうか。


>>479
責任は文章を書いた本人にあるのではなく
それを書かせた社会が悪いとでも?

本人が書きたくもないのに、
ああいう趣旨の文章を無理矢理書かされたというのなら
そういう理論も通るだろうが。

481 :デフォルトの名無しさん:01/10/21 18:51
>イベント機能をCUIで利用するなんていうバカ見たことないな
そうか、>>475さんはこの文に対してのレスだったのですね、スマソ

ああいう単純なHallowWorld的サンプルで
イベント機能を紹介するというのはひどいという事が言いたかったのです。

482 :デフォルトの名無しさん:01/10/21 19:10
HallowWorldだって、はずかし!

Hell Worldにでも逝けってんだ。(藁

483 :デフォルトの名無しさん:01/10/21 21:24
人物論評するならプログラマ板でやってくれ。

484 :デフォルトの名無しさん:01/10/21 21:58
んーコスト意識の無い人達に生産性などと持ち出しても無駄だったか。
再利用が可能かどうかなんて話になってるし。

485 :デフォルトの名無しさん:01/10/21 22:03
誰こいつ

486 :デフォルトの名無しさん:01/10/21 22:03
要は You Aren't Going to Need It を説得力なく語った川俣が悪いと。

487 :デフォルトの名無しさん:01/10/21 22:20
また「OOは生産性が‥‥」って一人で言ってる奴が来たよ。
アンタ懲りずに毎度毎度同じネタばかりでウザイよ。

488 :デフォルトの名無しさん:01/10/21 22:26
>>415は間違いなく確信犯だな。

489 :デフォルトの名無しさん:01/10/21 22:28
>>486
説得力がないのではなく、彼は理解も何もしていない。
理解していないのに説得力など出るわけがない。

490 :デフォルトの名無しさん:01/10/21 22:35
じゃOO導入で何パーセントコストダウンしたんだよ?
死ね!

491 :デフォルトの名無しさん:01/10/21 22:44
「俺が書いたクラスは再利用性最高だぜ」っていうやつのコード見ると
「再考だぜ?」の間違いかと思われる事が多いから問題なんだよな。
実際自分以外の奴が素直に再利用しているクラスって書けてる?
「なんちゅう使い方してんだ、ゴラァ!!」と思っている奴、使っている奴も
きっと憤懣やるかたない気持ちで使っているんだと思うよ。

492 :デフォルトの名無しさん:01/10/22 01:36
マズ「再利用」ヲ定義セヨ。

493 :デフォルトの名無しさん:01/10/22 02:03
定義してやるからここに持って来い。

494 :デフォルトの名無しさん:01/10/22 02:39
http://slashdot.jp/article.pl?sid=01/10/21/0838203&mode=thread&threshold=

ここでも川俣さんは叩かれているようです。

495 :名無しヘタぐらまさん:01/10/22 11:28
>>478
ごめんなさい,川俣氏の理論が正しいかどうかはわかりません.
でも「イベントを使えば簡潔なソースになるよ〜」の説明としては
呪文のようなコードを見せられても説得力がありませんね.

>そのイベントの使い方は正しいですが
>その利点があの川俣氏のサンプルでわかりますか?
わかりません(笑).

496 :デフォルトの名無しさん:01/10/22 21:09
川俣さん関係は以降はこちらで続けましょう↓
★デブプログラマーってどうよ★
http://mentai.2ch.net/test/read.cgi/prog/1001686611/133-

497 :デフォルトの名無しさん:01/10/23 01:37
JavaとかC#みたいなOOLのプログラムエントリって、
どうして適当なclassの中に書くの?
class A { public static void main(...) {...} }
非常に気持ち悪いんだけど。

Javaで.jarに固めるときに、Manifestファイルを書くけど、
プログラムの起動はManifestにクラス名を記述するけど、
だったら、最初から プログラム本体+起動定義ファイルで起動するようにして、
実行は起動定義ファイルで記されたクラスのコンストラクタからでいいと思うんだけど。

498 :デフォルトの名無しさん:01/10/23 01:39
age

499 :デフォルトの名無しさん:01/10/23 01:44
>>497
テストコードを埋め込むためじゃないの?

500 :デフォルトの名無しさん:01/10/23 01:46
>>497
単独で実行してそのクラスの機能をテストするためのコードを main に書いたりする。

501 :デフォルトの名無しさん:01/10/23 01:48
499だけど、mainから始めるという仕様はどこから来てるものなのか?
C/C++の名残というだけの理由なんですか?

502 :デフォルトの名無しさん:01/10/23 02:04
まさにそうでしょ。
Java は C/C++ と見た目の互換性を考えて作られた言語だからして。

503 :デフォルトの名無しさん:01/10/24 17:46
データが入っているオブジェクト(dA)があります。
このdAに対し、処理を行うオブジェクトが3つあります。(mB,mC,mD)

dAはmBにより処理され、その結果をmCが処理し、そのまた結果をmDが
処理します。このとき、各処理の入出力はdAです。

dAのカプセル化を保持したままmB,mC,mDで処理できるのでしょうか?
dAのデータ部分はpublicにするしかないのでしょうか?

504 :503:01/10/24 17:48
Javaでは「MVC」とかで、なんか「表示する内容」と「表示」を担当する部分と
あと、もう一つ、何かをうまく分けてあると今月のCmagaに載ってたんで
なんかやり方があるのではないかと思いまして。。
よろしくお願いしますです。

505 :デフォルトの名無しさん:01/10/24 17:51
>>503

ワラタヨ

506 :503:01/10/24 17:53
>>505 すいません。いたってまじめです。。
クラス設計を知りたいと言わなかったのがいけないの。。?

507 :デフォルトの名無しさん:01/10/24 17:56
>>503
カプセルかも何も、
mB.func(dA);
mC.func(dA);
mD.func(dA);
じゃないの?

やりたいことが今ひとつわからん。

508 :デフォルトの名無しさん:01/10/24 18:02
>>506

安心しろ。
dAにgetter,setterがあるんだろ。
だったらカプセル化は保持されてると思われ。

509 :デフォルトの名無しさん:01/10/24 18:04
>>506
mBやmCやmDがdAのprivateなデータを操作するためのメソッドが
dAによって提供されていて、mBやmCやmDが必要なメソッドにアク
セスできればいいだけでしょ。

簡単なサンプルとしてはIteratorパターンなんかそうだよね。

510 :デフォルトの名無しさん:01/10/24 18:09
>簡単なサンプルとしてはIteratorパターンなんかそうだよね。

ハァ?

511 :デフォルトの名無しさん:01/10/24 18:14
>>510
処理とデータを個別にカプセル化するサンプルじゃよ。

512 :デフォルトの名無しさん:01/10/24 18:31
>>511

いや、だからカプセル化の簡単なサンプルで、
Iteratorパターンは出ないと思われるが。
どうでもいいけど。

513 :503:01/10/24 18:34
すいません。具体的なことを書きます。
ターゲットはJPEGの圧縮処理みたいなやつを想定しています。

画があってこれにDCTして量子化(Q)してVLCして圧縮データを得るわけですが、

画のデータを収めるクラス(Pic)があり、
DCTを行うクラス、Qのクラス、VLCのクラス、
そして圧縮データのクラス(Stream)を作ろうと思ってます。

んで、このとき、画のクラスの情報を隠蔽しつつDCTを行えるのか?という疑問です。

画のPicクラスにDCT、Q、VLCを集約し、機能を委譲すればいいかとも
思いましたがたとえばDCTには4種類ほどやり方があるのでどうやって
Picクラスに入れればいいか、そしてDCTクラスをどのように設計すればいいかが
わかりませんでした。
 言語はJavaです。よろしくお願いしますです。

514 :デフォルトの名無しさん:01/10/24 18:35
>>503
>dAのデータ部分はpublicにするしかないのでしょうか?
publicとprivateの間にJavaならパッケージスコープやインナークラスがあるし、
C++ならファイルスコープやインナークラス、そしてfriendがある。
publicにする必要はないぞ

515 :503:01/10/24 18:36
データがふらふら〜っとオブジェクト間を渡り歩く。
で、OOPなのでデータのオブジェクトはしっかり情報隠蔽したい。
・・・データ部分をさらけ出すのはしょうがないんですかね?

516 :デフォルトの名無しさん:01/10/24 18:58
Strategyパターンか。
getterを適切に作れば良いだけだと思うが。
ピクセル要素やピクセルフォーマットにアクセスできない画像クラスなんて
なんの役に立つんだ?
それを隠蔽する事になんの意味がある?

517 :デフォルトの名無しさん:01/10/24 19:03
C++ならStrategy抽象クラスに対してフレンド宣言して
そいつにprotectedでgetterを書く。
Javaなら画像と
同じパッケージに入れてgetterをpublic宣言しなけりゃ良いだけ。

518 :503:01/10/24 19:24
>>516-517
どもです。ストラテジーについて調べてみます!

>ピクセル要素やピクセルフォーマットにアクセスできない画像クラスなんて
>なんの役に立つんだ?
>それを隠蔽する事になんの意味がある?
すいません。OOPがよく分かってないもんで。。
原則に対する割り切り方がまだ分からないんです。。
「Javaの格言」読んだら「データはprivate! protectedも危ないぞ!」って
書いてるもんだから。。

>Javaなら画像と同じパッケージに入れてgetterをpublic宣言しなけりゃ良いだけ。
パッケージレベルでの情報隠蔽ってことですね?なるほど。。

また疑問が出てきたら質問させていただきます。どうもありがとうございましたです!

519 :デフォルトの名無しさん:01/10/24 23:04
StrategyだのIteratorだのはデザインパターンの話。
デザインパターンのスレ有ったと思うからそこみて本買うよろし。
おいらはVisitorパターンのような実装にするかな。

class Image {
CompressedImage compress(Compressor compressor) {
return compressor.compress(pixels, pixelFormat);
}
}

520 :デフォルトの名無しさん:01/10/24 23:14
>「Javaの格言」読んだら「データはprivate! protectedも危ないぞ!」って
例えばJavaのVectorクラス。
あれはメンバ変数にはアクセスできないが、
要素にはアクセスできるだろう?
メンバ変数を公開するのは(勝手に書き換えられたりして)危険だが
メンバ関数を通じてアクセスや操作させるように作れば問題無い。
Javaの標準ライブラリ見てそのへんを考えてみては?

521 :503:01/10/24 23:48
Strategyを見てみました。感想は、、なんかTemplate methodと
ほとんど同じのような気が。。理解が足りてないんでしょうか??
まぁ、これでどのようにして4種類のDCTを切り替えるかの方法が分かった気がします。
>>519 Visitorパターンですか。。これから調べてみます。どもです!

>>520 Vectorの例、なるほどです。
>要素にはアクセスできるだろう?
情報隠蔽とはまた違うことですが、(Vectorに格納されているオブジェクトどもは
情報隠蔽されたオブジェクトだから)
でも、その観点からも考えて見ます。

>Javaの標準ライブラリ見てそのへんを考えてみては?
標準ライブラリをほとんど知らないので。。勉強してみます。
(なにかお勧めのパッケージとかありますでしょうか?)

皆さん、どうもありがとうございますです。

522 :デフォルトの名無しさん:01/10/24 23:57
>>520
Vector のメンバ変数って何よ?

523 :520じゃないけど:01/10/25 00:14
>>522 ソース見ましょう。
protected Object elementData[];
protected int elementCount;
とか。
ところで新しめの似非VectorであるArrayListでは
上の2つ相当のメンバーはprivateになってる。

524 :デフォルトの名無しさん:01/10/25 00:19
>>523
というか、Java厨として C++ 用語を糾弾してみた。
フィールドまたはインスタンス変数と読んでほしい。

525 :520:01/10/25 00:23
あんまいい例えじゃなかったかな。

>>521
例えばあなたがVectorクラスを自作したとします。
おそらくメンバ変数としてObjectの配列を持つと思います。
これをpublicにするといつでも外から読み書きができてしまいます。
これによって、Vectorを使う側が勝手にVectorがやるような処理を
実装してしまうかもしれません。
しかもその処理がVector側の処理と矛盾があったりするかもしれません。
これではVectorを一つの独立したオブジェクトとみなして安心して使う事は
できません。Vector内部の処理、Vectorを使っている処理
すべてに注意を払いながらコーディングしなければなりません。

一方、このObjectの配列をprivateで宣言し、代わりに
pubic Object get(int index) このように任意の位置のオブジェクトを
取得するメンバを実装したとします。
するとVectorが内部にもつ配列自体には干渉できないので
配列に関する処理はすべてVectorのメンバ関数に頼ることになります。
このように実装されていれば配列の管理は外部から隠蔽されます。
Vectorは独立したオブジェクトとして安心して
使いまわすことが出来ます。

長文ですまんが雰囲気だけでも伝わるだろうか。

526 :520:01/10/25 00:26
>>524
そういう事かい!!
フィールド、メソッドって呼び方もよいが
メンバ変数、メンバ関数て呼び方のほうが法則性があって好きなんだYO・・

527 :デフォルトの名無しさん:01/10/25 00:46
メンバ変数、関数メンバじゃなかったっけ?

528 :デフォルトの名無しさん:01/10/25 01:39
んなこたぁない。

529 :デフォルトの名無しさん:01/10/25 01:49
メンバー稲垣

530 :デフォルトの名無しさん:01/10/25 01:52
データ隠蔽は手段であって目的ではない。
そこを勘違いして、公開属性を必ず悪と考えるのは間違い。
goto問題の轍を踏んではいけない。

その目的とは、あえて難しい言い回しをすれば、
「オブジェクトが交わした契約の履行」。
これを中心に考えるべきなのに、
データ隠蔽を中心に考えるのはよくない。

531 :デフォルトの名無しさん:01/10/25 01:56
Member稲垣は紅白にでるらしいゾ!

532 :デフォルトの名無しさん:01/10/25 01:59
すでにOO教徒のセントラルドグマと化していると思われ。

533 :デフォルトの名無しさん:01/10/25 17:09
>>521
Template MethodとStrategyって目的が全然違うと思うけど。

Template Methodは基本的に振る舞いは同じだが、細かいところで異なる
クラスを作る場合に、基底クラスのメソッドに振る舞いの大枠を作っておき、
振る舞いの違う分をprotecedなメソッド呼び出しにしておいて、それを
派生クラスでオーバーライドすることで振る舞いを替えられるようにする
パターン。

Strategyは動的にアルゴリズムを変更できるようにするパターン。
Template Methodと組み合わせることも可能。

534 :デフォルトの名無しさん:01/10/26 00:13
>>533

つまるところTemplateMethodはそのObjectのメソッド定義を変える必要があるので、
クラスのメソッドを実行時に差し替えたり
クラスすら放置してObjectのメソッドをいきなり差し替えたり
できる言語(例:ruby)でもなければ、静的な変化しか得られない。

一方Strategyはメソッド持ちObjectを差し替えれば済むことだから、
今目の前に有るObject(のクラス)すら変化させることが出来ない
困った言語(例:C++(藁))でもなければ、動的な変化がばんばんやれる。

勿論、クラスにハードコードしちゃうほうが便利
(いちいちObject増やすのもうざい)な場合も多いので、
両パターンの間に明白な優劣があるわけではない。
なにをどう作りたいか?によって使い分ければいい。

キーワードは「差し替え可能」だな。

というかデザパタの多くが、ある特定の部分を「差し替え可能」になっている
ってのが売りなわけだけど。
逆にいえばその外の部分が固定になってて不便する、というパターンも多いから、
どこが「差し替え可能」になってると嬉しいか?によって、使うパターンは選ぶべきもの。

535 :age:01/10/26 03:51
スイッチングメソッド
http://www.kame-net.com/jplop/PatternRepository/PatternBody/SwitchingMethod/SwitchingMethod.doc
…通常、振る舞いの切替りには別のオブジェクトが利用される。
本イデオムでは、そうでなく、メソッドを利用する。…(抜粋)

どうよ?C++向けだけど

536 :デフォルトの名無しさん:01/10/26 03:52
この手のスレのタイトル見て、いつも副作用逝って良し
派とかdeterminisitic computing逝って良し派の意見を
期待するんだが、、、、
中はいっつもCとかそれ系側からの単なる煽り文なのはなんで?

537 :536:01/10/26 03:55
激しく誤爆。すまぬ。

538 :待って:01/10/26 04:01
>determinisitic computing
これなに?

539 :デフォルトの名無しさん:01/10/26 04:06
なんか今更もう一つの方に書く気も萎えた...
ちなみにnondterminisiticはPrologとかだな。
スレ違いなのでsage。

540 :デフォルトの名無しさん:01/10/26 05:24
副作用はともかくnondeterministicだと良い事ってあるの?

541 :538:01/10/26 12:03
はじめて見た。
Prolog
http://www.kprolog.com/doc/ja/language.html
えぐい言語ですね.

542 :デフォルトの名無しさん:01/10/26 19:32
カットが宣言型言語としては不純だよな。

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)