なぜオブジェクト指向は嫌われているのか？2

1 ：仕様書無しさん：2007/07/13(金) 01:43:53

前スレ
なぜオブジェクト指向は嫌われているのか？
http://pc11.2ch.net/test/read.cgi/prog/1183255047/

電卓すらオブジェクト指向で開発できないPGがオブジェクト指向について
俺俺論を展開するスレです。では、よろしく。

2 ：仕様書無しさん：2007/07/13(金) 01:51:20

With great power comes great responsibility

3 ：仕様書無しさん：2007/07/13(金) 01:55:06

Its a reason why OO is hated

4 ：本当は３ ◆j70fNS91Fs ：2007/07/13(金) 02:51:53

…です！

なぜオブジェクト指向は賛否両論なのか
http://pc11.2ch.net/test/read.cgi/prog/1181318210/

5 ：仕様書無しさん：2007/07/13(金) 23:14:16

名詞だよ名詞。
名詞にやらせたいことを決めるのがオブゼクト指向。

6 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/07/14(土) 12:45:44

検証の結果OO厨は使えないということが確実になりました

7 ：仕様書無しさん：2007/07/14(土) 13:30:04

まともなOO設計者なんか、会ったこと無いんだけど。

たいていは「パターンの適用」とか「疎結合」とかやたらこだわる奴。
こだわってたくさんクラスを作ったけど、それらを破綻しないように
慎重に協調させて動かすという、なんのためのオブジェクト指向なんだか
よくわからない職人技的な世界になっていて、しかもそういう設計が
できることに妙な優越感を持ってたり。

最悪なのは、クラスひとつひとつは汎用性があっても、それらを
組み合わせて実現できるのは、結局ひとつの機能だけ、という
タコな設計が多すぎ。
ひとつの機能追加だけで、大量に新規クラスを追加するハメになる。

プログラミング経験が浅く、センスが養われてない奴が設計しても、
汎用性とか開発効率とかの向かうベクトルが、見当違いなんだよね～。

8 ：仕様書無しさん：2007/07/14(土) 13:43:33

まともなＯＯ設計者に育つ為には何が必要？
広い視野、長い目、深い想像力とか？
手本にすべき良いクラスライブラリやフレームワークのソースコード？
それらの背景にある思想？

9 ：仕様書無しさん：2007/07/14(土) 15:03:01

>>8
おじゃぱさまのような先見性のある先輩だと思う。

10 ：仕様書無しさん：2007/07/14(土) 15:16:43

オブジェクト指向に必要なのは
・シンプルを好むこと
・美しさを追求すること
・一貫性、対象性を意識すること

11 ：仕様書無しさん：2007/07/14(土) 15:35:33

>>8
>まともなＯＯ設計者に育つ為には
会社にココ電、おじゃばさまのような反面教師がいれば、まともなＯＯ設計者が育つ

組み合わせて用いるクラスは疎結合に努め、そして、疎結合同士が連合したときにクラスによる多態を実現できるようにする
（間にインターフェースクラスを入れるのは、OK)
そうしないと、プロジェクト毎に同じようなクラスを作る羽目になり、>>6の結果になる。

12 ：仕様書無しさん：2007/07/14(土) 17:17:07

例えば、リエントラントを理解してるしてないだけで、
設計者の技量は分かる。知らなかった香具師は...

13 ：仕様書無しさん：2007/07/14(土) 17:22:28

例えば、デッカーのアルゴリズムを理解してるしてないだけで、
設計者の技量は分かる。

14 ：仕様書無しさん：2007/07/14(土) 17:25:03

このスレでは、ほとんどが理解していないと思う。

15 ：仕様書無しさん：2007/07/14(土) 17:30:37

（ ´,_ゝ｀）バカ？

16 ：仕様書無しさん：2007/07/14(土) 17:32:38

goto 15

17 ：仕様書無しさん：2007/07/14(土) 19:23:23

話題沸騰ポットってどうよ。

18 ：仕様書無しさん：2007/07/14(土) 19:34:39

>>12
組み込み屋ならリエントラントとか知らずに使えて当たり前。
普通にOOPだのソリューションだの言う人には無縁じゃないか。

19 ：仕様書無しさん：2007/07/14(土) 21:29:41

>>18
基礎的なことも学習していないような態度では
オブジェクト指向は学べないということ。では？

20 ：仕様書無しさん：2007/07/14(土) 21:37:01

オブジェクト指向はピンな技術ではないからね。
基礎がないとオブジェクト指向は嫌いになる。

21 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/07/14(土) 21:38:12

>>9
ひどい自演を見た

22 ：仕様書無しさん：2007/07/14(土) 21:46:48

オブジェクト指向はプログラマの自衛手段。
プログラマが自衛して生存率を高めると単価が抑えられなくなるので嫌われるのさ。

23 ：仕様書無しさん：2007/07/14(土) 22:01:06

今度のＪａｖａプロジェクト
オブジェクト指向してみるか迷う。
オブジェクト指向しなければ確実に成功するだろうけど
それでいいのか自問自答の日々（現在二日目）

24 ：仕様書無しさん：2007/07/14(土) 22:04:52

>>18
知らずに使えてるのと、知ってて使ってるのはぜんぜんちがうだろ。

25 ：仕様書無しさん：2007/07/14(土) 22:05:09

現状のスキルで確実に成功できるときにリスクとらないで、
現状のスキルではどうなるかわからないってときに、
取れるだけのリスクとるんだもんなあ
そりゃデスマも無くならんわ

26 ：仕様書無しさん：2007/07/14(土) 22:17:41

>>24
リエントラントプログラムについては
そういう呼び名だったんだ？
と用語を知ってからその概念というか定義みたいな物を知った。

知らずにいつの間にか使えてるというか、出来ないと仕事の遂行が
難しいという感じなテクニックだと思う。

OOも何時かはそういう感じになる日がやってくるんだろうね。

27 ：仕様書無しさん：2007/07/15(日) 02:10:16

普通にやってれば、
グローバル変数を使うなってのと同じように
リエントラント＝静的データを保持しないってのは思いつく。
別にOOだからって話ではないし、
スパゲッティコードを嫌う奴なら言葉を知らずとも
自ら考えてるはず。

でもこういう考えを全員が持ってないのがきついんだよな

28 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/07/15(日) 02:22:03

そして電卓さえ作れない

29 ：仕様書無しさん：2007/07/15(日) 03:04:06

抽象データ型無しのプログラムなんて思いつかないわけだが

30 ：仕様書無しさん：2007/07/15(日) 03:37:09

インターフェースの概念はある程度習熟してないと発想できんかもしれん。
不便だとかめんどくさいだとかの感覚が無いと
便利さもわからんかも。

31 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/07/15(日) 06:47:52

あほか
Cの関数宣言でとっくの昔からあるわ

32 ：仕様書無しさん：2007/07/15(日) 07:28:08

>>26
>知らずにいつの間にか使えてる

バグ発生時にデバッグ範囲限定できるし
処理の連結切り替えとか、部分的な拡張(VerUp)も楽だし
言葉を知らなくても、かなりの人が利用してる仕組みだろうね

ロジックとデータを明確に分離しておくと保守管理しやすいし

33 ：仕様書無しさん：2007/07/15(日) 10:29:51

自然に使えていることと
それを概念として捉えるようになることでは
差がある

例えば、
火とか熱を使えることと、
それをエネルギーという概念で捉えることでは
差がある。

概念として捉えることで、他の分野とも共通性を見つけることができると思う

34 ：仕様書無しさん：2007/07/15(日) 10:56:07

オブジェクト指向が理解できないのは、
オブジェクト指向がこれだけで完結した技術だと勘違いしているから。

35 ：仕様書無しさん：2007/07/15(日) 10:57:45

仕事でやるプログラムなんて
きっちり考えてやるだけ無駄
他人があとで助かるなんてむしろムカつくだけじゃん

36 ：仕様書無しさん：2007/07/15(日) 11:01:34

なんで他人？自分じゃないの？

37 ：仕様書無しさん：2007/07/15(日) 11:17:31

下請けさん

38 ：仕様書無しさん：2007/07/15(日) 14:14:30

>>35
別のプロジェクトで作ったドキュメントを、自分が参考に出来るかも知れなくね？

39 ：仕様書無しさん：2007/07/15(日) 16:49:14

オブジェクト指向でプログラムするようになってから
複雑な動作をするプログラムを作らなくなって(メリット面ね)
複雑な動作をするプログラムを作るのが億劫になってきたorz...
昔は平気で簡易インタプリタ言語くらい作れたのに今では...

40 ：仕様書無しさん：2007/07/15(日) 17:05:50

>>28
仕様はこんな感じで良いんですかい？
ttp://lecture.ecc.u-tokyo.ac.jp/~ktanaka/programming05/calc.html

41 ：仕様書無しさん：2007/07/15(日) 17:11:39

インタプリタってどうやって作るの？

42 ：仕様書無しさん：2007/07/15(日) 17:20:10

おまいらの実力では>>40の東京帝國大学の問題出来ないだろ
こんな難しい問題を解かせるなんて、さすが、東京帝國大学だ

43 ：仕様書無しさん：2007/07/15(日) 17:24:52

>>42
笑うところなのか、切実な問題なのか…

44 ：仕様書無しさん：2007/07/15(日) 17:44:02

>>42が釣りだとしても
こういう奴は少なくないんだろうな。
マイナス工程要員は邪魔でしかない。

45 ：さっさと死んだら?：2007/07/15(日) 17:47:22

学部実習持ち出してきて
あの内容を「仕様」と言い出すとは
どんだけキチガイなんだ

46 ：仕様書無しさん：2007/07/15(日) 17:50:13

まあそう責めるな。

キチガイの人は、キチガイなりに
誰かに構ってもらいたくて必死なんだよ・・・
無視が一番

47 ：仕様書無しさん：2007/07/15(日) 17:58:08

>>41
コンパイラを学習すればできる。

48 ：仕様書無しさん：2007/07/15(日) 17:58:54

>>39
簡易インタプリタ言語って複雑じゃないでしょ。

49 ：仕様書無しさん：2007/07/15(日) 18:00:27

OOと関係ない話題が以下９５０レス続く

50 ：仕様書無しさん：2007/07/15(日) 18:12:44

やっぱ、東京帝國大学の問題解けないんだ

>>41　言えることは、OOでは出来ないってこと

51 ：仕様書無しさん：2007/07/15(日) 18:24:21

インタプリタパターンでインタプリタってつくれないのー？

52 ：仕様書無しさん：2007/07/15(日) 18:33:35

********************
キチガイ自作自演スレ
********************

53 ：仕様書無しさん：2007/07/15(日) 18:35:54

ココに粘着してる奴
まさか大学も出てないとは
哀れなり

54 ：仕様書無しさん：2007/07/15(日) 18:57:09

このスレは、

キチガイがオブジェクト指向について、キチガイ論を展開するスレになりました。

>>53　大学出ならこんなスレ来ないよ。大学出てOO使いこなせないんじゃバカにされるだろ
高卒の俺でもバカにするよ、大学出てるのにエライ低能だなって。お前も出てないんだろ。

55 ：仕様書無しさん：2007/07/15(日) 19:12:14

>>54
おまいはオブジェクト指向をばりばり使えてるということを自負している方ですか。
ちなみに学歴は関係ないな。

56 ：仕様書無しさん：2007/07/15(日) 19:32:33

>>55
全然使えないと自負している高卒ドカタです。

57 ：仕様書無しさん：2007/07/15(日) 19:48:48

オブジェクト指向開発・設計って、C++が主流となった時分（10年ぐらい前？）から常識的な手法だろうから
当然、その時分より大学はオブジェクト指向開発・設計の基礎・応用位まで教えてるんじゃないの？

どうなの、間違ってこのスレに来たエロイ大卒PG様？

58 ：仕様書無しさん：2007/07/15(日) 20:58:34

とりあえずJavaのI/O系のクラス構造から勉強すれば
オブジェクト指向がなんとなく理解できると思うよ。
おまいらは。

59 ：仕様書無しさん：2007/07/15(日) 21:57:07

最近はガンダムまでOOになってるんだな。

60 ：仕様書無しさん：2007/07/15(日) 23:10:46

Googleで、"逝った"で検索してみよう!

61 ：仕様書無しさん：2007/07/15(日) 23:24:31

OOっとなんていうことだ
OOどろいたよ！

62 ：仕様書無しさん：2007/07/16(月) 00:15:05

アルゴリズムを考えるのは数学的センスが必要だけどオブジェクト指向するには分類学的センスというまた別のセンスが必要だと思うんだ。

63 ：仕様書無しさん：2007/07/16(月) 00:22:37

オブジェクト指向設計を理解してるってんなら、
「なぜオブジェクト指向で開発しなければならないのか」って問いに答えられるはずなんだが…

このスレの奴には無理そうだな

64 ：仕様書無しさん：2007/07/16(月) 00:24:39

何を難しく言ってるのが分からん。
業務を構成してる物をピックアップして
性格と動作を考えるだけだろ。

OOが嫌われてるというよりも、
「オブジェクト指向」って名前に拒否してる無学連中が多いため
理解してる奴とそうでない奴の温度差が激しく、
現場の統制が取れないってのが現状。

65 ：仕様書無しさん：2007/07/16(月) 00:38:45

俺は使えない
人間として

66 ：仕様書無しさん：2007/07/16(月) 00:41:38

>65は人間として使えないことは分かった

67 ：仕様書無しさん：2007/07/16(月) 00:49:31

なんだと人間として使えないんだぞ
宇宙人としてなら紙扱いなんだぞ！

68 ：仕様書無しさん：2007/07/16(月) 00:56:30

オブジェクト指向はそれほど嫌われてないだろう。
デザパタ厨などのアホどもが嫌われているだけさ。

69 ：仕様書無しさん：2007/07/16(月) 01:08:01

>>65
お前は人間どころか豚としても使えない

70 ：仕様書無しさん：2007/07/16(月) 03:03:31

>>63
保守性・再利用性等に優れたものを作れるから。
ただし、保守・再利用するヤツもOOに精通していなきゃ意味ないだろうな。

もし、全てのプログラマがOOを理解していたとしたら、OOが嫌われることは早々なかっただろう。

71 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/07/16(月) 03:13:03

インタプリタはテキストから単語を一個ずつ読み取ってコマンドと数値（や文字）を拾ってきて　処理ルーチンにまわすだけ

72 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/07/16(月) 03:18:22

OOが嫌われてるというよりも、
「オブジェクト指向」って名前でハッタリかましてる連中が多いため
理解して使わない奴とそうでない奴の温度差が激しく、
現場の統制が取れないってのが現状。

73 ：仕様書無しさん：2007/07/16(月) 03:27:19

>>70
再利用性はまた別の問題だがな。

74 ：仕様書無しさん：2007/07/16(月) 05:29:50

腐った設計のオブジェクト指向ば昔のＢＡＳＩＣのスパゲティ構造より
闇である。
つまり、どんなものでも設計が腐っていれば糞だということ。

特にＯＯは職人でも解析不能レベルまでありえる。

75 ：仕様書無しさん：2007/07/16(月) 08:22:14

>>>63
>保守性・再利用性等に優れたものを作れるから。
>ただし、保守・再利用するヤツもOOに精通していなきゃ意味ないだろうな。

こういう事言う奴はわかってないわな。
構造化設計の何がダメで、オブジェクト指向設計はそこをどういうふうに補完してるのか説明できなきゃ。
オブジェクト指向開発するなら全ての開発者がきちんと理解してて欲しいことなんだがね。

76 ：ここに張り付いてるキチガイの自己紹介ページ：2007/07/16(月) 08:58:52

○解説
　・一言居士。奇矯な意見多し。反駁されても返事なし。
　・拉致ネタに強い、というかサピオの丸写しを唱えてる。(2002/09)
　・経済ネタにも首を突っ込む
　・サピオは殆ど読んでないぞゴルア　ネタは中公新書とか。
　・典型的２ちゃんねらー。いつも誰かを叩いている。
　・主戦派。俺が正義。
　・最近カルシウムを摂取するようになった。
　・愛称でモコ君と呼ばれている(U・ェ・Uいぬ)
　・容姿は山城新伍に似ている（自己申告によると）。(王様)
　・軍オタ。旧日本軍のことについて詳しい。
　・ココ電逝ったぁぁぁああああああああ
とは明日の日経平均が下がりそうだという意味の２ちゃん語

　・円高・円安を理解せず、ロング・ショートも知らず、受け売りの知識をひけらかすアフォ
　・建設株を仕込んでいるらしい
　・円高円安は濡れ衣です

　619 ：ココ電球 ◆OMXTGV5oE6 ：03/09/20 19:22
　円高？ちょっと前まで１ドル１１５円だったじゃん。
　１ドル１１５円が１１３円台に下がったのだから
　円安じゃないの。みんな勘違いしてないか？
　・まだ逝ってないのか？（王様）
　・よくわからんが、割と長生きしそうなおじさん

77 ：仕様書無しさん：2007/07/16(月) 09:16:55

おいおい、電球の円安ネタってマジかよ
中学生でも分かることを・・・

78 ：仕様書無しさん：2007/07/16(月) 10:00:46

>77
ちょｗｗｗ円安ワロタｗｗｗ

79 ：仕様書無しさん：2007/07/16(月) 13:31:06

ちなみに韓国では円高円安が日本と逆なんだそうな。

80 ：仕様書無しさん：2007/07/16(月) 14:22:09

なぜオブジェクト厨は勤勉ぶれるのか？

81 ：仕様書無しさん：2007/07/16(月) 16:10:46

そもそもコストラクタで属性変更で済むものを
わざわざ派生クラスを大量につくるような設計
する香具師ばかりなんだからさ。現場はさ。
派生クラス１０００個とか。びっくりさ。

82 ：仕様書無しさん：2007/07/16(月) 16:25:34

火が悪いんじゃなくて、火を使いこなせず火事おこしちゃうヤツが悪い。
それを火が悪い、火が悪いと叫ぶ原始人たち。噴飯ものである。

83 ：仕様書無しさん：2007/07/16(月) 17:09:10

>>81
そういうの、いるよな。

84 ：仕様書無しさん：2007/07/16(月) 17:33:52

>>81-83
自己紹介乙！
自分だけじゃなくて安心した？

85 ：仕様書無しさん：2007/07/16(月) 17:43:39

　　 ∧＿∧　
　　（　´∀｀）
　　（　　　　）
　　｜｜　|
　　（_＿）＿）

86 ：仕様書無しさん：2007/07/16(月) 20:53:32

さぁ、明日からは素直になって、勉強しなおそうや。

87 ：仕様書無しさん：2007/07/16(月) 20:58:50

オブジェクト指向の極意はシミュレーションにあり。

88 ：仕様書無しさん：2007/07/16(月) 22:27:16

| ∧ 　　　　　　　∧
|/　ヽ　　　　　./ .∧
|　　｀､　　　　　/ 　 ∧
|　　　￣￣￣　　　　ヽ
|￣　　　火曜日　　　￣）
|￣￣￣￣￣￣￣￣￣.＼
|ヽ-=・=-′　ヽ-=・=-　　/ 　明日からは素直になって、勉強しなおそうや。
|:: 　　＼＿＿_／　　　　/
|:::::::　　　＼／　　　　　/

89 ：仕様書無しさん：2007/07/16(月) 22:32:13

　　　　　 ⊂ ⊂ヽ、　　/）/）
　　　　　ｃ､　　`っ（　　ヽ
　　　　　　　　（　　　v）ｃ、　`っ　
　　　　　　　　　V''V　（　　　ｖ）　 /￣`⊃
　　　　　　　　　　　　　　 V''V　　　|　　⊃　　　　　
　　　　　　　　　　　　　　　　　　　（　　　v）　　ﾊ,,ﾊ　　
　　　　　　　　　　　　　　　　　　　　 V''V　　（ﾟωﾟ　）　　　
　　　　　　　　　　　　　　　　　　　　　　　　　 ⊂⊂　ヽ
　　　　　　　　　　　　　　　　　　　　　　　　　　 >　　　）
　　　　　　　　　　　　　　　　　　　　　　　　　　(／(／

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　ﾊ,,ﾊ
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（ﾟωﾟ）　お断りします
　　　　　　　　　　　　　　　　　　　　　　　　　　　　((⊂ﾉ　　ヽつ ))　　お断りします
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（＿⌒ヽ　
　　　　　　　　　　　　　　　　　　　　　　　　　　ε≡Ξ　ﾉノ｀J

90 ：仕様書無しさん：2007/07/17(火) 00:15:33

>>69
なんだてめーは狂牛病ダンボールの癖に

91 ：仕様書無しさん：2007/07/17(火) 00:17:12

>>75
だってお本でしったかちしきをいかにもここでカキコするのがこのスレだからだもーん

92 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/07/17(火) 01:34:50

あほ
ＩＤが違う捏造レスだよ

93 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/17(火) 09:56:41

OOの設計を根本的に間違えている場合が多い。
OOと言うのは修正しても劣化しないのを基本としているため、構造化のように最初にきっちりと設計
しなくてもいいようになている。
つまり最初から拡張性を考えなくていい。OOの基本方針に従ってクラス分けすればいい。
最初から多段継承を考えて設計するのは間違いだ。最初は使っても1段ぐらいだろう。
コンストラクタのパラメータ変更で済むなら、それに修正すればいいんじゃないか？
なんで派生クラス1000個にしてるんだ？

94 ：仕様書無しさん：2007/07/17(火) 10:48:14

>>91
>だって　お本で　しったか　ちしきを　いかにも　ここで　カキコ　するのが　この　スレ　だから　だもーん
これは難解。「お本で」と「いかにも」は何処に掛かるんだろう…

95 ：仕様書無しさん：2007/07/17(火) 13:20:56

おじゃばの話はいつも「なぜ構造化と違ってそうなのか」
ちう説明がないから、納得のしようがない。
説明しろ、と言うとOOを勉強しろ、と返ってくる。
そんな発言に意味があるのだろうか。
啓蒙ってもなー全然逆効果っぽいしなぁ。

あ、そうか自分だけ知ってるOOを皆がやるとまずいwから、
やる気を無くすように仕向けてるつもりなのか！
ある意味成功してるかもしれん。

96 ：仕様書無しさん：2007/07/17(火) 15:10:02

> OOと言うのは修正しても劣化しないのを基本としているため、

意味不明。

> 構造化のように最初にきっちりと設計しなくてもいいようになている。

例を示せ。

97 ：仕様書無しさん：2007/07/17(火) 20:44:10

修正時に劣化しないとは限らんし、
設計については構造化よりも知識・経験が必要。

ってのが一般的な見解ではないかなぁ

98 ：仕様書無しさん：2007/07/17(火) 20:46:18

>>93
> なんで派生クラス1000個にしてるんだ？

「最初から拡張性を考え」ず、「構造化のように最初にきっちりと設計」してない
クラス設計を押し付けられた現場では、アホ設計者相手に議論する気もないので、
なるべく与えられたものは手をつけずに、派生クラスやらアダプタクラスやらで
なんとか完成させるのさ。それが糞だと充分知りながら。

99 ：仕様書無しさん：2007/07/17(火) 21:42:54

派遣請負の書き逃げコード。
アーキテクト不在。

100 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/17(火) 22:18:34

>>95
勉強しろなんて言ったかな？相当、的外れでない限り、いつも丁寧に教えているだろう。
多分説明が足りないように見えるのは、俺が過去に発言した内容を知らないためだろう。
俺も誰がどこから読んでいるのかは分からないからな。

ではまず、構造化が仕様変更によってどのように劣化するかから行くか。
毎回俺が説明しても面白くないので、誰かに答えてもらおう。
「構造化のソースが仕様変更で劣化する例」分かる人いるか？
俺が以前に「if分の追加」で説明しているし、構造化プログラミングの問題点としては、
昔から言われている有名な事だから、知っている人も多いと思う。
さあ、分かる奴はいるか？

101 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/07/17(火) 22:19:46

おじゃばが馬鹿なのは判った

102 ：仕様書無しさん：2007/07/17(火) 22:26:25

ということで、おじゃばさまが構造化プログラミングの問題点を教えてと
彼らしい依頼法で皆様にお願いしてます。誰か、教えてやれ。

103 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/17(火) 22:32:17

>>96
>意味不明。
「基本」→「基本構造」で分かるかな？

>例を示せ
例えば設定情報を読み込む処理があるとする。構造化の場合はそれが、ファイルなのかDBなのかによって、
処理が大きく変わるので作りにくい。レコードリードのループが処理の真ん中に入るので、
ファイルからDBに変わったら作り直しに近い。
OOの場合は、Propertyクラスみたいのをとりあえずファイル対応で作っておけば、
後からDBや環境変数から取って来るように変わっても、修正はPropertyクラスのみで良い。

>>97
プログラミング知識は97の言う通りだが、俺の言っているのは業務知識。

>>98
修正が簡単なOOで、最初の設計に固執する必要はない。
本当にコンストラクタのパラメータで対応出来る内容なら、簡単に修正出来るはずだ。
最初の設計に固執する「構造化」の癖が抜けてないだけだろう。

104 ：仕様書無しさん：2007/07/17(火) 22:48:44

すいません、基本となるクラスの設計って普通は誰がするの？
アーキテクト様、SE様、PGリーダー様、PGドカタ連中....
で、あなたは基本クラス設計してますか？

105 ：仕様書無しさん：2007/07/17(火) 22:57:14

PGドカタがやりますよ

106 ：仕様書無しさん：2007/07/17(火) 22:58:03

PGドカタだな

107 ：仕様書無しさん：2007/07/17(火) 23:00:11

基本クラスって何かよくわからんけど、まあドカタがやるだろ

108 ：仕様書無しさん：2007/07/17(火) 23:24:48

えーっ、ということは、MFC、VCL、java、.NETのクラスライブラリをPGドカタレベルで設計（実装）できるってことですね
日本のPGドカタってすごいんですね、これからPGドカタ様と言わなきゃならないですね。

109 ：仕様書無しさん：2007/07/18(水) 00:31:32

おれがひろめたおじゃばさまをこてにしやがったな

110 ：仕様書無しさん：2007/07/18(水) 00:34:08

重くねスレの痛い奴か？

111 ：仕様書無しさん：2007/07/18(水) 00:36:24

何ｄそのスレは？

112 ：仕様書無しさん：2007/07/18(水) 00:45:35

>処理が大きく変わるので作りにくい。レコードリードのループが処理の真ん中に入るので、
ファイルからDBに変わったら作り直しに近い。

別に構造化設計だってレコード読みに行くところを関数にしてれば同じじゃん
バカなの？

113 ：仕様書無しさん：2007/07/18(水) 00:51:21

バカなの

114 ：仕様書無しさん：2007/07/18(水) 00:59:13

です

115 ：仕様書無しさん：2007/07/18(水) 01:11:02

OOだから修正が簡単になるんじゃなく
修正が簡単になるように設計してるから修正が簡単になるんだよ

116 ：仕様書無しさん：2007/07/18(水) 01:26:53

おじゃばの論法は全て、
構造化の場合は設計がダメダメ
という前提のもとで話をするからおかしくなる。

要するにソースを基準とした論調なんだが、
ソースに業務設計を投影するバカはいない。

> >>97
> プログラミング知識は97の言う通りだが、俺の言っているのは業務知識。

こんなことを言い出す時点で矛盾が生じてるんだよ。

117 ：仕様書無しさん：2007/07/18(水) 01:35:32

円安の間違いを人違いと逃げる奴。
前提条件がめちゃくちゃなOO凶徒。
どっかまともなコテハンいないの？

118 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/18(水) 08:36:41

>>112
これも何回も説明しているが、的確に変更箇所を予測していれば、構造化でも影響が少ない。
つまり、DBになる事を予測して関数にしていれば、問題は少ないだろうが、予測していなければ変更は
多くなるし、予測が間違っていれば無駄な処理になる。
OOの場合は標準で全ての単位（クラスから機能まで）で抽象化するため、予想する必要がない。

>>115
JavaでもC++でも修正が難しくなるように書くことも出来る。
OOの基本（抽象化）を正しく守っていれば、修正が簡単になる。

119 ：仕様書無しさん：2007/07/18(水) 09:39:24

>>118
抽象化を正しく守っていても、すべての仕様変更に耐える実装は不可能だろ。
前の例で言えば、ファイルからDBじゃなくネットワーク越しに情報を読み込むような仕様変更の場合、
OOでもはたして修正は簡単かな？

120 ：仕様書無しさん：2007/07/18(水) 10:02:18

>>103
「OOと言うのは修正しても劣化しないのを基本構造としているため」
修正して劣化する、の意味が不明。
何をどう修正すれば、どうなるのか。なぜそれを劣化と呼ぶのか。

> >例を示せ
> 例えば設定情報を読み込む処理があるとする。構造化の場合は…作り直しに近い。
> OOの場合は、Propertyクラスみたいのをとりあえずファイル対応で作っておけば、
> 後からDBや…修正はPropertyクラスのみで良い。

その程度のことを例に挙げて、

>>118
> OOの基本（抽象化）を正しく守っていれば、修正が簡単になる。

などと言うのなら、

「構造化の基本を正しく守っていれば、修正が簡単になる。」

と言えるだけのこと。再利用可能な関数を準備するのは、
当たり外れの予測に頼ったものではなくて、構造化の基本。

121 ：仕様書無しさん：2007/07/18(水) 11:55:48

ある程度設計を洗練させる為にもプロトタイプ（たたき台）が必要だと思う。
いきなり本番では試行錯誤も出来ないだろ。

122 ：仕様書無しさん：2007/07/18(水) 14:26:59

おじゃばは「理解してる」と自分では言うが、
OOと比べるための構造化の欠点しか見てないよな。
構造化とそうでないプログラミングとの違い、
その上で構造化の欠点とOOの利点、ちう言い方をしないと説得力がない。
おじゃばの言い方だと
「OOは行き当たりばったりにお手軽に作れて、変更に強くてほどほどの性能が出るのが利点。クリティカルなもんには向かないよん」
つことになりそうなんだけど、それでいいのかな？＞他のOO推進派

･･･ここにそんな奴はいそうもないけどな。

123 ：仕様書無しさん：2007/07/18(水) 20:18:56

アジャイルな構築方法とＯＯを混同してるだけ。

124 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/18(水) 21:53:43

>>116
業務を知らなければ、まともなプログラムは書けない。特に構造化ではそうだ。

>>119
確かに全ての仕様変更に耐えるのは不可能だ。
しかしネットワーク越しに読み込む程度の修正なら簡単に出来る。それ以前にJavaでは標準で出来る。

>>120
劣化と言うのはスパゲッティープログラム化する事を言う。具体的に言うと、if文が増える事だ。
また120も構造化プログラマなら、苦労してモジュール化した機能だが、結局1通りでしか使わなかったとか、
苦労して共通化した関数だが、結局自分しか使わなかったとかないか？

>>121
サンプルがあればいいに越した事はない。I社やN社のミドルウェアは結構いいのが多いから、
見る機会があれば参考にするといい。

125 ：仕様書無しさん：2007/07/18(水) 21:59:20

自分しか使わなくても2回使えば元は採れてるじゃーん
自分が2回しか使わないからってコピペでいいわけじゃあるまいし

126 ：仕様書無しさん：2007/07/18(水) 22:47:56

6809から始めたおいらはオブジェクト指向の正統派。

127 ：仕様書無しさん：2007/07/18(水) 22:50:16

>>126
何それ(-｡-)

128 ：仕様書無しさん：2007/07/18(水) 22:51:39

FM-7もういっかいつついてみたいなぁ

129 ：仕様書無しさん：2007/07/18(水) 22:56:11

YAMAUCHI知ってるおいらはオブジェクト指向の貴公子。

130 ：仕様書無しさん：2007/07/18(水) 23:02:00

デザインパターンって26種類覚えればいいの？

131 ：仕様書無しさん：2007/07/18(水) 23:04:14

>>130
覚えるのではない！
感じるのじゃ。

132 ：仕様書無しさん：2007/07/18(水) 23:05:49

ポジションインディペンデントこそオブジェクト指向の神髄。

133 ：仕様書無しさん：2007/07/18(水) 23:10:26

>>130
感じれ。
ttp://www.hyuki.com/dp/cat_index.html

134 ：仕様書無しさん：2007/07/18(水) 23:24:17

>>126
AM2901から始めた和紙は、LSI設計の鬼

135 ：仕様書無しさん：2007/07/18(水) 23:41:14

つか、おじゃばはAOPとかどう思ってんの？

136 ：仕様書無しさん：2007/07/18(水) 23:48:28

デザインパターンをなんか表面だけなぞってるアホも多いから注意しろよ。
ファクトリーメソッドとアブストラクトファクトリーの違いもわからず
ファクトリーパターンってごっちゃにした挙句、
生成を隠蔽するとか全然わかってないことを偉そうに吹聴する恥ずかしい奴になるなよ。

137 ：仕様書無しさん：2007/07/18(水) 23:50:37

>>130
の言う 26 種類って、どのパターンを指しているの？

138 ：仕様書無しさん：2007/07/18(水) 23:53:14

機能定義できていないのに、とりあえずOOで作れとかいうSﾖを一言で黙らせるにはどうすればいいの？

139 ：仕様書無しさん：2007/07/18(水) 23:55:50

ガワだけ作って、はい出来ました。

140 ：仕様書無しさん：2007/07/18(水) 23:58:30

アジャイルなプログラミング方法を取ればいいだけ。
それはオブジェクト指向とは直接関係無いんだけどね。

141 ：仕様書無しさん：2007/07/19(木) 00:30:37

>>138
機能未定義クラスとか
業務仕様不明クラスとかガシガシ作ったれ！

142 ：仕様書無しさん：2007/07/19(木) 00:33:33

オブジェクト指向理解してる人に、是非開発工程をうｐしてもらいたい。

XP開発手法は写真付きで解説してあるけど

143 ：仕様書無しさん：2007/07/19(木) 00:44:06

48種じゃないのか?

144 ：仕様書無しさん：2007/07/19(木) 00:49:03

４８手、だろｗ

145 ：仕様書無しさん：2007/07/19(木) 00:50:49

おじゃばのようなオレサマOO独自見解をそれぞれが言い出したら
それこそまとまらんな。
つーか、OOも構造化の一種だということを分かってねーから
意味不明なんだよ。

146 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/07/19(木) 01:24:46

>>134
F8からはじめた(ry

147 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/07/19(木) 01:25:46

まてよ
それってビットスライスCPUだっけ？
それは触ってないなあ。
７４１８１なら触ったけど

148 ：仕様書無しさん：2007/07/19(木) 01:37:21

オブジェクト指向設計は構造化設計じゃないよ。

149 ：仕様書無しさん：2007/07/19(木) 01:44:44

オブジェクト指向設計は構造化設計をより抽象的にしたものだよ

150 ：仕様書無しさん：2007/07/19(木) 06:54:57

オブジェクト指向設計は抽象データ型を中心にソフトウェアを設計する方法論だよ。
構造化設計とは直交してる概念だよ。

151 ：仕様書無しさん：2007/07/19(木) 07:49:34

オブジェクト志向設計は構造化設計を前提にしているが

152 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/19(木) 08:03:51

>>122
OOは構造化の欠点を補う用途で使われる場合が多いので、構造化の欠点→OOの利点で説明している。
>「OOは行き当たりばったりにお手軽に作れて、変更に強くてほどほどの性能が出るのが利点。
>クリティカルなもんには向かないよん」
その通り。

>>123
プログラム技法の話をしているので、開発技法とは関係ない。

153 ：仕様書無しさん：2007/07/19(木) 08:06:08

>>152
いいからサンプルうｐれよ

154 ：仕様書無しさん：2007/07/19(木) 14:31:40

> それらを破綻しないように慎重に協調させて動かす

「疎結合」と言いながら、「密結合」に作る人はいるね。

> 最悪なのは、クラスひとつひとつは汎用性があっても、それらを
> 組み合わせて実現できるのは、結局ひとつの機能だけ

粒度が細かすぎる設計をする人はいるよね。

何でも出来る = 何もできない
だってことなのに。

155 ：仕様書無しさん：2007/07/19(木) 21:19:06

おれは、おじゃばの言うことは必ずしも違ってはいないと「思う」けどさ、
簡潔に説明する能力が欠けていると「思う」な。
それってOOに限らず構造化でも、設計に必要なことじゃない？
聞いてる相手に引かれちゃ、何のためのシステムよ、っつことだろ。

156 ：仕様書無しさん：2007/07/19(木) 22:13:31

>オブジェクト志向設計は構造化設計を前提にしているが

興味深いね。
抽象データ型を考えるさい、どこらへんに構造化が必要なのか伺いたい。

157 ：仕様書無しさん：2007/07/19(木) 22:46:36

構造化でないオブジェクト指向ってある？

158 ：仕様書無しさん：2007/07/19(木) 23:05:12

>構造化でないオブジェクト指向ってある？
構造化設計とオブジェクト指向設計は直交してるんだから
そもそも構造化設計はオブジェクト指向設計ではない

159 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/19(木) 23:09:30

>>125
共通化に手間が掛かってないなら、別に2回でも構わない。
「苦労して」共通化と言うのは、
例えばPostgresとORACLEに対応させようとして、コネクションや検索まわりを共通化するような事を言う。
Cでやるとかなり面倒だが、結局、ORACLEしか使わなかったとか言う話は良く聞く。

>>135
AOP良く分からんな。どういうのだ？

>>138
分かっている所からOOで作ればいい。

>>142
XPもアジャイルも、質の悪いプロトタイプ技法に過ぎない。
今の所、プロトタイプ以降はこれを越える物は出ていない。
プロトタイプおウォーターフォールだけマスターしておけばいい。

>>145
OOのは構造化の要素も含んでいるが、構造化の一種ではない。
OOと構造の違いが分からない限り、電球がOOを理解出来る日は来ないだろう。

160 ：仕様書無しさん：2007/07/19(木) 23:16:01

>>158
君の思っている「直交」は、世間一般とは違うのか？

161 ：仕様書無しさん：2007/07/19(木) 23:38:22

てか、オブジェクト指向と対立概念になるのは機能分解主義だろ。
状態を持つな（ローカルスタティックデータを持つな）、データは引数で渡せ、
etc、etc、って具合で。

162 ：仕様書無しさん：2007/07/19(木) 23:40:30

ＯＯは感性で設計するものだ。
書籍で学べるのは基本の「き」まで。
そこからはおまいの素質しだい。
努力だけではＯＯは「き」までだな。

163 ：仕様書無しさん：2007/07/19(木) 23:45:05

おまえらよ、OOはアドバンスド構造化なんだよ。
どれぐらい、アドバンスドかと言うと、ま、めっがさだな。

164 ：仕様書無しさん：2007/07/19(木) 23:45:06

つうか書籍で学べるのは基本の本の方じゃないか。書籍なだけに。

165 ：仕様書無しさん：2007/07/19(木) 23:46:09

……(；＾ω＾)

166 ：仕様書無しさん：2007/07/19(木) 23:48:20

>>164
いまいち意味がわかりませぬ
くわしく解説してくれ

167 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/19(木) 23:48:41

>>153
何のサンプルが欲しいんだ？

>>154
最初から疎結合を意識して作る必要はない。必要な機能を分かっているだけ作ればいい。
多く使われる部品については、修正するに従って抽象化が進むため、だんだん疎結合になっていく。
最初から汎用性のある部品を作って、その仕様を頑なに守るのは、構造化の手法だ。
必要な物を作る。部品でも要求があればガンガン変更。
メソッド追加なら既存への影響も少ないし、継承を使えば既存への影響はないから、変更の自由度は高い。
これがOOの手法だ。

>>155
簡潔に書くと意味が分からないと言われるし、長く書くと冗長だと言われる。
相手の知識がどの程度なのかも分からないのだから、くどくなるのは仕方ないだろう。
第一、劣化や再利用、知識・経験などの単語も、意図どおりに伝わらないのだから仕方ないだろう。

168 ：仕様書無しさん：2007/07/19(木) 23:49:47

>>161
> 状態を持つな（ローカルスタティックデータを持つな）、データは引数で渡せ、

オブジェクト指向でやる場合でも、↑は必要なことでしょう。

C++の場合、クラスのインスタンスのthisポインタを第一引数にこっそり渡すのだから。

169 ：仕様書無しさん：2007/07/19(木) 23:54:52

言語レベルでＯＯを語っているようでは。。。

170 ：仕様書無しさん：2007/07/20(金) 00:01:49

>>167
おじゃばって、自分でPGとしての適性がかなりあると思ってる？

>簡潔に書くと意味が分からないと言われるし、長く書くと冗長だと言われる。
これが出てくるようじゃPGとしての適性ないと思うぞ（簡素に意味が解るように書く能力ってPGの重要な適性）。
（おじゃまのプログラムも同様の傾向があるんじゃないか？）

171 ：仕様書無しさん：2007/07/20(金) 00:30:52

>>170
どこからも相手にされず、たらいまわしにされた結果、
誰もやりたがらない新人教育しかやってないから
ダラダラ文章の傾向になってるのよ

172 ：えいいち ◆GRGSIBERIA ：2007/07/20(金) 00:47:43

>>154
何々ができる　=　それしかできない

そういう連中ばかりが集まるとそのうち人海戦術になるんじゃね？
AというソフトにBのソフトの機能を結合させたようなCというソフトを作るのに、
AとBでは扱う分野が違う場合、AとBを両方扱える人が多ければ安心だろ？
AとBで机を分けてて、AとBを結合させたらなんか知らんがXになっちゃった、なんて悲しすぎ。
コミュニケーションが取れないのはやっぱりまずいぜ。

Cを作れと言うのに、AはAでBが分からず、BはBでAが分からず、なんてのは最悪。
お互い言ってることがなんなのかもわからないなんて、もう死ぬしかない。

173 ：仕様書無しさん：2007/07/20(金) 00:52:19

鳥がかっこいい件について

174 ：仕様書無しさん：2007/07/20(金) 00:57:41

こりゃまた名物コテが降臨したもんだw

175 ：仕様書無しさん：2007/07/20(金) 01:30:53

設計技術と実装技術を同列で語ってしまう人が多いのは
PGドカタにすべて丸投げしているせいだな。

176 ：仕様書無しさん：2007/07/20(金) 01:57:09

>>7
>最悪なのは、クラスひとつひとつは汎用性があっても、それらを
>組み合わせて実現できるのは、結局ひとつの機能だけ
汎用性のあるクラスはそれはそれでいいじゃねーか？
汎用性があったんだろ？いいじゃん。何が駄目？

177 ：仕様書無しさん：2007/07/20(金) 02:01:27

きちんと分析して作られたOO仕様は見事なものだよ。
オレの経験だとほとんどのケースでロクな分析もせず、いきなりクラスを作り始めている。
結果、グダグダなものしかできなくてOOはダメなんて分かった風なことを言うようだ。

178 ：仕様書無しさん：2007/07/20(金) 02:03:40

>>177
そんなの金かけて作った家が丈夫だよって言ってるだけでなんの意味もないじゃんｗ
そんなこともわからない奴がしたり顔でレスしてる姿を想像するだけで萎える

179 ：仕様書無しさん：2007/07/20(金) 02:04:23

>>177
そういう連中はOOしなくてもグダグダだと思う。

180 ：仕様書無しさん：2007/07/20(金) 02:15:29

もちょっとシンプルに考えようぜ

オブジェクト指向といえばOCP
全てはOCPのためのオブジェクト指向

すなわち、OCPがコスト効果的に見合うと思えばOO是、不要と思えばOO非
kれでいいじゃん

181 ：仕様書無しさん：2007/07/20(金) 02:21:45

>>180
何？OCPって？聞きなれねー

【大予想】
O・・・おっぱい
C・・・ちんこ
P・・・ぱんつ

182 ：仕様書無しさん：2007/07/20(金) 03:07:02

オカピーだよ
ほら、岡・・・、岡なんだっけ？
岡本？岡村？岡崎？岡島？
とにかくオカピーって言ってたじゃん

183 ：仕様書無しさん：2007/07/20(金) 03:59:15

> > > 構造化でないオブジェクト指向ってある？
> > 構造化設計とオブジェクト指向設計は直交してるんだから
> > そもそも構造化設計はオブジェクト指向設計ではない
>
> >>158
> 君の思っている「直交」は、世間一般とは違うのか？

>>158 の思っている「直交」は、世間一般の「直交」と直交しているんだから
そもそも >>158の発言は世間一般に通用しない

184 ：仕様書無しさん：2007/07/20(金) 04:01:44

>>167
オブジェクト指向はプログラムの修正を簡単にする手法じゃないぞ？

185 ：仕様書無しさん：2007/07/20(金) 04:11:02

↑↑↑↑↑24時間常駐体制かよｗ↑↑↑↑↑

186 ：仕様書無しさん：2007/07/20(金) 04:16:15

おじゃまも即レスくんも
世間一般の常識とは直交した存在だから

187 ：仕様書無しさん：2007/07/20(金) 08:36:07

>>156
オブジェクト指向は抽象データ型とそれを処理するためのメソッドのバインド、で
メソッドの部分は仮想的な引数であるthisなりselfなりに対して処理が行われるため
構造化設計であることはほぼ大前提と言っていい。

メソッド部分を非構造化設計するとなると、thisにメンバ変数が全く存在せず
thisのメンバ変数は全く使わず全部クラス変数だけでやり、
かつ外部インターフェースはそのクラス変数を直接参照する、
みたいな設計なのかもしれないが、やめてくれ。

188 ：仕様書無しさん：2007/07/20(金) 09:17:39

だぁかぁらぁ
機能で分類するか、役割で分類するかだけの違いなんだから、
オブジェクト指向は構造化の部分集合なの。

189 ：仕様書無しさん：2007/07/20(金) 16:51:29

最初からキッチリ分析してクラス設計なんてできるのか?
俺には無理だ。

一つのものを3回くらい作り直さないと、うまくできない。
そんなことは許されないので、最初から諦めている。

190 ：仕様書無しさん：2007/07/20(金) 16:53:59

>>189
＞一つのものを3回くらい作り直さないと、うまくできない。

オブジェクト指向に限らず設計に限らずなんでもそうだと思うよ。
よっぽど頭のいい人じゃないと一発でってのは無理。

191 ：仕様書無しさん：2007/07/20(金) 17:14:23

だから世の中には糞ライブラリがあふれるんだよな。
設計は一人の天才に任すが一番よい。

192 ：仕様書無しさん：2007/07/20(金) 17:31:21

天才だって一発で均整のとれたクラス構成はできないっしょ。
だからリファクタリングってプラクティスあんだし。
稼動後は出来ないけどな。

193 ：仕様書無しさん：2007/07/20(金) 18:04:08

作り直しのコストは軽視できないけれど、
勉強をしているんだという観点だと話は別。
作り直したときのあの充実感。

作り直そうとするときの「ああ、こうだったのか」
「この概念で分けるとスッとバランスとれるのか」
という学習効果。趣味のプログラミングこそ、
やたらと設計を吟味し、何度も作り直したい。

194 ：仕様書無しさん：2007/07/20(金) 18:09:48

仕事でだけプログラミングしてる奴は駄目って事か。

195 ：仕様書無しさん：2007/07/20(金) 18:20:37

ダメに決まってんだろ！

196 ：仕様書無しさん：2007/07/20(金) 18:24:22

でもどんな職でも、仕事でだけの人が圧倒的に多いと思う

197 ：仕様書無しさん：2007/07/20(金) 18:32:09

>>193
コスト的には作り直したほうが安いと思うよ。
だが、それを理解できない人、または、理解していても勇気のない人が、作り直しをさせない。

198 ：仕様書無しさん：2007/07/20(金) 18:32:40

つまり、サイヤ人の先祖がスーパーサイヤ人で、その子孫がさぶサイヤ人って事か。

199 ：仕様書無しさん：2007/07/20(金) 18:34:35

>>197 そして勇気がデスマを呼び…ｗ

200 ：仕様書無しさん：2007/07/20(金) 18:36:31

構造化は処理に注目してたけど、
データ中心に考えるようになって、
するとデータと処理の対応付けが解りにくくなったから、
処理とデータをカプセル化してオブジェクト指向になった。

構造化とDOAの良いとこ取りじゃない？

201 ：仕様書無しさん：2007/07/20(金) 18:39:11

>>194
>>196
ブラックではない会社なら、
それなりに良い給料を払い、残業ナシで帰宅させて、自主的に自宅で勉強したくなるように仕向ける
もしくは、
会社の拘束時間の中で勉強させるようにする
だろうな。

我々の自己防衛としては、
仕事をしているフリをして勉強するとか、
3回作り直すまでは、「まだ出来ていない」と報告するとか。

202 ：仕様書無しさん：2007/07/20(金) 18:42:57

> 3回作り直すまでは、「まだ出来ていない」と報告するとか。
名案ｋｔｋｒ

203 ：仕様書無しさん：2007/07/20(金) 18:44:49

バグが出てないならそいつはそのままにして、次の開発で教訓を生かせばいいんじゃない？
（ブランチ分けてデグレの影響出ない所で再設計するとか）
いずれ廃棄処分になるだろうし。

204 ：仕様書無しさん：2007/07/20(金) 19:14:09

>>202
素早くいいかげんに作る、「仕事が速い新人」がいると、困ることだ。

205 ：仕様書無しさん：2007/07/20(金) 19:15:59

>>204
上のほうが「素早くいいかげんに作る」やつだととんでもない事に・・・

206 ：仕様書無しさん：2007/07/20(金) 20:20:48

>>201
断言してもいい

そんな会社はない

207 ：仕様書無しさん：2007/07/20(金) 20:58:20

日本にはないだろうな。

208 ：仕様書無しさん：2007/07/20(金) 21:11:24

プログラミングと申しますのは、それはそれは膨大な学問でございます。
その全てを修め、身につけるとなると
それはそれは・・・・・・
とてもとても・・・・・・

209 ：仕様書無しさん：2007/07/20(金) 21:17:14

巨大プロジェクトでクラス設計３回も変更されたら、何億無駄になる事か・・・

210 ：仕様書無しさん：2007/07/20(金) 21:19:59

プロトタイピングしないで最初から人を投入するのが悪い。

211 ：仕様書無しさん：2007/07/20(金) 21:25:39

設計の不味さで運用に支障をきたしたらそれこそ何億も無駄になる。
コアの部分が不味ければ尚更。

212 ：仕様書無しさん：2007/07/20(金) 21:36:51

>>211
ああ、普通はそうなんだけどな。
でもたいがい実装時点で発覚した問題は実装者同士で解決しちゃう。
どんなに醜いクラス実装になっても平気

213 ：仕様書無しさん：2007/07/20(金) 22:02:35

実装のときに問題解決してたら、醜いクラス実装になっちゃた…

でもそんなの関係ねぇ！そんなの関係ねぇ！

ｵｯﾊﾟｯﾋﾟｰ♪

214 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/20(金) 22:41:02

>>170
170は全く分かっていないようだな。
「説明」「仕様書」「プログラミング」は、それぞれ全く異なる。
説明のコツは、相手のレベルに合わせることだ。つーか言うまでもない事だが。
仕様書のコツは、読む相手のレベルはある程度決まっているので、誤解の少ない明確な表現を使う事だ。
プログラミングは省略は出来ないし、不要な処理は不要だから、あるレベル以上なら同じ書き方になる。

>>171
新人教育はうまく使えば、教える中堅の能力アップにも繋がる。
誰もやりたがらないと言う理由で、窓際の人間に教育をさせているようでは、171も程度が知れているな。

>>201
そんなので社員が育つなら、苦労なんてないな。

>>206,207
残業なしで講習がある会社なんていっぱいあるだろう。やるのは簡単だし。
ただ社員が腐っている場合が多いが。

215 ：仕様書無しさん：2007/07/20(金) 22:49:08

おじゃば怖がりすぎ。もっと力抜いてていいよ。
んで、要点を簡潔に述べれるように、まずは注意してみては。

216 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/20(金) 22:56:39

>>215
簡潔に言うと、215は新人教育してみるといい。

217 ：仕様書無しさん：2007/07/20(金) 22:58:55

ブートローダーからオブジェクト指向まで
フルレンジなおいら。

218 ：仕様書無しさん：2007/07/20(金) 22:59:10

>>788
アスペクト指向ってやつだよ・・・
偉そうに語ってる暇があったら、多種多様にある指向の違いぐらい理解しといたら？

219 ：仕様書無しさん：2007/07/20(金) 23:00:36

訂正

>>159
アスペクト指向ってやつだよ・・・
偉そうに語ってる暇があったら、多種多様にある指向の違いぐらい理解しといたら？

220 ：仕様書無しさん：2007/07/20(金) 23:01:29

知識ばっかでばっかみたい。

221 ：仕様書無しさん：2007/07/20(金) 23:05:40

>>216 うはｗ　それは良いレスだね、うん。
しかしそのような立場であるのならなおさら、
このスレの住人にたいしても実力発揮を望む。

222 ：仕様書無しさん：2007/07/20(金) 23:09:24

アセンブラも書けないんだろ。どうせ。
んじゃ、だめだね。

223 ：仕様書無しさん：2007/07/20(金) 23:10:00

本質が見えるか！おまいらに。

224 ：仕様書無しさん：2007/07/20(金) 23:13:47

しかしながら、新人教育の難しさは異常

225 ：仕様書無しさん：2007/07/20(金) 23:14:26

『クラス』と『インスタンス』というモノ=オブジェクトがあって，
たとえば『哺乳類』がクラス(オブジェクト・クラス)，
それを継承した『人』,『犬』,『猫』もクラス(オブジェクト・クラス)，
『個々の人』,『個々の犬』,『個々の猫』がインスタンス(オブジェクト・インスタンス)

あと『個々の哺乳類』はおかしいので『哺乳類』を抽象クラスとする

226 ：仕様書無しさん：2007/07/20(金) 23:18:12

犬猫動物の例えは分かりにくかったなぁ個人的に。
ナツメ社のJava言語ハンドブック、っていうのを手に、
（こんな中途半端なもので学ぼうとしたのが間違い）
そもそもクラスって何？インスタンスって何？
で止まってた十年前の俺ｗ　インスタンス化が特に分からなかった。

227 ：仕様書無しさん：2007/07/20(金) 23:20:03

>>225
そこから始めると、全く先に進めん罠

それはそうと、中国語でオブジェクトのことを「対象」と訳すわけだが、
これはすごく良い訳だと思う

228 ：仕様書無しさん：2007/07/20(金) 23:22:15

「構造体に関数をくっつけたものがクラス！」
と気がついた（？）時の感動は今も覚えている。
それから、いくつかの誤解は徐々に正していけた。

Javaのinterfaceで抽象度を高めることのメリットを、
デザパタの力を借りるようになってOOPの味をしめた。
Javaが分かるまで三年。OOPをつかむまで、プラス三年はかかった。

229 ：仕様書無しさん：2007/07/20(金) 23:41:15

>>214
> そんなので社員が育つなら、苦労なんてないな。

必要十分条件だという話ではないのだが・・・

230 ：仕様書無しさん：2007/07/21(土) 00:09:54

クラス(オブジェクト・クラス) とインスタンス(オブジェクト・インスタンス)
はどちらもオブジェクトだよ

231 ：仕様書無しさん：2007/07/21(土) 00:53:38

>225 みたいな説明もOOPを混乱させたモノの一つだよなぁ
あと「はじめにデザパタありき」な考え方の奴らも

232 ：仕様書無しさん：2007/07/21(土) 01:09:38

俺はオブジェクト指向自体は嫌ってないが
オブジェクト指向しか知らないゆえになんでもかんでもに
適用するバカがいるのは困る

Javaはクラスを強要されるので嫌い

233 ：仕様書無しさん：2007/07/21(土) 01:12:52

おじゃばが新人教育のみで生産性ゼロの件について

234 ：仕様書無しさん：2007/07/21(土) 01:16:34

問題はわからんちんと単体テストがめんどくさいボクチンだろ
OOの仕事だろうがそうでなかろうが、
結局は人なんだよ。
協力会社と称するへっぽこがきてみ。
OOだろうがOOOOだろうがOOOOOOOOだろうがダメなんだよ。

235 ：仕様書無しさん：2007/07/21(土) 01:18:00

なぜメタプログラミングは嫌われているのか

236 ：仕様書無しさん：2007/07/21(土) 01:23:04

無学にはメタプログラミングの概念と利便性が理解できないから

237 ：仕様書無しさん：2007/07/21(土) 01:32:48

>>164
基本
きのもとをしれるってことか

238 ：仕様書無しさん：2007/07/21(土) 02:25:19

この本良いと思うよ
http://www.amazon.co.jp/gp/reader/4798107123/ref=sib_dp_pt/503-9438884-0594301#reader-page

239 ：仕様書無しさん：2007/07/21(土) 02:56:00

亀だが…

>>778
だそうだ。

240 ：仕様書無しさん：2007/07/21(土) 04:31:01

ファイアーモックス!

241 ：仕様書無しさん：2007/07/21(土) 07:45:05

>>228
それを理解してない奴が多いんだよなぁ

242 ：仕様書無しさん：2007/07/21(土) 10:49:54

＞Javaはクラスを強要されるので嫌い

どのへんが嫌いなの？
俺には嫌う理由がわからんちん

243 ：仕様書無しさん：2007/07/21(土) 11:13:38

>>242
おじゃばみたいなｶｽが周辺でのさばってるのが嫌い

244 ：仕様書無しさん：2007/07/21(土) 11:37:52

構造体？　ちげーよ
むしろクラスってえのは、その構造とやらを教えないようにするのが目的。

245 ：仕様書無しさん：2007/07/21(土) 11:39:00

>>232
>Javaはクラスを強要されるので嫌い
1クラスにすべて詰め込むといいと思いますよ。

246 ：仕様書無しさん：2007/07/21(土) 12:20:17

オブジェクト指向はその名前が混乱の元。
名前だけみると言葉明瞭意味不明。

どこぞの新人教育だけしかさせてもらえない無能で生産性の無い奴はおそらく
「そういう名前しかつけられない」
などと蒙昧なことを言い出すんだろうな。

247 ：仕様書無しさん：2007/07/21(土) 12:42:02

「名前が悪い」という事にして理解できないことの理由にしたがる人が後を絶ちませんね。

248 ：仕様書無しさん：2007/07/21(土) 12:55:09

サブジェクトに対してオブジェクト
我と彼とを疎隔する、みたいな感じが出てていいと思うけど。
彼は我の役にたちさえすればよく、そのとき
我彼はおんなじ公理に立脚している必要さえ無い。

249 ：仕様書無しさん：2007/07/21(土) 13:00:05

>>248
日本語でおｋ

250 ：仕様書無しさん：2007/07/21(土) 13:27:46

>>248
ひどい文章だな
福島瑞穂よりひどい

251 ：仕様書無しさん：2007/07/21(土) 14:09:55

>>103の、おじゃばの例でいうと
構造化設計の場合、設定情報を読み込む処理を呼び出す側（我）は、呼び出す先(彼)が
ファイルをロードする場合は(我)→(彼)に「ファイルパス」を渡す必要がある。
DBなら「ユーザ/パスワード(etc)」だ

オブジェクト指向なら何もわたす必要はない。どんな情報が欲しいかだけを(我)→(彼)に
つたえればよい

まあそういうことだ。

252 ：仕様書無しさん：2007/07/21(土) 14:28:32

馬脚

253 ：仕様書無しさん：2007/07/21(土) 14:50:44

こんな説明されてる新人連中は悲惨だな
研修を受けた新人から上役にクレームが上がるため
現場でなど到底使えないと判断され”教育担当”の肩書きのままなんだろ

254 ：仕様書無しさん：2007/07/21(土) 14:57:37

>>251
内容はわかりますが説明がひどすぎて
理解したくなくなります。
というかあなたと仕事したくありません。
というかあなたの不勉強が気になります。
というか日本語が満足にできるようにしてください。
というか母国に帰って仕事することをお勧めします。

255 ：仕様書無しさん：2007/07/21(土) 15:12:39

>>252
寧ろ上塗り

256 ：仕様書無しさん：2007/07/21(土) 15:41:15

>>244
隠蔽は、
教えないというよりは、コードを散在させない
ということのほうが大きいと思う。

JavaはともかくC++なんかは、
本当に構造を教えないようにするためには、
別の構造体にデータを格納して、そのポインタを持つようにしないといけない。

257 ：仕様書無しさん：2007/07/21(土) 16:02:33

「佐藤さんこれやっといて！」
「鈴木さんこれお願い！」
「山田さん例の案件進捗どう？」
という感じでプログラムするのが
「オブジェクト指向プログラミング」

と、抽象的な説明をしてみるテスト

258 ：仕様書無しさん：2007/07/21(土) 16:03:02

facadeパターンか

259 ：仕様書無しさん：2007/07/21(土) 16:12:59

いちいち仰々しい名前を付けないと理解できないデザパタ厨はいらない。

260 ：格之進 ◆xiPQGz7lVI ：2007/07/21(土) 16:13:36

>>257
「Chain-of-responsibility」パターンですね。

261 ：格之進 ◆xiPQGz7lVI ：2007/07/21(土) 16:17:14

>>259
名前は理解のため、というより識別のためですね。
仰々しく感じるのはあなたが英語を母国語としていないからでしょう。
「traimawashi pattern」なんて名前になったら、
逆に英語圏の人が、そう感じるかもしれません。

262 ：仕様書無しさん：2007/07/21(土) 16:45:45

名前があることが意思疎通を円滑にするというほぼ唯一の価値なのだけれど

263 ：仕様書無しさん：2007/07/21(土) 17:03:17

じゃぁ>>257を、

facadeパターンの感じでプログラムするのが「オブジェクト指向プログラミング」

と書き換えたら、意思疎通が円滑になるのか? ならねーよ。

264 ：仕様書無しさん：2007/07/21(土) 17:54:16

>>263
「じゃあ」て…莫迦でしょ？

265 ：仕様書無しさん：2007/07/21(土) 18:29:30

なかなかタメになるレスもあるな。

266 ：仕様書無しさん：2007/07/21(土) 18:38:49

お互いがfacadeパターンがどういうものか知ってれば、伝達コストを圧縮できるってことだろ

267 ：仕様書無しさん：2007/07/21(土) 19:06:48

デザパタを下手に語るとカオス発生だからなぁ。
分かってる！と言い張っておいて理解不十分なのは、
OOPのそれより多いと思う。いやはや。

268 ：格之進 ◆xiPQGz7lVI ：2007/07/21(土) 19:15:08

まあ、あくまでも道具なので、必要になったら使えばいい、
というか、必要になってから、必要なものだけ勉強すればそれで事足りるんでは。

「なんか Java で awt 使おうとすると、やたら Component ってクラスを継承してるんだけど、
　これなんだろう？そういえば Composite パターンってのがあったな・・・」
（おもむろに結城本をごそごそ）
「なるほどそういうことか。」

みたいな感じでいいんじゃないの。
GOF本を丸呑みとか、むりっす。

269 ：仕様書無しさん：2007/07/21(土) 19:45:43

技術系MLやfjで、有名な方々が議論してるのを見ると、
デザパタの発言も上手に噛み合っているように見え、
２ちゃんでデザパタが出ると大概カオス発生して見える。

>>268
GOFを丸覚えしようという発想は、いつも悲惨に見える。
デザパタを必要とする人がそれを求めるのであって、
ある程度以上の複雑さへ向かったことがない人は、
デザパタの価値も、そしてOOPやOOPLの価値もよく理解できないのかもしれない。

そして最後に、信者がどうとか、
「信じているから無理矢理使う」のだという論調さえ出てしまう。

270 ：仕様書無しさん：2007/07/21(土) 19:49:05

　　　　　　　　　　　　あいかわらずひどい自作自演だなぁ

271 ：格之進 ◆xiPQGz7lVI ：2007/07/21(土) 19:57:47

>>269
>そして最後に、信者がどうとか、
で、基本的に、信者というのは（特に無理矢理使う）、
あんまりわかっていない、というか、実務経験が少ない人が多いちょうなきがしますね。

あんまり会社の上司とかにはいえないことですが、
技術は使って面白いから、使うのであって、
信じているからじゃあ無理矢理つかうなんて、楽しくないじゃないですか。

272 ：仕様書無しさん：2007/07/21(土) 20:05:00

そうですよね。
的外れなOOP布教（？）も、信者（？）批判もどっちも悲惨ですよね。

ただ、食わず嫌いになるよりは、
無理矢理使ってみるほうがマシかも…しれませんが。

273 ：仕様書無しさん：2007/07/21(土) 20:13:24

>>268
デザインパターンというのは、
自然発生的に皆が同じようなことを考え出して使ってきたものに名前を付けた
ということだけでなく、
自分で考えるよりもベストプラクティスを真似たほうがいい
ということでもある。

デザインパターンの賛否が割れるのは、
レベルの低い人にとっては、デザインパターンから選択するのは、レベルアップだが、
レベルの高い人にとっては、デザインパターンから選択するのは、レベルダウンだから。

昔は、多くの清濁いろんなソースコードを読んだり、自分で経験積んでベストプラクティスを学ぶ必要があったが、
いまではデザインパターン本を読むだけで、ある程度のレベルまで一気に追い付けるのだから、いい時代ですな。

274 ：仕様書無しさん：2007/07/21(土) 20:16:35

>>269の前半

そりゃぁ似たような人達が集まれば、話は噛み合うさ。

275 ：仕様書無しさん：2007/07/21(土) 20:18:37

アルゴリズムそのものを言語が実装したように
デザインパターンも完全に組み込めばよろしい

276 ：仕様書無しさん：2007/07/21(土) 20:23:25

> レベルの高い人にとっては、デザインパターンから選択するのは、レベルダウンだから。

うへー。そういう意見もあるのか。目からウロコです。

　「同じ目的を達成するのに複数の実装方法がある場合、
　できるだけ一般的な方法で書いた方が良い」

などという言い方がありますが、上級者がデザパタレベルに書くのは、
ある種、一般的な方法で書こうとしたという選択、とさえ思っていました。
だから、保守性こそあがっても、レベルダウンにはならないんだと。

277 ：格之進 ◆xiPQGz7lVI ：2007/07/21(土) 20:26:48

まあ、無理矢理使うしかない時期ってのはありますね。
あたらしい言語を覚えるときとか、
全く知らない分野（ハードウェア制御とか通信とか、あとシステムプログラミングとか）
をやるときとか。

そういうときでも、「よくわからないけど、面白そうだから」というような動機がないと、
我慢が続きません。

自分がそういう考えなので、後輩の子に「Java 覚えてもらいたいな・・・」と思ったときには、
なるべく、その子の興味を引きそうなことを小出しにして、洗脳しようといろいろ苦労するのですが。
そういうときに、
「これからはオブジェクト指向だ、オブジェクト指向じゃなきゃダメだ！」
「UMLの全ての図を使え。」とかプレッシャーをかけて、アレルギーを植えつけてくれやがる上司がいるので困りものです。
もう、Java の話をすると目を合わせてくれません。

278 ：仕様書無しさん：2007/07/21(土) 20:28:36

>>277
> 「これからはオブジェクト指向だ、オブジェクト指向じゃなきゃダメだ！」
> 「UMLの全ての図を使え。」とかプレッシャーをかけて、アレルギーを植えつけてくれやがる上司
この業界でありがちな呪いですよね X-(

279 ：仕様書無しさん：2007/07/21(土) 20:47:33

>>276
> 同じ目的を達成するのに複数の実装方法がある場合、
>　できるだけ一般的な方法で書いた方が良い

まさに、レベルダウンです。

レベルダウンは一概に悪いことではなく、
一般的なレベルの他の人に合わせるのも必要なことだけど、
いつもいつも下に合わせて仕事をしているのであれば、
働く場所を変えたほうがいいかもしれませんね。

280 ：仕様書無しさん：2007/07/21(土) 20:47:41

>>273
上級者は、もっと優れたパターンを提供すればいいじゃないか
既存パターンだけがデザインパターンじゃないでしょ

281 ：仕様書無しさん：2007/07/21(土) 22:49:05

パタン。

282 ：仕様書無しさん：2007/07/21(土) 22:53:40

>>280
> もっと優れたパターン

散々既出のものをパターンというのだが・・・。
「既存パターン」というのは、「頭痛が痛い」みたいなもんだぞ。

上級者は、パターンを適切に使いこなした上で、
パターンが不適切なら、パターンから外れる。

なんでもパターンだけで解決できると思ったら大間違いだ。

283 ：仕様書無しさん：2007/07/21(土) 23:06:56

美しいモジュールを追求する心があれば
オブジェクト指向などごく自然なものであることがわかるだろう。

284 ：仕様書無しさん：2007/07/21(土) 23:21:30

>>282
複数のパターンと呼ばれるものがあるけど、
それに追加することはしないの？

パターンと呼ばれるクラスの新しいインスタンスを作らないの？

285 ：仕様書無しさん：2007/07/21(土) 23:28:45

パターンは旋律なので、覚えたり真似るのでなく、感性を磨くためにある。

286 ：仕様書無しさん：2007/07/21(土) 23:30:28

感性を磨けばオセロのクラスに石は登場しなくなる。

287 ：仕様書無しさん：2007/07/21(土) 23:30:36

まぁあれだ。GOFだけでももう23個もある。
そこに追加できるほど、
「パターンと読んでいいほどさんざん既出で」
「パターンカタログに追加しときたいほど有用であって」
「なおかつほかの23個にかぶらない」
条件をみたすものって、あるのかな。

むしろ怖いのは「俺流パターン思いつきますた」
「これは亜流っぽいけど新パターンとしたいんでつ」
みたいな、まさにパターンの乱造。

>>285 素敵だね。

288 ：仕様書無しさん：2007/07/21(土) 23:30:37

そもそもデザパタはオブジェクト指向の階層にないような・・・
実装技術だよな？デザパタって

289 ：仕様書無しさん：2007/07/21(土) 23:31:56

>>288 少なくともGOFのは
「オブジェクト指向における再利用性のためのデザインパターン」
と訳されており、中身もOOPを前提にしてたと思います。

290 ：仕様書無しさん：2007/07/21(土) 23:34:46

オブジェクト指向って、目で見える作りたいもんの構造をわかりやすいように
ソースに反映できるのがいいところなわけじゃん？

この工程にパターンに当てはめるとかそもそもいらない気がするんだけど
デザパタいいって言ってる人はどういう作り方してて「パターン」が必要になるのか
一度聞いてみたかった

291 ：仕様書無しさん：2007/07/21(土) 23:36:27

>>289
俺、それGoF本読んでも全然わからなかった
製作者に問い詰めたい感じだった

292 ：仕様書無しさん：2007/07/21(土) 23:38:10

そもそもオブジェクト指向自体、再利用なんて目的としたもんじゃないし
後付けで学者さんがメリットに勝ってにぶち込んでプレゼンでもして浸透してしまったと俺は思ってる

勢いで入れた概念で俺は無理があると思う＞オブジェクト指向の再利用効果

293 ：仕様書無しさん：2007/07/21(土) 23:41:23

＞オブジェクト指向って、目で見える作りたいもんの構造をわかりやすいように
＞ソースに反映できるのがいいところなわけじゃん？

またこれかよ。。

294 ：仕様書無しさん：2007/07/21(土) 23:48:20

デザパタはOOの本質じゃねーし、OOを犬猫哺乳類で説明しても何も益が無いし
目に見えるものを云々も違うし、構造化とOOも関係ねーし
そもそもOOは開発者に利便性をもたらすものじゃねーって。
そろそろ覚えろや。

295 ：仕様書無しさん：2007/07/21(土) 23:48:29

>>293
そう、そこでしょ？
そもそも出だしが間違ってるからデザパタは話にならないと俺は思ってる
どうみたってオブジェクト指向じゃねーもん
実装技術だろこれ

296 ：仕様書無しさん：2007/07/21(土) 23:49:11

よって、オブジェクト指向は嫌われる。

297 ：仕様書無しさん：2007/07/21(土) 23:49:41

>>287
ある限られた範囲で共有される「＊＊＊パターン」ってあっても良いんじゃない？
全世界で共有されるようなのは、難しいかもしれないけどさ

仮に、これ以上パターンと呼べるものは無いって言うんだったら
既存のパターンを継承して若干の変更をするだけで、
あらゆるソフトウェアを設計できるってことにならない？

298 ：仕様書無しさん：2007/07/21(土) 23:50:39

デザパタは実装技術ではない。
デザパタは本質の見極めかたの技術です。

299 ：仕様書無しさん：2007/07/21(土) 23:51:27

オブジェクト指向に実装が関係無いなら
なおさら実装に関する技術が重要になる気がするが

300 ：仕様書無しさん：2007/07/21(土) 23:51:30

>>294
>OOを犬猫哺乳類で説明
これも一見あってるようでいておかしいよね
これ継承の説明でしかないし、対象モデルをソースに落としこむ
一番重要な部分の説明がされてない場合が多いから困る

301 ：仕様書無しさん：2007/07/21(土) 23:53:42

オブジェクト指向は実装技術です。

302 ：仕様書無しさん：2007/07/21(土) 23:54:00

OOPしてて、よくあるやり方をまとめたのがデザインパターンだろ？

303 ：仕様書無しさん：2007/07/21(土) 23:54:48

デザパタはヒント集。

304 ：仕様書無しさん：2007/07/21(土) 23:56:57

>>301
実現したい構造があって、それをクラスで表現できたら
ひとまずオブジェクト指向を使う部分は終了だと思うけど？

だから言語仕様は細かい部分を省けばＣ言語＋クラスになってるわけだし

デザパタは細かいところまでちょっとうっとおしい希ガス
っていうかパターンなんて結果だろ必要ねぇよ

305 ：格之進 ◆xiPQGz7lVI ：2007/07/21(土) 23:58:04

>>295
オブジェクト指向は目的じゃなくて手段ですよ。

会社の業務であれ、個人の趣味のプログラムであれ、
なんらかの目的を達成するために「必要ならば」システムを開発し、
そのシステムの作成に「必要ならば」オブジェクト指向やデザインパターン
（の考え方）を使うわけでしょう。
パターンを使うことで、納期が短縮できたり、信頼性や保守性があがったり、
目的についてなんらかの有益な結果が得られるならば、それで成功なんですよ。
「オブジェクト指向かどうか」「実装技術かどうか」なんて基本的にはどうでもいい問題です。

306 ：仕様書無しさん：2007/07/21(土) 23:59:15

>>297 実際、色々ありますもんね。
マルチスレッドでのデザインパターンだとか。

> 既存のパターンを継承して若干の変更をするだけで、
> あらゆるソフトウェアを設計できるってことにならない？

あらゆるソフトウェアへの設計に対して、
充分なパターンを保障するのがデザインパターン、なのではない、かと。

いくつかの、いつも共通のわずらわしさに対して、
いくつかの解決方法を示してみせてるのがデザパタかと。

> 仮に、これ以上パターンと呼べるものは無いって言うんだったら

無くはないだろうけど、出てはこないだろう、と思ったわけです。根拠は>>287です。

307 ：仕様書無しさん：2007/07/22(日) 00:00:08

>>302
それがありえねぇんだけど

だって現実のモデルをソースに落とすだけだぜ
実際それだけでできるできないって問題はおいておいて
とりあえずオブジェクト指向での仕事はここで終わりといっていいだろ

現実モデル→ソース

だけの変換なのにパターンだのなんだのって話がでてくるの？
おかしくない？

デザパタ信者のいうオブジェクト思考と
いわゆる一般のオブジェクト指向ってかなり違うと思うんだけど？

308 ：仕様書無しさん：2007/07/22(日) 00:03:10

>>307 また信者かどうかの話がはじまりつつある X-(
使う人は必要だから使うんでしょうよ。それで便利になる、
スカッとするからこそ使うんでしょうよ。
そしてそれは、いつも必要になるようなものじゃないはず。

「信じているから使うんだ」の論調はジャンプ力がありすぎです。

309 ：仕様書無しさん：2007/07/22(日) 00:05:23

>>307
ソースに落とすんならそのときにパターン使いそうなもんだが

310 ：仕様書無しさん：2007/07/22(日) 00:08:34

>>309
それはどうやって？
結果として同じになる場合はあるかもしれないけど
そのマッチするパターンをわざわざ探すのはおかしくない？
あとやる意味がわからないんだけど？

311 ：仕様書無しさん：2007/07/22(日) 00:08:47

だから、便利にはならねって
便利さ柔軟さは捨ててるだろOOPは

312 ：仕様書無しさん：2007/07/22(日) 00:09:05

>>307
必殺技に名前がついているようなもんだ。

313 ：仕様書無しさん：2007/07/22(日) 00:09:06

しかし、オブジェクト指向で設計されたソースコードは見ないね。
ちっともね。

314 ：仕様書無しさん：2007/07/22(日) 00:10:47

どこかにあるの？オブジェクト指向で設計されたソースコード。

315 ：仕様書無しさん：2007/07/22(日) 00:11:02

>>306
網羅していないっていう点は、確かにそうですね。

企業(やある特定の業界)で得意とする分野があるんだったら
その設計をデザパタとして、その企業内で共有するのは
その企業(の経営者)にとっては、メリットがあると思う。

一々考えなくて済むし、もし改良が必要だったら
そのパターンを改良して、改良版を共有することで
品質や機能を底上げできると思う。

316 ：仕様書無しさん：2007/07/22(日) 00:13:13

>>314
最近は、ちらほら増えてきた
メモリとか余裕のある環境にいかないとないかも
意外と多かったりするのが組み込み系の期待値出すだけの
ハードと直結しないＧＵＩのツールの類

317 ：仕様書無しさん：2007/07/22(日) 00:13:22

>>310
お前の場合まずデザパタ使ってみれ
ちなみに俺はデザパタ推奨派じゃないから勘違いすんな

デザパタは役に立つ場面もあるが、コストが大きいので
思ったより活躍する場面が少ない。
これが一般的な認識だ。

318 ：仕様書無しさん：2007/07/22(日) 00:13:55

>>315 ああなるほど。

> 企業で得意とする分野…共有するのは

なんかそれって昔、フレームワークとか呼ばれてませんでした？
違うのかな？　MLとかでその単語が出るとほとんどカオス化してて、
その言葉がすごく怖かったような思い出がある。

319 ：仕様書無しさん：2007/07/22(日) 00:14:36

JavaのオプソでOOPじゃないものなんかないだろ
腐るほどあるぞ

くどい様だが、俺はOO推奨派じゃないからな

320 ：仕様書無しさん：2007/07/22(日) 00:15:24

>>314
SmallTalkのクラスライブラリの中に大昔からごちゃまんと

321 ：仕様書無しさん：2007/07/22(日) 00:16:06

あとGOFのデザパタは、いい加減古いしな
そろそろ刷新されるだろ

322 ：仕様書無しさん：2007/07/22(日) 00:16:58

それって俺様指向のソースコードじゃないの。結局のところ。

323 ：仕様書無しさん：2007/07/22(日) 00:17:09

ほんとはこういうスレって、
SmallTalkerの方々に出てきてもらうのが、

…いいのか悪いのか。

324 ：仕様書無しさん：2007/07/22(日) 00:17:54

>>317
いや、根底から考え方が違うからそもそもデザパタの使い方がわからない
俺のオブジェクト指向では「パターンに一致するものを探す」って工程を入れるところが無いんだよね
だからわからない

325 ：仕様書無しさん：2007/07/22(日) 00:18:24

おれあんまりSmallTalkはよく知らないから無理。
つーか、ここ遊ぶところでしょ。

326 ：仕様書無しさん：2007/07/22(日) 00:18:54

「パターンに一致するものを探す」ってか！
ありゃありゃ。

327 ：仕様書無しさん：2007/07/22(日) 00:21:07

>>326
いや、マジでわからないよ
ふざけや煽りじゃなくてホントにない

もし、これが「パターンに一致するように現実のモデルを湾曲する」て使い方をしてるのなら
デザパタはオブジェクト指向を逸脱してると思う

328 ：仕様書無しさん：2007/07/22(日) 00:21:54

>>324 無理に使う、っていうのはどこまで言っても間違いかと。
使わなくていいんです。使わなくていいんです。それでいいんです。

329 ：仕様書無しさん：2007/07/22(日) 00:23:24

>>328
じゃ、「デザパタって何？」って話にならない？
本読んでどんなパターンがあるかはわかったけどさ
「だからどうよ？」で終わるじゃん

330 ：仕様書無しさん：2007/07/22(日) 00:23:26

俺のオブジェクト指向ってなんだよ
知るかそんなもん

デザパタじゃなくてもなんでもいいけどオブザーバ「的な」オブジェクトが
プログラム上｢必要な」局面とかあるだろ

分析上はそんなもん必要ないとかいってるのか？
どうかわからんけど

331 ：仕様書無しさん：2007/07/22(日) 00:23:31

>>327
もういいよ。むりでしょう。

332 ：仕様書無しさん：2007/07/22(日) 00:23:43

GOF本は概要のところにオブジェクト指向設計とはどーいうもんでどーやって設計するのかが書いてあるんだが、
なんでみんなパターンを上っ面だけ真似して知ったかぶるだけで終わっちゃうんだろうなぁ
概論で説明してるオブジェクト指向設計の基本から得られたパターンがデザインパターンなのに
概論の基礎をすっとばしてもそりゃ役に立つわけが無いよ

333 ：仕様書無しさん：2007/07/22(日) 00:26:04

おまいらレベル低すぎ。まだまだおいら域には程遠いね。

334 ：仕様書無しさん：2007/07/22(日) 00:26:34

>>330
>デザパタじゃなくてもなんでもいいけどオブザーバ「的な」オブジェクトが
>プログラム上｢必要な」局面とかあるだろ
俺はそれを「実装技術」って表現してたんだけど？ｗ
やっぱ、そういう使い方っしょ？
オブジェクト指向の核の部分よりソース寄りな使い方すんだよね？＞デザパタ

ああ、なんかすっきりした
ｱﾘｶﾞﾄｳ

335 ：仕様書無しさん：2007/07/22(日) 00:27:02

>>329 それでいいんです。それでいいんです。「デザパタって何？」でいいんです。

> 本読んでどんなパターンがあるかはわかったけどさ

ちなみに僕は白状しますと、あのGoF本難しすぎて、
さっぱりわかりませんでした。

> 「だからどうよ？」で終わるじゃん

それでいいんです。「だからどうよ？」と思わないひとが、それを役に立てるだけのことです。

336 ：仕様書無しさん：2007/07/22(日) 00:29:37

>>332
>概論で説明してるオブジェクト指向設計の基本から得られたパターンがデザインパターンなのに
いや、それだったらパターンなんてでるわけがない

現実モデル→ソース

これがすべて
この要素以外あったらおかしい（実際は詳細な部品はでるだろうけど大まかなもんには出てこないよね？）
あったらオブジェクト指向わかりにくいじゃん
だれがみても一致するためのもんなのになんか悟りの境地にでも
立たないといけないようなもんがある時点でつかえねーじゃん

337 ：仕様書無しさん：2007/07/22(日) 00:31:34

デザパタは、いってみればプログラム書く上で良く出てくるし
必要なオブジェクトの組み合わせについてOOPの基本原則(特にOCP)をきちんと守った場合
こんな感じでつくることができるけど、どう？みたいなものの寄せ集め
直接役にたつ場合もたたない場合もある。

守るも守らないも任意だが、まずは「OOPの基本原則」これ知ってることが大事

338 ：仕様書無しさん：2007/07/22(日) 00:33:03

>>336
そもそも、アセンブラで出来ないことなんてないのであって
プログラミング言語やら設計開発手法やらは全て「もともと出来ていること」を
「あえて出来なくする」ことに意味がある
お前の観点では「つかえねーもん」そのものなんだよ

339 ：仕様書無しさん：2007/07/22(日) 00:33:18

>>336
> 現実モデル→ソース
> これがすべて

失礼ですが、業種はどのへんですか？

340 ：仕様書無しさん：2007/07/22(日) 00:33:33

>>336
そのオブジェクト指向は結局何もしてないような気がするんだが

341 ：仕様書無しさん：2007/07/22(日) 00:33:34

ボクシングで
「ダッキング」とか
「スェー」とか
「ワンツー」とか
「カエル飛び」
とかって名前がついているようなもんだって。

342 ：仕様書無しさん：2007/07/22(日) 00:33:50

>>337
いや、まったくわからん

だっていま作ってるもんがデザパタに一致するかどうかなんて
クラス出してみなきゃわからないし、出た構造がたまたまデザパタのあるパターンに似通っていたとしても
湾曲してデザパタに当てはめるのはとりあえずタブーじゃん

343 ：仕様書無しさん：2007/07/22(日) 00:35:31

お前らデザパタデザパタうるせぇよｗ

344 ：仕様書無しさん：2007/07/22(日) 00:36:21

>>343 確かにｗ　ちょっとスレ違いに勢いがつき過ぎてるｗ

345 ：仕様書無しさん：2007/07/22(日) 00:37:47

とりあえず歴史的にはOOPが先でOOA/OODは後付な
デザパタがOOPの範疇なのはそうだけど、それをOOA/OODに応用できるかどうかでいうと知らん
まあ、出来る場合も多少はあるんじゃね？
なにしろ、デザパタがオブジェクト指向じゃないっつのはどうかと。

346 ：仕様書無しさん：2007/07/22(日) 00:38:35

デザパタ使ってる奴はパターンをどうやって使っているんだ？
それがまずさっぱりわからねー

347 ：仕様書無しさん：2007/07/22(日) 00:40:11

>>345
いや、だから、パターンの使い方がまずわからん
対象物の実際の構造は無視しちゃってるの？

348 ：仕様書無しさん：2007/07/22(日) 00:40:44

>>346
OOPの基本原則知ってて、GOF読めば一瞬でわかるっつの
なんでそんなくいさがるんだよ

349 ：仕様書無しさん：2007/07/22(日) 00:40:46

OOAとかOODとかこれっぽっちも知識がない。何だろうか、と思う。
かといって不要だ不要だと騒いで回ったりはしない。

350 ：仕様書無しさん：2007/07/22(日) 00:41:13

現実のほうからパターンに飛び込んでくるよ

351 ：仕様書無しさん：2007/07/22(日) 00:42:22

対象物の実際の構造がどうとか、そっから離れろ
それがオブジェクト指向だって何に書いてあったか知らんけど、
それ何の後ろ盾もない戯言だから

352 ：仕様書無しさん：2007/07/22(日) 00:42:35

>>350
だったらパターンなんて覚えなくていいじゃん

353 ：仕様書無しさん：2007/07/22(日) 00:42:35

>>346,347
「おいしい料理を作るコツ28選」
ぐらいの使い方でOK

354 ：仕様書無しさん：2007/07/22(日) 00:43:47

自然界の物にたとえられることがオブジェクト指向の本質ではない。

たぶん、>>347さんのやってきた「オブジェクト指向」とやらは、
猫、犬、動物、がさまよっているあたりの物だと思う。

355 ：格之進 ◆xiPQGz7lVI ：2007/07/22(日) 00:43:52

>>336
その「現実モデル」というのは、具体的にはどういうものですか？

356 ：仕様書無しさん：2007/07/22(日) 00:44:44

>>353 正しいね。

357 ：仕様書無しさん：2007/07/22(日) 00:46:02

猫、犬、動物はクラスってものを説明するための方便で、本質とは何の関係もねー。
だれだこんなもん流行らせたのは

358 ：仕様書無しさん：2007/07/22(日) 00:46:17

>>351
>対象物の実際の構造がどうとか、そっから離れろ
え？そうじゃないって言ってる？
なんか根本から考え方違うんだなぁ・・・

原理主義者の俺の頭はオブジェクト指向がシミュレーションからできたもんって
ところからはじまってるからそういわれるとわけわからんな。たしかに。

359 ：仕様書無しさん：2007/07/22(日) 00:47:17

猫、犬、動物はまさに孔明の罠。

360 ：仕様書無しさん：2007/07/22(日) 00:47:32

>>356
ありが・・・ちゅっ

361 ：仕様書無しさん：2007/07/22(日) 00:48:08

しむらでやってたのが、対象物の実際の構造から落とし込まれたクラスだけで構成されたシミュレーションだって？
誤解だそりゃ。

362 ：仕様書無しさん：2007/07/22(日) 00:49:06

オブジェクト指向っつってもGoF本のオブジェクト指向はSmalltalkのオブジェクト指向だから
C++系列の抽象データ型を中心にしたオブジェクト指向とは全然別のオブジェクト指向だぞ。
抽象データ型のオブジェクト指向に関してはメイヤーのオブジェクト指向入門があるけど、
お前らSmalltalkのオブジェクト指向は一体どうやって勉強したんだ？

363 ：仕様書無しさん：2007/07/22(日) 00:49:19

>>357
それも原理主義者の俺からすると違うんだよね
犬、猫、動物の話は継承の説明でしかない
（それに俺は継承はやらんほうがいいと思ってる）

俺の考えは

現実モデル→ソース（クラスね）

のみ

364 ：仕様書無しさん：2007/07/22(日) 00:50:56

>>363
はげどう

365 ：仕様書無しさん：2007/07/22(日) 00:51:51

>>362
C++系列のってそんなに違うもんなの?

366 ：仕様書無しさん：2007/07/22(日) 00:52:10

>>361
気体分子のシミュレーションで気体分子１つの動作と
気体分子同士の衝突の動作を定義して
箱の中で複数の気体分子を動作させてその様子をみたのが最初

この場合は

気体分子＝クラス

とわかりやすい

367 ：仕様書無しさん：2007/07/22(日) 00:52:14

ケイのメッセージ指向なんて、勉強するも何も別に完成したもんじゃないだろ
まあそれいったらクラス指向についても然りなわけだが

368 ：仕様書無しさん：2007/07/22(日) 00:53:09

OOとデザインパターンは関係ない、は
「柔よく剛を制す」と「背負い投げ」は関係ないと言ってるようなもんだ

369 ：仕様書無しさん：2007/07/22(日) 00:53:16

>>366
実際の構造から落とし込まれたクラス「だけで」構成

だけで、のとこ重点的に読んでくれ

370 ：仕様書無しさん：2007/07/22(日) 00:53:32

>>363
> （それに俺は継承はやらんほうがいいと思ってる）
( ﾟдﾟ) ﾎﾟｶｰﾝ　ポリモーフィズムはご存知ですか？
そして、GoF本を読んで「>>329 本読んでどんなパターンがあるかはわかった」のですよね？？

> 現実モデル→ソース（クラスね）

どんな業種でそれが成り立ちえますか？

371 ：仕様書無しさん：2007/07/22(日) 00:54:45

>>367
別に完成してなくてもいいじゃん

372 ：仕様書無しさん：2007/07/22(日) 00:58:26

>>351
やっぱ、気になるのは>>351だな
この辺がデザパタ信者と俺との決定的な違いだと思ってる

現実モデルをソースにするんでなかったら>>351は一体何をオブジェクトにしてるのかと
もちろん実装するにあたって必要になる細かいクラスは省いたとしての話ね

373 ：仕様書無しさん：2007/07/22(日) 00:59:45

>>372 だから信者っていうのヤメレｗ
物事を正確に捉えたければ、思い込みと事実とは別にしなきゃ。

374 ：仕様書無しさん：2007/07/22(日) 01:00:06

継承使わないなら、Cで十分だけどな。
OOPのメリットの半分も享受出来ない。
どんな道具もそうだけど、「使う能力がないなら使わない方がマシ」であって、
使う能力あったら、話は違ってくる。
Cは簡単なコーディングなら誰でも出来るけど、継承とかある言語だと
センスないと、機能を全く生かせない気がする。
Cとまるで変わらないC++のコード書く奴とかいるしな。
構造化すら出来てない奴もいるし。

375 ：仕様書無しさん：2007/07/22(日) 01:00:40

信者はむしろ>>372だろｗ

376 ：仕様書無しさん：2007/07/22(日) 01:03:03

>>374
俺は構造を紙に書いて説明しやすいのがメリットだと思うけど？
はじめの人が気体分子の１つをクラスで表現したけど
それは意味ないって言ってる？

377 ：仕様書無しさん：2007/07/22(日) 01:05:02

>>376
うん。
意味はあると思うよ。
ただ、そんなん構造体がちょっと便利になっただけ。
継承の圧倒的なメリット知らないってことは、あまり大きな
プログラム作ったことないんじゃないかと。

378 ：仕様書無しさん：2007/07/22(日) 01:06:04

オブジェクト指向関係ないけど、SICPの最初のページに書いてあったじゃねえか
複雑なもん作るときには、ちっこいの合体させて大きくするだけじゃなくて
ある程度の大きさのもの同士を別の何かで繋いで使う方法があるつって。
オブジェクト指向ってな、まさにその繋いで使うことの方が主だろ

379 ：仕様書無しさん：2007/07/22(日) 01:08:33

OOPならではの最も重要な繋ぎ方の一つが継承なんだけど（笑

380 ：仕様書無しさん：2007/07/22(日) 01:09:20

>>377
いや、ネットじゃなんとでも言えるから言うのやなんだけどさ
俺、結構大きいプログラム組んでるよ
ゲーム→保健→金融→組み込み
って業種移ってるし、それとプログラマ１０年目なんで、とりあえず腕はそれなりに信じてほしい

継承は影響範囲無駄にでかくなるし管理がいい加減になるから辞めたほうがいいと思うんだよね
むしろ、でかく（金銭的にも）なるほどメリットないと思う

381 ：仕様書無しさん：2007/07/22(日) 01:10:25

こんなにも説得力がない。いくつかレスするだけで丸裸になるから。

382 ：仕様書無しさん：2007/07/22(日) 01:10:50

>>380
継承を使うと、メーカーさんの作った、大規模なライブラリを利用しやすいんだが、
その辺の事は知っているかな。

383 ：仕様書無しさん：2007/07/22(日) 01:10:52

>>380
はげどう

384 ：仕様書無しさん：2007/07/22(日) 01:13:45

知らなかったのかな(笑

385 ：仕様書無しさん：2007/07/22(日) 01:13:48

だからさ。普通に考えて現実世界をモデル化したものだけじゃ、うんともすんとも動かないわけじゃん
なぜならユースケースまわすためのメソッドはモデルの本質じゃないから。
すなわち、ユースケースをまわすためには何か別のもの必要だってことよ

386 ：仕様書無しさん：2007/07/22(日) 01:14:38

なんだかお開きムードにｗ

387 ：仕様書無しさん：2007/07/22(日) 01:15:01

じゃ、そろそろ三本締めで

388 ：仕様書無しさん：2007/07/22(日) 01:16:52

おやすま

389 ：仕様書無しさん：2007/07/22(日) 01:17:07

>>385
それは詳細でしょ？
抽出した大きなクラスの中に入ってしまうはず
お前のいってることはここの話題とは関係ない

390 ：仕様書無しさん：2007/07/22(日) 01:19:26

>>382
それは実装的な問題っしょ
なんでこの場面で話すのか意味不明

391 ：仕様書無しさん：2007/07/22(日) 01:21:12

>>374
プログラミング上の話で言えば、クラスの機能があるかないかで全然違う。
C言語で組んでて、継承は要らないがクラスが欲しいことはある。

392 ：仕様書無しさん：2007/07/22(日) 01:21:16

>>390
いや、スレの流れとか読んでないんだが、継承は使わない方がいいとか、
頭悪そうな奴がいたんで、脊髄でレスしたｗ

393 ：仕様書無しさん：2007/07/22(日) 01:22:06

　　　 ∧＿∧　／￣￣￣￣￣
　　［（　・∀・）＜　釣り中学生乙　ｵﾔｼﾐ
|￣￣￣￣￣￣＼＿＿＿＿＿
|　　|￣￣￣￣|　　|
|　　|　＠　＠|　　|
|　　|＠　＠　 |　　|
|　　|＿＿＿＿|　　|
|＿＿＿＿＿＿＿_|

394 ：仕様書無しさん：2007/07/22(日) 01:23:01

>>393
年とってからOOP理解すんのは大変なんすねｗ
オヤスミｗ

395 ：仕様書無しさん：2007/07/22(日) 01:30:15

>>392
継承は影響範囲が絞れんな
継承の継承の継承の継承の・・・って続いてると
小規模やっつけ的な場面なら便利ってだけで使えるが
ここでどの処理が動いてるか正確に出さなきゃいけない場面で使うと地獄

２回目の継承はこのメソッドはスルーされてて３回目は実装されてます
４回目でも実装されていますが、使ってあるのは２回目の継承のメソッドなんですよ
とすると呼ばれるのは１回目のでこれはバージョン４のときに削除されています
だから動かなかったとｗ
なんて場面に当ると結構死ねるし、みつけんの大変だぜ

396 ：仕様書無しさん：2007/07/22(日) 01:31:44

　　　 ∧＿∧　／￣￣￣￣￣
　　［（　^∀-）＜　突っ込みどころ満載乙 zzz
|￣￣￣￣￣￣＼＿＿＿＿＿
|　　|￣￣￣￣|　　|
|　　|　＠　＠|　　|
|　　|＠　＠　 |　　|
|　　|＿＿＿＿|　　|
|＿＿＿＿＿＿＿_|

397 ：仕様書無しさん：2007/07/22(日) 01:38:52

JAVAも.netも非推奨多いんだけどどうなのよ

398 ：仕様書無しさん：2007/07/22(日) 01:40:15

継承？リスコフの置換原則でも読んどけ

399 ：仕様書無しさん：2007/07/22(日) 01:43:19

>>389
はいらねーよｗ

400 ：仕様書無しさん：2007/07/22(日) 01:44:41

>>399
明らかに設計がおかしいじゃん

401 ：仕様書無しさん：2007/07/22(日) 01:52:05

>>395
だから言ってるじゃん。
高度で複雑なシステムだから、「使う能力ないなら使わない方がいい」って。

402 ：仕様書無しさん：2007/07/22(日) 01:55:30

能力なんて、今更ある程度関係ねってｗ
リスコフｒｙ

403 ：仕様書無しさん：2007/07/22(日) 01:56:26

無い奴は「あってもなくても関係ない」と思いたがるね。
この辺、金とか学歴とかと同じだね。

404 ：仕様書無しさん：2007/07/22(日) 01:59:53

リスコフって誰？

405 ：仕様書無しさん：2007/07/22(日) 02:02:41

>>403
俺を煽ってどうする
狂犬か、お前ｗ

406 ：仕様書無しさん：2007/07/22(日) 02:04:59

想定しなきゃいけないこととか決めごととか、多くて多くて、だと
じゃあ再利用とかどうでもいいよ、となっちまうよ

407 ：仕様書無しさん：2007/07/22(日) 02:06:51

>>405
煽れれば誰でもよかった。
今は反省しているｗ

408 ：仕様書無しさん：2007/07/22(日) 02:13:14

スレの流れとか全然関係ないし、今更なレベルの話なんだけど、
クラスの使い方をもの凄く狭く考えている人がいるみたいなんで、あえて言わせてもらうけどさ。

C++でクラス使うとWinプログラムとか簡単に書けるけど、
昔はCでWinプログラムとかだとHello Worldに300行とかかかったりしてたんだよ。
もちろんライブラリの整理でもっと簡単にできるだろうけど、
良く作られたクラスライブラリだと、その辺の煩雑さを全て隠蔽して使える。

関数のライブラリだと、複数のライブラリ、複数の変数や引数を全部把握して
使い分ける必要があるけど、クラスなら作った時点で初期化も終わってる。
使いたい機能だけ呼び出して終わり。
ただ、これの問題点は、特定の関数だけ働きを変えたいって融通が効かない点。
カプセル化されてるからね。
そして、それを解決するのが継承。

これが普通に便利な継承の使われ方だろ。
POSレジなんかの操作の時も、自前でドライバ用意して、ボード初期化してとか
昔はやってたけど、今はオブジェクト作って、使いたい機能だけ呼んで終わり。
継承あるから、融通も効くしね。
別にいちから作るのだけが、クラスじゃないよ。

409 ：仕様書無しさん：2007/07/22(日) 02:14:57

>>406
いんじゃね？その感覚であってる
めんどくせえけど有用な局面もたまにはある、って仕事で使う分にはその程度

ま、それもこれも一通り工夫して何らか自分のモノにした後の話だわな
メリットが理解できないからハナから取り組まないなんつってたら、一生何も身につきゃしねえ

410 ：仕様書無しさん：2007/07/22(日) 02:17:02

バージョンやら期間やら違うときは例えできたとしても
ライブラリ部分とはあえて再利用をしてはいけない
メソッドかクラスにバージョン名付けて同じソースでも複製しろ

とくにプロジェクトにライブラリが複数バージョン絡んでくるときは気をつけたい
関数名が同じで挙動が違うってのが一番最悪、収集つかなくなる

411 ：仕様書無しさん：2007/07/22(日) 02:18:08

>>408
「特定の関数だけ働きを変えたい」という目的での継承はNGなんだそうで。

412 ：仕様書無しさん：2007/07/22(日) 02:18:18

>>410
だからあリスコフｒｙ

413 ：仕様書無しさん：2007/07/22(日) 02:18:39

>>411
誰の意見だ、そりゃ。

414 ：仕様書無しさん：2007/07/22(日) 02:19:07

>>408
全くいいことだとは思えない

415 ：仕様書無しさん：2007/07/22(日) 02:19:34

>>413
リスコフさん

416 ：仕様書無しさん：2007/07/22(日) 02:20:27

>>414
で、継承使わなくて、どう実現するのがいいんだい？
POSでもWinでもいいから、代替案を教えて欲しいな。

>>415
手首切る奴か？

417 ：仕様書無しさん：2007/07/22(日) 02:23:07

>>416
いや、そもそも使い方を間違ってると思う
継承だってあくまでオブジェクト指向を実現するためのもんだろ
それとそういう実装テク的な話がなんでこのスレで出てくるんだ？

418 ：仕様書無しさん：2007/07/22(日) 02:24:40

>>417
上で「継承は使わない方がいい」って言っている頭弱い系の人がいたから、
その人に継承の便利さを教えてあげようと思ったんだけど、
そもそも継承必要なレベルの開発してないだろうから、
別に要らないわなと今気づいたので別にどうでもいいわ。

ところで、>>414は代替案よろしくねｗ

419 ：仕様書無しさん：2007/07/22(日) 02:28:25

ちなみにPOSレジなんかオブジェクト指向そのものだよ。
キャッシュドロア、カスタマディスプレイ、プリンタ。
それらをオブジェクトして扱っている。
そんで表示機能を呼び出すときは、display()、印刷するときはprint()。
これほど分かりやすい対応関係もないと思うが。

420 ：仕様書無しさん：2007/07/22(日) 02:28:54

　　　　　　　　　　　　　　　また自作自演で100スレ以上伸びてるｗｗｗ

421 ：仕様書無しさん：2007/07/22(日) 02:29:23

>>418
いや、俺は君の継承の使い方が間違ってると思う
あくまで継承機能はオブジェクト指向の継承の概念を実現するためのものでなければならないと思う

だから代替案とかそういう話じゃないんだ
そもそも使い方が間違ってるし、概念がおかしい
実装ありきでやってるし設計も糞もねぇような作り方してんじゃん

422 ：仕様書無しさん：2007/07/22(日) 02:30:00

追いつめられて火病ったか。
自演とか無駄な改行ってキチガイ好きだよなぁ。

ところで>>414は代替案よろしくねｗ

423 ：仕様書無しさん：2007/07/22(日) 02:31:13

>>421
レスが遅いんで先読みでレスしちゃったよｗ
>>419参照。
で、実装の段階で継承は便利だと思うんだけど、継承が要らない理由ってなんだい？
そして継承を使わない場合、どう実現するのが便利なのかな。

424 ：仕様書無しさん：2007/07/22(日) 02:31:23

　　　　　　いまどき継承の使いこなしで悩むとは

　　　　　　とんだ初心者だな

　　　　　　いや、やっぱりキチガイの自作自演だろうな、このクオリティｗｗｗ

425 ：仕様書無しさん：2007/07/22(日) 02:32:23

↑↑↑↑↑↑　　　以上、平日昼間からやる事もなく引き篭もっている頭の悪い子が提供しました　　　↑↑↑↑↑↑↑

426 ：仕様書無しさん：2007/07/22(日) 02:32:59

>>422
なんどもいうけど君の長文は全部実装テクじゃん
オブジェクト指向云々とは関係ないんだけど？

やりやすいから継承使った

それ以上の意味をもってないよね？
代替案も糞も設計からやり直せよ
ここが一番大事なところだし、ここでおかしかったら実装なんてする意味ないと思う
むりやり継承を使ってる悪い例だと思う

427 ：仕様書無しさん：2007/07/22(日) 02:33:05

そもそも「こう使うべき」ってが頭悪いんだよな。
応用力ないっていうか。
そんで「じゃあどうするがいいか？」って聞かれると答えられない。
本来の使い方じゃないっていうなら、Ajaxとかもまさに邪道だけどな。
じゃあ、それなしでGoogle Mapどう実現するか聞かれても答えられない。
馬鹿過ぎ。
ていうか、普通に役立たずだな。
ガラクタ持論こねてるだけで、何も実現出来ない。

428 ：仕様書無しさん：2007/07/22(日) 02:35:04

>>426
なるほど。
ところでプログラムとは特定の機能を実現するためのものだと思うんだが、
POSレジとかを上手く操作するにはどういう設計がやりやすいのかな。
ヒントとか概念だけでもいいから教えて欲しいな。

それと>>419を読んで、「POSレジはオブジェクトじゃない」って言う理由も教えて欲しいな。
君の言うオブジェクトって何を指しているのかな？
基本、あらゆるものはオブジェクトとして扱えると思うけどね。

429 ：仕様書無しさん：2007/07/22(日) 02:36:42

書き換えて働きそのものを変えるよりも単に別メソッド実装して拡張すれば済むハナシだろう。
しかし書き換えるってことは「スーパークラスのインスタンスとし振る舞ったうえで別の働きを期待するから」なのだろうけど、
リスコフさんはそういう場合にこそ「不整合が発生しかねないからダメ」と。

430 ：仕様書無しさん：2007/07/22(日) 02:38:00

>>423
>そして継承を使わない場合、どう実現するのが便利なのかな
概念が違うから全くわからない

俺は現実のモデルをソースに落とすだけ
だから君の悩んでる問題は経験したことないと思う

431 ：仕様書無しさん：2007/07/22(日) 02:38:36

>>429
お前が馬鹿な理由は「オブジェクト指向はこうあるべき」とか
「○○さんがダメっていってるからダメ」って思考回路そのものが腐ってる点だと思うよ。
柔軟性や根拠がない。
ダメだからダメ。
そんなんじゃないもん。
それだけ。
「じゃあ作ってみなよ」って言うと何も出来ない。
良くいる役立たずの理屈屋だな。

432 ：仕様書無しさん：2007/07/22(日) 02:39:34

>>430
一番大事なとこを省略してないかｗｗｗ

433 ：仕様書無しさん：2007/07/22(日) 02:41:44

>>432
ワロタ。
確かになｗ

仕事で「コレ作ってくれないか」っていわれて
「そんなのはオブジェクトとは呼べないですよ。
それにボク、そんなケース経験したことないですし」
って。
これだけ使えない奴もなかなかいない。
睡眠削って馬鹿相手にしたわｗ

434 ：仕様書無しさん：2007/07/22(日) 02:42:06

>>408
MyPosレジみたいなラッパー作成して汎用Posレジをそこから使用しろ

435 ：仕様書無しさん：2007/07/22(日) 02:42:28

>>431　いやリスコフ否定派だよ　「どうせ派生しても使い捨てだし別によくね？」とね。
同じ問題に直面したら同じコトをするだろう

436 ：仕様書無しさん：2007/07/22(日) 02:43:05

>>431
本来ならオブジェクト指向有りきのＣ＋＋なのに実装ありきのＣ＋＋だよね
あくまで言語は実現する手段であって手段が目的になってはいけないと思う

たしかに構造は使えるかもしれないけど
理念を無視して使えるもんなんでも使い出してできてるからＯＫ的ないい方するなら
どう組んでもいいじゃない

437 ：仕様書無しさん：2007/07/22(日) 02:45:29

馬鹿相手にするのってマジ疲れるわ。
しかも実になる意見が一つもないのが凄い。
コイツ無職の趣味プログラマじゃね？
使えなすぎ。

438 ：仕様書無しさん：2007/07/22(日) 02:46:37

継承の話だけど俺には実装テクの話でしかないと思うけどね
継承でそんな糞みたいな問題がおきるのはすでにあるものを
設計を無視して強引に拡張しようとするから起きる実装レベルの問題でしかないじゃん

439 ：仕様書無しさん：2007/07/22(日) 02:48:38

>>437
>>408のレスからの一連の派生レスを言ってるなら
そもそも>>408の話は実装レベルの話で設計レベルの話ではないと思う
問題の切り分けとしてこれで設計が動いてしまうのはおかしいと思う

440 ：仕様書無しさん：2007/07/22(日) 02:49:42

>>408
気やすく継承するのはどうかな。

多少面倒でも、メンバに持ったほうがいいこともあるよ。

441 ：仕様書無しさん：2007/07/22(日) 02:49:46

そもそも振ってきた話題がかなり実装よりだし
継承がオブジェクト指向の継承の実現ではなくて
実装テクとしての継承の悪用だっただけに相手にしたくなかったってのが俺の本音

442 ：仕様書無しさん：2007/07/22(日) 02:53:10

こいつアレだろ

ＯＯ無関係に
単に差分プログラミングしたいだけっつう

そんならAOPやっとけって

443 ：仕様書無しさん：2007/07/22(日) 02:54:36

OOPにおいて実装はどうするかって重要な話だと思うんだが

444 ：仕様書無しさん：2007/07/22(日) 02:57:26

C++で、
あるクラスから、そのクラスを使う人に対して、コールバックをしたい
という場合に、継承を悪用する人が多い。

同じ名前のメンバがあると収拾が付かなくなるし、
一対多、多対一にできないので、先々で困る。
ラップしてやればいいんだけど、だったら最初から!

445 ：仕様書無しさん：2007/07/22(日) 02:58:38

>>443
それってクラスまでじゃない？
中のメソッドやらメンバの話まで出るのってやっぱおかしいよ

要は問題の切り分けができてないからどこまでどう拡張を考慮するのかわからない
から設計の影響範囲が見えてないだけでしょ？

だから実装まで踏み込んでみなきゃ
書いた設計が何に影響を及ぼすか想像がつかないって言う・・・
未熟な設計も実装で不具合でて設計作り直すところまで逆流してくるしね
過去そういう痛い目にあうとそう考えちゃうのかもな

446 ：仕様書無しさん：2007/07/22(日) 03:02:00

>>408は「働きを変えたい」という部分が過剰に捉えられ反応されたのでは。問題にされるとは限らない

447 ：仕様書無しさん：2007/07/22(日) 04:23:34

結局実装するスキルはないんだなｗ

448 ：仕様書無しさん：2007/07/22(日) 04:45:28

リスコフの置換原則でスーパークラスの振る舞いの定義を
「派生先で個別に定義されたメソッドを呼び出す」とすれば書き換えし放題なんだけどこれもアウト？
一応定義は満たしてるはずなんだけど

449 ：仕様書無しさん：2007/07/22(日) 05:52:07

ま、あれだな。
議題がはっきりしないまま会議をしてる姿そっくりだな。
無用に時間だけが過ぎ、何も決まらない典型。

450 ：仕様書無しさん：2007/07/22(日) 09:25:18

結論
おまいらの俺様解釈によるオブジェクト指向は複雑さを増幅させるだけ。
よってオブジェクト指向は嫌われる。

451 ：仕様書無しさん：2007/07/22(日) 09:57:04

おいおい。
「継承なんか要らない」って頭弱い人がいたから、
「継承は便利ですよ」って教えてあげたけど、
馬鹿だから理解出来ずにかみついてきたってだけだろ。
おまけに代替案ダセっていったら「そんなん知らん」とか言ってるし。
議題云々の話じゃない。

仕事で言ったら
俺「こういうクラスを作ってくれ」
アレ「いや、それは本来オブジェクトを使って実現するものじゃありません」
俺「そうか、じゃあ構造体でも関数でもいいから、とにかくこういう機能を実現してくれ」
あれ「いや、それは俺も経験ないんで分かりません」

って話の流れだぜ。
単にコイツが異常に使えない馬鹿って事だろ。
ただオブジェクト指向が使えない理由はよく分かった。
新しいものとか、高度なものってのは、それを使えない奴とか年寄りには不便とか苦痛でしかない。
数学は出来た方が便利だけど、馬鹿は数学嫌いだろ？
オブジェクト指向もそう。
使える頭があれば、いくらでも応用の利く便利な機能であり、概念。
頭固くて弱い、使えない馬鹿には、単なる重くて面倒で、限定された状況以外全く使えない
応用の利かない重荷。

ま、ゲーデルが不確定性原理で叩かれたり、コペルニクスが地動説で叩かれたり、
ビートルズが不良の聴く音楽だって言われたり、とかく頭の固い年寄りは理解できないものを叩く。
それだけの事。

452 ：仕様書無しさん：2007/07/22(日) 09:59:38

ま、今後のアドバイスとしては

頭の弱い奴がメンバにいた場合、プロジェクトから外した方がいいって事。
それでメンバー足りなくなるならオブジェクト指向と関連ない、最下層をやらせるか事だね。
戦力になるとは思えないけど。
そこそこスキルのある人なら、誰でもOOPが便利なのは分かってるだろうしね。

453 ：仕様書無しさん：2007/07/22(日) 10:07:07

継承で禁止されてるのは実装継承ね。
強力だが、実装継承のある設計は親クラスの修正が子クラスにダイレクトに効いてくるので
カプセル化を破壊してしまうのが大きい問題なのよ。
それと継承を前提として設計されると修正が全く効かないしね。
頭悪い不勉強な奴が差分プログラミングこそオブジェクト指向の利点だ！なんて間抜けな理解してると
「このクラスを継承してこのメソッドを実装してね」なんて言い出すと
たいていは使いづらくてしょうがない変更の効かない設計になるし。経験ない？

ちなみに推奨されるのはインタフェース継承。
クラス同士が抽象クラスにのみ依存することができ、保守や変更に非常に強くなる。
ってGoF本の1章にもあるし、オブジェクト指向入門でも何度も説明されてるし、
その他のあらゆる有名な本でもインタフェース継承をする利点が説明されてる。

>>448

結局継承で書き換えちゃったらなんでもありになっちゃうよね。
っていう問題に対しては契約による設計って考え方がある。
C++、Java、C#なんかには実装されていない設計手法でこれらの言語では利用できないけどね。

454 ：仕様書無しさん：2007/07/22(日) 10:09:24

相変わらず長文くんのクオリティは低いな

まで読んだ

455 ：仕様書無しさん：2007/07/22(日) 10:10:32

>>454
確かに。
同じ長文でも>>451は知性に満ちあふれているのに、>>453はクオリティ低いよねｗ

456 ：仕様書無しさん：2007/07/22(日) 10:14:30

＞C++、Java、C#なんかには実装されていない設計手法でこれらの言語では利用できないけどね。

長いんで最後だけ読んだが、この1行だけで馬鹿の典型ってのがよく分かる。
上司「こういう機能を実現してくれ」
アレ「それはオブジェクト指向とは呼べません」
上司「なら、他の機能でもいいから実現してくれ」
アレ「その機能はJavaにはないので、Smalltalkで作ります」
上司「よし、死ね」

457 ：仕様書無しさん：2007/07/22(日) 10:17:09

OOPに限った話じゃないけどさ、本来こうあるべきとかで理屈コネくりまわして
結局「じゃあどう実装すんの？」って聞かれた時、現実的な答えが出せない奴は
使えないどころか、邪魔なんだよな。
そういうトンデモ理論級の奴がいるなら、OOPは避けた方が良い。
もっとも避けた所で、他でも邪魔するだろうけど。

458 ：仕様書無しさん：2007/07/22(日) 10:23:42

契約もassertとマクロで無理やり作るぐらいならC++でもいけるんでない？

459 ：仕様書無しさん：2007/07/22(日) 10:24:55

人のこと馬鹿、馬鹿言うやつのほうが馬鹿に見える。

460 ：仕様書無しさん：2007/07/22(日) 10:31:17

>>459
つまりお前が馬鹿だって事か。

461 ：仕様書無しさん：2007/07/22(日) 10:39:28

>>458
無能クンの主張によると、そういう本来の用途と違う使い方はNGだろ。
つまり実現不可能。

462 ：仕様書無しさん：2007/07/22(日) 11:11:32

オブジェクト指向はダメだって意見と
構造化プログラミングはダメだって意見が
似ているような気がするのは俺だけだろうか

463 ：仕様書無しさん：2007/07/22(日) 11:26:27

>>462
「頭弱い奴に使えないから使えない奴が文句言う」って構造では一緒の問題だろ。
トンデモ物理とかと同じで、頭弱い奴がそれを自覚してない事から発生する問題。
別に相手にする必要もなく、便利に使えば済む話。
そういう奴と同じ職場で仕事しないようにする努力の方が重要だな。

464 ：仕様書無しさん：2007/07/22(日) 11:51:05

実装能力ないなら口ださなきゃいいのに。
最終的な実装をイメージ出来ない人の設計なんか使い物にならないよ。

465 ：仕様書無しさん：2007/07/22(日) 11:58:09

朝から延びてんな
リスコフ否定派には笑ったｗ
継承使わずに振る舞いだけかえたきゃ、
ファンクタ受け取ってそれコールバックしてやりゃいいだろ

466 ：仕様書無しさん：2007/07/22(日) 12:12:55

C++やJavaのような、なんちゃってオブジェクト指向言語では無理。
グダグダになるのがオチ。

467 ：仕様書無しさん：2007/07/22(日) 12:16:01

何が無理？

468 ：仕様書無しさん：2007/07/22(日) 12:24:12

なんかバトルしてたみたいだが、頭でっかちな方は痛々しいなあ。
オブジェクト指向はこうあるべしと言いながら、その核となる内容が無い。

継承が良い悪いどうのこうのとかリスコフ置換がどうのこうのとか、
いろいろやり取りがあるが、
”継承ができる”のはオブジェクト指向の姿。

それをどう扱うか（API仕様）は設計の話であって、
継承はこうあるべし、
などと言い出す奴は言語仕様と設計の話が区別できてない。

リスコフ置換も「こういうやり方がありますよ」というだけであって、
こうしなければならない！という話でもないし。
別に否定派じゃないからな。他にも理論はある、ということ。

469 ：仕様書無しさん：2007/07/22(日) 12:31:51

>>458
assertなんてデバッグ時だけじゃないか。

470 ：仕様書無しさん：2007/07/22(日) 12:37:09

assertだの、loggingだの、DB 接続・開放だのメンドクサイことは全部、aspectで
wavingすればいいとおもうよ

471 ：仕様書無しさん：2007/07/22(日) 12:42:46

リスコフ置換は「継承すんな」って話じゃなくて
「継承するときは、原則としてこのルールに従え」っていう話だぞ

472 ：仕様書無しさん：2007/07/22(日) 12:54:03

>>471
その通りだな。
ただ、その原則を守るか別の方法を取るかは別の話。

たとえばC++では多重継承ができることが問題になるが、
場合によっては多重継承をうまくつかうことによって
とてつもなく優秀なものができるかもしれん。

まあ、多重継承はダメやけどね。
結局はどういう作り方にせよ、一貫性の無い設計がダメってこと。

473 ：仕様書無しさん：2007/07/22(日) 13:04:00

多重継承できれば、ブリッジパターンなんかはいらなくなるのかねえ。
JavaのORMで永続オブジェクトなんか使うとき、同じクラスにドメインモデルとしてのクラス階層と
永続化機能のためのクラス階層と割り当てる必要がでてくるけど多重継承できれば悩む必要ないしな。

474 ：仕様書無しさん：2007/07/22(日) 13:18:34

多重継承は扱いが難しいよね。
ヘボに使わせると大変な事になるから原則無しでいいな。

475 ：仕様書無しさん：2007/07/22(日) 13:22:13

そういう意味では継承も原則無しでいいな。

476 ：仕様書無しさん：2007/07/22(日) 14:05:33

>>475
こんなこと言い出す奴が言語仕様と設計の区別ができないんだろ

477 ：仕様書無しさん：2007/07/22(日) 14:08:14

「継承はするな」　と言ってる奴も
「多重継承をするな」　といってる奴も、

どっちも言語仕様と設計の区別ができないんだと思うよ

多重継承は実装面で非常に役立つのはすでにRubyで証明されている。

478 ：仕様書無しさん：2007/07/22(日) 14:09:55

Rubyに多重継承ないけど。
C++の間違いだろ

479 ：仕様書無しさん：2007/07/22(日) 14:10:49

上手に使いこなすのは難しいので、無理して使うな

たったこれだけの話じゃないか。

480 ：仕様書無しさん：2007/07/22(日) 14:11:02

>>478
え？
mix-inっは実装の多重継承だよ？
よーく考えてみ。

481 ：仕様書無しさん：2007/07/22(日) 14:13:32

>>480
知ってらそんなもん

482 ：仕様書無しさん：2007/07/22(日) 14:13:36

>>477
Rubyの多重継承は制限付き。
C++と同じではない。

483 ：仕様書無しさん：2007/07/22(日) 14:14:01

>>481
は？？？

じゃあ478は、意味が不明なんですけど

484 ：仕様書無しさん：2007/07/22(日) 14:15:19

こっちが、は？だよ
ミキシンなんて大昔からある概念だっつの
>>477が意味不明

485 ：仕様書無しさん：2007/07/22(日) 14:15:25

>>482
アホ、「C++と同じではない」って、俺がいつ「C++と同じ」とか言ったんだよ。

実装の多重継承は、実装面では有効だって言ってるんだよ。

486 ：仕様書無しさん：2007/07/22(日) 14:16:08

>>484
いやいや、478の意味がわからんよ。

487 ：仕様書無しさん：2007/07/22(日) 14:16:17

それは多重継承って言わなくね？

488 ：仕様書無しさん：2007/07/22(日) 14:16:19

お前がRubyで証明とかわけわからんこというからだろ

489 ：仕様書無しさん：2007/07/22(日) 14:17:12

>>487
言うよ。Rubyの作者も言ってるよ。

>>488
お前は478のレスの意味を説明しろバカ

490 ：仕様書無しさん：2007/07/22(日) 14:17:25

・一般的にRubyには多重継承は「無い」とされる
・mix-inはRuby起源ではない

これでわかるかボケナス

491 ：仕様書無しさん：2007/07/22(日) 14:20:54

>>490
>・一般的にRubyには多重継承は「無い」とされる
しかし、作者は「実質的にある」と言ってる

>・mix-inはRuby起源ではない
なんで俺がmix-inの始祖の言語の名前を出さないといけないの？

第一さあ、C++が起源でもないけど？
478の「C++の間違いだろ」って何が間違いなの？意味不明すぎ。

これでお前の意味不明さがわるかボケナス

492 ：仕様書無しさん：2007/07/22(日) 14:23:28

>>491
うぜえからすっこんでろカス、としかいいようがねえな

493 ：仕様書無しさん：2007/07/22(日) 14:24:00

>>492
反論できなくなるとコレだよｗ

494 ：仕様書無しさん：2007/07/22(日) 14:26:13

反論ときたもんだ。おまえ一人でいってればいいだろ

「実装の多重継承の有効性はRubyで証明された」pgr

495 ：仕様書無しさん：2007/07/22(日) 14:27:09

>>494
はいはい、もう無駄に噛み付くなよ。お前は負け犬なんだから。

話を戻して、
Javaの勢力が増すにつれ、悪とされていた「多重継承」「実装の継承」は
mix-inと呼び名を変え、また有効だと認知されつつあるっつーことで。

「継承はするな」　と言ってる奴も
「多重継承をするな」　といってる奴も、

どっちも言語仕様と設計の区別ができないんだと思うよ

496 ：仕様書無しさん：2007/07/22(日) 14:28:11

Ruby厨、性懲りも無く生き恥さらしてんなｗ

497 ：仕様書無しさん：2007/07/22(日) 14:30:00

なるほどね。こうやって逆恨みを買ってしまうわけだ。
Ruby厨、っていう言葉に頼ってしまったね。残念だ。

498 ：仕様書無しさん：2007/07/22(日) 14:33:45

>>495
それは語弊のある言い方じゃないか？
結局普通の継承関係での多重継承はあまり有効では無いってことだろ？

499 ：仕様書無しさん：2007/07/22(日) 14:33:51

>>495
Javaで実装の継承が悪とされてたってのは違うだろ
おまえ実装寄りの話しらねえんだから無理スンナよ

500 ：仕様書無しさん：2007/07/22(日) 14:38:08

>>499
何がどう違うのか説明頼む

501 ：仕様書無しさん：2007/07/22(日) 14:38:49

相手に理解されなくてもなんでもいいから、とにかく議論に負けたくない
って思いがビンビン伝わってくるなｗ

なら最初からレスすんなって話だ

502 ：仕様書無しさん：2007/07/22(日) 14:39:34

MixInは特殊な多重継承

503 ：仕様書無しさん：2007/07/22(日) 14:40:09

>>501
何が理解できなかった？

つーか、議論って？478の言いがかりは議論とは呼ばんよｗ

504 ：仕様書無しさん：2007/07/22(日) 14:40:37

おまいらコテつけてくんねえかなｗ
スパゲティみたいに絡まってる。

505 ：仕様書無しさん：2007/07/22(日) 14:42:41

>>503
くだらない話はどうでもいい
>>477の主張が相手に伝わらなきゃどうしようもないだろ
お前の中だけで勝利宣言しててもよお

506 ：仕様書無しさん：2007/07/22(日) 14:44:05

>>505
で、何が理解できなかったの？

507 ：仕様書無しさん：2007/07/22(日) 14:45:54

>>506
で、なんでお前が叩かれてるか何が理解できなかったの？
って聞いてるようなもんだ

くだらねえつってんだよ

508 ：仕様書無しさん：2007/07/22(日) 14:48:24

>>507
お前が「相手に理解されなくてもなんでもいいから」とか批判してるから、
やさしく説明してやろうと、何が理解できなかったか聞いてるのに、なんでそう突っぱねるの？

なんだよお前、俺に「何が理解できなかったか理解されなくてもいい」の？

相手に理解されなくてもなんでもいいから、とにかく議論に負けたくない
って思いがビンビン伝わってくるんですけど。

なら最初から501の書き込みすんなよ。

って、お前の「501理論」ならなるよ？俺はそんな理論主張はしないけどね。

509 ：仕様書無しさん：2007/07/22(日) 14:48:54

どっちももういいよ。
お茶でも飲んでもちつこうや。

510 ：仕様書無しさん：2007/07/22(日) 14:52:15

>>508
突っぱねてねえだろ

「お前に何が理解されなかったか理解されなくてもいい」に決まってんだろ
自意識過剰か、お前は

くだらねえ揚げ足取りの応酬してんな、うぜえっつってんだよ

511 ：仕様書無しさん：2007/07/22(日) 14:52:53

もまえらみんな、お茶ド・ド・ド・ド・ドゾ－

　　　　　　　∩∧＿∧ ∧＿∧旦~
　　　　　∧ヽ∩旦ﾍ＿∧´∀｀∩il
　　　　　（´∀ |lヽ∩´∀｀）　　ノ
　　　　旦⊂二､ミヽ　　　 ⊃旦~
　　　　　　　　/ (⌒)　ﾉ彡∧＿∧ミ
　　　　　　　（＿）~　し' ⌒つ´∀｀）つ旦~

512 ：仕様書無しさん：2007/07/22(日) 14:53:59

どっちも喧嘩ならこっちでやれ。
http://pc11.2ch.net/test/read.cgi/prog/1173840514/

513 ：仕様書無しさん：2007/07/22(日) 14:54:08

お二人さん、理性の残ってるほうが流れを戻したら？

514 ：仕様書無しさん：2007/07/22(日) 14:55:04

>>510
>「お前に何が理解されなかったか理解されなくてもいい」に決まってんだろ

？？？　じゃあ501のレスが意味が不明過ぎる。

この意味不明な「ただ噛み付きたいだけ」な奴、ほんのちょっと前に居たな。

つーか、くだらないって何度も言うぐらいなら、そもそもレスすんなよ。どんだけ低脳だよ。

515 ：仕様書無しさん：2007/07/22(日) 14:58:57

多重の実装の継承ならJavaにもimplementsっていうのがモロにあるんだが
あれとは話が違うのか？

516 ：仕様書無しさん：2007/07/22(日) 15:00:27

それはインターフェースね

517 ：仕様書無しさん：2007/07/22(日) 15:00:29

あれはインターフェイスの多重継承で、実装の継承とは言わないでしょ

518 ：仕様書無しさん：2007/07/22(日) 15:02:38

>>515 あれはインタフェースの実装。

519 ：仕様書無しさん：2007/07/22(日) 15:03:26

>>451
お前ってどういう理解でオブジェクト指向使ってるの？
>>453のいうような差分プログラミングこそオブジェクト指向の利点とか考えてる性質？

なんかね、お前、「オブジェクト指向わかって無い奴」に見えるんだ

520 ：仕様書無しさん：2007/07/22(日) 15:03:34

>>514
あげあしとりの応酬がくだらないっつってんの

521 ：仕様書無しさん：2007/07/22(日) 15:05:13

「クラスがimplements節の中でインタフェースを宣言する場合、
それは対象インタフェースの各メソッドについて実装を提供することを意味します」

522 ：仕様書無しさん：2007/07/22(日) 15:08:21

JAVAは静的型付けだから悩んだあげく、ああしたんだろうね

523 ：仕様書無しさん：2007/07/22(日) 15:10:51

設計の一番初めに”多重継承はしない”と取り決めをするかどうかなんよ。
しないと決めたらしない。例外は認めない。
これぐらいの意思を持って設計をやればいい。

多重継承禁止というルールを設計段階で決めたとした場合に、
ありがちなのは、ルールを守らない奴が「あ、このクラスいいじゃん」とか言って
約束事を守らずに多重継承をやり始めること。

多重継承に関わらず、
こうなって責務がよく分からんようになり、
荒れることがOOが嫌われる（というか敬遠される）原因の一つ。
そういったことから、OOは一人でやるもの、とかの論調があるわけじゃん。

524 ：仕様書無しさん：2007/07/22(日) 15:14:28

ウザ度で言うと
多重継承乱発くん＞実装の継承のみであり難がってるくん＞継承のメリットを知らず不用と喚くくん＞現実モデル→ソースくん

525 ：仕様書無しさん：2007/07/22(日) 15:14:45

継承禁止とか取り決めされたらどうするよ

526 ：仕様書無しさん：2007/07/22(日) 15:15:11

ルールを守れない奴がいるからXXが嫌われるとか言い出したら、
構造化設計だろうがなんだろうがあてはまるんじゃね？

527 ：仕様書無しさん：2007/07/22(日) 15:16:18

>>524
現実モデル→ソースくんは継承の話と関係ないだろ

528 ：仕様書無しさん：2007/07/22(日) 15:16:19

>>526 はげど

529 ：仕様書無しさん：2007/07/22(日) 15:16:59

>>525
末端は継承禁止でもいいんじゃね？

530 ：仕様書無しさん：2007/07/22(日) 15:18:16

>>529
サーブレットがつくれません。。とか言われちゃう

531 ：仕様書無しさん：2007/07/22(日) 15:18:37

>>527 まぁ、横断的なウザ度だからｗ
現実モデル→ソースくんはなんというか、もはや微笑ましいのであんまウザくもないという。

532 ：仕様書無しさん：2007/07/22(日) 15:20:33

>>531
現実モデル→ソースくんimplements多重継承乱発くん
とかｗ

533 ：仕様書無しさん：2007/07/22(日) 15:20:43

一番ウザ度が高いのは、「ウザいウザいとうるさいくん」だな。正直。

534 ：仕様書無しさん：2007/07/22(日) 15:21:57

>>532 そんなモンスターがいたら、全滅されられます＞＜

535 ：仕様書無しさん：2007/07/22(日) 15:22:17

>>530
作るクラスとそのインターフェイスまで用意してやる
設計者の負担でかくなっちゃうかな

536 ：仕様書無しさん：2007/07/22(日) 15:22:50

implements多重継承乱発くん　って何？

537 ：仕様書無しさん：2007/07/22(日) 15:23:51

implements というより、extends だろうな。条項

538 ：仕様書無しさん：2007/07/22(日) 15:23:57

　　　　　　　　　　　　　　　　　　　　　／.⌒ヽ
　　　　　　　　　　　　　　　　　　　／　　　　..＼
　　　　　　　　　　　　　　　　　　../　　　　　ヽ.　＼
　　　　　　　／￣￣＼　　　　 (./　　　　　　 .ヽ.　）
　　　　　　／　　　　　＼　　 /　　　　　　　　　l"　　
　　　　　　|:::::: 　　　　　｜　.ﾉ　　　　　　　　　l
　　　　　.　|:::::::::::　　　　　 |　 | 　─　　 ─ 　　.::| 　　俺のおなかにゴハンつめろ
　　　　　　 |::::::::::::::　　　　｜ .|　（●）　（●）　.:::::|
　　　　　.　 |::::::::::::::　　　　} 　|　　（__人__）　　..:::::::| 　
　　　　　.　ヽ:::::::::::::: 　　 }　　ヽ.._ ｀ ⌒´ 　　　_,ノ
　　　　　　　ヽ::::::::::　　ノ　　　　|　　　　　　　　　＼
　　　　　　　　/:::::::::::: く　　　　　|　|　　　　　　　 | 　|
-―――――|:::::::::::::::: ＼――┴┴――――-┴┴――

539 ：仕様書無しさん：2007/07/22(日) 15:24:09

>>536
すまんニュアンスでわかってくれｗ

540 ：仕様書無しさん：2007/07/22(日) 15:27:59

>継承のメリットを知らず不用と喚くくん

継承のデメリットを知らず絶対必要とわめくくんは何位？

541 ：仕様書無しさん：2007/07/22(日) 15:30:11

>>540 いっしょか、それ以上のウザさでしょうね。
いや違う、かなりウザイはず。そして悲惨なコード量産してるはず。

542 ：仕様書無しさん：2007/07/22(日) 15:31:24

まあ継承のデメリットよりメリットの方が
先にわかるはずだしな

543 ：仕様書無しさん：2007/07/22(日) 15:32:08

非OOPLしか使ったことない時でさえ、
「C++での多重継承がウンタラ」という怪談はさんざん耳にしてた。
だから、多重継承というものをしょっぱなから恐れていた。

544 ：仕様書無しさん：2007/07/22(日) 15:32:09

多重継承もメリットの方が咲きにわかるのに、「絶対禁止」とか言う不思議

545 ：仕様書無しさん：2007/07/22(日) 15:35:12

>>544
ヒント：Java信者

546 ：仕様書無しさん：2007/07/22(日) 15:35:19

>>544
多重継承やっちゃうと役割が怪しくなる場合があるからね。
分かっててやるならいいけど、
goto文と同じように危ないものには触らない方がいい、
ってことでしょ。

547 ：仕様書無しさん：2007/07/22(日) 15:35:55

まぁ、賢者の知恵だな。

548 ：仕様書無しさん：2007/07/22(日) 15:38:41

多重継承があってもそれほど必要な場面も多くないし

549 ：仕様書無しさん：2007/07/22(日) 15:39:38

>>546
継承を嫌ってる人も、多分それと同じ発想なんだろうね。

俺からしてみれば、どっちもアレなんだが。

550 ：仕様書無しさん：2007/07/22(日) 15:39:56

火を恐れて使わないのも愚か。
火を効果的に使えないばかりか、
間違って使ってしまうのも愚か。
いずれも、原始人の態度である。

551 ：仕様書無しさん：2007/07/22(日) 15:41:32

ま、今となっては多重継承は有りでいいな

552 ：仕様書無しさん：2007/07/22(日) 15:44:23

>>550
Javaは火を恐れて使えないようにした＝プログラマーを守る
C++は火を使えるようにした＝プログラマーに任せる

もし火が怖いならJavaを使った方がいいかもしれません、
有効に使えるならC++を使った方がいいかもしれません。

もし多重継承が怖いなら、以下略

553 ：仕様書無しさん：2007/07/22(日) 15:46:00

多重継承で問題になるのはメソッドの探索順

554 ：格之進 ◆xiPQGz7lVI ：2007/07/22(日) 15:55:54

どうしても多重継承が必要な場面というのは限られるんじゃないでしょうかね。
Java の場合、Interface を使えばたいがいの場合はそれで済んでしまうように思いますが。

555 ：仕様書無しさん：2007/07/22(日) 16:00:38

>>554
根本的な間違いがある。
Javaは多重継承が言語仕様として使えない。

556 ：格之進 ◆xiPQGz7lVI ：2007/07/22(日) 16:07:21

>>555
ええと、誤解を招く書き方ですいません。

Java の場合（言語仕様として多重継承を持っていませんが）、
（多重継承が必要とされるような問題の多くは、多重継承の代わりに、）
Interface を使えばたいがいの場合はそれで済んでしまうように思いますが。

という意味です。

557 ：仕様書無しさん：2007/07/22(日) 16:07:56

Javaしかしない人と、Javaに無い機能の話をすると、
彼らは一様に"なくてもなんとかなる"としか言わない。

そりゃ無くてもなんとかなるだろうが、不便だという話をしてるのに、
"なんとかなる"と言われても困る。

"なんとかなる"で済ませたら、ほとんどの言語機能は要らなくなってしまう。

Cしかしない人は "クラスがなくてもなんとかなる" と言うだろうさ。

558 ：仕様書無しさん：2007/07/22(日) 16:12:33

言語仕様寄りの話が続いてるけど、
オブジェクト指向としては継承とポリモとクラスで、
役割を作って設計するってことじゃん。

それができて初めて実装するんだし。
言語仕様以前の話じゃねーの？オブジェクト指向って。

559 ：格之進 ◆xiPQGz7lVI ：2007/07/22(日) 16:17:13

まあおそらく、「不便」「なんとかなる」について、
一般論としてどちらかに決めてしまうのは無理なんじゃないでしょうかね。
個人個人のやり方の違いもあるでしょうし。

それよりも、具体的に、どういうふうに不便か、どういうふうになんとかなるのか。
という話をしたほうが有益だと思いますが。

560 ：仕様書無しさん：2007/07/22(日) 16:22:18

>>558
クラスと継承が存在する時点で多重継承問題を内包してると思う

561 ：仕様書無しさん：2007/07/22(日) 16:28:55

>>556
>Java の場合（言語仕様として多重継承を持っていませんが）、
>（多重継承が必要とされるような問題の多くは、多重継承の代わりに、）
>Interface を使えばたいがいの場合はそれで済んでしまうように思いますが。

思うから何？
そもそも>>554は誰に向けたレスなの？

562 ：格之進 ◆xiPQGz7lVI ：2007/07/22(日) 16:30:54

>>561
特に、どなたかに向けたレスではないです、ですからレス先をつけていません。
何かお気にさわったのならごめんなさい。

563 ：仕様書無しさん：2007/07/22(日) 16:32:23

なんかおまぃらトゲトゲしぃな。
お茶飲んで気楽にいこうや。

564 ：仕様書無しさん：2007/07/22(日) 16:32:24

>>562
では、>>554はどんな意見に対する意見なの？

唐突に言ってみたくなっただけ？

565 ：仕様書無しさん：2007/07/22(日) 16:33:44

読み手依存って奴だ
もちつけや

566 ：仕様書無しさん：2007/07/22(日) 16:36:35

質問してるだけじゃん。おまえが落ち着け。

567 ：仕様書無しさん：2007/07/22(日) 16:38:11

狂犬がいるなｗ

568 ：仕様書無しさん：2007/07/22(日) 16:48:47

暴れてんのは瑠媚厨ですか？

569 ：仕様書無しさん：2007/07/22(日) 16:57:46

とりあえずUMLを書くのがめんどい

570 ：仕様書無しさん：2007/07/22(日) 16:58:34

実装テクの話が好きな奴はこのスレくるなよ、っていつも思う
お前等のはオブジェクト指向じゃないからｗ

571 ：仕様書無しさん：2007/07/22(日) 17:05:53

アンチOO以外は来るなよｗ

572 ：仕様書無しさん：2007/07/22(日) 17:08:04

実装以外の話って何を話せばいいんだろう

573 ：仕様書無しさん：2007/07/22(日) 17:09:02

ポエム

574 ：仕様書無しさん：2007/07/22(日) 17:09:11

>>569
メンドイよね。

人間が書くのはテキストで、それを分析するときにビジュアルに表示する
というのでいいと思うんだけどなぁ。

あと情報が散在して人間が一貫性を維持するために管理するのも馬鹿馬鹿しい。
かといって統合ツールは、なんかお仕着せっぽくてな。

575 ：仕様書無しさん：2007/07/22(日) 17:22:28

Microsoft ProjectみたいなUMLツールが出てくればなあ
設計作業よりUML書く作業に時間かかる

576 ：仕様書無しさん：2007/07/22(日) 17:38:13

>>568
話の感じだとC++じゃないか?

577 ：仕様書無しさん：2007/07/22(日) 17:56:21

正直UMLは仕様細か過ぎな気がする

578 ：仕様書無しさん：2007/07/22(日) 18:06:35

UML書ける技術者が圧倒的に少ないよな。
JavaやC++の案件でクラス図がまともに存在してるとこ見たことないし。
UMLって何？って奴も多い。

579 ：仕様書無しさん：2007/07/22(日) 18:07:46

>>574
UMLのデータってXMLで保存できるから、
バージョン管理ツールに入れて管理すればよくない？

580 ：仕様書無しさん：2007/07/22(日) 18:14:01

UMLは手で書くの面倒なんでEA使ってるお^^

581 ：仕様書無しさん：2007/07/22(日) 18:51:07

C++でも実装を入れた多重継承をすると結構凶悪な事態に陥るので、
結局多重継承を行ったとしてもJavaやC#のinterfaceと同等の範囲でしか使えない
取り分け、virtual 多重継承のコンストラクタは悪夢だし、非virtual多重継承では何がどうなっているのか分け分からなくなるしで、
おれは、interfaceで十分だとおもうな。
そもそも、JavaのinterfaceはC++の多重継承から必要なものを抽出したものだから、これで十分だろ。

582 ：仕様書無しさん：2007/07/22(日) 18:54:37

特化の為に多重継承使ってるのなら、特化をtraitsで実現すればいいらしいけど
modern C++読んだ事無いからよく分からない

583 ：仕様書無しさん：2007/07/22(日) 19:17:21

　　　　　　　　　　　　　　　　　　　　　　相変わらずひどい自作自演だな

584 ：仕様書無しさん：2007/07/22(日) 19:25:20

>>579
駄目だ
バージョン管理ツールってプログラマ以外使えない
バージョン管理ツール事態の誤操作までサポートしてくれるわけじゃないところが一番の欠点だなｗ

585 ：仕様書無しさん：2007/07/22(日) 19:30:16

>>584
プログラマ以外がバージョン管理の必要に迫られているのか？
Subversionあたりを採用してGUIフロントエンドでも作ってやれよ、
これなら無能でなければ一日作業でできるだろ。

586 ：仕様書無しさん：2007/07/22(日) 19:36:51

上にそういう発想が無いかは知らんがそんな要求がくるのなんて無いし
せっかく作っても個人が作ったものなんて採用しません( ´,_ゝ｀)って言われて検討すらされない
チーム内で使っててもセキュリティの問題とか理由で禁止され始末書

なのは俺のレベルが低いからですかそうですか

587 ：仕様書無しさん：2007/07/22(日) 19:38:46

>>586
可哀想だな。

588 ：仕様書無しさん：2007/07/22(日) 19:45:08

>>586
お前らみたいな低脳とは一緒に仕事できませんって書いた辞表たたきつけて別の会社に移れ。

589 ：仕様書無しさん：2007/07/22(日) 19:52:37

>>581
お前らみたいな低脳とは一緒に仕事できません

590 ：仕様書無しさん：2007/07/22(日) 20:02:43

>>585
>Subversionあたりを採用してGUIフロントエンドでも作ってやれよ
RapidSVNっていうの入れたけどこれが最悪
プログラマはそんなにミスしねぇし、なんかおかしくなったら削除して全部とってくるとか頭回るんだけど
わかんない人はエラー出てるのにそのまま突っ走るからおかしくなったまんまになる

しかも、RapidSVNって結構動作が糞
なんか更新思いっきり時間かかるし、強制的に上書きとかできないから
ＶＣのプロジェクトファイル開いただけで一度こっちの変更取り消してから上書きしないと
リポジトリとちゃんと整合性とれてるかどうかわかりずらい

しかも、日本語の文章すくねーって状態

591 ：仕様書無しさん：2007/07/22(日) 20:19:24

>>590
なるほど・・・
エロ本を買いてーけど気が小さくて買えねー
それでしょぼくれてたってわけか・・・

592 ：仕様書無しさん：2007/07/22(日) 20:41:37

>>590
TortoiseSVNは試してみました？

593 ：仕様書無しさん：2007/07/22(日) 21:11:38

えーっと、
スレ違い？

594 ：仕様書無しさん：2007/07/22(日) 21:14:10

いいんでないの？

595 ：仕様書無しさん：2007/07/22(日) 21:19:19

>>579
そういう問題じゃぁない。

ソースコードとUMLの同期、もしくは関連ドキュメントとの同期の問題。

596 ：仕様書無しさん：2007/07/22(日) 21:20:49

>>581
is-aではなくhas-aなのに継承するアホが多いからな。
メンバに持つのを面倒くさがるような人は、どうかと思う。

597 ：仕様書無しさん：2007/07/22(日) 21:22:52

>>579
バージョン管理ツールは、XMLを単なるテキストデータとして扱うだろ?
UMLの図の上で、変更についてビジュアルに表示することはできない。

598 ：仕様書無しさん：2007/07/22(日) 21:55:56

>>595
ソースコードや、UMLや、関連ドキュメントを同じバージョン番号で管理すれば、
その版の一式を取り出せるようになるんじゃね？

同期する作業自体は、人の作業になるかな
（支援するツールは何かありそうな気もするけど）

>>597
xmldiffっていうXMLの構造を考慮して差分を検出するツールがあるから
その出力をつかって元UMLのXMLの変更部分の属性を変えるとか
出来そうな気がする。

599 ：仕様書無しさん：2007/07/22(日) 22:07:21

新人に、
同じ内容の関数をあちこちに作ってはいけない
同じ内容のコードをあちこちに書いてはいけない
と言うでしょう。

それなのにドキュメントは同じ内容をあちこちに書く。

おかしいよね。

600 ：仕様書無しさん：2007/07/22(日) 22:12:04

>>596
うかつな継承はマジで収集つかなくなるからな、has-aなら百歩譲って許す、最悪に酷いのは単純に機能拡張に継承を使おうとするケース
もうね逝って良し

601 ：仕様書無しさん：2007/07/22(日) 22:22:28

継承は弊害が多い。
ちゃんと設計してないのに
やたら継承を使うのはどうしょうもない。
確実に火を噴く

602 ：仕様書無しさん：2007/07/22(日) 22:25:20

is-a、has-aってなんだ？

603 ：仕様書無しさん：2007/07/22(日) 22:27:40

実装の楽のために継承するならprivate継承にすべき。

604 ：仕様書無しさん：2007/07/22(日) 22:29:32

>>602
ソモサン！セッパ！
みたいな物だ

605 ：仕様書無しさん：2007/07/22(日) 22:29:59

>>602
っ Googleで日本語ページを検索して一番上に来るもの
ttp://www.atmarkit.co.jp/farc/rensai/column/world09/world09.html

606 ：仕様書無しさん：2007/07/22(日) 22:40:35

もはや研究理論だな

607 ：仕様書無しさん：2007/07/22(日) 22:49:51

URL読んだ。
なんつか、まどろっこしいな。

608 ：仕様書無しさん：2007/07/22(日) 22:55:26

説明が長ったらしいよな。

609 ：仕様書無しさん：2007/07/22(日) 23:09:00

>>606
デザインパターンよりも、よっぽど簡単で実用的な指標ですよ?

A is a B
ならば継承する。

A has a B
ならば継承せずにメンバに持つ。

610 ：仕様書無しさん：2007/07/22(日) 23:18:58

is-a関係とか知らない奴がオブジェクト指向がどーのとか語ってたのか？
オブジェクト指向が普及しないのは低脳どものせいだって言われる理由がわかったわ

611 ：仕様書無しさん：2007/07/22(日) 23:20:56

じゃあ優秀な設計者様が指定しといてあげればいいよ
コーダがアホでも大丈夫なようにね

612 ：仕様書無しさん：2007/07/22(日) 23:22:14

is-aとかの関係を述語論理式で判定する方法教えてください＞＜

613 ：仕様書無しさん：2007/07/22(日) 23:26:39

is-aの関係

this->pen

614 ：仕様書無しさん：2007/07/22(日) 23:28:18

I am a pen!

615 ：仕様書無しさん：2007/07/22(日) 23:28:49

>>605
それの次のページとか、例えが多過ぎるな
オブジェクト指向やるぞー、って人間が最初に買った言語本でそういう説明が多いと
誤解する可能性が高いのではないか。（それでも一応使えるから矯正されなかったり）

616 ：仕様書無しさん：2007/07/22(日) 23:32:30

ttp://www.atmarkit.co.jp/im/carc/serial/world21/world21.html
このページとか・・・

617 ：仕様書無しさん：2007/07/22(日) 23:36:40

has-aはどうするんですか？
あるページでは「aはbを持っている」を
a～bみたいに表記してましたがこんな記号あるんですかね？

618 ：仕様書無しさん：2007/07/22(日) 23:40:34

>>617
俺には分からないから
河合昭男さんに聞いてくれ

619 ：仕様書無しさん：2007/07/22(日) 23:49:03

c++に従うなら

this : pen (is-a)
car->tire (has-a)

ってかんじ？

620 ：仕様書無しさん：2007/07/22(日) 23:59:10

趣旨は変わってしまいますが、a has b.を表す述語関数has(a,b)を導入する時に、
aとbの間に成り立つ簡潔に表せる関係が知りたいんです
例えばスコープを導入すると、a has bの時aからbは可視ですがbからaは見えませんよね
こういう類の性質の中でクリティカルなものがあれば、
has-a関係を判定する時に楽になるかなと思うんですが

621 ：仕様書無しさん：2007/07/23(月) 00:20:33

>>620
そのへんよく分からんけど
２,３個何かに対してis_a, has_aを二三回やってみれば違いがでてくるんじゃない。

is_a(a,b), is_a(b,c)でis_a(a,c)
だけど
has_a(a,b), has_a(b,c)でhas_a(a,c)とは言わないんじゃないかな?
つか言わねぇだろ。

622 ：仕様書無しさん：2007/07/23(月) 00:24:24

なるほど
has-a関係などプラシーボに過ぎないって良く言うしな

623 ：仕様書無しさん：2007/07/23(月) 01:28:05

is-aの関係のあるものは、基底クラス object とその他全部で十分だ
あとは全部メンバとinterfaceにしてしまえ、問題はおおむねそれで解決だ。
考えると頭が痛いしな、そうするとinterface継承以外の継承などイランという結論になる。
これは極論だが、実際問題このぐらいでもいいと思うよ。

624 ：仕様書無しさん：2007/07/23(月) 01:46:57

キーワードばしばし来てますね。
TortoiseSVN, EA, 河合さんｗ

625 ：仕様書無しさん：2007/07/23(月) 02:04:24

>>592
やってない
でも、他のチームの話聞いた限りだと誤操作関連のミスはRapidSVNと同じようなもんだって話
バージョン管理細かいところで普通の人には駄目そう

626 ：仕様書無しさん：2007/07/23(月) 02:15:32

一般人が見る場合、ややこしいのはテキストデータについてコンフリクトを起こした場合の対処方法でパニックする点だろう
直前の版と現在の版の間に他人の操作が入った旨を伝えるインターフェイスと、その他人の操作が入った文書について見えるようにしてやれば十分だと思うよ。
そういう独自GUIを作ればいいかと。
バイナリーデータの場合はロックで取得するから、ロックしている奴の氏名を見せて、ただいま操作できませんとでもして、普通の感覚のインターフェイスで問題は無いかと。
いずれにしても一般人向けにするならオリジナルGUIは作成したほうが良いだろう、作ったところで大した工数でもないしね。
プログラマ側のインターフェイスはコマンドライン版のみで十分だろう。

627 ：仕様書無しさん：2007/07/23(月) 04:19:35

>>626
ていうかアレ
普通の奴にとっては

「何があろうが強引に更新」
「何があろうが強引にコミット」

さえあればいいんだと思うよｗ
そもそもローカルの状態をリポジトリに反映するって頭がない
直接リポジトリを更新させてやったほうが親切だと思うんだよね（これなら履歴は残るし問題ないっしょｗ）
ＧＵＩに放り込んだファイルで該当ファイルを更新とかねｗ
ローカルの状態を「更新」「コミット」って実は２段階にしてるのが間違いの元のような希ガス

628 ：仕様書無しさん：2007/07/23(月) 05:26:29

>>627
WebDAV経由でSVNにしとけばいいじゃん、河合さん？

629 ：仕様書無しさん：2007/07/23(月) 05:35:09

>>628
え？俺、そんな苗字じゃないけど？
てかWebDAV経由ってどういうこと？

630 ：仕様書無しさん：2007/07/23(月) 06:25:42

>>629
WebDAVのバージョニング拡張、別名DeltaV、RFC 3253な、河合さん。。。

631 ：仕様書無しさん：2007/07/23(月) 06:33:11

私怨ノイローゼが流行ってんのか？

632 ：仕様書無しさん：2007/07/23(月) 06:48:09

ヤバイ河合さん刺○ＥＤルートに流れてる可能大
逃げて河合さん逃げて

633 ：仕様書無しさん：2007/07/23(月) 08:17:48

まああれだ。
OOとは直接関係ない話が混入しすぎ。
OOが嫌われる必殺技「用語爆弾」炸裂中ってやつ？

634 ：仕様書無しさん：2007/07/23(月) 20:37:04

00を勉強したければ小話を使えよ。おれは、Visual　SmallTalkで00を勉強したぞ

635 ：仕様書無しさん：2007/07/23(月) 20:49:55

|　　SmallTalk 勉強したいので、
|　　Alto ください。
＼＿＿＿＿＿　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　 ∨　|　　なんですかそれ？
　　　　　　　　　　　＼＿　＿＿＿＿＿＿＿＿＿＿＿
　＿＿　　　　　　　　　 ∨
／　　／|　　　　　　 ∧＿∧　　∧ ∧　　　　.
|￣￣|／|　　　　　　（´∀｀；）　(ﾟДﾟ )　　　
|￣￣| |￣￣￣|＼＿（＿　　） ⊂＿|＿＿＿
|￣￣| |＿＿＿| ∧＿∧￣￣￣　／／／／|
|￣￣| |＿＿＿|（　　　　）＿＿＿_|￣￣￣|／|
|￣￣　　　　　　（　○　）　　　　　￣￣￣|　 |
| 　XEROX 　　｜｜　| .　　　　　　　 |　 |
| 　　　　　　　（＿（＿）.　　　　　　　　　|／

636 ：仕様書無しさん：2007/07/23(月) 21:18:39

英文法みたいに言ってる時点でもうぜんぜん概念がちぐはぐになってきたから
発展しないんじゃねえの？これって。

数学で話そうぜ。

637 ：仕様書無しさん：2007/07/23(月) 21:18:49

>>635
|　　SmallTalk 勉強したいので、
|　　Alto ください。
＼＿＿＿＿＿　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　 ∨　|　　Mesaしかないんですけど･･･
　　　　　　　　　　　＼＿　＿＿＿＿＿＿＿＿＿＿＿
　＿＿　　　　　　　　　 ∨
／　　／|　　　　　　 ∧＿∧　　∧ ∧　　　　.
|￣￣|／|　　　　　　（´∀｀；）　(ﾟДﾟ )　　　
|￣￣| |￣￣￣|＼＿（＿　　） ⊂＿|＿＿＿
|￣￣| |＿＿＿| ∧＿∧￣￣￣　／／／／|
|￣￣| |＿＿＿|（　　　　）＿＿＿_|￣￣￣|／|
|￣￣　　　　　　（　○　）　　　　　￣￣￣|　 |
| 　XEROX 　　｜｜　| .　　　　　　　 |　 |
| 　　　　　　　（＿（＿）.　　　　　　　　　|／

638 ：仕様書無しさん：2007/07/23(月) 21:38:35

そういや何かの展示会でXeroxのブースにAlto置いてあったな。
他の連中スルーの中俺一人興奮して見てた。

639 ：仕様書無しさん：2007/07/23(月) 22:12:00

オブジェクト指向を理解しているつもりの奴の中にも
デザインパターンの知識もないようななんちゃってオブジェクト野郎が
いるから話はややこしい。

３層スキーマや正規化の知識すらないのにデータベース技術者を自称するシロートと同類。

640 ：仕様書無しさん：2007/07/23(月) 22:13:43

またそうやって荒そうとする

641 ：仕様書無しさん：2007/07/23(月) 22:18:22

ふん、どうせSQLクエリ発行するだけしかやってないモン！

642 ：仕様書無しさん：2007/07/24(火) 01:41:12

クラス(オブジェクト・クラス) とインスタンス(オブジェクト・インスタンス)
はどちらもオブジェクト

643 ：仕様書無しさん：2007/07/24(火) 02:26:42

Javaにもフレンドクラスが欲しいとです……
ついでに僕にもフレンドが欲しいとです……

644 ：仕様書無しさん：2007/07/24(火) 02:39:38

はい、次。

645 ：仕様書無しさん：2007/07/24(火) 04:49:10

>>640
デザパタはもう釣りだな
このスレ見てりゃデザパタが実装テクでしかないことなんて一目瞭然

646 ：仕様書無しさん：2007/07/24(火) 05:48:39

兄弟で近親相姦。
男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦
また男女を産んで、兄弟で近親相姦

近親相姦で多重継承されてきた人間

647 ：仕様書無しさん：2007/07/24(火) 07:04:08

NGワード
つデザパタ

648 ：仕様書無しさん：2007/07/24(火) 07:29:43

takahiroが頑張って書くと、
途端に訳わかんない奴が戯言書き連ね始めるのなｗ

このパターンいい加減もう飽きた
引き篭もり自称トレーダは
さっさと巣に帰って二度と戻ってくんなｗ

649 ：仕様書無しさん：2007/07/24(火) 07:30:10

オブジェクト指向が嫌われてるのは、プログラマの認識とIDEの機能が許す限り複雑化していくからだろ。
そして誰もメンテできなくなる。

650 ：仕様書無しさん：2007/07/24(火) 07:38:06

オブジェクト思考を基本設計に据えて設計した場合、手間がかかる。
オブジェクト思考を導入したメリットにより、
３０％以上の効率が求められない場合、無駄になる。

どこかで、読んだ主張ですが、私もほぼ同感です。

オブジェクト化による効率化（品質）も重要
単にオブジェクト化するだけでは無意味

使いどころは考慮するべき。

651 ：仕様書無しさん：2007/07/24(火) 07:47:49

確かにオブジェクトとして扱うべき要件に遭遇することもあるが、どう見ても関数ライブラリで足りることも多い。
そういうときは将来を考えてシングルトンパターンにしとけば十分。いちいちnewする必要無い。

652 ：仕様書無しさん：2007/07/24(火) 08:26:43

シングルトンパターンは極力使わない

653 ：仕様書無しさん：2007/07/24(火) 08:41:23

好き勝手得意絶頂に糞オブジェクトのインスタンスをnewされるとそこを書き直す時に困るんだよ。
newより関数呼び出しのほうが見つけやすいし直しやすい。

あとあれだ。例外処理すら満足にカプセル化できない低能がスレッド使うな。
というかスレッド使うな。
あれだけオブジェクトが飛び交うゲームの実装にさえ使われてねえだろ。
安全性と保守性考えたら使うべきでないことに気付け。

654 ：仕様書無しさん：2007/07/24(火) 08:43:20

シングルトンは使い出すと全部それですましちゃう奴が出る。
グローバル変数と同じ邪悪さがある。

655 ：仕様書無しさん：2007/07/24(火) 08:55:43

>>654
パッケージやクラスが持つ名前空間こそグローバル変数そのものだろ。
単一の機能のために7つ以上のクラスが作られるとき、その設計は常に把握しづらいオナニーに堕している。

良いクラスは3秒で使い方が分かるものだ。

656 ：仕様書無しさん：2007/07/24(火) 08:59:42

10個以上のライブラリを使ってプログラミングしてみることだよ。
おそらくもう二度とやりたくなくなるか、あるいは少し賢ければ、インターフェースを極度に単純化した
ラッパークラスを書きたくなるだろうから。

増えすぎたクラスこそグローバル変数の生まれ変わりなんだよ。

657 ：仕様書無しさん：2007/07/24(火) 09:02:07

全部継承しちゃえば楽だよｗ

658 ：仕様書無しさん：2007/07/24(火) 09:08:32

数がいくつって具体的な数字はあんまり関係ないな

設計の本質は大きく複雑なものは小さく単純な形にすること
どんなに崇高な理論だろうと設計は単なる「分け方」に過ぎない

分けすぎて数が多くなってしまったらまたそれを分けなくてはならない
だからといって分けないわけにはいかない
分けることを否定してしまったらあとは膨らみ続けいずれ限界がくる

どう分けるか？はプログラムを組む限り永遠に考え続けなければならない

また、オブジェクト指向も所詮オブジェクト単位でわけてるだけ
つまり、数ある分け方の１つでしかない

659 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/24(火) 09:18:24

デザインパターンとは学問である。
これは、膨大なOOソースを分析、分類することによってそこから何かを導き出そうと言う物である。
昆虫や植物を分類するのと似ている。
パターンを暗記する事に意味はない。無理にパターンに当てはめて設計するのも無意味だ。
意味があるとしたら、パターンの特徴（どこで使われていたかと、利点と欠点）を知る事ぐらいだろう。
「これは○○パターンだね」と言うなら、用途と利点ぐらいは押さえておくべきだ。

しかし本当の目的は「何かを導き出す」事だ。それが論理なのか、実装技術なのか、哲学なのかは
分からない。もし何かを導き出した人がいたら、是非とも発表してもらいたい。

660 ：仕様書無しさん：2007/07/24(火) 09:19:19

分けるばっかりでまとめないのかｗ

661 ：仕様書無しさん：2007/07/24(火) 09:21:36

>>645 分かってねえ奴のセリフじゃないね。ちったぁ自覚しろ。

662 ：仕様書無しさん：2007/07/24(火) 09:50:59

>>658 非常に頷ける。結局のところ、
OOPのメリットもそういうもんだと僕も思う。
複雑さに対抗する手段。整頓方法。

663 ：仕様書無しさん：2007/07/24(火) 11:12:44

>>660
それも結局分けることなんだよ

ある集合Ｘがあってその中にＸ１Ｙ１Ｚ１Ｘ２Ｙ２Ｚ２があったとして
Ｘ１Ｙ１Ｚ１をＡとまとめる、
Ｘ２Ｙ２Ｚ２をＢとまとめるとするとできる構造は

Ｘ－ＡーＸ１Ｙ１Ｚ１
　－ＢーＸ２Ｙ２Ｚ２

となるわけで結局Ｘからしてみれば垣根のなかった
Ｘ１Ｙ１Ｚ１Ｘ２Ｙ２Ｚ２をＡとＢに「分けた」だけに過ぎない

664 ：仕様書無しさん：2007/07/24(火) 12:47:18

>>651
>>653
なんでnewの話になるんだよ。

オブジェクトの寿命をプログラマが考えるのを放棄して、
なんでもかんでも参照カウンタで寿命管理するのか?

まず、それがおかしい。

関数ライブラリだってオブジェクト指向だったりするんだよ?
引数にハンドルや状態を保持している構造体へのポインタを渡したりするでしょ?
どーみても、thisポインタをこっそり渡すC++のクラスのメンバ関数の呼び出しと一緒です。

665 ：仕様書無しさん：2007/07/24(火) 12:56:11

>653

> 例外処理すら満足にカプセル化できない低能がスレッド使うな。

例外処理をカプセル化？

> というかスレッド使うな。
> あれだけオブジェクトが飛び交うゲームの実装にさえ使われてねえだろ。
>安全性と保守性考えたら使うべきでないことに気付け。

誰かこいつになんか言ってやって（；＾ω＾）

666 ：仕様書無しさん：2007/07/24(火) 13:06:42

一般的なオブジェクト系言語で、スレッドプログラムで困ることあるか？
準備されすぎててまったく意識しないでできるじゃん。

あ、OO言語で非OOで組むマジシャンか？ｗ

667 ：仕様書無しさん：2007/07/24(火) 13:22:13

newこそoo

668 ：仕様書無しさん：2007/07/24(火) 13:39:39

>>653
例外のカプセル化ってなんだよ、ふつーに使えふつーに
もしC++の例外の事を言っているのなら、故障中と書かれた蛇口をひねって水被るような行為だ
カプセル化以前にまず使わない事を考えるべき。
そもそも今時のOSでスレッドを使わずにすむ局面なんて無いだろ、Windowsにしてすらもうスレッド使用前提のAPIになってんだからさ。
I/O系はブロッキングされるタイプのものが増えているだろ、メッセージポンプ止めるクソコードをVC++で書くぐらいなら、VC++はあきらめてVBを使うべきだな。

669 ：仕様書無しさん：2007/07/24(火) 13:55:04

>>665
> 例外処理をカプセル化？

中で発生した例外を、そのまま呼び出し側にスルーするな!
ってことでしょう。

>>668
> メッセージポンプ止めるクソコードをVC++で書くぐらいなら

UIスレッドで何かの処理をするアホが多いよね、ほんとに。

VCのMFCのウィザードが吐くスケルトンが、
UIスレッドとワーカースレッドを分けていればなぁ。

670 ：仕様書無しさん：2007/07/24(火) 14:38:09

エラーで最悪なのは、例外発生で停止すること、これは論外。
次にエラー処理を完全に隠蔽してしまうクラス。

エラー処理はオーバライドブル宣言しておくと吉。
エラー内容及び、クラスインデックス等を返すと尚よろしい。
さらにログへ出力すると更によろしいが、
これは頻度と内容を計算してなけばならない。

671 ：仕様書無しさん：2007/07/24(火) 15:06:19

プロセスにとって致命的な続行不能なエラーならば停止するべき。
それを無理に動かし続けるのは被害が拡大する。

勝手にログに出力するのも勘弁して欲しい。
勝手にエラーのダイアログを表示してユーザに入力を求めるのと同じくらい迷惑だ。

672 ：仕様書無しさん：2007/07/24(火) 15:21:37

>>662
関連づけのことじゃない？
分けた上で、関連を考えないと浮いたものになる

673 ：仕様書無しさん：2007/07/24(火) 15:26:46

抽象化や概念化してモデル化し、それらを継承して具体的な問題を解決していく方法(の一つ)が、オブジェクト指向だとおもう

674 ：仕様書無しさん：2007/07/24(火) 15:47:43

1.HDDの空き容量が足りない為、ファイルを作成できませんでした。
　↓
2.ここは親切にログ出力

675 ：仕様書無しさん：2007/07/24(火) 16:17:13

>>671
勝手というか、それはサービス全体でログを出すかどうかであって。。。
エラーについては、オーバーライド可能なOnERRを定義しておけばよいでしょう
クラスユーザーがログを出したいなら、それに実装すればよい。

オブジェクト思考のクラス設計を考える上で、イベントトリガーを
正しく設定することは重要。
中身（実装部分）はなくてもいい。
そのタイミングでトリガーを打つことが重要。

676 ：仕様書無しさん：2007/07/24(火) 16:40:25

>>675
コールバック vs 例外 vs エラーオブジェクトをreturnする
どれがいいんだろうねぇ。

677 ：仕様書無しさん：2007/07/24(火) 17:02:39

クラス単体では戻り値は成功失敗だけにして
エラーの詳細は取得したいときだけ別に取得できるように組んでるぜ

じゃないとサービスによってエラーの出し方呼び出し元のエラー処理が違うから
どうでもいいところで汎用性が消えちまう

678 ：仕様書無しさん：2007/07/24(火) 17:13:03

>>677
正解
すばらしい。他のやつはカス

679 ：仕様書無しさん：2007/07/24(火) 17:31:56

クラス単体で戻り値ってだれか和訳してくれ。

680 ：仕様書無しさん：2007/07/24(火) 17:50:32

クラスのインターフェース単位ってことなんじゃね？

681 ：仕様書無しさん：2007/07/24(火) 18:17:23

>>679
そこは関数だったｗ

682 ：仕様書無しさん：2007/07/24(火) 18:30:49

Win32のGetLastError()みたいだな

683 ：仕様書無しさん：2007/07/24(火) 18:38:00

巻き込まれてエラー吐く奴がいるのが玉にキズだけどな。

684 ：仕様書無しさん：2007/07/24(火) 20:35:08

「例外」エラーと論理的（false)とは、扱いが違うわけでして、
戻り値をBoolean型で扱っている先で、例外エラーが発生した場合、
Falseを返す？　これは間違ったアプローチだと思われる。

例外のコールバックについては、戻り先の保証がない可能性がある
（厳密な設計がされていれば良いのだろうが。。。）という事で、やや減点。

ここはオブジェクト指向について書かれたスレッドということもあるが、
「エラートリガー」を打つを推奨する。

エラーの詳細などは、クラス内部に書き込むと言う方法もあるが、
システムから呼ばれる、エラー構造体をそのまま使うほうが効率が良い。

685 ：仕様書無しさん：2007/07/24(火) 20:40:38

で？

686 ：仕様書無しさん：2007/07/24(火) 21:11:52

ちょっと誰か >>684 にお帰り願って（；＾ω＾）

687 ：仕様書無しさん：2007/07/24(火) 21:26:56

変なことすな
素直に例外だせ屑どもが

688 ：仕様書無しさん：2007/07/24(火) 21:38:54

例外を下手にcatchしちまったら、どこで例外が発生したのかも、わからなくなっちまうな。

自分用のツール群では、あえて例外はcatchしない。
Dr.Watson32が例外発生箇所を記録してくれるので、それで十分だから。
デバッガが入っている環境なら、その場でデバッガをアタッチする。
下手にエラー処理してログに限られた情報だけを記録するのは、良くない。

人様に提供するものについては、例外はcatchして、
WindowsのDr.Watson32のソースを参考に、例外発生箇所やスタックをログにダンプしてる。

こういうとき、関数の引数をスタックに積むアーキテクチャは良いと思う。
レジスタ渡しなんかしてたら、スタックを見てもわからんからね。

689 ：仕様書無しさん：2007/07/24(火) 21:51:41

>>659
ﾌﾟｷﾞｬ━━━━≡≡≡≡≡⊂｀⌒m9^Д^)⊃━━━━ !!!!!!内容薄っ！

690 ：仕様書無しさん：2007/07/24(火) 21:51:51

なんかC++やらC♯やらを基準に語っているようだな。
Javaプログラマはお呼びじゃないようだ。

691 ：仕様書無しさん：2007/07/24(火) 21:53:29

>>659
導き出した答え：

　だ　め　な　や　つ　は　な　に　を　や　っ　て　も　だ　め

692 ：仕様書無しさん：2007/07/24(火) 22:07:10

>>659 俺が導きだした答え
デザパタを理解するためにはOOの超深い理解が必要だ。でも、なんちゃってデザパタなら理解の必要なし

693 ：仕様書無しさん：2007/07/24(火) 22:09:06

なんちゃってデザパタは、もはやパターンだ。
なんちゃってOOPもまた、同様である。

694 ：仕様書無しさん：2007/07/24(火) 22:23:37

無駄に捻るよりパターンで解決できるならそれでいいじゃない

695 ：仕様書無しさん：2007/07/24(火) 22:29:31

>>659
導き出した答え：
おじゃばは説明が下手なので客先に出せず
せいぜい新人の踏み台くらいにしかなれない。

696 ：仕様書無しさん：2007/07/24(火) 22:42:14

OOPは分かっている、デザパタなんか簡単だ、
などと言ってみせる人は、意図的にそうしてる。
思い込みを補強しようとしているかのようにすら見える。
その姿は充分悲惨だが、もっと悲惨なのは彼のチームメイトである。

697 ：仕様書無しさん：2007/07/24(火) 23:09:58

必要にせまられて勉強したのとブライドで勉強したのとの違いも考えて欲しいな
どうも後者の様に思われているようで欝になる
ぬるすぎる環境はあらゆる点で問題だ
完全に仕事場間違えたオレ

698 ：仕様書無しさん：2007/07/24(火) 23:11:34

デザパタは実装テク

699 ：仕様書無しさん：2007/07/24(火) 23:12:39

Q なぜ勉強したのですか？

A 勉強というか趣味。つーか遊び？って？やつ？じゃね？

700 ：仕様書無しさん：2007/07/24(火) 23:13:33

>>690
Javaスクールの危険
http://local.joelonsoftware.com/mediawiki/index.php/Java%E3%82%B9%E3%82%AF%E3%83%BC%E3%83%AB%E3%81%AE%E5%8D%B1%E9%99%BA

701 ：仕様書無しさん：2007/07/24(火) 23:19:38

>>698
GoF本から引用。

「本書の目的は、オブジェクト指向ソフトウェアを設計する際の経験を
デザインパターンとして記録することである。これらのデザインパターンは、
オブジェクト指向システムにおいて重要でかつ繰り返し現れる設計を、
それぞれ体系的に名前付けし、説明を加え、評価したものである。」

「デザインパターンを使えば、成功した設計やアーキテクチャの再利用が簡単にできる。」

「つまり、デザインパターンを利用することによって、設計者は適切な設計により速く到達できるということである。」

実装テク、が何を意味するか不明ですが、
少なくとも、デザパタは設計のテクなのでは？

702 ：仕様書無しさん：2007/07/24(火) 23:19:50

＞Javaは大体において優れたプログラマと凡庸なプログラマを見分けるのに使えるほど難しい言語ではないということだ。

実質、褒めてるだけにしか思えない

703 ：仕様書無しさん：2007/07/24(火) 23:21:29

>>701
だってそもそもデザパタ書いた奴がオブジェクト指向わかってねーし
デザパタに書いてある内容は設計ででてこないほど実装よりだろ？

704 ：仕様書無しさん：2007/07/24(火) 23:22:08

どちら寄り、に関わらず
実装に使えなければ無価値でしょう

705 ：仕様書無しさん：2007/07/24(火) 23:23:09

>>703
> だってそもそもデザパタ書いた奴がオブジェクト指向わかってねーし

初耳です。なんかしらのソースはあります？

> デザパタに書いてある内容は設計ででてこないほど実装よりだろ？

「設計ででてこないほど実装より」とは？

706 ：仕様書無しさん：2007/07/24(火) 23:26:48

>>705
>初耳です。なんかしらのソースはあります？
デザパタを読んだ俺の意見だけど
誰のいう言葉なら理解できる？
どっかの偉い人のいうことじゃなきゃ納得いかない？

707 ：仕様書無しさん：2007/07/24(火) 23:28:21

>>706
ソースがあるわけではない、と。それだけ答えれば十分。

708 ：仕様書無しさん：2007/07/24(火) 23:29:25

>>704
馬鹿でしょ？
実装は設計を反映させるもんだろ？
反映させるだけだ
普通に作ればパターンなんてでてこないし入る余地はない

709 ：仕様書無しさん：2007/07/24(火) 23:29:52

主にリファクタ用と思うよ
デザパタは
手際よい設計にも使えるが

710 ：仕様書無しさん：2007/07/24(火) 23:30:24

> デザパタに書いてある内容は設計ででてこないほど実装よりだろ？

「設計ででてこないほど実装より」とは？

711 ：仕様書無しさん：2007/07/24(火) 23:31:40

>>710
読んでそのままだけど？
何がわからん？

712 ：仕様書無しさん：2007/07/24(火) 23:34:54

ウィキペディアからコピペ
ドキュメンテーションは以下のように分類される:
* アーキテクチャ/設計文書 - ソフトウェアの概要。外部環境との関係、設計原則などが記述される文書。
* 技術文書 - コード、アルゴリズム、インタフェース、APIなどの文書。
* エンドユーザー文書 - エンドユーザー向けのマニュアル、システム管理者やサポートスタッフ向けの文書。
* マーケティング文書 - 製品概要などのプロモーション用文書。

"実装より"っつーのは「技術文書」っつーことを言っているのか？
GoFデザインパターン本はどー考えても「アーキテクチャ/設計文書」ぢゃん

713 ：仕様書無しさん：2007/07/24(火) 23:35:59

実装レベルのバターンはイデオムという概念が相当だろう
デザパタ実装レベルではない

714 ：仕様書無しさん：2007/07/24(火) 23:36:28

>>711 正直言うと、さっぱり分からん。

>>701 で引用したとおり、
「本書の目的は、オブジェクト指向ソフトウェアを設計する際の経験を
デザインパターンとして記録することである」

「つまり、デザインパターンを利用することによって、
設計者は適切な設計により速く到達できるということである。」
とある。それなのに「設計ででてこない」とは意味不明。

715 ：仕様書無しさん：2007/07/24(火) 23:37:21

>>714
はぁ？
わからんところがわからんって言ってる？

716 ：仕様書無しさん：2007/07/24(火) 23:37:30

>>713 そうそう、せいぜいイディオムのことだと思いますよね。
実装テク、なんていう言葉を聴くと。

717 ：仕様書無しさん：2007/07/24(火) 23:40:15

>>715
えーと。>>714で書いたのをさらに要約するとこうなる。

　デザパタは設計のためのものだ。
　なのに、「設計ででてこない」という言葉を言う人がいる。

設計のためのものは、おそらく「設計に出てくる」と言う表現になるはず。
なのに、「設計ででてこない」というのは矛盾してるか、意図が分からない。

718 ：仕様書無しさん：2007/07/24(火) 23:40:54

年金をオブジェクト指向で騙ってみませんか？
おまえら、年金システムを何とかしてくれ！！
http://pc11.2ch.net/test/read.cgi/prog/1181456871/

719 ：仕様書無しさん：2007/07/24(火) 23:41:24

>>714
デザパタが適切な設計なんて誰が決めたんだよ
誰が太鼓判押したらあんな糞設計がいい設計になるんだ？アフォ？
まともな頭持ってる奴がパターンにシングルトンいれるかよｗ

もうこの時点でかなり馬鹿な奴が書いたもんだって普通わかるよね？

720 ：仕様書無しさん：2007/07/24(火) 23:43:30

>>719
> あんな糞設計

何に比べて、どう糞設計であるのか、評価してみて頂けますか？

721 ：仕様書無しさん：2007/07/24(火) 23:46:41

シングルトンのどこがどう糞なのかぜひ教えてくれ

722 ：仕様書無しさん：2007/07/24(火) 23:46:45

>>720
あの設計はバグるよ
紙に書いて説明せにゃわからんような余計なクラスも作りすぎてる
オブジェクト指向からすりゃ普通に糞設計だと思う

だいたいパターンなんて作ったとしてそれって活かせるもんなの？
無理でしょ

723 ：仕様書無しさん：2007/07/24(火) 23:48:28

>>721
まんまグローバル変数

724 ：仕様書無しさん：2007/07/24(火) 23:49:12

>>722 誤解してらっしゃいますね？
Singleton パターンの「構成要素」の欄によると、

> 紙に書いて説明せにゃわからんような余計なクラスも作りすぎてる

なんてことはありません。クラスは、たったひとつです。

725 ：仕様書無しさん：2007/07/24(火) 23:50:06

年金をオブジェクト指向で

わカモの -----> 金を集める謎の団体
　　　　　金

謎の団体 -----> 年寄り
　　　集めた金の一部

726 ：仕様書無しさん：2007/07/24(火) 23:51:02

そうそう。それより、まず>>717にお答えくださいね。

727 ：仕様書無しさん：2007/07/24(火) 23:53:33

>>726
大丈夫、>>722にそこらへんひっくるめて書いてある

728 ：仕様書無しさん：2007/07/24(火) 23:55:11

>>717 大丈夫かどうかは私が判断します。質問したのは、私ですんで。

「そこらへんひっくるめて」という言葉以外で、
用語を補ったりしつつ話して貰えますか。

729 ：仕様書無しさん：2007/07/24(火) 23:57:59

あと、>>724に対するレスもいただけませんと、
>>722に対する話のつづきができません。

>>722の
「オブジェクト指向からすりゃ普通に糞設計だと思う」
という主張に対する反論として
>>724を挙げておりますので、そこを把握してください。

730 ：仕様書無しさん：2007/07/25(水) 00:00:02

>>723

グローバル変数＝使っちゃだめ

これは短絡すぎるとは思わないか？
そもそもグローバル変数とシングルトンは違うし

731 ：仕様書無しさん：2007/07/25(水) 00:00:45

おっとレス番間違えてる。

>>727 大丈夫かどうかは私が判断します。質問したのは、私ですんで。

「そこらへんひっくるめて」という言葉以外で、
用語を補ったりしつつ話して貰えますか。

732 ：仕様書無しさん：2007/07/25(水) 00:03:38

そもそもデザパタはパターンをどうしたいの？
パターンにあてはめるとかいうのは言語道断だと思うけど・・・

733 ：仕様書無しさん：2007/07/25(水) 00:04:39

　 ∧＿∧　　ｶﾀｶﾀ　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　　　　）　　∧ ∧ ＜　ｺﾝｽﾄﾗｸﾀはprivateにしましょうね…と。
　（　　　　）　　(,,ﾟДﾟ)　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣（つ＿つ＿＿__
￣￣￣日∇￣＼|ThinkPad|＼
　　　　　￣　　　=========　＼
|　ほう、Singletonﾊﾟﾀｰﾝですか？
　￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）　 ∧ ∧ ＜　な、なんですか？あなた・・・
　（　　⊃ ）　 (ﾟДﾟ；)　　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣（つ＿つ＿＿__
￣￣￣日∇￣＼|ThinkPad|＼
　　　　　￣　　　=========　＼
|　他のｸﾗｽからnewさせたくないわけですな…
　￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）　 ∧ ∧ ＜　ま、まあ、そうなりますね…
　（　　　　）　 (；ﾟДﾟ)　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣（つ＿つ＿＿__
￣￣￣日∇￣＼|ThinkPad|＼
　　　　　￣　　　=========　＼
|　ﾌﾟﾛｸﾞﾗﾏは信用できない、と…
　￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）　 ∧ ∧ ＜　ｿﾝﾅｺﾄ言ってないでしょ!!
　（　　⊃ ）　 (ﾟДﾟ；)　　＼＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣（つ＿つ＿＿__
￣￣￣日∇￣＼|ThinkPad|＼
　　　　　￣　　　=========　＼

734 ：仕様書無しさん：2007/07/25(水) 00:05:59

>>730
認めろよ・・・力の無さをよ・・・

735 ：仕様書無しさん：2007/07/25(水) 00:09:58

パターンに当てはめる必要があるって状況がそもそもおかしいよね

736 ：仕様書無しさん：2007/07/25(水) 00:12:04

>>734
つーかシングルトンに状態持たせるなよ。
状態を持たせないなら static メソッドにするよりマシだからシングルトン使うべきだし、
状態持たせるなら new する設計にするべき。

その程度の判断もできずに「シングルトンはグローバル変数！！使っちゃダメ！！！１」
とかレベル低すぎだろｗｗｗｗｗｗｗｗｗｗｗ

737 ：仕様書無しさん：2007/07/25(水) 00:14:24

サーブレットのようなマルチスレッド環境下で共有リソースを扱うとき、
複数のスレッド間で単一のオブジェクトを操作するようなプログラムが必要になることがあります。
また、マルチスレッド環境以外でも、プログラム全体の情報を共有するオブジェクトや、
生成に非常にコストが掛かるものの使い回しが利くオブジェクトのように、
プログラム全体で1つのインスタンスだけを扱いたいこともあります。

実際、いろいろな箇所でSingletonパターンを使っているケースを目にする。
だが、本当にSingletonパターンを使うべきケースというのは、相当に少ないはずだ。
プログラミングの初心者には、グローバル変数を多用したがる人もいる。
グローバル変数の代用として、Singletonパターンを使っているケースが、少なくない。
この背景には、「デザインパターンを使っていないものより、使っているものの方が、良い設計である」
と誤解されていることもあるようだ。
デザインパターンを使っているだけで、何か良いことをしているような気になってしまうこともありそうだ。

だが、誤ったSingletonパターンの濫用は、グローバル変数を多用した場合と、結局はまったく同じことをしている。

738 ：仕様書無しさん：2007/07/25(水) 00:16:37

>>736
馬鹿はそれっぽっちしか理解できねぇのか？ｗ
グローバル変数でまずい挙動が全部見えてねぇんだろうな

739 ：仕様書無しさん：2007/07/25(水) 00:18:05

>>737
ていうか、誤ったも糞もグローバル変数じゃん

740 ：仕様書無しさん：2007/07/25(水) 00:18:11

>>736
> 状態持たせるなら new する設計にするべき。

なんで new 限定なの?
スタック上にインスタンスを持ってはいけないの?

741 ：仕様書無しさん：2007/07/25(水) 00:19:01

だれも突っ込まないのが不思議だ。
デザインパターンとオブジェクト指向は直接には全く関係ない。
再利用しやすいように名前をつけてるだけ。
OOにも構造化にも適用できる。

つか、スレ違いなんだよ、デザインパターンは。

742 ：よく読め>739：2007/07/25(水) 00:20:10

本当にSingletonパターンを使うべきケースというのは、相当に少ないはずだ。

743 ：仕様書無しさん：2007/07/25(水) 00:21:56

デザインパターン「しか」知らないことが問題だと思う。

なぜ、それが良いのか
なぜ、それを選ぶべきなのか

ということを考える上では、採用に至らない他の選択肢についても知っているべきだ。
でなければ、適切なものを選んだことにはならない。

744 ：仕様書無しさん：2007/07/25(水) 00:23:39

そうだ
デザパタはスレ違いだよ
だいたいオブジェクト指向は再利用なんて狙ってるわけじゃねーぞ
やりたい奴で勝手にやれっての
元はシミュレーション、再利用の要素などない

745 ：仕様書無しさん：2007/07/25(水) 00:24:15

既存のオブジェクト指向分析／設計方法論は充分ではない。
実装ではなく、設計を再利用すべき。

アルゴリズムの設計や実装におけるオブジェクト指向のメリットを
見極めるためには、デザインパターンという視点が有用

746 ：仕様書無しさん：2007/07/25(水) 00:24:48

ここはココ電やおじゃばと遊ぶスレであってオブジェクト指向のスレじゃないんだから
そのネタになりそうなことならなんでもおｋなんだよ

747 ：仕様書無しさん：2007/07/25(水) 00:24:52

>>743
駄目に決まってんだろ
パターンにあてはめるその柔軟性のなさが駄目
設計なんて無限にあるのにこんなちょっとのパターンに拘る意味が全くない
しかも、そのパターンてのがまた糞だし

748 ：仕様書無しさん：2007/07/25(水) 00:25:00

GoFはOOP分かってないの話題：
>>703 デザパタ書いた奴がオブジェクト指向わかってねーし
>>705 ソースは？
>>706 無い。根拠は俺の感想。

Singletonの話題：
>>719 デザパタのついでにSingletonを非難
>>720 詳しく
>>722 Singletonパターンへのトンチンカンな評価
>>724 それに対し、誤解があるのでは？と指摘
>>729 お返事待ってますよ、という点を伝え

749 ：仕様書無しさん：2007/07/25(水) 00:25:23

>>745
そりゃお前がオブジェクト指向わかってないからじゃんｗ

750 ：仕様書無しさん：2007/07/25(水) 00:25:35

ケースが少ないも何も、シングルトンにすることで後々のオブジェクト管理方法に選択の幅が出ることが重要なんだろ。
これだからソースを殺那的にしか見れない奴は…。

751 ：仕様書無しさん：2007/07/25(水) 00:26:15

「設計ででてこないほど実装より」の話題：
>>698 デザパタは実装テク
>>701 デザパタは設計テクでは？
>>703 デザパタに書いてある内容は設計ででてこないほど実装より
>>704 その意味は？
>>711 読んでそのままだけど？何がわからん？
>>714 GoF本には設計、とある
>>717 出てくるのに出てこないとは、これいかに
>>726 レス催促
>>727 大丈夫、ひっくるめて既に書いた
>>731 ひっくるめられては困ります

752 ：仕様書無しさん：2007/07/25(水) 00:26:34

>>748
で？結局、デザパタとオブジェクト指向をどう結びつけるの？
全然関係ないけど？ｗ

753 ：仕様書無しさん：2007/07/25(水) 00:27:47

>>750
グローバル変数使って？
駄目なんだよ
絶対にシングルトンは使っちゃいけない
これがわからん奴はもう設計なんてしなくていい

754 ：仕様書無しさん：2007/07/25(水) 00:29:43

>>752
少なくともGoF本は
「オブジェクト指向における再利用のためのデザインパターン」
とあります。

755 ：仕様書無しさん：2007/07/25(水) 00:30:27

グローバルに存在しないと困るオブジェクトもある。
LoggerとかLoggerとか、あとLoggerとか。

756 ：仕様書無しさん：2007/07/25(水) 00:31:09

Singletonの話題：
そろそろ、>>724に対するレスもいただけませんと、
>>722に対する話のつづきができません。

>>722の
「オブジェクト指向からすりゃ普通に糞設計だと思う」
という主張に対する反論として
>>724を挙げておりますので、そこを把握してください。

　　　＊＊＊

「設計ででてこないほど実装より」の話題：
えーと。>>714で書いたのをさらに要約するとこうなる。

　デザパタは設計のためのものだ。
　なのに、「設計ででてこない」という言葉を言う人がいる。

設計のためのものは、おそらく「設計に出てくる」と言う表現になるはず。
なのに、「設計ででてこない」というのは矛盾してるか、意図が分からない。

757 ：仕様書無しさん：2007/07/25(水) 00:31:43

よいフレームワークは適切な「ホットスポット」を持つ。
（ホットスポット：可変場所）

フレームワークの実装においては
・可変箇所(ホットスポット) ＝フックメソッド
・固定個所(コールドスポット)＝テンプレートメソッド
として実装する。

フックメソッドは下の３つのどれかである。
・抽象メソッド
・正規メソッド＝他のメソッドを呼び出さない実装
・テンプレートメソッド

テンプレートとフックの関係は相対的なものとなる。
たとえば、State というパターンの例では、
・TCPConnection と TCPState
・Template ＝ TCPConnection::Open()
　Hook ＝ TCPState::Open()

ということですね。

758 ：仕様書無しさん：2007/07/25(水) 00:32:29

>>754
内容と照らし合わせるとどの辺がオブジェクト指向なのか
作者に突っ込んでやりてぇ酷いタイトルだなｗ

759 ：仕様書無しさん：2007/07/25(水) 00:33:40

グローバルになら、リソース関係はたいていシングルトンが似合う。

760 ：仕様書無しさん：2007/07/25(水) 00:34:23

>>758 どこがどうひどいのか、言えますか？

761 ：仕様書無しさん：2007/07/25(水) 00:34:33

ていうか、デザパタ出すときまわりの奴等止めなかったのが不思議でしょうがねぇ
まわりも全員わかってねぇ奴ばっかりだったんだろうか？

762 ：仕様書無しさん：2007/07/25(水) 00:38:08

デザインパターンとは簡単に言うと「良い設計の虎の巻」です。
プログラミングや設計をしていると、以前経験したことがある、似たような問題に出くわすことがよくありますよね。
そのような問題の解決法にわかりやすい名前を付けて、カタログ化したものがデザインパターンです。

デザインパターンではオブジェクト指向の「継承」「ポリモフィズム」を効果的に利用したものが多いです。

763 ：仕様書無しさん：2007/07/25(水) 00:43:12

method invokeによるコールバックパターンは楽しいぞｗ
くだらない匿名Actionクラスを量産しなくて済む。

764 ：仕様書無しさん：2007/07/25(水) 00:47:17

>>762
は？じゃあ、いい設計も糞も
オブジェクト指向で一番重要なところは何をオブジェクトとして認識するかであって
ここで９９％その設計がいいか悪いか決まる
オブジェクト抽出した後であれこれやる必要ねーんだけど？

ここから違うんだよね
パターンも糞もオブジェクト指向は仕組みそのままオブジェクトにしてあとはよろしくやればいいだけなんで
パターンにあてはめるとおかしなことになっちゃうと思うんだけど
その辺どうなの？

おれの言ってることは間違ってるかい？

765 ：仕様書無しさん：2007/07/25(水) 00:47:47

オブジェクト指向言語で開発を行う際に、どのような設計にしておけば、再利用性が高いクラスやライブラリができるのでしょう。
これに対する指針を示してくれるのが「オブジェクト指向における再利用のためのデザインパターン」(通称「GoF本」)です。
設計者が何か問題に直面したとき、そのような問題に出会うのが初めてであれば、いろいろ試行錯誤をして良い解決方法を見つける必要があります。
しかし、以前似たような問題に出会い、うまく解決した経験があれば、以前と同じような方法でその問題を解決することができるのです。
「よく出会う問題とそれに対処する良い設計」をたくさん知っていれば、良い設計をスムースに進めていくことができるわけです。
デザインパターンとは、「よく出会う問題とそれにうまく対処するための設計」をまとめたものです。

デザインパターンを利用するメリットとして、最初にあげられるのが、「再利用性の高い柔軟な設計ができる」
という点です。これまでは、設計者の直感や経験などに依存していた設計が、デザインパターンを導入することで、
先人たちの「知恵」を利用した設計をすることが可能となります。

766 ：仕様書無しさん：2007/07/25(水) 00:49:03

>>764さん、しっかりして？

Singletonの話題：
そろそろ、>>724に対するレスもいただけませんと、
>>722に対する話のつづきができません。

>>722の
「オブジェクト指向からすりゃ普通に糞設計だと思う」
という主張に対する反論として
>>724を挙げておりますので、そこを把握してください。

　　　＊＊＊

「設計ででてこないほど実装より」の話題：
えーと。>>714で書いたのをさらに要約するとこうなる。

　デザパタは設計のためのものだ。
　なのに、「設計ででてこない」という言葉を言う人がいる。

設計のためのものは、おそらく「設計に出てくる」と言う表現になるはず。
なのに、「設計ででてこない」というのは矛盾してるか、意図が分からない。

767 ：仕様書無しさん：2007/07/25(水) 00:50:32

>>764
なにこの低能コンサルっぽい発言
釣り？釣りなの？もしかして釣られちゃった？

768 ：仕様書無しさん：2007/07/25(水) 00:53:00

>>767 釣りかどうかはあやしいですね。
釣りだったらフヒヒすみません。一本釣りされた俺です。

769 ：仕様書無しさん：2007/07/25(水) 00:54:04

すごいね。よく勉強してる。
でだ、
>オブジェクト指向で一番重要なところは何をオブジェクトとして認識するかであって
ここで９９％その設計がいいか悪いか決まる
ってところがよくわからんのだが、そもそも何がいい設計で、適切だとあなたが考えるオブジェクトってどういうものか教えてくれないかな。

それと
>パターンも糞もオブジェクト指向は仕組みそのままオブジェクトにしてあとはよろしくやればいいだけなんで
もよくわからなかった。
仕組みそのままにすると何がよろしいのか？よろしくやるとは一体どういうことだ？

770 ：仕様書無しさん：2007/07/25(水) 00:54:53

>>765
元の思想がアフォなんだな
オブジェクト指向で再利用前提でなにか利益産もうって考えがそもそも馬鹿なんだよｗ

771 ：仕様書無しさん：2007/07/25(水) 00:55:12

デザインパターンは言語に関係なく適用可能です。

ファサード（Facade）とは、仰々しく飾り立てられた正面の外観――つまり「表の顔」――を指す建築用語で、
その裏側にある魅力のない構造および機能を隠蔽する方法です。例えば建築家は、本体はれんが造りの建物なのに、
通りに面した側には大理石のファサードを追加したりします。
同様に、 Facadeデザインパターンは、開発者が複雑なオブジェクトの周囲にラッパー（つまり表の顔）を
作成するときに使用する概念です。このようなラッパーは、オブジェクトのメソッドとプロパティを公開しますが、
他のほとんどの部分は隠蔽します。
一般的には、Facadeパターンを適用することでオブジェクトを扱いやすくし、
特定の目的に適した「表の顔」を用意します。

772 ：仕様書無しさん：2007/07/25(水) 00:57:50

>>769
>そもそも何がいい設計で、適切だとあなたが考えるオブジェクトってどういうものか教えてくれないかな
みんなが考える仕組みがそのまま設計からソースにまで反映されてる状態
だからパターンに当てはめるとかありえないの

これは２つ目の質問にもあてはまると思う

773 ：仕様書無しさん：2007/07/25(水) 00:58:58

アフォとか馬鹿とかしか言わなくなってきたよ…。
>>764さん、酒飲んでんの？　しっかり！

774 ：仕様書無しさん：2007/07/25(水) 01:03:11

>>771
なにいってるのかさっぱりわからん
俺はこういう聞き手を限定するような文章書く奴ってそもそも技術者として駄目だと思う

775 ：仕様書無しさん：2007/07/25(水) 01:03:49

ご存知の通り、オブジェクトを生成するにはnew演算子を使うのが一般的だ。
ソースコードを記述するときは通常、生成するオブジェクトがわかっているのでこの方法を使えばよい。
しかし、あるクラスとあるクラスを対として利用するようなクラス設計をした場合には工夫した方が良い。
この場合にnew演算子を使う方法しか提供されていないとしたら、これらのクラスを対として使う必要があることを
プログラマーが意識してコーディングをしないといけないことになる。
プログラマーがそこまで意識してクラスを使ってくれれば良いが、気付かなかった場合は間違ったコードが
プログラムに紛れ込むことになる。これを避けるための工夫が必要なのだ。

Factory Methodパターンは、あらかじめ「オブジェクトを生成するメソッドを規定」しておき、
「どのオブジェクトを生成するか」についてはこのメソッドを実装したクラスによって決まるようにするパターンである。
ちなみに、factoryとは工場という意味であり、デザインパターンではオブジェクトを生成する機能に対して
この単語を使うことが多い。

776 ：仕様書無しさん：2007/07/25(水) 01:04:42

>>774 自分の不勉強は棚にあげっぱなしですか？
勉強が必須だとか言いたいんじゃない。
学んでないこと、理解してないことを批判してるのが、
滑稽だと言ってる。そんで、もはや迷惑のレベルだと言ってる。

777 ：仕様書無しさん：2007/07/25(水) 01:05:55

>>776
設計技術ってさ、
みんなが理解できるようなものじゃないと意味がないと思うんだよね
だから勉強不足で使えないようなもんはそもそも設計思想として駄目なのさ

俺の言ってることは間違ってる？

778 ：仕様書無しさん：2007/07/25(水) 01:05:58

コードのサイズに比例してNGになる

779 ：仕様書無しさん：2007/07/25(水) 01:09:19

>>777 そうだね。けれど、デザパタくらいは理解可能のはず。

780 ：仕様書無しさん：2007/07/25(水) 01:11:00

>>771
もしかして河合さん？

781 ：仕様書無しさん：2007/07/25(水) 01:11:02

>>779
デザパタはそれとは違って
そもそもオブジェクト指向にはそってないねって話

オブジェクト指向にパターンは必要ない
そこにあるものを反映させるだけだ

782 ：仕様書無しさん：2007/07/25(水) 01:12:08

分かってない奴が大多数なのかそれとも暗黙の前提ありきなのか。
デザインパターンとはGoF本に限った話ではないだろ。

前提をはっきりしろよ。
GoF本に書いてあるデザインパターンなのか、
アンチパターン等も含めたデザインパターンなのか。

おまぃらは前提がはっきりしねーから、
おまぃらの職場同様のだらだら長いだけで何も決まらん会議を呈してんだよ。

783 ：仕様書無しさん：2007/07/25(水) 01:13:21

>>781さん、それ以上話を続けたいのなら、

Singletonの話題：
そろそろ、>>724に対するレスもいただけませんと、
>>722に対する話のつづきができません。

>>722の
「オブジェクト指向からすりゃ普通に糞設計だと思う」
という主張に対する反論として
>>724を挙げておりますので、そこを把握してください。

　　　＊＊＊

「設計ででてこないほど実装より」の話題：
えーと。>>714で書いたのをさらに要約するとこうなる。

　デザパタは設計のためのものだ。
　なのに、「設計ででてこない」という言葉を言う人がいる。

設計のためのものは、おそらく「設計に出てくる」と言う表現になるはず。
なのに、「設計ででてこない」というのは矛盾してるか、意図が分からない。

784 ：仕様書無しさん：2007/07/25(水) 01:13:39

>777
勉強不足でも使える設計思想を教えてもらえませんか？

Facadeパターンなんかは関数の使い方を勉強しない実装者なんかには有効だと思うけど？
っていうか全ての関数はFacadeパターンなんだけどね。

785 ：仕様書無しさん：2007/07/25(水) 01:15:45

>>781と>>783の話題がどーでもいい件について

786 ：仕様書無しさん：2007/07/25(水) 01:16:07

デザパタ信者追い詰められてまいりました！

っつか、デザパタとかどこの会社でも使ってないし、
話題になるのはせいぜい２ちゃんでだけ、
みんなスルーしてるのにあいてにするな

787 ：仕様書無しさん：2007/07/25(水) 01:16:11

>だいたいパターンなんて作ったとしてそれって活かせるもんなの？
>無理でしょ

そもそもパターンっていうのは、活かした経験を集約したものだから、
この質問の答えとしては、「活かせます」だよな。

788 ：仕様書無しさん：2007/07/25(水) 01:16:52

>>786
使ってます。意識してます。恩恵に与ってます。

789 ：仕様書無しさん：2007/07/25(水) 01:17:30

>>781
わかり易いようですごく難しい事を言うよなｗ

790 ：仕様書無しさん：2007/07/25(水) 01:18:31

>>786
> っつか、デザパタとかどこの会社でも使ってないし、

ソースはありますか？　思い込みですか？

791 ：>774 "建築"話が唐突だったのかな？：2007/07/25(水) 01:18:40

Christopher Alexanderは、建築はそこに実際に住む人の要求を満たした形で作られなければならないとしています。
しかし、実際の作業を行っていくためには、建築に対する詳細かつ専門的な知識が必要になり、そのままでは単に理想を述べただけのものとなってしまいます。
そこでAlexanderが提唱したのは、「パターン」の考えでした。建築の過程で生じてくる様々なトレードオフや問題、
そしてそれに対する典型的な解決の方法を、誰もがわかりやすいパターンとし、カタログ化して示すことにより、
設計者が自由にパターンを選択して、より要求にかなった建築の手がかりとしていくという方式を提唱したのです。

Kent Beck、Ward Cunninghamの二人は「パターン」の考えをソフトウェアにも応用できるのではと示唆したのです。
オブジェクト指向の再利用というと、とかく「クラスライブラリの再利用」といった"what"に関する再利用性ばかりが
クローズアップされてしまう傾向がありました。しかしデザインパターンは、今まできちんと形あるものとして示されなかった
「whatを生み出すためのknow-how」("how")の再利用について焦点をあてたところが画期的だったのです。

792 ：仕様書無しさん：2007/07/25(水) 01:20:20

デザインパターンがすべてって感じの頭でっかちがいっぱい！
分かってる奴も分かってない奴も。

793 ：仕様書無しさん：2007/07/25(水) 01:20:36

>>787
いや、それが今度ものにもって意味では微妙じゃね？
共通点が相違点に影響がないことを説明しなきゃいけないし
それってもとの構造を無視してパターンにあてはめようとすることだし
なんか最終的にできたもんが元の原型を保ってないようだと
いくらうまくいってもわかりにくくなっちゃったら意味ないと思う

794 ：仕様書無しさん：2007/07/25(水) 01:20:48

GoF本のパターンを知ってたら、
「あー、あれ系でやるかな」
と思いつく。

知らんなら知らんなりに
「あー、こうやればいいかな」
と思いつく。

それだけの差。
その差が大きいか小さいかはその都度でしかわからん。
ただ知らんよりは知ってる方が型にはまれるから都合がいいこともある。

それだけのことをおまぃらときたら、うだうだうだうだうだうだうだうだうだうだうだうだうだうだうだうだうだうだうだうだ
うっとーしいのお。

795 ：仕様書無しさん：2007/07/25(水) 01:22:20

>>771
Facadeパターンなんて仰々しい名前を付けてるけど、
ごく常識的なクラス設計における分析だろ?

さらに言うと、オブジェクト指向とか関係なくて、
普通に便利な関数を作ろうという次元じゃないか。

ちなみに↓のような例での解説がまかり通るのは、どういうことなんだ?
ttp://www.techscore.com/tech/DesignPattern/Facade.html

所蔵本リストがpublicなのはいいとしても、
図書委員がいるのに貸出帳がpublicなのは変だろ。

しかも、
BookList bookList = new BookList();
LendingList lendingList = new LendingList();
もうねアホかと。

所蔵本リストも貸出帳も、図書館に置かれているものでしょう。
ならば、置いてある場所から、一時的に手許に引き寄せて参照しないと。

どこに置いてあるのかクラスが知っているということは、再利用性ないってことよ。

796 ：仕様書無しさん：2007/07/25(水) 01:23:37

>>794
そもそも

>「あー、あれ系でやるかな」

これがわからない
仕組みをそのままソースに落とすだけなのに何を悩む必要があるのか？
パターンなんてあるのがおかしい
オブジェクト指向から絶対に逸脱してるといい切る俺

797 ：仕様書無しさん：2007/07/25(水) 01:26:48

>>796
あなたみたいに優秀な人なら抽象化対象の抽出や完璧なクラス設計が可能なのかもしれませんが、
我々一般分析設計者には、自分の考えを補助してくれるものがあると助かるのですよ。
逸脱してることは絶対無いですよね。

798 ：仕様書無しさん：2007/07/25(水) 01:27:16

＞仕組みをそのままソースに落とすだけなのに何を悩む必要があるのか？

そこまでいうなら、なんかサンプルみしてみ？

799 ：仕様書無しさん：2007/07/25(水) 01:27:40

>>795
>784

800 ：仕様書無しさん：2007/07/25(水) 01:28:08

>>796
どこに悩んでるなんて書いてあるんだ？
どこにオブジェクト指向なんて書いてあるんだ？

あえて釣られてやると、
Javaでデザインパターンの名前そのままの奴あるじゃん。
あー、あれ系で、がイテレータかもしれんし。

つか、もちつけ。あんまり何でもかんでも噛み付くな。

801 ：>784：2007/07/25(水) 01:28:48

オブジェクト指向は，もともとソフトウエアの再利用性を向上させることを目的としており，その仕組みを，いくつも備えている。

クラスやオブジェクトの再利用性を高めるための手法としては，ライブラリとして提供されているクラスや
フレームワーク，コンポーネントなどを利用することが挙げられる。
クラスやフレームワークの活用とは，具体的なプログラムを再利用することだ。

デザインパターンを活用することも，再利用の手法の1つだが，他の再利用手法とは根本的に異なる点がある。
デザインパターンを活用して再利用できるのは，技術者の「ノウハウ」である。
デザインパターンとは，オブジェクト指向設計において，「頻繁に登場する問題を解決するための常套手段」を整理したものである。
オブジェクト指向設計を行っている最中に問題に直面したとき，同じような問題を解決する常套手段があるかもしれない。
もしデザインパターンのどれかに，直面している問題の解決策が定義されていれば，適切なクラス構造を設計できる可能性が高まる。
「先人の知恵」を活用して設計上の問題を解決しようというわけだ。

802 ：仕様書無しさん：2007/07/25(水) 01:28:54

ま、サンプルを待ちましょう。

803 ：仕様書無しさん：2007/07/25(水) 01:29:12

>>798
こないだ（前スレで）俺が設計した電卓はどう？

電卓を設計するとなりゃ
とりあえず内部の計算機の部分と外のケース（電卓）の部分にわけるだろ？

電卓クラス（液晶パネル、ボタン、計算機の関連を制御）
　液晶パネルクラス（数字を表示する。計算機の表示レジスタを画面に反映。）
　ボタンクラス（自分の記号がなんであるか知っている、ユーザの押下を検出。）

計算機クラス（表示レジスタと計算クラスの関連を制御）
　表示レジスタクラス（ここにぶち込まれたものが表示される）
　計算クラス（入力された文字列を解析→計算し、結果、経過を返す。
　　　　　　　　　文字列は電卓クラスから計算機クラスを通して渡される。
　　　　　　　　　押されたボタンの記号が文字列をして流れてくる。例：「１＋１＝」←これが文字列）

即興だがこんな感じでどうだろうか？

804 ：仕様書無しさん：2007/07/25(水) 01:30:55

>>801
お前なんで784にレスしてんのかよくわからん。
言ってることはよく分かるが、文章長くて読む気にならん

805 ：仕様書無しさん：2007/07/25(水) 01:31:57

ハードもののクラスはいらんだろ。
「なんでもかんでもオブジェクト」はやめれ。実現不可だから。

806 ：仕様書無しさん：2007/07/25(水) 01:32:01

>>803
ソースに落としてください

807 ：仕様書無しさん：2007/07/25(水) 01:32:24

んじゃ、それでクラス図

808 ：仕様書無しさん：2007/07/25(水) 01:33:21

んじゃそれでUMLでｐｌｚ

809 ：仕様書無しさん：2007/07/25(水) 01:33:42

>>796
いやだから、ソースに落としたときに一定の法則があったから、それをパターンとして知識の蓄積をしているだけだから

810 ：仕様書無しさん：2007/07/25(水) 01:34:08

>>805 いやいや、待ちましょう。
それが出来る、というのが彼の主張ですんで。

いよいよクライマックスか。

811 ：仕様書無しさん：2007/07/25(水) 01:35:07

↓全員を納得させるソースコード登場。

812 ：仕様書無しさん：2007/07/25(水) 01:35:25

モデルだけじゃ動かんよ
動かすにはなんらかのアーキテクチャが必要

813 ：仕様書無しさん：2007/07/25(水) 01:35:35

>>806
そのままいける
それぞれクラスにするだけでいいよ
そうできるように狙って作ったから

814 ：仕様書無しさん：2007/07/25(水) 01:35:55

>>813
じゃソース

815 ：仕様書無しさん：2007/07/25(水) 01:36:15

デザインパターンの話よりUMLの話の方が聞きたい俺ガイル
つーか、UMLの管理方法がいまいち確立できねー
つーか、UML書くのめんどくせー

816 ：仕様書無しさん：2007/07/25(水) 01:36:19

ワクワクしてきたぞｗ

817 ：仕様書無しさん：2007/07/25(水) 01:36:44

>>815
じゃ書かなければええんじゃねーの？
必要があるから書くのよ。

818 ：仕様書無しさん：2007/07/25(水) 01:36:52

>>814
そこまで必要かぁ？ｗ

819 ：>804：2007/07/25(水) 01:37:36

よく使うデータ構造やアルゴリズムに対しては名前がついていたので、「クイックソートを使って並び替えをしよう」と言えば、
詳しい処理手順を説明しなくても開発者同士で意思疎通ができていたのだが、オブジェクト指向プログラムの設計については
こういったものがこれまでなかったのだ。
そういう意味では、デザインパターンとは、オブジェクト指向プログラム設計の指針として利用できる、クラス設計のカタログ集
といってよいだろう。もっとも有名なものとしては、GoFがまとめた23のデザインパターンがある。

ただし、注意してもらいたいことがある。デザインパターンは、決して魔法の杖ではなく、
どんな課題でも解決できる万能薬とはなりえない。無理をしてわざわざ使わなければならないものでもない。
デザインパターンは、オブジェクト指向プログラムにおいて、よく課題となることに対して、
これまでに提案されてきた有用な解決方法についてまとめたものだ。それ以上でもそれ以下でもない。

オブジェクト指向プログラムに対してよく理解している人からみると、当たり前だと思えるような設計も
パターンとして紹介されていることもある。

過度の期待をしてはいけない。設計の参考にするぐらいの気持ちでいいだろう。

820 ：仕様書無しさん：2007/07/25(水) 01:38:23

分析と設計とごっちゃになってるだけだと思うけど。常考

821 ：仕様書無しさん：2007/07/25(水) 01:38:28

おまぃ、おじゃばだろ

822 ：仕様書無しさん：2007/07/25(水) 01:39:02

ぽいね

823 ：仕様書無しさん：2007/07/25(水) 01:39:09

なっげーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー！！！！！
読む気しねーよ・・・

824 ：仕様書無しさん：2007/07/25(水) 01:39:24

>>819
うん知ってる。

825 ：仕様書無しさん：2007/07/25(水) 01:39:26

>>803の状態からまだソースみなきゃわかんね
って奴がいるならもうなんもいうことないねｗ

でさ、デザパタだとここからどうするの？
それともやり方違うの？

俺の場合は>>803の状態からそのまんまクラスにするだけ
そりゃ詳細な部品はちょこちょこ増えるかもしれないけど大枠はこの構造が見えるように作る

826 ：仕様書無しさん：2007/07/25(水) 01:40:17

ちょこちょこどころか、すっげー増えるよ
とりあえずやれよ

827 ：仕様書無しさん：2007/07/25(水) 01:41:13

>>818
仕組みをそのままソースに落とすだけでしょ？はやくはやく～
そのままクラスにするだけなんでしょ？
ぼくわからないんで早くサンプル見せて

828 ：仕様書無しさん：2007/07/25(水) 01:41:34

祭りｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!!!

829 ：仕様書無しさん：2007/07/25(水) 01:41:37

経験則でいうと
アーキテクチャのクラス数：モデルのクラス数＝９：１
くらいか？w

830 ：仕様書無しさん：2007/07/25(水) 01:41:44

Unified Process(笑)とは全く合わないタイプの人間だな

831 ：仕様書無しさん：2007/07/25(水) 01:42:21

動作するものがすべてなんですわ。早くしろや

832 ：仕様書無しさん：2007/07/25(水) 01:43:11

動作するアーキテクチャが重要

833 ：仕様書無しさん：2007/07/25(水) 01:43:32

>>826
そうかよ増えるのかよ
じゃ、何が増えるのか言ってみろ
部品挙げたらぶっ殺すぞ

834 ：仕様書無しさん：2007/07/25(水) 01:44:27

＞部品挙げたらぶっ殺すぞ

　　　　はあ？？？？？？

835 ：仕様書無しさん：2007/07/25(水) 01:44:52

素朴な質問。

「デザインパターン」の「デザイン」とは何をデザインすることを指しているの?

836 ：仕様書無しさん：2007/07/25(水) 01:44:57

現実モデル→ソース

ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!!!

837 ：仕様書無しさん：2007/07/25(水) 01:44:58

とりあえずはやくそーす

838 ：仕様書無しさん：2007/07/25(水) 01:45:38

>>835
よくでてくる構造

839 ：仕様書無しさん：2007/07/25(水) 01:45:51

　 ∧＿∧
　（　・∀・）ﾜｸﾜｸ現実モデル→ソース
　（　∪ ∪
　と＿_）__）

840 ：仕様書無しさん：2007/07/25(水) 01:45:56

おじゃばはいつになったら短くまとめられるようになるんだ？
まあ２ｃｈぐらいならいいが、
隣の奴とかマジで悲惨。
メールとかめちゃくちゃ長そうだし。

要点をまとめて書く！
小学校で習っただろ？＞おじゃば

841 ：仕様書無しさん：2007/07/25(水) 01:46:50

>>840 なに話そらしてんのｗ　みっともねえｗｗｗ

842 ：仕様書無しさん：2007/07/25(水) 01:46:53

まーあれだ、「守」「破」「離」ってやつだな

デザパタそのまま使う段階だと「守」で、
ちょっと工夫して使うと「破」で
自分なりの型を見つけると「離」かな

まー、「守」以前の人もいると思うけど

あと、デザパタを積極的に利用しない人も、
自分自身が過去に設計したものを思い出して使うことがあるんじゃないか？
それは自分が設計したパターンを利用したことになる。
他人の知恵を使うか、自分の知恵を使うか、それだけの違い。

843 ：仕様書無しさん：2007/07/25(水) 01:47:00

結論はこうでいい？
「デザインパターンはお好みで」

844 ：仕様書無しさん：2007/07/25(水) 01:47:15

え？つかマジで>>803の状態からソースに落としたもんが想像できないって言ってる？

845 ：仕様書無しさん：2007/07/25(水) 01:47:59

デザパタの応用パターンも、くっさるほどあるじゃん

846 ：仕様書無しさん：2007/07/25(水) 01:48:18

>>844
皆想像して呆れてるんだと思うが

847 ：仕様書無しさん：2007/07/25(水) 01:48:42

デザパタ使ってる人って>>803の状態からどうやってパターンを適用するの？

848 ：仕様書無しさん：2007/07/25(水) 01:49:16

>>838
何についての、良く出てくる構造なの?

849 ：仕様書無しさん：2007/07/25(水) 01:49:21

>>844
オブジェクト指向なのに「ソース！ソース！」言ってる奴は
全然分かってねー奴なんだよ。
設計手法なのにな。

850 ：仕様書無しさん：2007/07/25(水) 01:49:27

>>846
なにか不味いところがあるなら言ってくれ
自分ならこうする
デザパタ使えばこうなる
等

851 ：仕様書無しさん：2007/07/25(水) 01:50:02

GoFとは違うけどMVCもデザインパターンの1つ

852 ：仕様書無しさん：2007/07/25(水) 01:50:05

結論はこうでいい？
「デザパタとオブジェクト指向はまとまらない」

853 ：仕様書無しさん：2007/07/25(水) 01:50:22

まずいまずくない以前に、設計になってない
分析モデルだろこれ

854 ：仕様書無しさん：2007/07/25(水) 01:51:20

>>803
物理的な部品を、そのままクラスにすると、
部品の数だけスレッドが必要
なんてことになりませんか?

855 ：仕様書無しさん：2007/07/25(水) 01:51:43

>>853
そのまま実装にまで反映できないと意味がないってのが俺の考えなんだけど？

856 ：仕様書無しさん：2007/07/25(水) 01:52:19

>>854
ええー？びっくりだぜ
なんでそんなこといいだすの？

857 ：仕様書無しさん：2007/07/25(水) 01:53:14

てか、折角俺が具体的なもん出したんだから
これを元にデザパタならどうするとか
これはこうすべきとか出てこないの？

858 ：仕様書無しさん：2007/07/25(水) 01:53:25

ただいま要件定義中です。
外部設計担当者、製造担当者はしばらくお待ちください。

859 ：仕様書無しさん：2007/07/25(水) 01:54:04

オブジェクト指向ってのは、モノのありようをそのまま写し取ることじゃなくて
必要な部分のみを恣意的にピックアップして抽象化してつなぎ合わせることだと思う

860 ：仕様書無しさん：2007/07/25(水) 01:55:14

>>855
別にモデルは捨てないよ
アーキテクチャで包み込んで使うんだ

861 ：仕様書無しさん：2007/07/25(水) 01:56:57

B'z新曲　8/1発売
だから相変わらず前提が無い奴ら

862 ：仕様書無しさん：2007/07/25(水) 01:57:21

>>860
べつにアーキテクチャなんて関係ねーと思うけどな

863 ：仕様書無しさん：2007/07/25(水) 02:00:06

２時

864 ：仕様書無しさん：2007/07/25(水) 02:02:09

仕組みをそのままソースに落とせるって言い出した奴がいるからそーすを求めてるわけだが

865 ：仕様書無しさん：2007/07/25(水) 02:03:12

UML書いてからだな。

866 ：仕様書無しさん：2007/07/25(水) 02:03:38

デザインパターンとかどうでもいいから電卓のソース！！

867 ：仕様書無しさん：2007/07/25(水) 02:04:34

>>857
話をそらすなよ

868 ：仕様書無しさん：2007/07/25(水) 02:05:00

ちょっと、まだソースきてないの？

869 ：仕様書無しさん：2007/07/25(水) 02:05:22

>>856
物理的な部品は、それぞれの部品がスレッドに相当するものを持っているから。

例えば、2つの入力の和を求めて1つの出力を出す
非同期加算回路を、そのままクラスにするとする。
入力が変化するのを待つという処理がはいる。
だからスレッドが必要でしょう?

870 ：仕様書無しさん：2007/07/25(水) 02:05:53

オブジェクト指向ってのは曼荼羅図を描かないと神の恩恵を受けられないんだよ。
神の恩恵が無いとデスマーチになるのでみんな曼荼羅図を必死に書くんだが、
あまりの量と難解さでみんな挫折して結局デスマーチになるんだよ。

という話を「オブジェクト指向」って言葉に置き換えてるだけさ。

871 ：仕様書無しさん：2007/07/25(水) 02:06:16

え？なんでそんなにソースばっかり気になるの？
設計の話ちゃうんかい？ｗ
つーか、そのまま>>803からソースを想像できると思うんだけどなぁ？

まずそれができんって言ってる？

872 ：仕様書無しさん：2007/07/25(水) 02:06:29

誰か>>835に答えてほしい。

873 ：仕様書無しさん：2007/07/25(水) 02:06:37

よくもまぁそのもの（要件）が存在しない電卓なんかをモデリングできるよな。しかもUI部までｗ

874 ：仕様書無しさん：2007/07/25(水) 02:06:48

>>869
いや、いらないｗ

875 ：仕様書無しさん：2007/07/25(水) 02:07:33

>871
仕組みをそのままソースに落とせるらしいから。

876 ：仕様書無しさん：2007/07/25(水) 02:07:57

>>873
いや、仕様も全部ありがちなの想像すりゃみんなと一致しやすいだろうから
前スレの電卓使ったんだけど？

877 ：仕様書無しさん：2007/07/25(水) 02:08:13

>>874
俺の電卓はスレッド機能もってるんだけど

878 ：仕様書無しさん：2007/07/25(水) 02:08:21

>>835
デザイン＝設計ノウハウ

879 ：仕様書無しさん：2007/07/25(水) 02:08:26

>>875
できるできる
出来るように設計した

880 ：仕様書無しさん：2007/07/25(水) 02:08:54

>876
不一致が発生しております。
ここは統一から入ったほうがよろしいかと

881 ：仕様書無しさん：2007/07/25(水) 02:08:57

>>877
スレッドは絶対お前だけだと思うぞｗ

882 ：仕様書無しさん：2007/07/25(水) 02:09:16

>>873 そこがミラクル、そこが我々の最大の関心ｗ

883 ：仕様書無しさん：2007/07/25(水) 02:09:49

デザパタの人はどうやるの？
仕様はありがちな電卓でいいよ
ちょっとちゃちゃっと設計してみて

884 ：仕様書無しさん：2007/07/25(水) 02:09:54

利用者―(use)→電卓クラス(笑)←→計算機クラス(笑)
みたいなもんだな
どこのUML入門本のコピペなんだよｗ

885 ：仕様書無しさん：2007/07/25(水) 02:11:51

ソースにできる、って言っておいて、
じゃあどうぞ、ってなると黙るんだよなぁ。

886 ：仕様書無しさん：2007/07/25(水) 02:11:57

電卓とか荒れるからもういいよ。
あれやって、あれ。
パーマンのコピーロボットの設計。
鼻は赤で、手は○ね。

887 ：仕様書無しさん：2007/07/25(水) 02:12:25

僕のありがちな電卓は非同期で計算が行われます。裏では宇宙に電波を発生させてその結果を受け取ってます。

888 ：仕様書無しさん：2007/07/25(水) 02:13:31

>>874
部品をそのままクラスにするなら、
メッセージが届いたら何かする
ではなく、
メッセージが届くのを待つ
ということになるっしょ?

889 ：仕様書無しさん：2007/07/25(水) 02:13:50

>>885
設計のスレでソースを要求するのはどう考えてもおかしいし
>>803みてソースに落とせ無い奴はいないと思う
反論できない苦し紛れに即興で用意なんてできるわけないソースを求めてると予想してみる

890 ：仕様書無しさん：2007/07/25(水) 02:13:54

796 名前：仕様書無しさん [sage] 投稿日： 2007/07/25(水) 01:23:37
>>794
そもそも

>「あー、あれ系でやるかな」

これがわからない
仕組みをそのままソースに落とすだけなのに何を悩む必要があるのか？
パターンなんてあるのがおかしい
オブジェクト指向から絶対に逸脱してるといい切る俺

↑何を、悩むｗ必要がｗあるのかｗ

891 ：仕様書無しさん：2007/07/25(水) 02:14:01

>>878
何の設計ノウハウ?

892 ：仕様書無しさん：2007/07/25(水) 02:14:50

ちょっとマジメな話なんだが、
女友達がたった今泊めてくれと電話してきた。
オブジェクト指向的にはどうすりゃいんだ？

893 ：仕様書無しさん：2007/07/25(水) 02:15:10

じゃお前がソースだせ

894 ：仕様書無しさん：2007/07/25(水) 02:15:39

>>888
なんかお前の言ってることってすげー実装よりじゃん
それで>>803の構造が変わるの？
変わるなら自分なりに変えてみてよ

895 ：仕様書無しさん：2007/07/25(水) 02:15:40

だいたい、具象レベルの現実世界をコードに落としてなんかメリットあるか？
手間ばっかりかかっていいこと無いと思うけど。

896 ：仕様書無しさん：2007/07/25(水) 02:15:51

>>892
とりあえずソース出せ

897 ：仕様書無しさん：2007/07/25(水) 02:16:05

悩む必要が無いというサンプルを見せてくれる、という話。

898 ：仕様書無しさん：2007/07/25(水) 02:16:24

>>892
オレに紹介する

899 ：仕様書無しさん：2007/07/25(水) 02:16:35

>>895
手間なんてかからないよ
むしろ、余計なことしないから一番シンプルな形になるはず

900 ：仕様書無しさん：2007/07/25(水) 02:16:41

>>895
いや、すぐソースに落とせるっていうからソースを求めてるわけで

901 ：仕様書無しさん：2007/07/25(水) 02:19:05

>>900
は？わざと議論から逃げてない？
設計はこれで終わりだし、この構造はそのままソースに反映できるよ
なんで開発まで一瞬でできるとか思ってんの？
頭の悪い経営者まんまだなお前の発言
技術者なら技術者らしく技術にたいして意見言ってみろよ
そうやって逃げてるからオブジェクト指向がわからない

902 ：仕様書無しさん：2007/07/25(水) 02:19:05

796 名前：仕様書無しさん [sage] 投稿日： 2007/07/25(水) 01:23:37
仕組みをそのままソースに落とすだけなのに何を悩む必要があるのか？
パターンなんてあるのがおかしい
オブジェクト指向から絶対に逸脱してるといい切る俺

↑パターン不要説の最大の根拠を、なぜ出し惜しむ。
ソース見せてくれたら、デザパタの話に戻れるのに。

903 ：仕様書無しさん：2007/07/25(水) 02:20:25

>>899
どんな機能が必要かって目線でバイアスかけながら、
必要な部分だけをピックアップしてモデル化してくんじゃん。普通は。

904 ：仕様書無しさん：2007/07/25(水) 02:20:29

>>902
わざと議論から逃げて無い？
そんなんでいいの？

905 ：仕様書無しさん：2007/07/25(水) 02:21:30

暇人

906 ：仕様書無しさん：2007/07/25(水) 02:21:46

よしまずは要求定義からやりなおそうぜ

907 ：仕様書無しさん：2007/07/25(水) 02:21:49

もうまともに議論する気ないならそれでもいいよ
デザパタは駄目だし、アーキテクチャなんて設計に絡むわけねぇだろ・・・

908 ：仕様書無しさん：2007/07/25(水) 02:21:56

議論する時間かよｗ
じゃあ第三者は寝るぞｂ

909 ：仕様書無しさん：2007/07/25(水) 02:22:26

>>904
煽りにばっか反応してんなよ
お前の意見は斬新なんだから説明の義務があるだろw

910 ：仕様書無しさん：2007/07/25(水) 02:22:28

現実モデルをソースに落とし込むのがOOだと言っておきながら
落とし込む作業を省くとはなｗ

911 ：仕様書無しさん：2007/07/25(水) 02:22:41

>>906
ありがちな電卓ってところまでだして設計までしてやったのにそれかよ
で、設計したら今度はソースだせ
お前等糞だな

912 ：仕様書無しさん：2007/07/25(水) 02:23:18

＞アーキテクチャなんて設計に絡むわけねぇだろ・・・

　　　　　はあああああ？？？？？？？

913 ：仕様書無しさん：2007/07/25(水) 02:24:12

饅頭怖いってやつだな
相手するだけ無駄

914 ：仕様書無しさん：2007/07/25(水) 02:24:55

分析と設計とどういう仕切りにしてるのか聞きたいもんだ

915 ：仕様書無しさん：2007/07/25(水) 02:26:24

それよりデザパタの人に設計してもらって比べてみなよ

916 ：仕様書無しさん：2007/07/25(水) 02:27:25

「 Open-Closed Principle (OCP) 」という設計ルールに基づいて眺めてみることにします．

"計算機クラスが表示レジスタと計算クラスの関連を制御"とありますが、
大雑把に書くと、
　(new 表示レジスタクラス).set((new 計算クラス(計算式)).getAns())
となるでしょうか?

ところがこれは OCP を満たせません．
表示レジスタクラスや計算クラスを他のものにしたいときに，計算機クラスのコードを修正する必要があります．
この例での修正は簡単ですが，ある程度規模が大きいプログラムではこのような関数が
プログラムのあちこちに現われる可能性があります．

計算機クラスと計算クラスの間にAbstractServerクラスをはさんで考えてみましょう．
AbstractServer クラスは抽象クラスで，計算クラスのスーパークラスです．
計算クラス' が必要になった場合を考えましょう．
このとき，計算機クラスクラスと AbstractServer はまったく修正されません．
また，計算クラス' への機能追加（あるいは変更）をコードの修正ではなくコードの追加によって
実現できます．したがってこのモデルは OCP を守っているといえるでしょう．

これが OCP を満たすオブジェクト指向ソフトウェアの戦略だといえます．

917 ：仕様書無しさん：2007/07/25(水) 02:28:54

要するにあれだな
こいつは「設計など不要。分析モデルから直接コーディングすべし」
って言ってるんだな

918 ：仕様書無しさん：2007/07/25(水) 02:29:47

あらすじ
暇をもてあました若者数名が集まり、それぞれ嫌いなもの、怖いものを言いあっていく。
皆、「蜘蛛」「蛇」「蟻」などと言ってる中にひとり、「いい若い者がくだらないものを怖がるとは情けない、
世の中に怖いものなぞあるものか」という男がいる。本当に怖いものは無いのかと
さんざん念を押しても「ないものはない!」と言う。しかし、何度も念を押しているうちにしぶしぶ「実はある」という。
何が嫌いなのかと聞くと「饅頭」。

その男は「饅頭の話をしているだけで気分が悪くなった」と言い出し、隣の部屋で寝てしまう。

そこで皆は「あいつは気に食わないから饅頭攻めにしてやろう」と、金を出し合い、
饅頭をたくさん買いこんで隣の部屋に投げ込む。すると、男は怖がるどころか「怖いから食べちまおう」
「旨すぎて怖い」などと言いながらとうとう全部食べてしまった。

怒った皆が「本当のお前の怖いものは何だ!」と聞くと「今度は濃いお茶が怖い」。

919 ：仕様書無しさん：2007/07/25(水) 02:30:53

おまいら、なんで強姦魔が辞められないか知ってる?
経験者から聞いた話なんだが、レイプしようとすると大抵の女は始めは嫌がるんだが、
暴れて疲れるとほとんど身動きも出来なくなる。もう好きにして状態になる。
そして驚く事に、女はレイプされるともの凄く感じる。普通にセックスした時よりも、
比べ物にならないほど激しくイクらしい。痙攣してイキまくる。だから通報できない女が多い。
大抵の女性はレイプされるとありえないほどの快感を覚える。
それは大量のアドレナリンとドーパミンが順番に分泌されるからである。
吊り橋効果と似ていて、レイプ魔に襲われて恐怖を感じた時に、
アドレナリンが大量に分泌され生理的に極度の興奮状態に陥る事により、
自分が恋愛をしていると脳が錯覚して、脳が快感を与えるドーパミンを分泌してしまう為、
体が快感を覚えて反応し、挿入からしばらくすると、
膣が充血する事で、クリトリスや膣内の性感帯が過敏になり、
膣が刺激される度にピストン運動にあわせて脊髄反射で腰を振ってしまったり、
痛みに対して悲鳴を上げるように、快感に対してよがり声をあげてしまうわけなのです。
女性というのは、そういう風に出来ているのだそうだ。
だから強姦はクセになってしまうのだそうです。ついでに言うと、
強姦被害者がよく自殺なんて話があるが、あれは強姦されたことが嫌で死ぬわけではなく、
強姦されて激しく快感を覚えた自分の体に嫌悪して死ぬのだそうですよ。

920 ：仕様書無しさん：2007/07/25(水) 02:32:27

真面目な長文に対してコピペで流すのなんて酷くないっすか？すか？

921 ：仕様書無しさん：2007/07/25(水) 02:34:43

ちなみにこれは知り合いの弁護士が連続強姦魔から聞いた話です。
強姦魔の話では、強姦をするときに女性が自分が感じてしまっている事への戸惑いと、
快楽に身を任せる表情とが入り混じってたまらないと言います。
どんな美人でも最後には泣きながら自分から腰を振るそうです。
嫌だとは思いながらも体は感じすぎてしまい拒絶できない。むしろ自分から求めてしまうそうです。
強姦魔によると、美人が泣きながらも苦悶の表情で、「イク」と言うのがたまらないと言います。
一度知ったら誰であろうと絶対に辞められるわけないとも言っておりました。
テレビや映画でたまに出てくるレイプシーンなどは、
経験者に言わせると完全に作り物でありえないと言います。
まぁプロデューサーや映画監督がレイプ経験者ばかりのわけはないですから当然と言えば当然ですが
よく、暴れて挿入されてもレイプ魔を罵っていたり、
逆に放心状態で無反応状態になる描写が多いですが、あれは嘘だそうです。
実際には、快感を憶えてしまう女性が大半だそうです。
最初の段階で、泣きじゃくって半狂乱になるのは本当にあるらしいですけどね。
ただし、半狂乱の状態というのは体力の消耗が激しいので5分と続かないそうです。

922 ：仕様書無しさん：2007/07/25(水) 02:49:24

>>916
いいじゃん修正すりゃ
わかりやすいの優先だと思うんだけど

それに誰も想定してない汎用性を勝手に想定してるけどだいたい全部ぶっ壊れるよ
自分で>>803作っといてなんだけと次の変更で
「普通のじゃなくて関数電卓作って、ホントは関数電卓がほしかったんだよ」なんてきた時点で
正直全部作りなおしたほうが速いと思うよ
ユーザが考える変更ってそういう根本からひっくり返る場合が多いと思う

923 ：仕様書無しさん：2007/07/25(水) 02:50:18

いろんな汎用性があるよりも
その時点でできることできないことがパッとわかるほうが価値があると思うんだよね

924 ：仕様書無しさん：2007/07/25(水) 02:51:41

不眠症のオレが言うのもなんだが
おまいらはよねれ

925 ：仕様書無しさん：2007/07/25(水) 03:26:50

発明と発見の違いはかなり微妙です。
ニュートンは引力を「発見」したといわれていますが、別の考え方をすれば引力という概念を「発明」したとしたと言えるかもしれません。
しかし蒸気機関はそれらが発明される前には何もなかったのに対し、引力はニュートン以前からずっと存在しました。
だから蒸気機関は発明であって引力は発見なのです。たとえ後の人が万有引力の法則というものを星の運行を計算する道具としてしか
使わなかったとしても、法則それ自体は道具ではありません。

オブジェクトも同様です。「ウィンドウ」というものもあなたが考え出したものではなく、あなたが「ウィンドウをオブジェクトにしよう」
と言い出す前からずっと存在していたものです。だからこれは発見です。
あなたは「コンピュータの画面には枠で囲まれたいくつもの四角形が存在する」ということを発見し、それを「ウィンドウ」と名付けたのです。
同様に「ウィンドウの一種に、閉じるまで他のウィンドウの操作ができなくなる特殊なウィンドウがある」ということを見つけ、
それを「ダイアログ」と名付けるのです。このように、継承も作り出すものではなく見つけるものです。

オブジェクトは作るものではなく見つけるものです。
例えば「『ウィンドウ』をオブジェクトにすればプログラムがすっきり書ける」というのはオブジェクトを自分から作り出していること、
すなわち発明していることにあたります。
これは考え方が逆です。
「なるほど。『ウィンドウ』というものがあるんだ。これを軸に考えればわかりやすい」というのが「オブジェクトを発見する」ことです。

926 ：仕様書無しさん：2007/07/25(水) 03:38:43

汎用性
と
「モジュールは拡張性について開いて（Open）おり，修正について閉じて（Closed）いなければならない」
は意味が違うぞ

ソフトウェアが安定するためには，修正に対して閉じていることが要求され、
一方で、その機能を拡張できる柔軟性 -- 開いていることが要求される.
コードの修正ではなく，コードの追加で変化に対応する -- これは，従来の構造化プログラミングでは簡単には実現できなかったこと．
けれどもオブジェクト指向の道具である継承とポリモルフィズムを使えば，それが実現できる．
この「機能拡張をコードの修正ではなくコードの追加によって行う」というのが，
Open-Closed Principleにしたがうソフトウェアがもつ最大の特徴だ.

927 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/07/25(水) 03:41:05

ああ、最近気づいたけど
OOを熱心に説くやつとUFOを信じてるやつは同じ種類の人間だ。

928 ：仕様書無しさん：2007/07/25(水) 03:49:39

>>926
そんなもん想定して組むの無駄だろ
だいたい誰が言ったんだそんなこと
はじめのオブジェクト指向からかなり逸脱してるじゃん

だいたい継承とポリモなんてつかってバグったらどう修正するきだ？
関数名別に切ってバージョンごとに違う関数名にして旧バージョンのは切り捨てろって職場結構あるぞ
これは同じ関数名で違う挙動をすることによる混乱をさけるためだ

929 ：仕様書無しさん：2007/07/25(水) 03:53:48

>>803
めっちゃ乗り遅れてる上にオブジェクト指向関係あるのか分からんが、
>>803をそのままコードに落とせ、って言われても無理。
表示レジスタクラスの挙動が謎過ぎる。

表示レジスタクラスのインスタンスがただ1つだけあるとすると、
電卓クラスと計算機クラスは非同期で動くのを期待してるのか？
同期して電卓クラスが表示レジスタクラスを参照しに行くぐらいなら、
実装としては、計算結果は計算機クラスのメソッドの戻り値で取得した方が楽だろうに。

電卓クラスは、表示レジスタクラスの値をポーリングするのか
それとも計算機クラスが表示レジスタ値更新メッセージ（割り込み的な）を通知するのか

あと、一般的に電卓で押されたボタンは液晶に表示するものだと思うが、
この電卓では押されたボタンは表示するのかね？
表示するとすれば、それも表示レジスタを経由して表示するのか？

>>803からは電卓の挙動が十分に想像出来ない。

930 ：仕様書無しさん：2007/07/25(水) 03:56:04

>>929
お前、書いてもないことあれこれ想像しすぎじゃね？ｗ

931 ：仕様書無しさん：2007/07/25(水) 04:03:12

ヒント:キチガイスレ

932 ：仕様書無しさん：2007/07/25(水) 04:07:39

>>929
>表示レジスタクラスのインスタンスがただ1つだけあるとすると、
>電卓クラスと計算機クラスは非同期で動くのを期待してるのか？
同期非同期なんて関係ないけど？
何をみてそんな複雑なもん作ろうとしてるの？
もっと素直に作れよ。関連って書いてあるやんけ。
インスタンスを整理するとだな

電卓クラス（１つ）
　液晶パネルクラス（１つ）
　ボタンクラス（複数）
　計算機クラス（１つ）
　　表示レジスタクラス（１つ）
　　計算クラス（１つ）

って感じだ

>同期して電卓クラスが表示レジスタクラスを参照しに行くぐらいなら、
>実装としては、計算結果は計算機クラスのメソッドの戻り値で取得した方が楽だろうに。
表示レジスタには計算機の状態を反映しなきゃいけないから「+-*/」とかあるぜ
お前数字だけしか想定してなくね？
まあ、計算機クラスのステータスを直接渡すようにしてもいいけど
そこまで電卓クラスは計算機クラスに用はねー。どんなに拡張しようが必要なのはおそらく表示だけだ。
っつーことで計算機のステータスを整理する（表示に変換する）意味で表示レジスタなんて置いたんだよ。

933 ：仕様書無しさん：2007/07/25(水) 04:10:10

>>929
>あと、一般的に電卓で押されたボタンは液晶に表示するものだと思うが、
>この電卓では押されたボタンは表示するのかね？
何言ってんだこいつ？

>表示するとすれば、それも表示レジスタを経由して表示するのか？
お前電卓の「+-*/」ってその時点の計算機の計算中のステータスを表してるもんだろ？

934 ：仕様書無しさん：2007/07/25(水) 05:28:10

「人はカナヅチを与えられると、
飛び出ている物は何でも釘の頭だと思って叩こうとする。」

935 ：仕様書無しさん：2007/07/25(水) 05:50:04

みっともない自作自演だな。

建前、複数人参加の議論が
実態、一人の脳内妄想に完結している

936 ：仕様書無しさん：2007/07/25(水) 08:05:57

ポーランド式電卓こそ最強

937 ：仕様書無しさん：2007/07/25(水) 08:40:24

もうどーでもいいべ

938 ：仕様書無しさん：2007/07/25(水) 08:42:50

電卓みたいに単純でわかりやすいものなんか
どんな設計手法を使ったってちゃんと設計されてるように見えるよ。
そこを指摘しないで、アホの粗探ししてる奴ってそうとうなバカだ。

939 ：仕様書無しさん：2007/07/25(水) 08:44:38

無限精度演算ができない電卓なんてカスだ。

940 ：仕様書無しさん：2007/07/25(水) 09:01:39

>928
http://ja.wikipedia.org/wiki/%E9%96%8B%E6%94%BE/%E9%96%89%E9%8E%96%E5%8E%9F%E5%89%87
勉強してからこい

941 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/25(水) 09:49:33

819は俺じゃないが、俺の言いたい事と全く同じだ。

942 ：仕様書無しさん：2007/07/25(水) 11:23:40

で？

943 ：仕様書無しさん：2007/07/25(水) 11:44:31

まあ、何事も拘りすぎると良くない傾向にあるよな。

オタ・マニア系や、細かい言葉のミスを見過ごせない奴とか。
と言っても、マ族は得てしてそういう傾向にあると思うが。

結果、過不足無く動作して、納期が早くなれば何でも良いよ。

と、クライアントと上層部は思っている。

944 ：仕様書無しさん：2007/07/25(水) 11:50:27

>>926
>継承とポリモルフィズムを使えば，それが実現できる
拡張性について開いて（Open）いているが，修正について閉じてはいないぞ
無闇な継承バグの元って奴だ。

945 ：仕様書無しさん：2007/07/25(水) 12:13:20

そこでJavaグラマの好物である委譲の出番ですよ

946 ：仕様書無しさん：2007/07/25(水) 12:25:39

世の中には目に見えない「もの」もある
うまく機能させるには、見えないものや元々なかったものを追加する事もある

947 ：仕様書無しさん：2007/07/25(水) 13:10:09

しかし、既に開発済みのシステムが、
保守に再開発以上のコストがかかるならば。
どうなるだろうね

948 ：仕様書無しさん：2007/07/25(水) 19:37:07

作り替えだろ？

949 ：819：2007/07/25(水) 21:18:54

>>941
うぜえ

950 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/25(水) 21:42:16

デザインパターンの説明をする時は、用途も説明した方がいいようだ。
例えば「シングルトンパターン」
まあ、はっきり言って用途は少ない。誰かが言っていたが「ログ」とか、DBのコネクションプーリングなど、
リソースを共有したい時に使うといいだろう。ただ普通にクラスをstaticで宣言して同じ事は出来る。

次に「ファクトリーパターン」
これは誰かに説明してもらおうかな。具体的な用途を。

951 ：仕様書無しさん：2007/07/25(水) 21:44:38

>950
>>949

952 ：仕様書無しさん：2007/07/25(水) 21:49:58

つか、ここで新人教育と同じ口調で書くから馬鹿だろ、おじゃば。
なにが「説明してもらおうかな。」だｗ
TPOがわかんねぇから、素人の踏み台にされるんだよ。

953 ：仕様書無しさん：2007/07/25(水) 21:57:52

おじゃばって本当にバカだな
マジでファクトリーパターンだとか言ってんのか？
アブストラクトファクトリとファクトリメソッドは別ものだぞ
抽象と生成っていうオブジェクト指向設計の超基本を理解してないのは明らかだな

954 ：仕様書無しさん：2007/07/25(水) 21:58:47

しかし、これほど人に教える適性の無い奴も珍しいな。
うちの会社の教育は超優秀なんだけどな。
会社の将来に影響するわけだから。
アホの教育はアホにさせろ、みたいな会社はダメだと思う。

955 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/25(水) 22:23:12

素人の踏み台？
前にも言ったかもしれないが、新人教育を馬鹿にしてはいけない。
新人教育というのはうまく使えば、新人の育成だけではなく中堅の育成にも繋がる。
誰かが「新人教育はすごく難しい」と言っていたが、その人は新人教育を馬鹿にしている連中より、
遥かにレベルが高い。はっきり言って、新人教育するならプログラム作っていた方が遥かに楽だ。
あとどこかのアホが、新人教育は生産性がないと言っていたが呆れた意見だ。
有能な中堅に苛酷な作業をさせるより、その仕事を半分にして、新人教育をやらせた方が、中長期的に見て
遥かに生産性がいい。まあ、個人や小人数でやっているとかなら別の話だが。

ちなみに企業の新人教育というのは、学校の授業やセミナーとは違う。教師に課せられる使命も違う。
決められた期間で、多くの生徒を一般業務にそれなりに耐えられるようにしなければならない。
優秀な人間に教える必要はないし、全くダメな人間に構う必要もない。
6割～8割の「その他どうでもいい人間」を、「それなりに使える人間」にする必要がある。
最初に基礎を教えた後に、実際にはOJTになるだろう。
このOJTの組み合わせも非常に重要だ。当然、性格やプロジェクトの忙しさなども考えなければならない。
新人への指導の他、指導している中堅へのアドバイスも必要となる。

956 ：仕様書無しさん：2007/07/25(水) 22:24:28

ちょっと煽られると読む意味も価値もない長文で火病る。
２ｃｈだから読み飛ばせば済むけど、教育係だったらと思うと恐ろしいよ。
教育後に客先行けるとかならいいけどね。

957 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/25(水) 22:25:26

>>953
じゃ俺にも分かるように説明してくれよ。

958 ：仕様書無しさん：2007/07/25(水) 22:26:55

クワガタムシにかけ算教えるようなモンだな。

959 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/25(水) 22:26:57

>>956
956は教育係やったことあるのか？

960 ：仕様書無しさん：2007/07/25(水) 22:28:53

>>959
教育係っていうかプロマネだな。
最初は「お前程度で意見してんなよ」って感じだったけど、
俺が改善したら、相手も俺をしたって頼るようになってきた。
そしたら業務もスムーズになったよ。
あんた、くだらない反論する暇があったら、なんで煽られたり
ダメだしされるのか、真面目に考えた方がいいよ。
率直に言って、ウザいし、空気読めてないよ。
教育係は新人には権限強いから、カスでもカスと言われない立場。
表だってはね。
裏ではどうだか。

961 ：仕様書無しさん：2007/07/25(水) 22:34:36

>>957
お前みたいなアホになんで教えてやらにゃならんのだｗ
お前の持ってる本でも知ってるサイトでもなんでもちゃんと書いてあるだろ
お前みたいのに教えられてる奴等がマジでかわいそうだ

962 ：仕様書無しさん：2007/07/25(水) 22:43:11

おじゃばはもいちど69式に教えを乞えばいいんじゃまいか。
69式氏はえらい迷惑だろうけどさ。

963 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/25(水) 22:44:08

>>961
961も新人教育経験なし？
OJTで一人つけられるとかもないのか？

964 ：仕様書無しさん：2007/07/25(水) 22:45:26

69式とかしらんけど、過疎クソ板でコテやってる時点で目くそ鼻くそじゃねーのかな。
少々スキルあっても、そのまま管理職どころかプロパーにもなれなかった
パソコンヲタクのなれの果てだろ。
他に優れた書籍とかいっぱいあるんで、そういうの読んだ方がナンボかマシかと。

965 ：仕様書無しさん：2007/07/25(水) 22:51:58

だからそのOOにしろ教育にしろ「自分だけが」ってぇのに
拘る自意識過剰なのが皆のつっこみを呼ぶんだバカ。
もっとも自意識過剰でもなきゃマ板でコテハンなぞやらんだろうけどなぁ

966 ：仕様書無しさん：2007/07/25(水) 22:53:34

こんな過疎板で相手にされたくてコテしてるなんて、研修生にすら構ってもらえてないのが良く分かるよ。
直すならそっちだろ。
２ｃｈで口先でなんとかしようと思うのが間違い。

967 ：仕様書無しさん：2007/07/25(水) 22:54:28

>964
よく知ってるじゃんw
まさか本人じゃあるまいかｗ

968 ：仕様書無しさん：2007/07/25(水) 22:55:59

うーん、管理職をやりたいと思ってるような奴は、
真面目にオブジェクト指向なんて勉強しないでしょ。

969 ：仕様書無しさん：2007/07/25(水) 22:56:15

>>967
いんや。
ただこの板は半年くらいいるんで、むかし読んだ記憶はある。
ダメな奴だが、自覚がないって意味でおじゃばと変わらんよ。
大事なのは言語じゃない、そう思った22の夜。

970 ：仕様書無しさん：2007/07/25(水) 22:56:40

>>700
おいらが最高なのはポインタも再帰も瞬間に理解して
使いこなせるほどの才能があったからか。納得。

971 ：仕様書無しさん：2007/07/25(水) 22:56:47

>>963
お前、人の話全く聞いてねーだろｗ
正しく理解もしてねーくせに他人に物を教えようなんざ10年早いって言ってんの
ファクトリーパターンわかりませーんなんて言ってる奴に教えられてる奴等がかわいそうだって言ってんの
わかった？

972 ：仕様書無しさん：2007/07/25(水) 22:57:29

>>968
それは管理能力のない無能の言い訳だよ。
適切に管理するには、管理能力、人望の他、スキルもかなり必要なんだよ。
特に我の強い技術者をまとめるには、相応のスキルがないとだめ。

973 ：仕様書無しさん：2007/07/25(水) 22:58:08

>>964
>>964
>>964

次スレ立ててくれよ
次スレ立ててくれよ
次スレ立ててくれよ

974 ：仕様書無しさん：2007/07/25(水) 22:59:56

>>974
>>974
>>974

何で俺だよ
何で俺だよ
何で俺だよ

975 ：仕様書無しさん：2007/07/25(水) 23:00:41

アンカ、ミスった。
アンカ、ミスった。
アンカ、ミスった。

976 ：おじゃばさま ◆GxjxF3yEw6 ：2007/07/25(水) 23:04:37

でも新人教育の経験もなくて、OJTで1人もつけられた事のない人に文句を言われてもな。
前に新人教育が難しいと言っていた人が言う事なら聞く気になるが。

977 ：仕様書無しさん：2007/07/25(水) 23:08:30

>>976
マネジメントって教育も含んでるんだけどｗ
そんなポジション経験する事もないだろうから分からないだろうけどさ。
そもそも相手の言っている事が適切か判断するまえに
火病って、とにかく自己弁護に走る。
そこがお前の成長しない理由の一つ。
「大した経験の無い奴の意見は聞けない？」
それがこの板や研修生がお前の意見を聞かない理由だよ。
良く気づいたね。

978 ：仕様書無しさん：2007/07/25(水) 23:10:00

ガキかてめぇはｗ
相手の話は素性がわからんときけねーのに
自分のは理解してくれかよ！

そらぁ新人がかわいそうなわけだわな。

979 ：仕様書無しさん：2007/07/25(水) 23:15:08

>>972
>適切に管理するには、管理能力、人望の他、スキルもかなり必要なんだよ。
>特に我の強い技術者をまとめるには、相応のスキルがないとだめ。
まったくそのとおり、全面的に同意する。

でも、全ての人間に管理職をやる義務があるわけではないし、
やる必要があるわけでもない。やりたい奴がやればいい。
そういう人間は、必ずしも真面目にオブジェクト指向を勉強する必要はないだろう。
要は分かっている人間を管理できればいい。

人には適性と、嗜好がある。
組織に管理が必要だからといって、組織に所属する全ての人間が、
管理を行うわけではない。

980 ：仕様書無しさん：2007/07/25(水) 23:20:10

>979
管理する立場にもある程度は必要、っつ視点がないと。
どの程度？と言われても困るけどねｗ

981 ：仕様書無しさん：2007/07/25(水) 23:20:14

>>979
言い訳がましいな。
同じ人間ができなきゃ意味ないんだよ。
わかってねぇな。
ま、アンタは管理職になれんだろうから別に気にしなくて良いよ。

982 ：仕様書無しさん：2007/07/25(水) 23:31:28

　　　　　 /^､　／＼　　　／￣￣￣￣￣￣￣
　　　,--y'"'~"ﾞ´ヽ＼　＼　＜　あ　ふんぐるい　むぐるうなふ　くとぅるう
　　　ヽ　　 ´ ∀｀／＼／) 　＼＿＿＿＿＿＿＿
　　　　ﾐ　　　/)／/)ﾐ　（（　　ｺﾈｺﾈ
　　　　ﾞ.,　　　　　´''ﾐ　　））　　 ,,ﾊ,ﾊ
　　　ミ　　　　　　;:'　（ ⌒ヽ q;∀｀ ';,
　　　';　　　　　,彡　)￣￣￣(;: ｃ　.ﾐ
　　　　(/'"ﾞ''"ﾞ''u~"　（;;;;;;;;;;;;;;;;;;;）u''ﾞJ" 　　

　　　　　　 /^､
　　　　,--y'"'~"ﾞ´ヽ　　　＿_　ﾍﾟｯﾀﾝ
　　　　ヽ　　 ´ ∀｀ﾞ':　　|　.|
　　　　ﾐ　　　　⊃ .∋―┤ .|
　　　　ﾞ.,　　　　　´''ﾐ　　|　.|,、 ,,ﾊ,ﾊ
　　　ミ　　　　　　;:'　（~￣　）:;∀｀ ';,
　　　';　　　　　,彡　)￣￣￣(;: ｃ　.ﾐ
　　　　(/'"ﾞ''"ﾞ''u~"　（;;;;;;;;;;;;;;;;;;;）u''ﾞJ"

983 ：仕様書無しさん：2007/07/25(水) 23:34:29

　　　　　 /^､　／＼　　　／￣￣￣￣￣￣￣
　　　,--y'"'~"ﾞ´ヽ＼　＼　＜　それ　るるいえ　うがふなぐる　ふたぐん
　　　ヽ　　 ´ ∀｀／＼／) 　＼＿＿＿＿＿＿＿
　　　　ﾐ　　　/)／/)ﾐ　（（　　ｺﾈｺﾈ
　　　　ﾞ.,　　　　　´''ﾐ　　））　　 ,,ﾊ,ﾊ
　　　ミ　　　　　　;:'　（ ⌒ヽ q;∀｀ ';,
　　　';　　　　　,彡　)￣￣￣(;: ｃ　.ﾐ
　　　　(/'"ﾞ''"ﾞ''u~"　（;;;;;;;;;;;;;;;;;;;）u''ﾞJ" 　　

　　　　　　 /^､
　　　　,--y'"'~"ﾞ´ヽ　　　＿_　ﾍﾟｯﾀﾝ
　　　　ヽ　　 ´ ∀｀ﾞ':　　|　.|
　　　　ﾐ　　　　⊃ .∋―┤ .|
　　　　ﾞ.,　　　　　´''ﾐ　　|　.|,、 ,,ﾊ,ﾊ
　　　ミ　　　　　　;:'　（~￣　）:;∀｀ ';,
　　　';　　　　　,彡　)￣￣￣(;: ｃ　.ﾐ
　　　　(/'"ﾞ''"ﾞ''u~"　（;;;;;;;;;;;;;;;;;;;）u''ﾞJ"

984 ：仕様書無しさん：2007/07/25(水) 23:40:13

マ板は脱力系だとおもっていたのに、
なんでここはこんなにアツイの？

985 ：仕様書無しさん：2007/07/25(水) 23:41:33

>>984
勘違いするなよボウズ。
熱いのは俺だけだ。
俺の書き込むスレは必ず炎上する。

986 ：仕様書無しさん：2007/07/26(木) 00:10:32

どんな職務だろうと、集団や組織が上手く機能してやっていける方法
を考えると、わりと似たような感じになると思うけどね。
国でも会社でもサークルみたいのでも。
しょせん一人で出来ることなんて限られてるから、
ある程度の事をやろうとすると、協力する必要がある。
協力の形には色々あるんだろうけど。

987 ：仕様書無しさん：2007/07/26(木) 00:42:20

次スレ

なぜオブジェクト指向は嫌われているのか？3
http://pc11.2ch.net/test/read.cgi/prog/1185378099/

988 ：仕様書無しさん：2007/07/26(木) 00:49:01

なあ、スレタイ、なぜアホコテは嫌われているのか、に変えた方が良くね？

989 ：仕様書無しさん：2007/07/26(木) 00:50:03

>>988
大事なことは先に言ってくれ、
と現場で言われない？

990 ：仕様書無しさん：2007/07/26(木) 02:12:05

帰宅時間がスレ立ったあとだったんだから仕方ないだろ

991 ：仕様書無しさん：2007/07/26(木) 03:04:12

なんか上昇志向強い奴が多いな
管理職とかしちめんどくせえことやりたかねーよ
給料は下がるしろくなことがねえよ全く