なぜオブジェクト指向は普及しないのか 4

このエントリーをはてなブックマークに追加
1 ：仕様書無しさん：
part 1 http://pc11.2ch.net/test/read.cgi/prog/1183255047/
part 2 http://pc11.2ch.net/test/read.cgi/prog/1184258633/
part 3 http://pc11.2ch.net/test/read.cgi/prog/1185378099/

アホコテ、煽りは華麗にスルー推奨。
2 ：仕様書無しさん：2007/08/29(水) 23:07:53
「Javaやってるのでオブジェクト指向は理解しています」
こういう奴が多数いる限り、普及したとは言えない。
3 ：仕様書無しさん：2007/08/29(水) 23:17:08
普及しないなあ
低レベPGは量産されてるけど
4 ：仕様書無しさん：2007/08/29(水) 23:29:14
オブジェクト指向が普及しないのは
フレームワークのせいだろう。

フレームワークがオブジェクト指向で作られているため
一見矛盾しているように感じるかもしれないが、
フレームワークの利用者はビジネスロジックだけを書けば良いため
オブジェクト指向を意識しなくてよくなっている。
5 ：仕様書無しさん：2007/08/29(水) 23:30:12
.Netでさらにゴミが量産か・・・
6 ：仕様書無しさん：2007/08/30(木) 00:00:40
おまえら、つべこべ言わずC言語を勉強しろ
Cができないとオブジェクト指向は絶対にできない。
OOの基礎ははCなんだよ。
俺の言うことと、池田犬策の言うことは信じろ
7 ：仕様書無しさん：2007/08/30(木) 00:05:23
Cができりゃあ言語はなんでも出来るわな。
もちろんそいつが出来る奴でないとダメだけどな。
8 ：仕様書無しさん：2007/08/30(木) 00:07:37
perlで十分
9 ：仕様書無しさん：2007/08/30(木) 00:15:51
>>7
つHaskell
10 ：仕様書無しさん：2007/08/30(木) 00:24:49
マニアックな言語はどーもなあ
11 ：仕様書無しさん：2007/08/30(木) 00:59:47
Lisp を馬鹿にすんな
12 ：仕様書無しさん：2007/08/30(木) 01:04:04
オブジェクト指向ないと
現代の複雑なソフトウェアシステムなんて
まともにつくれんだろｗｗｗ
複雑じゃないやつなら、使わなくてもいいかもしらんがｗｗｗ

とか思っていたが・・・
VS2008のLINQとかラムダ式が熱すぎｗｗｗ
ラムダ式があれば、もうインターフェイスも継承も必要ないなｗｗｗ
オブジェクト指向は必要だが、これからはオブジェクト指向プログラミングはいらないかもなｗｗｗ
13 ：仕様書無しさん：2007/08/30(木) 01:12:05
ラムダ式？要はファンクタだろ。やっぱオブジェクト指向じゃん
14 ：仕様書無しさん：2007/08/30(木) 01:20:09
>>12
> オブジェクト指向ないと
> 現代の複雑なソフトウェアシステムなんて
> まともにつくれんだろｗｗｗ

確かに作れない。作れないが
一般プログラマが使うことはない。
オブジェクト指向はフレームワーク開発者が使うもの。
15 ：仕様書無しさん：2007/08/30(木) 01:26:58
とはいえ、デフォのまんまでフレームワークを使えるケースは少なく
プロジェクトに合うようにカスタマイズする必要がある
16 ：仕様書無しさん：2007/08/30(木) 01:30:03
どんだけつかえねーフレームワークだよｗ
17 ：仕様書無しさん：2007/08/30(木) 01:31:44
>>14 >>15
たしかにな。

というか、アレだな。
「一般プログラマ」ってくくりは語弊があるだろ。
ただ単に「使えないやつ」ってことでおｋ

＠ビジネスロジックでも、Stateパターンとか
SingletonとかNullObjectとかその他もろもろ、
いわゆるデザパタ的なものは普通に使うし、
オブジェクト指向なくてもおｋてことにはならないだろう
18 ：仕様書無しさん：2007/08/30(木) 01:37:48
>>16
つかえねえんじゃなくて、しょうがねえんだよ

RoRみたいなオールインワンタイプの奴ならまだしも
Javaのフレームワークなんか、いろいろ組み合わせて使う前提なんだから
全ての組み合わせが想定されたフレームワークなんてあるわけねえだろ
19 ：仕様書無しさん：2007/08/30(木) 07:43:51



おじゃま某、もともと技術的にまともな事を言えないゴミクズなのはよく判っているが、




最近はチンピラなみに言動がバカになってきたなｗ





いいぞいいぞ。その調子だ。その調子でリアル人格の方も崩壊しちまえｗ
20 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/30(木) 09:18:09
>>19
いやだから、昔から言動は変わってないし、崩壊するほど精神不安定ではないって。
19は前スレの妄想全開の断定君かな？
分かりにくいからコテにすれば？「ダンテ」なんてどうだ？
21 ：仕様書無しさん：2007/08/30(木) 10:52:25
2ちゃんで個人を特定して仮想敵を欲しがるのって妄想だろ？
寂しいから話し相手してくれって、素直になりなよ、おじゃば。
いつもの「妄想乙」じゃなくて、心を開いて。こわくないこわくない。
22 ：仕様書無しさん：2007/08/30(木) 11:59:46
つーかこれで本人はまともだと思ってるのが理解不能
根拠のない断定はお前のほうが数段上手だろ

どう見ても本人の認識と現実が掛け離れてるパターンちゃうか
本人は友達居ると思ってても友達だと思ってる相手からは
友達とは認識されてなかったり嫌われてたりするという現実
23 ：仕様書無しさん：2007/08/30(木) 13:42:47
大人になっても平然と”友達”とか言う人とはお友達にはなりたくないですね
24 ：仕様書無しさん：2007/08/30(木) 18:53:25
>>21
いや、普通に怖いって。
下手に心開いて弱音を語りでもしたら一瞬で食われるって。
25 ：仕様書無しさん：2007/08/30(木) 21:27:29
食われるって…リアルで害が及ぶわけでもないのに？
そんなに2ちゃんに命かけてどーするよ。
26 ：仕様書無しさん：2007/08/30(木) 22:18:29
最近、灰汁出身者の会社に顔出してるけど、
相変わらずレベル低いな、あいつら。

大体文系出身者ならともかく、理系出身でMBAみてぇなクダラねぇ学位拘る時点で（ｒｙ
27 ：仕様書無しさん：2007/08/31(金) 00:38:31
オブジェクト指向は失敗と言っていいのでは？
アルゴリズム → オブジェクト指向ときて今はまだ過渡期なのでは。
これから、デザインパターン、サービス指向等に進んでいくと思うが。
28 ：仕様書無しさん：2007/08/31(金) 00:46:46
これからって何いってんの？
サービス指向って既に流行りまくった上で、遅くて使い物にならないって結論出ちゃってんじゃん
29 ：仕様書無しさん：2007/08/31(金) 00:56:40
相変わらず思考の発散したこと言ってるな。
お前は２ちゃんだからと言って、一貫性のない支離滅裂な発言が多すぎだ。
ちゃんと身近に腹を割って話せるブレーンを用意しておけよｗ
30 ：仕様書無しさん：2007/08/31(金) 01:19:17
デザインパターンはオブジェクト指向だろ。

まぁ、昔のオブジェクト指向のことを言ってるんならあながち間違いじゃないが。

そして、昔のオブジェクト指向のことをいって今のオブジェクト指向を否定するバカもいる。

それ以前に昔のオブジェクト指向のことをまるで今のオブジェクト指向のように取り上げてるのが多いのが問題なんだが。

流動的要素のカプセル化にも言及せずに何がオブジェクト指向かと。
31 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/31(金) 09:03:51
>>21
では試しに素直に回答してみよう。
仮想敵を欲しがるのが妄想？悪いが意味が分からない。哲学か？
話し相手が欲しいってのはなくて、内容のある討論がしたいって事だ。
怖い？つーか、何が怖いのか分からない。討論に負けるのが怖いと言う事かな？
討論で負けるのは良いことだと思っているから、むしろ歓迎。

>>22
現実と本人の認識が掛け離れていると言われると、何を言っても認識誤りになるから、否定する手段がないな。
まあたとえ、俺が無能で嫌われていていたとしても、それなら重要な仕事を任される事はないだろうから
気楽だと思うし、友人がいなければ、それは自由な時間が多いと言う事だろうから、それはそれで
いいんじゃね？

>>25
同意
32 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/31(金) 09:19:16
>>27
アルゴリズムって何のアルゴリズム？

>>30
昔のオブジェクト指向って何？
33 ：仕様書無しさん：2007/08/31(金) 09:56:06
お、おじゃばが全レスしとるｗ

質問：OOPの最大のメリットって何？

質問の背景：
で、OOPって何が嬉しいの？　と聞かれて、
答えているうちに、自分がさほど理解できてないと知った。
非OOPとOOPを比較して、この場合はこのように有利、
という例をスカッとあげることができなかった。
34 ：仕様書無しさん：2007/08/31(金) 10:35:02
オブジェクト指向はハイコンテキスト・コミュニケーションのための、ひとつのツール

同じことをいわんとするとき、熟語や慣用句、メタファを用いた文章がそうでない文章より
意味を理解しやすく簡潔に表現できることに似ている。
35 ：30：2007/08/31(金) 12:28:46
>32
・オブジェクトはデータとその操作をまとめたものである
・カプセル化はデータ隠蔽である
・継承は特殊化と再利用の手段である
というオブジェクト指向。

>33
昔のオブジェクト指向
・現実世界をそのままの形でモデル化することで、実装が簡単になり、属人性を排除できる
・既存クラスを継承し、違う部分だけを実装することで再利用性が高まる

今のオブジェクト指向
・問題領域を流動的要素に着目して分析し、流動的要素をカプセル化することで、システムが堅牢で柔軟なものになる
36 ：仕様書無しさん：2007/08/31(金) 12:48:00
おじゃばに質問２：

「現実世界をそのままの形でモデル化」
というのをOOPの利点だと挙げるひとが散見されますが、
これはOOPの利点として挙げるにふさわしいものですか？
そもそも、これはよくありがちなOOPに対する誤解ではないですか？
37 ：仕様書無しさん：2007/08/31(金) 13:31:09
OOPの利点って、コード間の直交性を高めるって
ただその一点につきるんじゃね？
38 ：仕様書無しさん：2007/08/31(金) 14:02:10
あーあ、とうとう全レスするようになっちゃったよ。
よっぽど気に障ってたんだなぁ。ごめんよ、おじゃばｗ
39 ：仕様書無しさん：2007/08/31(金) 14:06:03
>>30
>デザインパターンはオブジェクト指向だろ。
猛省を望む。
40 ：仕様書無しさん：2007/08/31(金) 15:29:39
>>39
またかよ・・・
41 ：仕様書無しさん：2007/08/31(金) 15:44:48
>>40
何が？
42 ：仕様書無しさん：2007/08/31(金) 15:48:00
>>41
デザパタ・オブジェクト指向無関係厨
43 ：仕様書無しさん：2007/08/31(金) 16:18:59
やれやれ、なんでも厨つけりゃいいとでも思っているんですかねえ？
>>30 が「デザパタ」って単語を出して来ていれば
「ああ、デザパタ = GoF だと思っているいつもの阿呆か」とも思えたんですが。

とりあえずソフトウェアパターンから学習を進めていくと
いいと思いますよ。
44 ：仕様書無しさん：2007/08/31(金) 16:25:13
どうでもいい話に拘泥する
これすなわち厨
45 ：仕様書無しさん：2007/08/31(金) 16:32:05
>>44
あなたがどうでもいいと思っているかどうかなど
それこそ私にはどうでもいいことです。
46 ：仕様書無しさん：2007/08/31(金) 16:34:31
いちいちと突っかかってくる
これ即ち厨
47 ：仕様書無しさん：2007/08/31(金) 16:35:39
>>43 マ板で「デザパタ」っていう用語が出たとき、
GoFの他に何を連想すればいいの？
「Java言語で学ぶデザインパターン入門 マルチスレッド編」とか？？
48 ：仕様書無しさん：2007/08/31(金) 16:53:36
>>47
「デザパタ」と略されていれば、十中八九 GoF のつもりなんでしょう。
「デザインパターン」だと、文脈次第ですね。
49 ：30：2007/08/31(金) 17:12:39
俺の発言に誤解を招くようなところがあったようで。

一般にデザインパターンっていったらGoFの23個の方を指すと思ったんだ。

勿論、デザインパターンが他にあるのは知っているが、今言われてるようなデザインパターンってオブジェクト指向原則に乗っ取ったものじゃないのか？
(他にあるならすまん。俺の勉強不足だ)
(建築分野にもあるってのは知ってるが)

>43
ソフトウェアパターンって、
・デザインパターン
・アーキテクチャパターン
・アナリシスパターン
・アンチパターン
の総称のことでいいのか？
50 ：仕様書無しさん：2007/08/31(金) 17:14:16
「デザインパターン」だと、抽象的な、
デザインのパターンというものについて、ってことですか？
それとも、具体的な候補がGoF以外にでてくるってことですか？
51 ：50：2007/08/31(金) 17:15:31
おっと。>>50は>>48へのレス。
52 ：仕様書無しさん：2007/08/31(金) 19:23:17
contextとproblemとsokutionの一まとまりがパターン
今は厳密な意味じゃなくてもっと漠然としてるけど

>>49
PoEAAが入ってないよ
53 ：30=35=49：2007/08/31(金) 20:00:54
>52
そういわれるとしっくりくるな。

俺が言ってるのは確かにGoFのデザインパターン(デザパタ？)のことだ。

だとするとデザインパターンとオブジェクト指向の間に関係がないと言うのも一理あると思う。
ただ、オブジェクト指向の元で生まれたデザインパターン(デザパタ？)もあることを考えると、全く関係がないというのもどうかと思う。

もし、>27のデザインパターンが本当にデザインパターンのことならば、俺は馬鹿なことを言っていたんだな。
でも、デザパタのことを言っていたとすれば、俺の言ったこともそんなに間違っちゃいないってことか。


エンタープライズアプリケーションアーキテクチャパターンか…
そんなのもあるんだな。
54 ：仕様書無しさん：2007/08/31(金) 20:09:08
おじゃばはおじゃばじゃなくなってもわかると「思う」。
自己顕示したいもんな。
55 ：仕様書無しさん：2007/08/31(金) 20:56:43
>31
＞内容のある討論がしたい

なら、内容のある文章書いてくれよ。頼むから。
冗長なだけの糞文で、何が内容のある討論？
冗談は顔だけにしてくれ。マジで。
56 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/31(金) 21:42:51
>>33
前にファイル操作を例に、抽象化された入出力の利便性を話しただろう。あれを説明すればいい。

>>34
関係無いだろう。

>>35
今のオブジェクト指向の意味が分からない。
流動要素をカプセル化？それだけ聞くと単にパラメータを外出しにするだけのように聞こえる。
抽象化は？

>>36
相応しくない。
現実の物をそのままモデル化と言うのは、モデル化の初期段階として、現実の物を参考に設計した方が
分かりやすいと言うだけだ。ところで質問1は？

>>37
直交性を高めるってどういう意味だ？再利用性の事か？
57 ：仕様書無しさん：2007/08/31(金) 21:47:49
まさかこれからSPAM並の全レスATTACKするつもり？
58 ：仕様書無しさん：2007/08/31(金) 22:00:13
おじゃばがんばれよ
おまえのことは嫌いだけどな。
59 ：おじゃばさま ◆GxjxF3yEw6 ：2007/08/31(金) 22:01:31
>>38
どこかに気に障る要素があったのか？

>>54
そのままでは意味不明。
俺が名無しで書き込んでいるという妄想でもあるのか？

>>55
その言葉、そっくりそのまま返す。
60 ：仕様書無しさん：2007/08/31(金) 22:15:51
直行性知らないって今までどんな本読んできたんだよ…
61 ：仕様書無しさん：2007/08/31(金) 22:26:06
直行性 の検索結果 約 2,020 件中 1 - 10 件目 (0.24 秒)
62 ：仕様書無しさん：2007/08/31(金) 23:36:06
直交性な
達人プログラマかなんかで読んだことある
63 ：35：2007/08/31(金) 23:36:14
>56
抽象化はカプセル化(の作業)に含まれる。
ひょっとしてデザパタとかそんなに知らなかったりする？
直交性についてもあまりご存知ないようだし。
64 ：仕様書無しさん：2007/09/01(土) 00:17:14
直交性ってのはつまるところ、変更容易性を高めるものだ
オープン･クローズドの原則とか聞いたことあるだろ
65 ：仕様書無しさん：2007/09/01(土) 00:28:15
>オープン･クローズドの原則とか聞いたことあるだろ
うーん、デバイスのオープン・クローズなら知ってます
あと、Paintのビギン、エンドも知ってます
これが、OOなんですか？？？？
66 ：仕様書無しさん：2007/09/01(土) 00:38:35
はいはい
67 ：仕様書無しさん：2007/09/01(土) 01:02:19
OCPの話が出たがら、LSPやDIPも出てくるかなと期待してみる。
68 ：仕様書無しさん：2007/09/01(土) 06:03:39
誰か言ってやれよ。
OOの利点は設計とコーディングの親和性の高さだ、って。
69 ：仕様書無しさん：2007/09/01(土) 10:51:34
OOの利点は、単純に「使える手法が増える」というだけだろ。
設計でも変更作業でも、攻める手筋と手駒が増えるんだよ。
70 ：仕様書無しさん：2007/09/01(土) 10:58:06
>>69
不勉強乙
71 ：仕様書無しさん：2007/09/01(土) 11:00:34
>>35
カプセル化なんかは、機能分割ベースのモジュール化でも行われるわけで。
カップリングとコヒージョンの話はOOに関係なく出てくるし。

＞・オブジェクトはデータとその操作をまとめたものである
この前提に、すごい違和感あるんだけど。
72 ：仕様書無しさん：2007/09/01(土) 11:04:43
でも
＞・オブジェクトはデータとその操作をまとめたものである

ってかなり便利
73 ：仕様書無しさん：2007/09/01(土) 11:26:55
>>71
必要条件と十分条件の区別ぐらいしろよ
74 ：仕様書無しさん：2007/09/01(土) 12:38:19
>>73
機能分割したモジュールについてカプセル化と継承が行われてたら「オブジェクト指向」か？
そんなオブジェクト指向は古今にかかわらずねぇよ。
75 ：仕様書無しさん：2007/09/01(土) 12:44:51
>>74
だからそれは35の言ってることの逆なんだから真偽が一致するわけないだろ
きちんと区別しろって
76 ：仕様書無しさん：2007/09/01(土) 13:10:00
多分だが、>>73-74 のやり取りから察するに
>>74 には「逆」の意味が判らないと思われ。
77 ：仕様書無しさん：2007/09/01(土) 13:21:16
逆裏対偶って高校で習ったね
78 ：仕様書無しさん：2007/09/01(土) 13:42:20
おまいら言葉遊び乙
79 ：仕様書無しさん：2007/09/01(土) 13:54:01
言葉遊び嫌いな奴にはオブジェクト指向理解できんだろうな
言葉で本質を表現することができないとこと、必ずしも本質を表現できていない言葉であっても
それでも別の何かの役に立てることができることの区別がついてないって感じ
80 ：仕様書無しさん：2007/09/01(土) 13:56:18
>>78
それで誤魔化したつもりか。
81 ：仕様書無しさん：2007/09/01(土) 13:57:37
必死だな
82 ：仕様書無しさん：2007/09/01(土) 13:59:56
命題条件も理解できてない奴らにオブジェクト指向は無理。

こういう連中が言葉遊び乙とか言って自分を正当化したあげく
「やっぱりオブジェクト指向は糞！」みたいに吹聴して周ってるんだろうな。
83 ：仕様書無しさん：2007/09/01(土) 14:03:58
ほんとに必死だな
84 ：仕様書無しさん：2007/09/01(土) 14:07:22
結局「必死だということにしたい」に辿りつくわけか。哀れ。
85 ：仕様書無しさん：2007/09/01(土) 14:12:47
うんうん
86 ：仕様書無しさん：2007/09/01(土) 14:13:50
煽り合いなら他所でやれよ
このスレ、頭からずっと煽り合いばっかじゃねえか
削除依頼出すか…
87 ：仕様書無しさん：2007/09/01(土) 14:14:33
ほんとに必死だな
88 ：仕様書無しさん：2007/09/01(土) 15:19:26
>>86
今頃になってまだそんな事言い出す人がいるとは思わなんだ。
マ板で OO つったら、ずっとこんなもんだ。
89 ：仕様書無しさん：2007/09/01(土) 15:25:23
OOはみんなの心の中に存在する神様なんです。


～Fin～
90 ：仕様書無しさん：2007/09/01(土) 15:31:22
じゃあオブジェクト指向に言ってくるかな。
自己負担三割だし。
91 ：仕様書無しさん：2007/09/01(土) 16:09:31
>>89
神格化してる奴がいる間は普及しないな
92 ：仕様書無しさん：2007/09/01(土) 23:54:34
とりあえず「間違った本」が出回り過ぎて、その問題が今出てきてるんだろ。
オブジェクト指向だと再利用が可能、なんてことを言ってるのは悲惨すぎ。
再利用なんて昔からライブラリとして利用してたわけで、
まともな奴なら、再利用とか当たり前のことを何言ってんの？って感じで、
違和感覚えるだろ。関数でやりゃいいじゃん、と。

カプセル化もそう。
メンバーをprivateにして、ゲッター、セッター、って、
そりゃお前publicとかわんねーじゃねーか、と。

こういう、
オブジェクト指向の名に、違和感を覚えてる奴はまともなんだよ。
しかし書籍がな。
悪書が普及してるために、オブジェクト指向が普及してないのはあるんじゃねーの？
93 ：仕様書無しさん：2007/09/02(日) 00:04:01
でもデータと操作をセットに書くようになって
ずいぶんとプログラムが楽になったしバグも少なくなった
でもちとメモリ食うのとちと遅くなったｗ
94 ：仕様書無しさん：2007/09/02(日) 00:22:29
>でもちとメモリ食うのとちと遅くなった
だからさ、OOはメタボに陥りやすいんだよ
C言語の達人じゃないのがOOを使うとと大量のメタボプログラムを作る
まずは、C言語をマスターしろ！　OOの達人の必要条件はCの達人であることなんだぞ
95 ：仕様書無しさん：2007/09/02(日) 00:28:02
>>94
お前の言うCの達人の条件って何だよｗ
96 ：仕様書無しさん：2007/09/02(日) 00:33:47
いやいや、メモリ消費を気にしたり速度気にすれば
そういうプログラムも書けるよ！
もちろんC言語もマスターしてるよ！
97 ：仕様書無しさん：2007/09/02(日) 00:42:08
>>95
ま、coutじゃなくprintfを使わないとプログラムした気にならないぐらいのレベルの香具師で、
一方でboost使いまくりの香具師かな
ついでに、C達人はclassじゃなく、structを使ってクラスを定義しないとOOしてる気にならない様な香具師である
98 ：仕様書無しさん：2007/09/02(日) 00:44:53
>>97
どうでもいいことだな。

お前は、オブジェクト指向という考えではなく、
ただの一言語に支配されているだけ。
99 ：仕様書無しさん：2007/09/02(日) 00:50:00
http://d.hatena.ne.jp/JavaBlack/
中の人、頭でっかちでかわいそうだ
100 ：仕様書無しさん：2007/09/02(日) 00:55:48
>>99
違います。

そうじゃない。

そこじゃない。


否定の単語を羅列してないで、
お前の意見を書けといいたくなるなｗ
101 ：35：2007/09/02(日) 01:04:00
>71
機能分割でのモジュール化は実装のカプセル化やね。
オブジェクト指向でよく言われる流動的要素のカプセル化とは依存の方向が逆。(DIP)
勿論、使う側からみれば依存方向はモジュールと同じだけど。

あと、俺が言った昔のオブジェクト指向ってのは今でいったら間違ったものだし、俺が挙げた昔のオブジェクト指向のメリットも、あれは実際メリットでなく目標でしかなかった。しかも失敗してる。


>92
同意
102 ：仕様書無しさん：2007/09/02(日) 01:12:02
>>92
それ以前の問題で、本なんか読まないってやつがほとんどなんじゃね? > オブジェクト指向できないやつ
103 ：仕様書無しさん：2007/09/02(日) 01:14:19
オブジェクト指向とか金型があって、
その金型から、実際に使うものをいくつでも生成できるもの。

スライムという種別があって、
その種別のスライムA、スライムB、スライムCが現れた。
見たいなもんだ。
104 ：仕様書無しさん：2007/09/02(日) 01:19:12
オブジェクト指向っつーか、クラスの説明に見えるなぁ
105 ：仕様書無しさん：2007/09/02(日) 02:00:34
よくゲッターセッターを批判する文章を見かけるんだけど、
何か要点を踏み外してる気がするんだよなあ

オブジェクトから値をとるとき、全てをメモリに置いてそこから読み出すんじゃなくて
計算で出せるものはなるべくそうしようってのがDRYの考え方だよな
で、そのとき計算値なのかメモリから引っ張ってるのか、呼び出し元で
意識しないですむようにするのがゲッターの目的だよな

ぶっちゃけ、ゲッターセッターにメリットがあるとは俺も感じないんだけど
批判するなら上で書いたことにも言及しないとダメじゃね？
106 ：仕様書無しさん：2007/09/02(日) 02:01:35
>>92「間違ってない本」教えてください。
107 ：仕様書無しさん：2007/09/02(日) 02:09:10
>>105
> オブジェクトから値をとるとき、全てをメモリに置いてそこから読み出すんじゃなくて
> 計算で出せるものはなるべくそうしようってのがDRYの考え方だよな

はぁ？

DRY = Don't Repeat Yourself （同じことを二度書くな）

計算でさせるものはそうしようとか言う意味はねーよ。
ソースコード中に同じようなことを二回書くなってこと。
むしろPublic変数があればすむのに、
プライベート変数とゲッターセッターを書くことがDRYに反してる。
108 ：仕様書無しさん：2007/09/02(日) 02:15:37
よくOOP以前のライブラリを引き合いに出して、再利用性の批判する奴いるけど（ｒｙ

呼び出し元の再利用性（要は、フレームワーク）にも言及しないとダメじゃね？
109 ：仕様書無しさん：2007/09/02(日) 02:19:00
>>106
ダメな本
http://d.hatena.ne.jp/JavaBlack/20070805/p2

良書
http://d.hatena.ne.jp/JavaBlack/20070522/p1

初心者向けオブジェクト指向学習法
http://d.hatena.ne.jp/JavaBlack/20070825/p1
110 ：仕様書無しさん：2007/09/02(日) 02:19:15
>>107
はあっつか俺が考えたわけじゃなくて、
達人プログラマに書いてあったことほとんどそのままだよ
まあ俺の理解が間違ってるかもだけど

>オブジェクトから値をとるとき、全てをメモリに置いてそこから読み出すんじゃなくて
>計算で出せるものはなるべくそうしよう

だからまあ、批判するならこっちをしてくれよ
111 ：仕様書無しさん：2007/09/02(日) 02:36:57
まぁ、一切の値チェックやフックをしないなら直接publicでも可…かな？
つーか俺、名前そのままのセッタって滅多に作らないのだけど
setXxxxx()ってそんなに頻繁に作る？
大概の場合、もう少し違った書き方にならない？
俺はコンストラクタの時点で渡すか
changeXxx()
replaceXxx()
addXxx()
removeXxx()
みたいな感じで、もう少し違った名前になるか
getXxx().change()
みたいに、メカザウルス自体はゲッターだけでストナーサンシャイン
112 ：仕様書無しさん：2007/09/02(日) 03:01:19
話戻すと、カプセル化とゲッターセッターってイコールじゃないじゃん
プロパティがある言語ならゲッターセッター無くてもカプセル化できるだろ
いずれにしても、ゲッターセッターがアホらしいからってカプセル化が無意味って
話にはならない
113 ：仕様書無しさん：2007/09/02(日) 08:30:19
おれおれオブジェクト指向と揶揄する奴を見て、
「おれおれ、ってどういうのを指してんの？」と思うのは正常。
114 ：仕様書無しさん：2007/09/02(日) 09:18:57
セッターゲッターはカプセル化でもなんでもないよ。
内部実装にアクセスする表現を全てメソッドに統一するための小手先のテクニックでしかない。
小手先のテクニックのおまけ機能で、内部実装を変更してもインタフェースを変更しなくてもすむかもしれないって程度。
ここらへんの話もオブジェクト指向入門に書いてある。
115 ：仕様書無しさん：2007/09/02(日) 09:37:45
でもStrutsタグはゲッターないと表示してくれなくない？
116 ：仕様書無しさん：2007/09/02(日) 10:04:54
萌えOOPとか出版されないと普及は難しい。
117 ：仕様書無しさん：2007/09/02(日) 10:07:26
オブジェクト指向のスレでなんで特定のフレームワークの話をしたがるのかね。
118 ：仕様書無しさん：2007/09/02(日) 10:41:36
オブジェクト指向の最大の弱点は、人を選ぶことだろうな。
この世に、ヘタな奴が書いたオブジェクト指向もどき
プログラムほど読みたくないものはない。
119 ：仕様書無しさん：2007/09/02(日) 10:48:11
>>114 じゃあカプセル化って何よ？言える？
120 ：仕様書無しさん：2007/09/02(日) 10:48:18
お、お、オブジェクトたんの好みの殿方はどんなたいぷでつかー？
121 ：仕様書無しさん：2007/09/02(日) 10:55:08
>>118
> ヘタな奴が書いたオブジェクト指向もどき

詳しく。
122 ：仕様書無しさん：2007/09/02(日) 10:58:59
微妙に古臭いテイストが混ざってて萌え絵になりきってない漫画ってあるだろ

それと同じ
123 ：仕様書無しさん：2007/09/02(日) 10:59:26
>>115
ActionFormはBeanである必要があるな。
が、Javaにおける全てのクラスがBeanである必要はない。
アクセサなければクラス内に隠蔽できる。
124 ：仕様書無しさん：2007/09/02(日) 13:13:44
カプセル化はOCPのためにある
あるクラスの内部構造を変更したとき(ただし、仕様は変えずに)、その変更がどんなものであっても
そのクラスの呼び出し元を修正する必要がないことが保障されている状態について、カプセル化という。

C++やJavaの場合は、const/finalでないPublic変数を使った時点でOCP違反となるが、
C#やRubyなどは、Public変数をアクセッサに変更しても呼び出し元を修正する必要は無いのでOCP違反とは必ずしもならない
125 ：仕様書無しさん：2007/09/02(日) 14:03:45
> C++やJavaの場合は、const/finalでないPublic変数を使った時点でOCP違反となるが、

それはクラスの外部インターフェースを変更したときであって、
「クラスの内部構造を変更したとき」云々という説明と関係ないよね。
OCPを実現する上でどちらが理想的か、という問題はあるにしても、
違反と言うほどのものでもない。
126 ：仕様書無しさん：2007/09/02(日) 14:04:34
OCPって何？
127 ：仕様書無しさん：2007/09/02(日) 14:18:39
>>124
C++でなければ、リファクタツールが充実しているのでそれほど気にすることは無いかと
ちなみにC++では template メタプログラミングを駆使するとプロパティーと同様の書き方機能を持つメンバを作り出せたりするw
変数に書き込んだ瞬間に呼び出されるメソッドが作れるという事実にはたまげたよ。
オレの見たのは operator == のオーバーロードからスタートしてboostのラムダ演算をめぐりめぐって Get/Set メソッドへ制御を飛ばす物。
まだ他にも手段はあるらしい。
128 ：仕様書無しさん：2007/09/02(日) 14:27:28
OCPって何よ
129 ：仕様書無しさん：2007/09/02(日) 14:30:54
そんぐらいググれ
130 ：仕様書無しさん：2007/09/02(日) 14:42:48
C++でtemplate使うとpimpl崩壊する・・・
やっぱtemplateメタやらないといけないのかな。
131 ：仕様書無しさん：2007/09/02(日) 14:49:31
なんかさぁ、ここって古い話題ひたすらこねくり回してねぇ？
話題が退屈なんだよな
132 ：仕様書無しさん：2007/09/02(日) 14:52:29
C++ならtemplate使って、JavaならAOP使って・・・ってのは、まあ枝葉の話だわな
なにしろ、カプセル化はOCPのためにあって、OCPに違反してなきゃどんなカプセル化のやり方でも
かまわないってことを言いたかった
133 ：仕様書無しさん：2007/09/02(日) 14:58:48
話が進み始めたころについて行けないアホコテがレベルを下げるってな永久ループスレだからね
134 ：仕様書無しさん：2007/09/02(日) 16:17:55
OpenClosePrincipleは重要だけど別にカプセル化がそのためにあるってわけでもない
同じことを言ってるだけ
135 ：仕様書無しさん：2007/09/02(日) 18:18:01
>>128
ロボコップ作った会社だろ？
136 ：仕様書無しさん：2007/09/02(日) 18:26:01
ちがうべ？
OCP（Oracle Certification Program）
137 ：仕様書無しさん：2007/09/02(日) 18:58:47
オブジェクト指向ってのは、結局は、保守性やら再利用性やらの追及にある。
派遣社員だらけのこの業界では「作ってリリースしたらバイバイ」というのが基本スタイル。
つまり、未来のためのコーディングはしないのさ。
138 ：仕様書無しさん：2007/09/02(日) 19:19:11
>>131
ん～？
物同士の関係を表す手法なだけで、
保守性やら再利用性やらは全然関係ないだろ。
139 ：仕様書無しさん：2007/09/02(日) 19:31:08
今はそれに変わる方法がないんだろうけど
オブジェクト指向は最終的にはダメだと思う。

OOPは、ある概念を規定しようとするとき、
その概念を特徴付けるメソッドの存在を定義してしまい、
その概念を実現するオブジェクトには
そのメソッドの実装を強制するような仕組みになっている。
たぶんここがダメ。

というのも、現実世界においては、どんな言葉についても、
ある言葉が人から発せられる際、
そのあらゆるケースについて、そのケースに必ず含まれるような
その言葉を特徴付ける共通の属性など存在しない。
ある言葉が使われるさまざまなケースにおいて、
その同じ言葉が使われる理由は、そのケースにおいて
多くの話者を一致させるような家族的類似性があるから、
としかせいぜい言いようが無いわけで。
(この段落はウィトゲンシュタインの受け売り)

で、にもかかわらず、ある概念にあてはまるオブジェクトには
共通のメソッドが存在することを前提とした
OOPのような方法をつかって、現実の事象をモデル化しようとしたところで、
そんなもんうまくいくわけがないよなー、と、思うんだよな。
つかみ所の無いクラスライブラリやフレームワークの
APIのドキュメントを読むたびに思う。
140 ：仕様書無しさん：2007/09/02(日) 19:35:27
オブジェクト指向って、
「お前は間違ってる」
「お前の方こそ間違ってる」
「どっちも間違ってる」
と全員が間違い探しを始める手法のことだよな？
141 ：仕様書無しさん：2007/09/02(日) 20:11:27
>>139
例えばIntegerってクラスがあったとして、使い手はそのクラスをIntegerと認識して使ってるわけじゃないじゃん
countであったりlengthであったりnumberであったり、そういう風に各々勝手に理解して使ってるわけじゃん
即ちIntegerの使い手達は、IntegerがIntegerであるという共通認識のもとでIntegerを使ってるわけじゃないじゃん
要はIntegerってモデルを定義する側と、モデルを使う側は同じ考え方を共有する必要はないわけじゃん
この「モデル(=概念(=サブジェクト))自身とそのモデルの使い手の間で、同じ考え方を共有する必要性の無さ」
を指して、「オブジェクト指向」っていってるわけじゃん

なんでかわからないけど、
「絶対普遍の共通概念を定義すること=クラス設計」
って誤解が多いんだよな。というか、ついそう考えたくなるんだよな。
142 ：仕様書無しさん：2007/09/02(日) 20:17:05
>>139
日常会話レベルなら概念の定義が曖昧な事もあるだろうけど
論文レベルだとちゃんと定義があるだろ

クラス図の前段階としてマインドマップを使えないか？
って話があったと思う
143 ：仕様書無しさん：2007/09/02(日) 20:24:05
>>141
じゃん
じゃん
じゃん
じゃん
じゃん
だよな
144 ：仕様書無しさん：2007/09/02(日) 20:25:02
>>141
Integerはlengthとかのスーパークラスじゃない？
面倒だからわざわざサブクラスにしないだけ
145 ：仕様書無しさん：2007/09/02(日) 20:26:15
構造化のときに、嘘なんだけどわかりやすい「gotoレス」があったような
もんがOOにあればいいんだけどね。
こうすりゃとりあえずOO、つのが数多すぎて困っちゃうよｗ
146 ：仕様書無しさん：2007/09/02(日) 20:26:50
>>144
それが誤解だっつの
凝り固まっちゃってる？
147 ：仕様書無しさん：2007/09/02(日) 20:30:28
kwsk
148 ：仕様書無しさん：2007/09/02(日) 20:31:22
だな。lengthがfloatのサブクラスだったりしてもなんの不都合もない。
149 ：仕様書無しさん：2007/09/02(日) 20:37:23
もはや何の話をしてるのか意味不明だ。
150 ：仕様書無しさん：2007/09/02(日) 20:40:27
頑張って考えろよ
多少ごちゃごちゃしてるけど、そんな難しい話してないし
151 ：仕様書無しさん：2007/09/02(日) 20:41:42
抽象度の高いクラス(Integerとか)はいろんな使い方を出来てしまう
限定されてないんだから当然
152 ：仕様書無しさん：2007/09/02(日) 20:48:17
じゃあIntegerじゃなくてもいいよ
HttpClientをラップしたクラスつくって、外部にカウント取りに行くクラス作って
それをcountって呼んでもいいし
要は使い手は、countを返してくれるものをcountと呼ぶってこと
153 ：仕様書無しさん：2007/09/02(日) 21:00:39
創り手が意図しない使い方をする事があるって事を言いたいんだとおもうけど
それは抽象化したレベルで共通の性質が有るから
例えば、包丁を刀みたいに使って人を傷つけるとか
154 ：仕様書無しさん：2007/09/02(日) 21:04:26
>最終的にダメ
ってのが結局どういうことなのかわかりません
155 ：仕様書無しさん：2007/09/02(日) 21:09:51
>>153
作り手が意図しない、っていうより作り手が使い手に意識させる必要がないってこと
>>152のHttpClientの例考えてみ？
どうやってカウントを取るか、その詳細は使い手が気にするべきかどうか。

そして、言うまでも無く全てのクラスに共通の性質は確かにあるんだよ
・操作を呼ぶ
・値を返す
でもそれは、抽象化ってのとはちょっと違う
156 ：仕様書無しさん：2007/09/02(日) 21:22:10
抽象化と継承の話がごちゃごちゃしてるから伝わらないんだろ
157 ：仕様書無しさん：2007/09/02(日) 21:28:07
integerとかいうのは、
実態はvalidationつきの変数なんだよ。

つまり、ある範囲の整数しか代入できないという
制約がついた変数。

いい加減コンピュータの都合によって作られた変数なんてのは消えてほしい。

型というものを作るのなら、もっと柔軟に、integer(10) （十桁の整数型）というものも
宣言できるようにしてほしい。

string(10)で10桁の文字列型。もっと発展して、string(/^\d{3}\-\d{4}$/) 郵便番号の正規表現型とかな。
158 ：仕様書無しさん：2007/09/02(日) 21:34:45
では、どうして作り手と使い手が同じ概念を共有しないですむようにしたのかというと
それはやっぱり再利用性のためなんだな

なぜなら、あるドメインについて考えるとき全てが無矛盾な状態での概念の切り出し方ってのは
「複数」存在するから。公理系って言葉知ってればなんとなくわかると思う

そしてそのドメインや他のドメインを含むメタドメインの領域で、なんらかのアプリケーションを
つくろうとした際に、概念の切り出し方が1つだけしか許容されないって前提を作ってしまうと
再利用性の観点で著しく不利になる
要はドメイン単体で考えたときには矛盾がなかったモデルのはずなのに、組み合わせると矛盾が
生じてしまうってことだ。いろんなところで作られたライブラリを組み合わせることを想像してみて欲しい

だからそもそも(あるドメイン内に存在する)我と、(他のドメインにいる)彼とで同じ考え方を共有する
必要があるのか、いやその必要はないってのがオブジェクト
指向って名前に込められた意味ってわけだ

全てのドメインで、統一された切り口で生み出されたモデルを使って構築されたアプリケーションは
確かに美しいかもしれない。だが、はたしてアプリケーションを使う側にとってそれは必要なことなのか、
そして作る側にとって現実的なことなのかってことに対する、ひとつの解がオブジェクト指向だ
159 ：仕様書無しさん：2007/09/02(日) 21:35:29
もうどうでもいいや ^^;
160 ：仕様書無しさん：2007/09/02(日) 21:40:32
長すぎて読む気にならん。
161 ：仕様書無しさん：2007/09/02(日) 21:48:04
田嶋陽子なみの自己陶酔論だな
162 ：仕様書無しさん：2007/09/02(日) 21:52:46
>>158
こんな思想で構築されたOO言語なんてあったっけ
163 ：仕様書無しさん：2007/09/02(日) 21:54:19
物同士の関係や意思疎通の道具は、UMLなどの要求定義と設計技術やろが・・・。

ユーザーが使う＆依頼する上で、オブジェクト指向がどうかかわるというのか。
まさか客にクラス図なんて見せて満足げにしてるんじゃないよな・・・。
164 ：仕様書無しさん：2007/09/02(日) 21:58:24
>>158
おまぃ、おじゃばだろ
165 ：仕様書無しさん：2007/09/02(日) 22:02:37
ＵＩとオブジェクト指向、全く関係ないな。
こういうポン助が現場を混乱させ、デスマを引き起こす。
166 ：仕様書無しさん：2007/09/02(日) 22:06:00
「お前間違ってるよ！」
「いいや、お前が間違っている！」
「いや、お前だ！」
「お前だ！」

「ちょっとまてまて、俺が間違っている」

「どうぞどうぞ」「どうぞどうぞ」
167 ：仕様書無しさん：2007/09/02(日) 22:09:08
これが本当の、オブジェクト至高倶楽部
168 ：仕様書無しさん：2007/09/02(日) 22:21:20
オブジェクト指向を神格化＋理解が難しい物と考えてる奴が多すぎ。

基本構成のクラス・ポリモ・継承を理解し、設計と製造に落とせれば基本はＯＫなんだよ。
あとは経験を積んで、本を読んで、という通常の学習方法でいい。
学習していく中で、知らないことや新しいことが出てくれば、また学習。
それの繰り返し。

その当たり前のことを、
理由は分からんが小難しいことを言って阻害したがる奴がおる。
その結果敬遠される＝普及しない。

もちろん最初から学習放棄してる奴は論外だけど。
169 ：仕様書無しさん：2007/09/02(日) 23:07:58
Javaなんかでは、親クラスの持ってる属性は子クラスも持ってるのが当然なんだが
言語によっては子クラスが親クラスの属性を持たないとか
親クラスのメソッドをオーバーライドする際にprivateにするのを許すなんて処理系もある。
170 ：158：2007/09/02(日) 23:45:51
大体予想どおりのレスがついたところで、俺のいいたいことの要諦を再掲

> 「絶対普遍の共通概念を定義すること=クラス設計」
> って誤解が多い

この誤解を解かないまま経験を積んでいくと大抵OOアンチになるはず
なぜなら、
> 「絶対普遍の共通概念を定義すること=クラス設計」
こんなことは現実問題として無意味、不可能だと気づくだろうから
171 ：仕様書無しさん：2007/09/03(月) 00:10:29
全然意味がわかりません
本当にありがとうございました
172 ：仕様書無しさん：2007/09/03(月) 00:15:21
>>170
っていうかさー、オブジェクト指向が一番素直な考え方ではないというのならさ、
じゃあ、何が一番素直な考え方だと思うの？
173 ：158：2007/09/03(月) 00:30:31
>>172
まずもって、「オブジェクト指向が一番素直な考え方ではない」
って主張をした覚えが無いわ
どこをそう読んだか指摘してくれればその個所を噛み砕いて説明するけど
174 ：仕様書無しさん：2007/09/03(月) 00:36:03
>>172
アホコテはスルーしれ。
175 ：仕様書無しさん：2007/09/03(月) 00:40:20
>>173
そういう主張をしていないというのなら、

オブジェクト指向は、ごく自然に考えたものを、
そのまま実装すれば良いだけ
何も難しいことはない。
と俺は主張したいんだが、問題ないよね？
176 ：158：2007/09/03(月) 00:49:55
>>175
したければ、どうぞ？

あまり同意はできんけど。
上で俺が主張したこととは別に、感覚的な問題でな
177 ：仕様書無しさん：2007/09/03(月) 00:51:19
ヘタな文章とは――

・書き手の言いたいことが明確でなく、主張が伝わってこない
・内容の構成や順序が整理されておらず、わかりにくい
・主張を裏付ける情報がなく、論理的に納得できない
・難しい用語が定義されないまま使われ、意味がわからない
・長い文が続くうえ、冗長な言い回しが多く、読みにくい
178 ：仕様書無しさん：2007/09/03(月) 01:04:10
>>158には>>168をよく読むことをお勧めする
179 ：仕様書無しさん：2007/09/03(月) 01:06:59
>>178
自演乙
180 ：仕様書無しさん：2007/09/03(月) 01:09:46
>>179
妄想乙
181 ：仕様書無しさん：2007/09/03(月) 01:14:34
下手な文章を書くやつは、
自分が下手な文章だと気づいていない。
182 ：158：2007/09/03(月) 01:16:40
>>178
もとをただせば俺はただ、OO批判に対する回答をしてただけなんだが
問題領域の共有ができてなきゃ、読むのはさぞつらかろう
183 ：仕様書無しさん：2007/09/03(月) 01:20:14
> 問題領域の共有ができてなきゃ

このように下手な文章を書きます。
184 ：158：2007/09/03(月) 01:24:13
じゃあ簡単に書くよ

>>139を読んでないor意味がわかんない(俺もわかってる自信ないけどｗ)
>>158だけ読んでも意味わかんなくね？
185 ：仕様書無しさん：2007/09/03(月) 01:27:42
意味わかんないのにわかった振りして
適当に話をあわせるから
ますます話がめちゃくちゃになる。

自称頭がいい人同士の会話ｗ
186 ：158：2007/09/03(月) 01:44:28
じゃあ、>>158の内容を簡単に書くよ

Q「オブジェクト指向って、クラス作るじゃん。いろいろ勉強していくうちに
クラスの作り方(コードの書き方)は分かったんだけど、クラスの正しい設計の
仕方ってどんなのよ。やり方書いてある本なんてねーじゃんｗ」

A「別に正しくなくても動きゃいいよｗ後でなんとでもなるからｗ」

いろいろ違うけど、そんな感じ
187 ：仕様書無しさん：2007/09/03(月) 01:59:05
あ、わかった！
OO推進してる奴らはみんな説明が下手。
188 ：仕様書無しさん：2007/09/03(月) 02:04:29
>>187
おまえmanで出てくるヘルプとか読めないタイプだろ。
自分が理解できないからって他人もそうだと思うなよ。
189 ：仕様書無しさん：2007/09/03(月) 02:07:50
「オブジェクト指向＝クラス」だと思っているバカが集うスレはここですか？
190 ：仕様書無しさん：2007/09/03(月) 02:13:13
たしかにmanのヘルプは読みにくい。
191 ：仕様書無しさん：2007/09/03(月) 02:40:25
manページってあれ英語のほうがわかりやすいよな。なんでだろ。
192 ：仕様書無しさん：2007/09/03(月) 02:58:29
Linuxの日本語が変なのは昔から。
193 ：仕様書無しさん：2007/09/03(月) 03:42:50
他人のオブジェクト指向に駄目出しするばっかりで自分では自分じゃ読んでもいない書籍の
アマゾンのアフィリエイトを貼るだけの>>109のblogを見ていてふと思ったんだ
もしかしたらオブジェクト指向なるものは実際には存在していなくて
あるのはオブジェクト指向言語とデザインパターンだけなんじゃなかろうかと

そんなことはないよね？
194 ：仕様書無しさん：2007/09/03(月) 07:49:32
>>193
デザパタのどこがオブジェクト指向なのか説明してくれ
195 ：仕様書無しさん：2007/09/03(月) 09:47:44
>>194 意図的に誤読してんの？

> もしかしたらオブジェクト指向なるものは実際には存在していなくて
> あるのはオブジェクト指向言語とデザインパターンだけなんじゃなかろうかと

「もしかしたらAは存在していなくて
あるのはオBとCだけなんじゃなかろうかと」

という文だろ？　お前の脳はいつもカオスか。
196 ：仕様書無しさん：2007/09/03(月) 11:02:32
オブジェクト指向言語は確かに存在する。
デザインパターンはGOFがその一面を定義した。概念上のものだが存在すると仮定して良いだろう。

「オブジェクト指向」自体はやはり概念上のものだ。パラダイムと呼ぶ人もいるけど。
「オブジェクト指向は存在するか」は「神は存在するか」と同じ疑問にしか聞こえない。
概念はそれを信じるものにとっては確実に存在し、信じないものにとっては存在しない。
197 ：仕様書無しさん：2007/09/03(月) 11:41:25
>>193
デザインパターンはOOとはまったく独立に存在しますし
OOPL は OOP の現実解です。
198 ：仕様書無しさん：2007/09/03(月) 14:11:45
>>197 OOとはまったく独立に存在するデザインパターンとは、例えば何？
GoFのは「オブジェクト指向における再利用のためのデザインパターン」なわけで。
199 ：仕様書無しさん：2007/09/03(月) 18:20:19
つアンチパターン
200 ：仕様書無しさん：2007/09/03(月) 18:53:06
なんかオブジェクト指向がそういう超越的な存在なんだとすると
たしかに>>109のブログみたいに原理的なことは考えないで
実践的なことだけ知ってりゃいいよってのもアリだなと思うね
下手に変な宗教にはまって戒律で身動きとれなくなられたりすると困るしな
念仏さえ唱えてりゃ極楽浄土ですよと
201 ：仕様書無しさん：2007/09/03(月) 18:58:24
技術の話に宗教を持ち出すのは間違いだと思うんだ。
根拠を信仰心に求めるってのは技術者としてどうか。
宗教うんぬん言い出す前に検討すべきことがあるはず。
202 ：仕様書無しさん：2007/09/03(月) 19:39:10
なんだこの流れ。

オブジェクト指向設計を全社的に導入して、関連するイベントでも
積極的に講演をしてる某社が、慢性的な納期遅れに陥ったあげく、
外注依存がすぎて品質がボロボロになっている理由が、
なんとなくわかった気がするよ。
203 ：仕様書無しさん：2007/09/03(月) 20:08:39
なんだぁ、今日はおじゃばいないのか、つまんねーのw
204 ：仕様書無しさん：2007/09/03(月) 20:56:49
デザパタ作った奴はオブジェクト指向わかってないってのが問題なんだな
ここが勘違いのはじまりと言っていい
デザパタ覚えてオブジェクト指向覚えたと思ってるアフォは
オブジェクト指向の本をもっとちゃんと読んでみたまへｗ
205 ：仕様書無しさん：2007/09/03(月) 21:06:33
ラピッドデベロプメントっつーエンジニアなら絶対に読んでなきゃならない本には、
オブジェクト指向開発を過信しちゃならねーって書いてあるけどな。
オブジェクト指向を導入してデスマになった言ってる奴は、どんな技法を使ったところでデスマるよ。
一技法が劇的なプロセス改善をするなんてことはありえない。
206 ：仕様書無しさん：2007/09/03(月) 21:17:57
139で自分で煽っておいてなんだが
このスレちょっと殺伐としすぎだなｗ
カリカリせずに久しぶりにこれでも読んで息抜きしようよ
ttp://hp.vector.co.jp/authors/VA000092/jokes/strup.html
207 ：仕様書無しさん：2007/09/03(月) 22:00:37
C++ や Java で、オブジェクト指向なんて言ってる奴は
本質理解していないから、死ね（ｗ
208 ：仕様書無しさん：2007/09/03(月) 22:05:21
>>207さまが、オブジェクト指向の本質をどう考えているかを
これから説明してくださるそうですｗ
209 ：仕様書無しさん：2007/09/03(月) 22:21:09
C#に違いない
210 ：仕様書無しさん：2007/09/03(月) 22:39:40
意外と Smalltalk かもしれない
211 ：仕様書無しさん：2007/09/03(月) 22:40:36
オブ脳買ってきたけど余りのキモさに挫折しそうです！
212 ：仕様書無しさん：2007/09/03(月) 22:42:49
このスレ見れば、何で普及しないのか判る気がする。

難しいからだ。
213 ：仕様書無しさん：2007/09/03(月) 22:57:27
ちがうちがう、ぜんぜんちがうよね
普及しないのは、低能PGが大多数を占めるからなのです。
214 ：仕様書無しさん：2007/09/03(月) 23:01:08
馬鹿だな全然ちげーよ。
OOPが普及しないのはOOPなんて無きゃ無いで困らないからだよ。
215 ：仕様書無しさん：2007/09/04(火) 05:03:46






　　　　　　　　　　　　　　　　　　　　　話がつまらない人間が無理にレスを重ねるために





　　　　　　　　　　　　　　　　　　　　どうしようもなくつまらなくなっている






　　　　　　　　　　　　　　　　　　　　かわいそうなスレｗ






216 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/04(火) 09:10:32
>>105
setterとgetterの利点は、抽象化とアクセスコントロールだ。
もし、変数そのままを読み書き兼用で使用して変更しないなら、メリットは感じないだろう。
しかし場合にもよるが、管理する形式と欲しい形式が違う事も多く、読み込み専用で使いたい場合もある。
それを考えると利点が分かるはずだ。

>>139
機能設計の分野（OOD）で言うなら、前にも言った通り、特殊な分野でしか有効でない。
しかし、コンピュータ世界に落とした後、詳細設計以降の分野（OOP）においては有効だと分かるだろう。
なぜなら現実世界の法則は当てはまらないのだから。

>>157
いや桁数とかは出力の問題じゃないか？
俺的には何桁でも入るInteger型とかにして、フォーマットはC++のマニピュレーターみたいなので
対処する方がいいと思う。
217 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/04(火) 09:32:11
>>158
概念の切り出しを1つにしなければならないと言う事はないし、その概念も上書き可能な訳だから、
問題にならないだろう。

>>168
同意

>>170
普遍の共通概念をクラス化するのは不可能だが、必要な物の中から共通概念を定義するのは可能だろう。

>>186
158の説明が186なのか。そこまで読み取れなかったな。まあ、186の意見は概ね同意。

>>196
哲学的だな。その言い方で言うなら、
扇風機をみて電気が存在すると分かるように、ウィンドウズプログラムを見ればオブジェクト指向が
存在すると分かる。と言いたい。
218 ：仕様書無しさん：2007/09/04(火) 12:17:55
同意してもらえて良かったねｗ喜びなよ。
219 ：仕様書無しさん：2007/09/04(火) 12:30:18
>>196読んで思ったんだけど
C++やC#が生み出されてC++BuilderやVSが実際に現場で使われてるわけだからオブジェクト指向は
新しいパラダイムである、ってことで差し支えないんじゃないかな。

あとオブジェクト指向が普及してないって言ってる人がいるけど、学生さんですか？w
とは言っても、>>212には同意せざるを得ない。
オブジェクト指向というかその言語はすげー奥深い。凡人にはつらい時代ですわ。
220 ：仕様書無しさん：2007/09/04(火) 12:55:42
みんな頭よす・・
俺オブジェクト指向無理かも
221 ：仕様書無しさん：2007/09/04(火) 12:57:40
>>220 それくらいの姿勢のほうが高感度あっぷ。
分かってる簡単だ無駄だ不要だ、と言い張る奴ほど危険。
222 ：仕様書無しさん：2007/09/04(火) 13:39:20
問題に対して1つだけ正しい答えが求まるものじゃないから、
日本人の感覚に合わないんじゃない？
223 ：仕様書無しさん：2007/09/04(火) 14:58:26
「俺のオブジェクト指向」ってのを持ち出す馬鹿がいるから問題だ。
224 ：仕様書無しさん：2007/09/04(火) 19:42:31
オマンジェクト指向にしようよ
クンニスタンスを生成して中でファックションを実行して動く技術
225 ：仕様書無しさん：2007/09/05(水) 02:52:06
>>223
残念ながら「俺の」以外のオブジェクト指向など無いわ
お前適当な題材でクラス切ってさらしてみ？
絶対「おまえの」オブジェクト指向になるから
226 ：仕様書無しさん：2007/09/05(水) 07:03:51
デザパタだけは完全否定させてもらう
227 ：仕様書無しさん：2007/09/05(水) 07:11:23


　_-"ﾐ;ﾉﾘ人ﾉﾉﾍ/ﾘ;　`゛゛ ﾐ
　>ﾐ/ 　 　　　　　　'γ､`　ﾐ　
　了| 　＼,, ,,／ 　　 {,',;　;} 。
　"7 ─◎─◎─── }ﾐ:. {
　　'|　　　　　　　　　　　ﾚﾘ*
+　 （∴（o o ）∴∵）　 }ｨ'
　 　`<∵　Ｅ　　∵　> /|` + 　＜デザパタだけは完全否定させてもらう！！　　
　　 　ヽ　　 　　　　 ／ |__


228 ：仕様書無しさん：2007/09/05(水) 07:51:01
ﾅﾂｶｼｽ(´∀｀).
http://intermezzo.cool.ne.jp/report/Lupin/R3_temp.swf?inputStr=%83f%83U%83p%83%5E%82%BE%82%AF%82%CD%8A%AE%91S%94%DB%92%E8%82%B3%82%B9%82%C4%82%E0%82%E7%82%A4%81I%81I
229 ：仕様書無しさん：2007/09/05(水) 09:16:41
マネージャー
「オブジェクト指向？設計？はぁ？
　動けばいいんだよ、動けば！
　エンジニアはどーでもいいことばっか言って自己満足するバカばっか
　どうせコーダーなんざいくらでも交換できるんだよ！」
230 ：仕様書無しさん：2007/09/05(水) 09:33:02
>>226 しとけよ勝手に。そして黙っとけ。
自分が理解できないのを自覚すらできず、
しょうがないから否定に走る。
落ちぶれた人間特有のイビツな根性。

無理に使おうとすることはないんだ。
使って有利になる場面で、使える人だけ使うんだ。
231 ：仕様書無しさん：2007/09/05(水) 09:48:33
>>225 その言い方で何か解決する？

例えば地図で説明したとする。
その地図には島がいっぱい写ってる。
ここで「オブジェクト諸島」とはどれか、という話になる。

「オブジェクト諸島とはこの辺」と、ぐるり円を描いたとき、
そりゃそれぞれ指す場所は微妙にことなったりするだろう。
枠が小さかったり大きかったり、含む島に過不足があったり。

ここで、「俺の」と言い出さない人は他人の定義を見た時、
静かに黙って、探りを入れたり歩み寄ったりで修正するだろう。
自分なりの、というものを主張することにに価値を見出すのではなく、
技術用語をなるべく正しく共有することの方に静かに価値を見出す。

しかし、「俺の」と言い出す人は、「（お前らとは違って）俺の」と、
他人との差異を認めてはいるものの、自分側の定義を示す態度。
自分で修正するつもりもないのか、「俺の俺の」と騒ぐ奴がいるとき、
周りの人にとって滑稽であるか、単に迷惑であるかしかない。
232 ：仕様書無しさん：2007/09/05(水) 12:29:55
>>231
なにその無根拠なレッテル貼り

技術用語の共有ができていたら、
> お前適当な題材でクラス切ってさらしてみ？
> 絶対「おまえの」オブジェクト指向になるから
こっちはなんか解決するのか？

お前が、これについて
1. 解決する、と考えている
→ するはず無い。やってみせろ
2. 解決しない、と考えている
→ >>231のレスは>>225の答えになっていない。

好きなほう選べ
233 ：仕様書無しさん：2007/09/05(水) 12:48:03
>>231を読むと、
ハルヒの何話かで小泉の分かりにくい例えを聞かされたキョンのセリフを思い出す。

「お前の例えは分かりにくい」
234 ：仕様書無しさん：2007/09/05(水) 13:11:10
>>232

> > お前適当な題材でクラス切ってさらしてみ？
> > 絶対「おまえの」オブジェクト指向になるから
> こっちはなんか解決するのか？

こっちが解決するとは？
235 ：仕様書無しさん：2007/09/05(水) 13:21:53
>>232
んー。わからんままに>>234の続き。

細かく言えば>>231の言うとおり、
各自の受け取り方にはばらつきがあり、
完全に同一であったりはしないだろう。
ただし、それは他の用語とてまったく同じこと。

技術用語を共有して有効に使いたいのなら、
「俺の俺の」と騒ぐことなんかに意味は無い。
「俺たちの」について冷静に擦り合わせるべき。

一言で言うと、俺の俺のと騒ぐな。
236 ：仕様書無しさん：2007/09/05(水) 13:23:39
×細かく言えば>>231の言うとおり、
○細かく言えば>>225の言うとおり、
237 ：仕様書無しさん：2007/09/05(水) 14:25:13
>>235
もしオブジェクト指向って言葉について定義するとしても、
「ある対象の事物に対し、何をどういう理由でクラスとして捉えるか」ってレベルで合意なんてとれないだろ

でもそのレベルの意見を全部「俺俺オブジェクト指向である」として排除したら、なんか意味ある会話になると思うか?
238 ：仕様書無しさん：2007/09/05(水) 14:29:12
>>237
> 「ある対象…捉えるか」ってレベルで合意なんてとれないだろ

何の話？　そう言う話がしたかったの？
239 ：238：2007/09/05(水) 14:31:18
>>238は訂正。ちょっと白紙に。
そもそも、>>237の意図が良くつかめてない。いや、よくわからない。
240 ：仕様書無しさん：2007/09/05(水) 14:33:50
一番良く分からないのは
> 「ある対象…捉えるか」ってレベルで合意なんてとれないだろ
の部分。どういうクラスとするかの合意を、いつ取る必要が？
そういう部分の合意を、何のために、誰の間で取るの？
241 ：仕様書無しさん：2007/09/05(水) 14:48:16
>>240
「俺のオブジェクト指向」でない、最大多数とコンセンサスの取れるオブジェクト指向の定義なんて
「クラスとかそういう言葉の上位レベルの概念」とかその辺でしかないわけだ。

あんた、だれかがそのレベルでその定義を拒否るから困ってるって言ってる?
違うとするなら「俺のオブジェクト指向」ってどんなよ?
242 ：仕様書無しさん：2007/09/05(水) 14:50:59
>>241
人に説明できるほどにちゃんとした理解がない。
そう自覚してるし、語れば輪郭はあいまいだし、
突っ込みどころも満載なことだろうと知ってる。
だから俺は「俺の」について語らないんだって。
243 ：仕様書無しさん：2007/09/05(水) 14:56:33
あ、たぶん>>242は読み違えたね。

おっと、
> あんた、だれかがそのレベルでその定義を拒否るから困ってるって言ってる?
自分なりの定義、というのを持ち出してきてしまう奴がいて困っている。
そのつもりで一連、ずっと書いていた。
たぶん、アナタの興味あることとは関係がないだろう。
244 ：仕様書無しさん：2007/09/05(水) 15:01:05
こりゃすごいのが釣れちゃったなぁ
最近見るようになってようやく分かったんだがここって要するに単なる釣堀なのね
245 ：仕様書無しさん：2007/09/05(水) 15:05:12
こういう人もいたね。

324 名前： 仕様書無しさん [sage] 投稿日： 2007/07/22(日) 00:17:54
>>317
いや、根底から考え方が違うからそもそもデザパタの使い方がわからない
俺のオブジェクト指向では「パターンに一致するものを探す」って工程を入れるところが無いんだよね
だからわからない

336 名前： 仕様書無しさん [sage] 投稿日： 2007/07/22(日) 00:29:37
>>332
>概論で説明してるオブジェクト指向設計の基本から得られたパターンがデザインパターンなのに
いや、それだったらパターンなんてでるわけがない

現実モデル→ソース

これがすべて
この要素以外あったらおかしい（実際は詳細な部品はでるだろうけど大まかなもんには出てこないよね？）
あったらオブジェクト指向わかりにくいじゃん
だれがみても一致するためのもんなのになんか悟りの境地にでも
立たないといけないようなもんがある時点でつかえねーじゃん
246 ：仕様書無しさん：2007/09/05(水) 15:05:43
こういう人もいたね。

358 名前： 仕様書無しさん [sage] 投稿日： 2007/07/22(日) 00:46:17
>>351
>対象物の実際の構造がどうとか、そっから離れろ
え？そうじゃないって言ってる？
なんか根本から考え方違うんだなぁ・・・

原理主義者の俺の頭はオブジェクト指向がシミュレーションからできたもんって
ところからはじまってるからそういわれるとわけわからんな。たしかに。

703 名前： 仕様書無しさん [sage] 投稿日： 2007/07/24(火) 23:21:29
>>701
だってそもそもデザパタ書いた奴がオブジェクト指向わかってねーし
デザパタに書いてある内容は設計ででてこないほど実装よりだろ？
247 ：仕様書無しさん：2007/09/05(水) 15:21:31
>>245-246
そいつらに同意は出来んが、そういう意見持ってたとしたら
ここに書き込むこと自体はしょうがねえじゃん
俺も含めて、そいつらの意見に同意できない奴らは
脳内に別のオブジェクト指向のメンタルモデル=「俺のオブジェクト指向」があるからだろ
248 ：仕様書無しさん：2007/09/05(水) 15:26:00
>>245,>>246
なんか奇形の標本のコレクションでも見させられてる気分だ
249 ：仕様書無しさん：2007/09/05(水) 15:27:43
>>247
ここで >>231 >>235 を極限まで短くしつつ、あなたの表現にも添った形でいうと、
「俺のオブジェクト指向」と呼びうるけれどもそれを喚いても不毛。
250 ：仕様書無しさん：2007/09/05(水) 15:28:49
それと、この話続けます？
これ以上続けてもアナタの望む答えは、俺から出てこない希ガス。
251 ：仕様書無しさん：2007/09/05(水) 15:33:26
オブジェクト指向というもの自体を研究してる人とかなら、
「俺の俺の」に耳を貸す道理もあるだろうけど、
技術者が技術用語として単に共有しておきたいだけのとき、
「俺の俺の」は混乱をもたらすだけ。

と、少なくとも俺には思えた、というまとめの感想。
252 ：仕様書無しさん：2007/09/05(水) 15:38:44
オブジェクト指向が指すものはあいまいすぎるか、個人的な解釈を含みすぎるから
「オブジェクト指向」という名詞は意味を成さない、無効だ
というなら俺は賛同する
使わなくても何ら問題ないぜ
253 ：仕様書無しさん：2007/09/05(水) 15:38:52
>>249-250
だから、なんで不毛なんだよ
勝手に俺とおまえで議論がすれ違ってるかのように誘導してるけど、
全然すれ違ってねえんだよ

お前の言葉でいうと、俺の言いたいことは>>225から一貫して
「俺のオブジェクト指向」を喚いても「不毛ではない」(つか、意味あるレベルで会話しようと思ったら避けて通れない)
ってことだ

むしろ逆に「コンセンサスがとれた用語の定義」の話ばっかしてても、それこそ不毛だっつの
254 ：仕様書無しさん：2007/09/05(水) 15:43:25
>>253 少なくとも「コンセンサスがとれた用語の定義」についての話をしている。
それ以外について発言したつもりはないんだけどね。>>240でチョコっと書いたように、
アナタが問題視しているものについて、俺には興味がない。だから否定もしない。
255 ：仕様書無しさん：2007/09/05(水) 15:50:32
>>252 現時点ではほかの技術用語にくらべ、ひょっとしたら、
あいまいで個人的な解釈を含みすぎるのかもしれませんね。
名詞として意味を成さない、とするのはもったいない気がしますが。
256 ：仕様書無しさん：2007/09/05(水) 15:55:41
まずもって、オブジェクト指向が技術用語であるという命題からしておかしい気がする
257 ：仕様書無しさん：2007/09/05(水) 15:56:58
>>256 あ、そうすか。元々はもっと汎用的な言葉でしたっけ。
オブジェクト指向＝OOP（OOプログラミング）って感じで使ってました。
これも先に言っておくべきだったか。
258 ：仕様書無しさん：2007/09/05(水) 15:57:36
なんだそのもったいない気がするって
どんだけオブジェクト指向脳なんだよ
真面目にやれ
259 ：仕様書無しさん：2007/09/05(水) 15:58:18
>>258 フヒヒすいません
260 ：仕様書無しさん：2007/09/05(水) 16:03:07
>>254
なんだそれ
「あなたには私のいいたいことがわかってませんねぇ～。まあ、伝える気もありませんけどｗ
あなたの意見には興味がないですねぇ～。まあ、理解するつもりもないですけどｗ」
ってことか?

おまえ議論する資格がねえよ
最初からレスすんなハゲ
261 ：仕様書無しさん：2007/09/05(水) 16:04:54
>>260 なんだそりゃ。逆。
「私にはあなたのいいたいことがわかってません。まあ、理解するつもりもないですけど
私の意見には興味がないですね。まあ、伝える気もありませんけど」

レスしてきたんはおまいでしょｗ
262 ：仕様書無しさん：2007/09/05(水) 16:19:34
罵倒合戦だったら他所でやれ。
263 ：仕様書無しさん：2007/09/05(水) 17:35:20
断定できるほど知っているわけじゃないのに断定したり、相手への尊敬を一切持たずにレスするから
罵倒し合うことになるんじゃまいか。
264 ：仕様書無しさん：2007/09/05(水) 18:12:25
意見をするとき、いちいち「と思う」などと付けないのが基本
265 ：仕様書無しさん：2007/09/05(水) 19:02:17
俺もそれが基本だと思う
266 ：仕様書無しさん：2007/09/05(水) 19:08:41
ちょまｗ
267 ：仕様書無しさん：2007/09/05(水) 20:37:25
俺はそうは思わない。
真理を説く神様でもなければ、自分の意見が絶対だなんて思えない。

基地外を除く
268 ：仕様書無しさん：2007/09/05(水) 20:40:07
オレオレオブジェクト指向だっていいじゃないか
にんげんだもの
269 ：仕様書無しさん：2007/09/05(水) 20:57:55
>>267
読解力無さ杉
270 ：仕様書無しさん：2007/09/05(水) 21:02:16
なあ、そろそろOOPとは何ぞや、の結論出してくれよ。
どうしてこう延々と話し合っても結論が出ないんだよ。
結論が無いのが結論なのか？
271 ：仕様書無しさん：2007/09/05(水) 21:05:24
>>270
その疑いはあるねぇ。
272 ：仕様書無しさん：2007/09/05(水) 21:17:26
>>270
ttp://d.hatena.ne.jp/sumim/20040525/p1
273 ：仕様書無しさん：2007/09/05(水) 21:30:26
>>272
俺、こいつも言ってること違うと思うな
こいつの話どおりだとすると一番はじめの
シミュレーションで使われてたという話にどうやっても着陸できない
274 ：仕様書無しさん：2007/09/05(水) 21:37:20
つかOOPの原理とか厳密な定義なんてどうでもよくね?
諸説ある、くらいに思っとけっつの
各自で本質が掴めるまで使い込んでいけばいいだけじゃねーの
275 ：仕様書無しさん：2007/09/05(水) 21:57:35
つかOOPの定義なんて「オブジェクト指向」でググれば腐るほどヒットするだろうに…
276 ：仕様書無しさん：2007/09/05(水) 22:02:49
たくさんヒットしたうちのどれが正解と言えるのか・・・
277 ：仕様書無しさん：2007/09/05(水) 22:12:44
>>273
>シミュレーションで使われてたという話

シミュレーションのときというのは SIMULA のことですか？
そのときは、疑似並列処理向けに生み出された「クラス」と「オブジェクト」があっただけで、
「オブジェクト指向」という考え方に属する概念はまだなかったんです。
278 ：仕様書無しさん：2007/09/05(水) 22:48:32
OOPの正解はない、らしい。

クラス設計一つとっても、要求仕様に対し、複数の設計が存在する。
（誰がやっても「俺のオブジェクト指向」になるといわれる所以）

しかし、設計によって実装のし易さは違う。
設計だけをする奴は、実装なんて考えないんじゃないだろうか。

俺は、実装まで考慮にいれると、OOPの正解（に近いもの）は
あるんじゃないかと思ってる。
まぁ、「俺のオブジェクト指向」かもしれないが。
279 ：仕様書無しさん：2007/09/05(水) 23:02:31
なるほｄオブジェクト指向に関して電波なレスがすぐにつくのはコレ
アランケイのせいやね
280 ：仕様書無しさん：2007/09/05(水) 23:18:13
全然オブジェクト指向じゃねぇよなｗ＞アランケイ
何が「オブジェクト」なんだか説明してみろよって感じはするｗ
281 ：仕様書無しさん：2007/09/06(木) 00:04:52
ああそうか。
そもそも俺らオブジェクトとは何か、すら定義できてないんだよ。
こりゃお笑いだｗ
282 ：仕様書無しさん：2007/09/06(木) 00:07:20
アラン・ケイも「オブジェクト指向」と呼んでしまったのは（自分の発案である、“動的システム
構築のための「メッセージング」というアイデア”を伝えるには）失敗だったって、
あとになって言っていますしね…。
283 ：仕様書無しさん：2007/09/06(木) 00:18:45
大昔、C++でオブジェクト指向を勉強したときはメッセージのやりとりが重要だとか
言われてもなんのことかまったく理解できなかったけど、最近ようやく言わんとする
ことが理解できるようになってきた。
284 ：仕様書無しさん：2007/09/06(木) 00:18:50
役に立つノウハウだけ採取できれば、定義なんてどーでもいっすわ
それとも役に立たなくてもいいから定義だけしたいのかい
285 ：仕様書無しさん：2007/09/06(木) 00:19:30
>>281
それは、「オブジェクト指向」がなにを指すかによるでしょう。

ストラウストラップ発のユーザー定義型のＯＯなら「クラスのインスタンス」、つまり
「ユーザーが定義した型に属するデータ」だし、ケイのＯＯなら、「メッセージの受け手」。
プロトタイプベースＯＯなら「スロットホルダ」で、ブーチ発のＯＯＤなら「属性ホルダ」。
286 ：仕様書無しさん：2007/09/06(木) 00:20:22
>>282
マジ？
何で失敗になるん？
287 ：仕様書無しさん：2007/09/06(木) 00:22:04
とりあえず、ノウハウ確立度の観点で比較して最も優位なストラウストラップの定義を採用するとして
話を先に進めるってのはだめかい
288 ：仕様書無しさん：2007/09/06(木) 00:38:27
>>288
ケイ的にはメッセージングでシステムを動かすことが重要で、その受け手として
SIMULA から借りてきただけの「オブジェクト」の中身はあまり気にする必要がない
こともメリットのひとつにしたかった。（これは、クラス設計を通じて「オブジェクト」を
どう作り込むかということこそが重要なストラウストラップたちのＯＯとの違いでもある）

けれど、オブジェクトという名前を冠してしまったから、皆、目新しいこの
「オブジェクト」とはなんぞやということに集中してしまったため、
肝心のメッセージングのありかたというような議論なおざりにされてしまったという反省。
289 ：仕様書無しさん：2007/09/06(木) 00:42:38
>>286
ケイのオブジェクト指向ではメッセージのやりとりのカタチが主題であって、その先の
オブジェクトがテストスタブだろうが糞ころがしだろうがどうでも良かったんだけど
C++(特に90年代後半)のオブジェクト指向では名前そのまんまのオブジェクト自体に
ばかり着目が行ってしまったのがマズいと思ったんじゃないの？

と、書こうとしたらもう既に同じことが書かれてた。
290 ：仕様書無しさん：2007/09/06(木) 01:04:32
アラン・ケイはほんとは Erlang のメッセージみたいのをやりたかったんだけど、
けっきょくダン・インガルスが実装したのはちょっと変わった関数呼び出し程度の
ものだったので「メッセージング」という言葉自体お題目化したうえ、後の言語にも
Smalltalk の顰みに倣うかたちで仮組みにすぎないはずの実装がそのまま伝わってしまった。

Smalltalk 自体もケイの影響下を離れて（アデル・ゴールドバーグが面倒をみるように
なって）から、ストラウストラップのＯＯと同種の考え方に一部染まってしまったので、
ますます「メッセージング」は形骸化してしまった。

ということで、メッセージングという彼のアイデアは実装としても未だ実現できていない。
だから、「オブジェクト指向」に関しては「メッセージ」とかはいっさい無視していいと思う。
291 ：仕様書無しさん：2007/09/06(木) 01:47:50
スレタイ無視が半端者クオリティ
292 ：仕様書無しさん：2007/09/06(木) 06:58:19
とは言え、とりあえずちゃんと議論するためにSmalltalkは勉強しなきゃだめだよな。
293 ：仕様書無しさん：2007/09/06(木) 09:11:27
こういうときには一切発言しないおじゃばって一体。
294 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/06(木) 09:20:55
>>204
デザインパターンを作った人がオブジェクト指向を分かってないと言う訳ではないだろう。
前にも言ったが、○○パターンと言うのは学問であり、膨大なサンプルの中からパターンを抜き出し
分類することによって、法則や何かを導き出そうと言う物だ。
この手の分類では、大体よく使うのは2割ぐらいで、残りはレアなパターンとなる。
だからオブジェクト指向の教科書として使うのが間違いで、上記のことを認識した上で参考程度に
しておくのが良い。

>>212-214
流行ってないか？今はCよりC++の仕事が多いだろう。

>>219
そんな事はない。実際、プログラミング未経験の新人でも、最初からJavaを教えた人は言葉で
説明出来なくても、感覚的にオブジェクト指向を習得している事が多い。
C言語経験者でも教える人がいれば、初心者よりはずっと早く習得出来る。
295 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/06(木) 09:35:02
>>293
俺が回答すると話が終わるので、しばらく様子を見ようかと思ったら、
俺様オブジェクトについては253で、メッセージングについては290で答えが出ているようだ。
296 ：仕様書無しさん：2007/09/06(木) 13:41:23
今日、台風で残業無しかな、wktk
10年ぐらい前から、オブジェクト指向+ジェネリックプログラミングが本流になってんだけど
低能PG用OO言語って、ジェネリックプログラミングがバリバリに使えないんだよな...

おまいらよ、おじゃばの言う"オブジェクト指向を習得"ってどんなレベルを想像する？
297 ：仕様書無しさん：2007/09/06(木) 13:46:15
できるやつには冗長だし　馬鹿には理解できないからなあｗｗｗｗｗｗｗｗｗｗｗ
298 ：仕様書無しさん：2007/09/06(木) 14:21:13
世の中的には動的プログラミングの方に流れてね?
299 ：仕様書無しさん：2007/09/06(木) 14:34:43
ダックタイピング？
300 ：仕様書無しさん：2007/09/06(木) 18:34:05
モルモン信者はひっこんどけっ
301 ：仕様書無しさん：2007/09/06(木) 20:04:47
オブジェクト指向が普及していない世界の皆様　コンニチハ
302 ：仕様書無しさん：2007/09/06(木) 20:15:31
コンニチハ
303 ：仕様書無しさん：2007/09/06(木) 20:15:59
普及しないのは不経済だから
304 ：仕様書無しさん：2007/09/06(木) 20:51:17
再利用すれば経済的なメリット増大さ。
305 ：仕様書無しさん：2007/09/06(木) 21:09:34
「良き市民たるあなたたちは、ものを捨てましょう。必要なものでも出来るだけ我慢して、より多くのものを捨てましょう」
306 ：仕様書無しさん：2007/09/06(木) 22:19:58
普及云々より人が集まらない
307 ：仕様書無しさん：2007/09/07(金) 00:43:28
１ファイル（*.cpp、*.java）＝１クラス
これは許せるor許せない？
308 ：仕様書無しさん：2007/09/07(金) 07:03:09
あれ？おじゃばってエセ原理主義者じゃなかったの？
309 ：仕様書無しさん：2007/09/07(金) 07:20:47
>>307
俺は１クラスにつきcppとhで必ずペアにしてる
たまに実装の都合で２クラス入ったりもするけど
外部（クラスを呼び出す側）からは見えないような仕組みにする
310 ：仕様書無しさん：2007/09/07(金) 08:12:45
許せるもなにも１クラス１ファイルが普通でしょ？
311 ：仕様書無しさん：2007/09/07(金) 08:25:40
>>310
そうしないと流用できないしな
でも、たまにこれでもかってほど詰め込む奴いるなｗ
312 ：wolf ◆8VH3XAqjlU ：2007/09/07(金) 08:28:10
>>307
open sourceのJava本体約15000ファイル420万行では平均１ファイル１クラスですね
interfaceも１ファイルとして切り出しているので比率は１以下です
台風は思ったより早く通りすぎたかな
313 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/07(金) 10:50:57
>>308
エセ原理主義者って何だ？
314 ：仕様書無しさん：2007/09/07(金) 14:33:35
面倒だから関連のあるデリゲートとかはまとめてたりしてる
315 ：仕様書無しさん：2007/09/07(金) 15:37:16
あれ？おじゃばってエセ原理主義者じゃなかったの？
316 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/07(金) 18:51:24
>>315
だから、エセ原理主義って何だよ。
317 ：仕様書無しさん：2007/09/07(金) 21:17:32
あれ？
318 ：仕様書無しさん：2007/09/08(土) 00:17:20
要するに、
・オブジェクト指向はちゃんと本1冊読まないとわからないのかどうか
・オブジェクト指向言語じゃないとこんなことできないだろ？ｗっていう例題
これおねがい。
319 ：仕様書無しさん：2007/09/08(土) 00:21:40
一冊じゃ無理だろ。
320 ：仕様書無しさん：2007/09/08(土) 00:23:49
>>319
・オブジェクト指向言語じゃないとこんなことできないだろ？ｗっていう例題
これおねがい。
321 ：仕様書無しさん：2007/09/08(土) 01:46:44
人間にとって理解しやすいコードとか
シンプルさとかスマートさとか
少ない労力で大きな効果が出せるとか
そういう例題を出せということです。
322 ：仕様書無しさん：2007/09/08(土) 01:49:01
>>320-321
クラスの継承
323 ：仕様書無しさん：2007/09/08(土) 10:39:56
また実装レベルの小手先話かよ。
んなもん、オブジェクト指向に関係なく昔からやってるだろ。
324 ：仕様書無しさん：2007/09/08(土) 13:28:30
＞また実装レベルの小手先話かよ。
OOPLで出来ることを聞いて実装レベル以上のモンが出て来るわけねーだろーが。ｊｋ

＞んなもん、オブジェクト指向に関係なく昔からやってるだろ。
ねぇよ。
325 ：仕様書無しさん：2007/09/08(土) 14:15:20
ああああああもう！小さい！小さいよお前ら！
何でそう用語の定義とか細かい実装テクに話が行っちゃうわけ？
そんなんじゃインドどころか中国朝鮮にすら負けるっつ-の！！
326 ：仕様書無しさん：2007/09/08(土) 14:18:23
はいはい誤爆乙
327 ：仕様書無しさん：2007/09/08(土) 14:28:56
貼りなおしてんじゃねーよ
恥ずかしい奴だなｗ
328 ：仕様書無しさん：2007/09/08(土) 14:30:22
>>325
自分で水向けてみればいいじゃん
329 ：698：2007/09/08(土) 14:39:02
>>326-327
五月蝿いなあ。似たようなスレ何個も立てるからこうなったんじゃねえか！
330 ：仕様書無しさん：2007/09/08(土) 14:55:35
生き恥乙
331 ：仕様書無しさん：2007/09/08(土) 15:36:09
staticて難しくね？イマイチ使いこなせねーバカな俺
332 ：仕様書無しさん：2007/09/08(土) 15:38:09
static超便利だろ。
333 ：仕様書無しさん：2007/09/08(土) 17:23:48
>>332
このDIな世の中static便利とかアリエナス
334 ：仕様書無しさん：2007/09/08(土) 23:18:01
staticってどの言語のstaticだよと
335 ：仕様書無しさん：2007/09/09(日) 00:00:07
COBOLのstatic。
そういやーオブジェクト指向コボルってどうなのよ？
336 ：仕様書無しさん：2007/09/09(日) 01:05:02
Java本体420万行ってすごっ
ってか、Java本体が何で書かれているのかが謎
337 ：仕様書無しさん：2007/09/09(日) 01:45:16
>336
Java環境自体は C + Java じゃなかったっけ？
338 ：仕様書無しさん：2007/09/09(日) 02:03:12
本体ってのが何か良く分からないけど、SUNのJVMはCだった気がする。
RubyのVMとかもあるらしい。
339 ：仕様書無しさん：2007/09/09(日) 02:07:03
Javaの本体って呼べるのは仕様だけでしょ
340 ：仕様書無しさん：2007/09/09(日) 15:43:20
必要なクラスとメソッドは把握しとくべき？
いったいどんだけの数あんだよ。
341 ：仕様書無しさん：2007/09/09(日) 15:52:14
>340
よく使うクラスは把握しといた方が良いかも。
でも全部のクラスを把握してるマはほとんど居ない。
特にJavaなんてクラス数凄いことになってるし。
342 ：仕様書無しさん：2007/09/09(日) 16:25:14
>>340
どんなクラスがあるか、さらっと見とく程度でおｋ
土地勘とデザパタ知ってりゃ
どんなクラスやメソッドがあるはず、と推測できるようになる
343 ：仕様書無しさん：2007/09/09(日) 16:45:56
まーた、実装技術かよｗ
344 ：仕様書無しさん：2007/09/09(日) 17:15:57
まーた、低脳の煽りかよｗ
345 ：仕様書無しさん：2007/09/09(日) 17:38:28
デザパタ厨涙目ﾜﾛｽｗ
346 ：仕様書無しさん：2007/09/09(日) 17:48:22









　　　　　　　　　　　　　休みの日も独り言か









　　　　　　　　　　　　　寂しいねぇ～






347 ：仕様書無しさん：2007/09/09(日) 17:59:25
空白改行の数から必死バロメーターが計算できる世の中になりました
348 ：仕様書無しさん：2007/09/09(日) 20:31:23
おにいちゃんのかきこみ、とってもつまらないでつ。
349 ：340：2007/09/09(日) 22:05:48
>>341-342ありがとうございます！
それと、押さえておくべきクラスとはどんなものがあるのかどうか是非教えてください。
確かにきっと業務によって違うのでしょうけど。
350 ：仕様書無しさん：2007/09/09(日) 22:20:36
>>349
java.util.*は便利ですよ。
List, Set, Mapは将来ずっと使えます。
351 ：仕様書無しさん：2007/09/09(日) 22:32:32
>>340
「学問」はいいから自分でなんか作ってみろ。
頭でっかちになっても何も出来てないならしょーがない。
352 ：340：2007/09/09(日) 23:17:24
>>350-351どうもありがとうございます。
ちなみにプログラムは作ったことあるけど、
どーしてもAPIから探し出すだけで時間がかかってしまう無能振り。OTZ
353 ：仕様書無しさん：2007/09/09(日) 23:24:19
慣れだよ、慣れ
354 ：340：2007/09/09(日) 23:27:29
>>353皆さんどうもです、ありが㌧クス
355 ：仕様書無しさん：2007/09/10(月) 11:08:39
良スレかなーとか思ったんだけどな。

>>346
休みの日も独り言か…。寂しいねぇ～。
356 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/10(月) 22:49:28
>>318
オブジェクト指向をマスターするのに必要なのは、書籍ではなく試行錯誤だ。
一番重要な抽象化の概念自体は難しい物ではないが、効果的に使用するのが難しい。
抽象化の概念を覚えたら、実際にコーディングしてみて、試行錯誤を繰り返すのが望ましい。
人にもよるが、半年から1年半ぐらいでマスター出来るだろう。

オブジェクト指向の利点を確認出来る課題は、ウィンドウズプログラムだが、コードの自動生成や
膨大なライブラリのため、コーディングスキルの向上には適切でないかもしれない。
その点を認識した上でなら、VC++でメモ帳を作って見るといい。
出来たら、それにファイルセーブ、ロード機能を追加する。またそれに印刷機能を追加する。
規定内の機能なら、簡単に追加出来ると言う事が分かるだろう。
ただ初心者にVC++は厳しいので、経験者向けだが。
357 ：仕様書無しさん：2007/09/10(月) 23:20:22
はいはい。

では、次のひと。
358 ：318：2007/09/10(月) 23:29:30
>>356
318ですけどありがとうございますおじゃばさま
要するに手ぇ動かせってことで。
普段必要を感じないのなら別にいらないと。

そう思うとほかにやるべきことあるわけで
自分に本当に必要と思われるMathematicaやMatlabあたりに逝ってくる
プログラミング言語じゃないけど
359 ：仕様書無しさん：2007/09/10(月) 23:58:33
このクソったれは本当に毎回毎回いい加減なことばっか言ってるな
わかったふりして他人に説教できるほど本を読み込んだのか？
恥を知れ
360 ：仕様書無しさん：2007/09/11(火) 01:20:05
スルースキルを身につけるんだ！
361 ：仕様書無しさん：2007/09/11(火) 09:11:56
おじゃばはプログラマじゃないんじゃね？
少なくとも、よくて小規模プログラマじゃね？
362 ：仕様書無しさん：2007/09/11(火) 13:27:59
「なぜオブジェクト指向は普及しないのか」という命題が間違いである以上、このスレって
もういらなくね？
363 ：仕様書無しさん：2007/09/11(火) 14:29:11
なぜオブジェクト指向は（それほど）普及しないのか
364 ：仕様書無しさん：2007/09/11(火) 15:32:24
最初の10レスを読んだだけですが、とりあえずすべての基本はC言語という事でおｋ？
365 ：（ ´v｀） ：2007/09/11(火) 15:38:58
>なぜオブジェクト指向は（それほど）普及しないのか
違うよ、正しくは
なぜ、お前はオブジェクト指向が使えないのか
先ずは自分自身と向き合おうね...あ、いや、俺低能だから..orz
366 ：仕様書無しさん：2007/09/11(火) 16:06:59
VBやdelphiのコンポーネントの環境を始めてみた時、
コンポーネントとかOLEはオブジェクト指向のさらに上の発明だと思った。
367 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/11(火) 23:16:36
>>358
学生と違って社会人にはたくさんの時間があるのだから、興味を持ったら両方やればいい。
やたらにこれは必要だとか不必要とか区別していると、自分の限界を決めてしまうことになる。

>>359
俺に言っているのかな？

>>361
どうしてそう思ったんだ？

>>364
いやJavaかC++。
368 ：仕様書無しさん：2007/09/12(水) 00:45:18
>>366
>コンポーネントとかOLEはオブジェクト指向のさらに上の発明だと思った
なにいってんだ？こいつ
369 ：仕様書無しさん：2007/09/12(水) 02:14:53
普及しない理由ははっきりしてるじゃん。
業界の構造的な問題と、曖昧な定義のせい。

派遣であっちいったりこっちいったりで、
その場しのぎのコーディングをするような奴が多すぎ。
残った奴がつぎはぎしてグダグダソースの出来上がり。

あとは「言葉」の問題。
オブジェクト指向＝オブジェクト指向設計、分析、プログラミング、のどれを指すのかが
全く定義されてなく、学習者が無用に混乱させられてるし。

学習者がいくら真剣に取り組もうと思っても、
のらりくらりと何が正解なのか分からないばかりで、
「アホらし。時間も無駄。もういいべ。やめた。」
「クラスの作り方・使い方がわかればよし。」
「わけのわからんこだわりは邪魔なんで無視」
ってなる奴がいても不思議じゃない。
370 ：仕様書無しさん：2007/09/12(水) 02:30:51
>>369
おまえオブジェクト指向使いこなせるか？
どうも、そんな感じがしないんだよな
371 ：仕様書無しさん：2007/09/12(水) 02:42:18
使いこなせるって言葉がびみょ～
372 ：仕様書無しさん：2007/09/12(水) 08:47:07
>>371
使いこなす、に違和感があるようではだめだな
373 ：仕様書無しさん：2007/09/12(水) 09:05:56
this（言語によってはselfやme）の利便性が解った瞬間俺はOOP信者になった
374 ：仕様書無しさん：2007/09/12(水) 09:30:04
それは利便性ではなくむしろそれまでが不完全だったのさ
375 ：仕様書無しさん：2007/09/12(水) 13:14:49
OOPの何が便利？という質問が後を絶たないが、
プログラミングの何たるかを理解していないという他ない
376 ：仕様書無しさん：2007/09/12(水) 13:33:15
>>375 そういう言い方じゃなくて、
その「何たるか」をズバリ言ってやってよ。
377 ：仕様書無しさん：2007/09/12(水) 13:53:53
ズバリ言ってるようなものだ
プログラミングパラダイムというものは、便利さを求めた結果生まれるものではない
378 ：仕様書無しさん：2007/09/12(水) 14:17:32
なんで遠まわしな言い方しかできないの？
OOP理解してるなら分かるとか自明とか言いたいならこんなスレ来る必要ないよ
379 ：仕様書無しさん：2007/09/12(水) 14:34:26
遠まわしとは、一体何のことだろう

OOPの何が便利？という質問が「愚問である」とズバリ言っているではないか
便利さを基準にOOPを理解しようとするアプローチは誤っている、と言い換えても問題は無い

むしろ私の発言の中で不明瞭な点があるなら、あなたがズバリ指摘してみては？
380 ：仕様書無しさん：2007/09/12(水) 14:49:03
>>プログラミングの何たるか
って何？
>>便利さを求めた結果生まれるものではない
ならどうして生まれたの？
>>OOPの何が便利？という質問が「愚問である」
何故？
>>便利さを基準にOOPを理解しようとするアプローチは誤っている
じゃあどうすればいい？

お前らは分かってない、くだらない事ばっか議論してる
けど俺からは説明しない、って言いたいの？
381 ：仕様書無しさん：2007/09/12(水) 14:51:39
愚問であるとするかどうかはいいんだよｗ
OOPの何が便利？　に答えることはできるの？　できないの？
　→ [Y/N]
そして、プログラミングの何たるか、とは何？
　→ [プログラミングの何たるかとは、○○である]
382 ：381：2007/09/12(水) 14:52:36
おっと、>>380とはｹｺｰﾝだな（死語）
383 ：仕様書無しさん：2007/09/12(水) 15:04:16
>>380
私は議論の「要素」をひとつ提示しただけに過ぎない
そうするために「結論」を知っている必要は無いと思うのだが

もし気に入らないのなら、私の全ての発言に「少なくとも」と付け足してみてくれ
384 ：仕様書無しさん：2007/09/12(水) 15:13:24
お前は知ってるかのような断定口調で全て書いてるだろ
別に間違っててもいいから>>380の事を思った根拠を書けよ
本当に知ったかなのか叩かれるのが怖くて書けないのか知らないけどさ
385 ：仕様書無しさん：2007/09/12(水) 15:26:16
オブジェクト指向便利だろ。

理屈がわかんなくても、データを保持できる関数の集まりだとでも思えば誰にだって便利に使えるだろうし。

わけのわからん理念ばっかり教えようとして、変なコトになってるのが問題。
便利に使えば良いのに。
386 ：仕様書無しさん：2007/09/12(水) 15:26:57
断定口調が気に入らなければ、全ての私の発言の末尾に「と、私は考える」とでも付け足してみればいい
主張とは書き手の考えであるのは自明であるため省略するのが通例だが

プログラミング・パラダイムの本質とは、「制約」だ
「便利」の定義にも拠るだろうが、「制約」は多ければ多いほど当然「便利」ではなくなる
387 ：仕様書無しさん：2007/09/12(水) 15:38:40
制約が無くなって便利になる、の図が、想像すらつかないｗ
388 ：仕様書無しさん：2007/09/12(水) 15:40:10
>>「と、私は考える」
だから、そう考えてるんだろ？
その根拠を書けと言ってるんじゃないのか
書けない理由でもあるのか？
お前の中の自明が世界共通だと思ってるのか？
逃げて屁理屈で保身に回るくらいなら謝って終わりにしろ
389 ：仕様書無しさん：2007/09/12(水) 15:41:00
>>385
関数が特定のデータに対してのみアクセス可能であることは、「制約」だ
便利の定義にも拠るが、任意のデータに対してアクセス可能であるほうが「便利」であるといえるのではないか

だが、プログラミングの世界では「便利でない」が故に「有益」足りうることがある
データのアクセスコントロールの例では、「任意のデータに対してアクセス可能である」とこは
裏を返せば「任意の関数が、任意のデータを破壊しうる」ということでもある

言いたいことは以上だ
390 ：仕様書無しさん：2007/09/12(水) 21:22:26
>>377
何この劣化した(?)おじゃばみたいなの。

>>389
言語の文法が便利なんであって、その変数が便利かどうかの問題じゃねぇだろバカ。
391 ：仕様書無しさん：2007/09/12(水) 21:34:40
いや、いつもの間抜けなじゃばだろ
392 ：仕様書無しさん：2007/09/12(水) 21:40:52
あいつ時々名無し自演するから・・・
すぐバレるのに
393 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/12(水) 22:01:06
俺じゃないよ、少し考えれば分かるだろう？
あまり考えずに断定するから、発言に信憑性がなくなるんだよ。
第一、377は明らかに釣りだ。
この手の釣りの場合は、長い言い回しを要約して、冗長だと攻撃するのがいいだろう。
394 ：仕様書無しさん：2007/09/12(水) 22:04:33
>393
長い言い回しを要約して
お前の存在そのものが冗長だ
395 ：仕様書無しさん：2007/09/12(水) 22:14:37
　　　　　　＿＿、_ノ
　 　　　／　　 　 　＼
　　　／　 _ノ 　ヽ､_　 ＼
　 ／ 　oﾟ⌒　　　⌒ﾟo　 ＼ 　また明日から2chで釣りの仕事がはじまるお
　 |　　　　　 （__人__）　　　|
　 ＼　　 　 　｀ ⌒´ 　 　／
396 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/12(水) 22:27:49
>>394
だから、攻撃する時はもう少し頭使えっての。
397 ：仕様書無しさん：2007/09/12(水) 22:30:34
頭悪そうなひとに言われたくないお
398 ：仕様書無しさん：2007/09/12(水) 22:39:27
アホコテ、煽りは華麗にスルーしれ
399 ：仕様書無しさん：2007/09/12(水) 22:44:01
アホコテ自体が荒らしな件について
「アホコテ」とかお前も煽ってる件について
400 ：仕様書無しさん：2007/09/12(水) 22:54:04
オブジェクト指向でも何でも良いからヌルヌル動けば良いんですよ
401 ：仕様書無しさん：2007/09/13(木) 10:23:11
そろそろ3行でまとめろよ
402 ：仕様書無しさん：2007/09/13(木) 10:51:55
同意ｗ
403 ：仕様書無しさん：2007/09/13(木) 10:52:22
金の力に屈してしまうから
404 ：仕様書無しさん：2007/09/13(木) 11:52:01
このスレ見ればわかるだろ
頭が悪いからだよ
405 ：仕様書無しさん：2007/09/13(木) 15:16:47
>>404
これに尽きるな。
いえ、自分も例外ではなくｗ
406 ：仕様書無しさん：2007/09/13(木) 17:55:46
Youは低能ですか？→ [Y/N]
YouはITドカタですか？→ [Y/N]

ちなみに、わしはおじゃばさま同様に低能なITドカタです。
さて、あなたはどうですか？
407 ：仕様書無しさん：2007/09/13(木) 18:06:24
　　_, ,_ ∩))
(*｀皿´)彡　　ﾊﾟﾝﾊﾟﾝﾊﾟﾝﾊﾟﾝ
　 ((⊂彡☆∩)) _, ,_ 　_, ,_
　　((⊂((⌒⌒ ((Д´≡｀Д))　YYYYYY ――――― !!!
　　　　　　｀ヽ_つ ⊂ノ
408 ：仕様書無しさん：2007/09/13(木) 18:37:57
正直、煽ってる連中よりおじゃばの方が学歴高そうな件
409 ：仕様書無しさん：2007/09/13(木) 18:40:52
もしオレが「なぜ構造化プログラミングは普及しなかったのか」というスレ立てたら、
何言ってんのこいつって話になるでしょ？
このスレも同じ。十分普及してんのに普及しない理由を探っても無意味。
410 ：仕様書無しさん：2007/09/13(木) 19:18:53
ほら。立ててやったぞ。

なぜ関数は普及しなかったのか？
http://pc11.2ch.net/test/read.cgi/prog/1189678689/l50
411 ：仕様書無しさん：2007/09/13(木) 19:23:48
>>410
センスの欠片も無い
もっと謙虚に生きるべきと感じた
412 ：仕様書無しさん：2007/09/13(木) 21:32:33
>>410
私は君ほど惨めな生物をいまだかって見たことが無い
413 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/13(木) 22:29:14
>>404
実際、殆どの新人がマスターしているのだから、頭は関係ない。一番の問題点はやる気だ。

>>406
俺は優秀な技術者だ。406とは違う。
ただ一番の違いは、自分を低能だと嘆く暇があたら、そう言われないように学習するプライドを
持っているかどうかだ。
414 ：仕様書無しさん：2007/09/13(木) 22:57:10
このスレにいるようなooｵﾀですら、
オブジェクト指向のメリットを、
誰もが腑に落ちるようにちゃんと説明
できないんだから、普及なんて無理だな。
415 ：仕様書無しさん：2007/09/13(木) 23:03:20
メリットだらけだと思うが・・
416 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/13(木) 23:08:14
>>414
前にファイルを例に利点を説明しただろう？
もう一回聞きたいのか？
417 ：仕様書無しさん：2007/09/13(木) 23:10:03
方法論を持たないやつの仕事の結果は悲惨だな
418 ：仕様書無しさん：2007/09/13(木) 23:27:56
>415
じゃ、何個かあげてみて。
419 ：仕様書無しさん：2007/09/13(木) 23:33:55
普通に教科書嫁よ。

情報のカプセル化
仕様変更に柔軟
オブジェクトの再利用性
420 ：仕様書無しさん：2007/09/13(木) 23:36:07
で、それが実際どれくらいのメリットになるの？
定量的に言ってよ。
生産性が50%向上するとか。
数値にも表れないようなメリットじゃ、どうしようもない。
421 ：仕様書無しさん：2007/09/13(木) 23:39:35
>>416
DB(SQL)で利点をお願いします。
422 ：仕様書無しさん：2007/09/13(木) 23:43:16
コードの見通しが極端に悪くなるデメリットの前には>>419程度のメリットなんか屁のツッパリにもならん。
423 ：仕様書無しさん：2007/09/13(木) 23:43:21
数値は分からんなぁ。

でもソフトウェア開発は大規模になればなるほどOOが有効なのは確か
424 ：仕様書無しさん：2007/09/13(木) 23:44:26
インターフェイスさえ理解すれば内部を見通す必要なんて無いだろ
425 ：仕様書無しさん：2007/09/13(木) 23:46:42
オブジェクト指向のメリットかぁ
OCPのおかげでデグレしなくなるってのはどうよ
426 ：仕様書無しさん：2007/09/13(木) 23:47:47
>>423
それじゃ説得力、ないですよ
具体的じゃないのに、確かといわれて納得すると思う?
427 ：仕様書無しさん：2007/09/13(木) 23:48:49
>>426
じゃあ一生泥縄やってれば？
428 ：仕様書無しさん：2007/09/13(木) 23:53:27
>423
それって理論上は、じゃない？
大規模開発において、PO、DOよりOOのが
はるかに有効だったという実績あるかな？
失敗例もあるようだけど。
429 ：仕様書無しさん：2007/09/13(木) 23:55:38
おまえら、わかんないからって俺のOCPスルーすんなｗ
430 ：仕様書無しさん：2007/09/13(木) 23:57:01
>情報のカプセル化
>仕様変更に柔軟
>オブジェクトの再利用性

カプセル化、柔軟な仕様変更、再利用って、
オブジェクト指向でしかできないことじゃないからねえ。

オブジェクト指向のが明らかに向いてるのは確か。
でも、どれくらい差があるかっていうと・・・・？
431 ：仕様書無しさん：2007/09/14(金) 00:04:51
>>414
OOオタなんてどこにも見当たりませんが
432 ：仕様書無しさん：2007/09/14(金) 00:05:35
>>428
数字にできないのに理論なわけあるかいｗ
現状、迷信とかそっちの方へ入れられてもおかしくないだろｗ
433 ：仕様書無しさん：2007/09/14(金) 00:05:59
OOのメリットってOOPLじゃなくOOD/OOAなんだよ
OOをマスターしたければは、先ずOOA/OODを徹底的にまマナベ！
OOPLはあくまでOODをやり易くした言語・プログラミングスタイルに過ぎないない。
OOPLの使い方なんてはOOの末端の枝葉の部分だ。OOの幹はOOD/OOA！



434 ：仕様書無しさん：2007/09/14(金) 00:07:33
>>433
あんた・・・嘘つきだね
435 ：仕様書無しさん：2007/09/14(金) 00:07:39
>>433
俺、そうやってｲﾐﾌなアルファベットとかカタカナ並べる奴が一番嫌い
436 ：仕様書無しさん：2007/09/14(金) 00:08:47
>>433
ちょっと聞くけど、OOD/OOA勉強するためにどんな本読んだの？
挙げられるだけ挙げてみてよ
437 ：仕様書無しさん：2007/09/14(金) 00:10:02
>>435
失礼ながら>>433がｲﾐﾌってどんだけゆとりかと。。
438 ：仕様書無しさん：2007/09/14(金) 00:10:41
>432
計測できるよ。
同じような規模の開発同士で統計とって、
比較すればいい。
439 ：仕様書無しさん：2007/09/14(金) 00:10:43
>>436
>>433は間違えてＡＤＯの勉強してただけ
440 ：仕様書無しさん：2007/09/14(金) 00:11:18
>>438
惨敗したらどうすんのさ・・・
441 ：仕様書無しさん：2007/09/14(金) 00:12:30
>>438
生産性なんて人による変動が激しすぎて統計無理だろ
442 ：仕様書無しさん：2007/09/14(金) 00:12:40
>433
で、OOD/OOAをマナぶとどんなメリットが
ありますか。
443 ：仕様書無しさん：2007/09/14(金) 00:13:34
>441
なんのための統計よ。
444 ：仕様書無しさん：2007/09/14(金) 00:14:15
OOと非OOの案件数比較すればいいんじゃね
445 ：仕様書無しさん：2007/09/14(金) 00:14:52
>>441
加えて個体差が大きすぎるときてるしなｗ
んでもって生産したものがよかったかどうかすら
リリースしてしばらく様子みるまでわからんしな
446 ：仕様書無しさん：2007/09/14(金) 00:17:15
>>443
おまえ、「かくあらねばならない」故に「かくあるはず」
ってどんなロジックよ？

うえの方でも似たようなこといってるやついたなｗそういえば
447 ：仕様書無しさん：2007/09/14(金) 00:18:26
生産性は計測不能byM・ファウラー、つってな
448 ：仕様書無しさん：2007/09/14(金) 00:19:24
>>444
案件にそんな属性ねーよｗ
449 ：仕様書無しさん：2007/09/14(金) 00:22:31
テストの数は計測できるだろ
450 ：仕様書無しさん：2007/09/14(金) 00:22:41
>>448
まったくだなｗ
451 ：仕様書無しさん：2007/09/14(金) 00:23:14
>>449
もはや意味不明
452 ：仕様書無しさん：2007/09/14(金) 00:30:22
>>442
給料があがる。
うちの会社じゃ主業務がPGって入社して4年位まででそれ以後は徐々に上流工程に組み込まれていく。
給料を上げようと思ったら、早くPGを卒業しなければならない。
453 ：仕様書無しさん：2007/09/14(金) 00:37:07
>>452
その発想でいくと、PMPでも取ってPL目指した方がましなんじゃね？
給料上げるためにOOA/OODなんて選択肢ありえねーし
454 ：仕様書無しさん：2007/09/14(金) 00:41:34
おまいら、大事なことは開発コストを下げられるかだよ。
開発コストを下げるために、OOを導入したり、人件費の安い派遣PGを利用するんだが、
ただ、OOの場合、全員がOOを理解し使いこなせるような開発チームしないと、開発コストの
削減が出来ないばかりか、最悪、開発プロジェクトが火を噴いて終わりになる。
つまり、会社が技術者育成にどれだけ力入れられるかがOO普及(成功）のキーになる。
でも、今のITドカタ会社じゃ技術者の育成なんて無理だろ？　お前だけがOO出来たって駄目なんだよ。
455 ：仕様書無しさん：2007/09/14(金) 00:42:34
正直PMとかめんどくさいんだよなあ。
背に腹は変えられんけど。
456 ：仕様書無しさん：2007/09/14(金) 00:42:49
>446
ん？おまえ、統計の意味分かってなくない？
457 ：仕様書無しさん：2007/09/14(金) 00:43:38
最近、かなり大規模な開発でも実質PG俺一人とかザラな件について
458 ：仕様書無しさん：2007/09/14(金) 00:46:46
人数あればいいわけじゃないからな。
下手するとコミュニケーションコストがN(N-1)/２で爆発
459 ：仕様書無しさん：2007/09/14(金) 00:46:46
むしろ、OOって開発は生産性低いよ。
保守以降が楽なだけ。
460 ：仕様書無しさん：2007/09/14(金) 00:52:15
一人が最も生産性がいいのは常識。
人が増えれば増えるほど生産性は下がる。
この問題を解決するのがＯＯなのでは？
461 ：仕様書無しさん：2007/09/14(金) 00:55:33
でもOOってある程度ライブラリを作り貯めてからでないと効率良くならないよ？
最初から一人でって事になると地獄見る。
462 ：仕様書無しさん：2007/09/14(金) 00:57:10
>>435
リーダーとしての才能があればな。
俺のところだと技術者として生き残り、かつ、給料上げようと思ったらOOD/OOA学び
専門分野の知識を深めなければ３０ぐらいで終わりになる。
特に、"この分野に関してはXXに聞け"といわれるよな技術者にならないとだめだな。
463 ：仕様書無しさん：2007/09/14(金) 01:03:17
>>461
OOであろうが非OOであろうがライブラリは充実してないと困るよ。
OOの場合特に系統だった良いフレームワークがあるのが望ましいな。（ま、必須って言っても良いな）
464 ：仕様書無しさん：2007/09/14(金) 01:04:45
実装が一番難易度高い気がするんだが。
むしろ上流工程は誰でもできる。
日本語さえ話せれば。
465 ：仕様書無しさん：2007/09/14(金) 01:08:21
フレームワーク使うんなら、パーツはめるだけだから、
わざわざ自分でOO学ぶ必要ないよな。
466 ：仕様書無しさん：2007/09/14(金) 01:23:34
そこでテンプレートですよ。　とか言ってみる。
467 ：仕様書無しさん：2007/09/14(金) 01:25:57
>>464
ところが、どっこい、どのようなものが良いのか具体的に顧客自身が解らないのに
納入後に顧客がこれこれこんなのが欲しかったんだよというソリューション
にしなければならない難しさってやってみなければ解らないよ。
顧客の言うとおりに作っても、ま、ほとんど、こんなはずじゃなかったと顧客から
言われるのがおち。大事なことは、顧客が満足するものを提供できるかだよ。
468 ：仕様書無しさん：2007/09/14(金) 01:41:18
10人チームでOO分かってるのは2人だけっていう場合に、
OOで開発しちゃったら大惨事になるよね。

じゃ、何人からならOK？
1人でも異分子が混ざるとエライことになりますかね？
469 ：仕様書無しさん：2007/09/14(金) 01:43:55
大き過ぎる物はまず分割して小さくする。思考の基本ね
470 ：仕様書無しさん：2007/09/14(金) 02:09:47
>>467
おっしゃることがいちいち古い古いｗ
おまえ汎用機やってたろｗ
471 ：仕様書無しさん：2007/09/14(金) 02:35:14
>>468
やってみなければ分からないじゃね

10人中2人しかOOPLが出来る香具師が居なくても、
その2人が頑張れば成功するかもしれん
472 ：仕様書無しさん：2007/09/14(金) 07:10:14
オブジェクト指向プログラミングを本当にちゃんと理解して使える奴だと、
そんな技術を全然勉強しない奴に対して5倍くらいは生産性が高いからなぁ。
メインプログラマー2人のツートップで行くのもありかもしれん。
473 ：472：2007/09/14(金) 07:11:38
別にオブジェクト指向プログラミングで生産性が5倍になるわけじゃないからね。
そういうのをちゃんと勉強してる人はもともと5倍くらいは違うってことね。
474 ：仕様書無しさん：2007/09/14(金) 07:13:33
そしてとんでもない量の作業を二人でこなし→鬱→行方不明
475 ：仕様書無しさん：2007/09/14(金) 08:30:00
むしろオブジェクト指向で設計を行うと、
設計段階での作業量は非オブジェクト指向設計の何倍にもなる。
476 ：仕様書無しさん：2007/09/14(金) 09:21:11
もはやサブルーチンを関数呼び出しするなんて時代遅れ。
メソッドにメッセージを送るのが今時の開発style

これだけで効率は3倍になる。
477 ：仕様書無しさん：2007/09/14(金) 13:55:22
それでは無駄が多すぎる。
まあ、個人向けのPCで1つ動かすだけなら問題ないんだろうが。
478 ：仕様書無しさん：2007/09/14(金) 14:27:11
だから「メッセージ」なんてオブジェクト指向にはもはや無関係だと何度言えば…。

いまだにオブジェクト指向から「メッセージ」を切り離せないでいるヤツは、
自らの「オブジェクト指向」の理解がヤヴァイところにあると認識すべき。

もっともメッセージを「メソッド」に送っちゃう時点ですでに馬脚を現しているけど。
479 ：仕様書無しさん：2007/09/14(金) 15:42:50
OO
kakaku = car.price('matuda','MPV');
array_calor_list = car.color.all('matuda','MPV');
OO風関数
kakaku = car_price('matuda','MPV');
array_calor_list = car_color_all('matuda','MPV');

これとどう違うの？　. 区切りだったりPerlとかなら　->　区切りになるだけで
関数からの利点がわからないんだけど
関数でもOO風に書いたりできるわけなんだけど、余計なnewとかしないで良い分関数の方が楽な気がする
オブジェクトの宣言やオブジェクト格納変数が増えるとコードも見難くなるし。

どうなんでしょう。もうちょっとOOの良さ教えて
480 ：仕様書無しさん：2007/09/14(金) 15:44:42
インスタンス数は無視ですかそうですか
481 ：仕様書無しさん：2007/09/14(金) 16:32:29
>>478
どこがどう間違っているのか言える？

単に言葉を言い換えるだけならワロス
オブジェクト指向から切り離せないのはメッセージじゃなくて
メソッドだとかな。
482 ：仕様書無しさん：2007/09/14(金) 16:33:28
OOだったらこうだろ

Car car1 = CarDealer.getCar('matsuda', 'MPV');
Car car2 = CarDealer.getCar('matsuda', 'DEMIO');
int price1 = car1.getPrice();
int price2 = car2.getPrice();
483 ：仕様書無しさん：2007/09/14(金) 16:41:55
class Spec
　def initialize(name, company, price, colors)
　　@name, @company, @price, @colors = name, company, price, colors
　end
　attr_accessor :name, :company, :price, :colors
end
# specs = []
mpvspecs = specs.select {|s| s.name == 'MPV' && s.company == 'mazda'}
kakaku = mpvspecs.first.price
mpvcolors = mpvspecs.inject([]) {|colors, s| colors += s.colors}.uniq

まあなんというか、こういうのはRDBMSで扱っていたいけど。
484 ：仕様書無しさん：2007/09/14(金) 16:49:39
オブジェクト指向とは、ようするにパターンなのだよ。

■オブジェクトパターン

【目的】
共通する処理を持つ抽象型から、状態を持たせた具象型を
一つのものとして生成・管理する

【動機】
画面上に置かれた複数のコンボボックスはそれぞれ共通の処理
（テキストを入力する、ドロップダウンをする、リストから選択する）を
持つが、それぞれのコンボボックスには別個のテキスト文字列やリストが存在する。
これを生成・管理するためのパターン


【実装】
C言語の場合

　　構造体とか関数の第一引数に構造体のポインタを入れるとか
　　newしたいときに初期化関数を呼び出すとか、面倒な実装。

C++言語の場合

　　言語自体に組み込まれているので超簡単。

【関連するパターン】
コンストラクタ･デストラクタパターン
継承パターン
抽象メソッドパターン

↑C言語で実装するとルール多すぎで面倒なもの
485 ：仕様書無しさん：2007/09/14(金) 16:52:35
↓煽り厨登場
486 ：仕様書無しさん：2007/09/14(金) 16:53:38
│　≡　　('('('('A` )
│≡　～( ( ( ( ～)　
│　≡ 　ノノノノ ノ
│
↓
487 ：仕様書無しさん：2007/09/14(金) 16:54:41
│
└───────┐
　　　 　 　 　 　 　 　 |
　..Λ＿Λ...　　　 　　|
　（　・∀・）　 ／|　　│
　（　つ|￣￣|..　|　　│
....（＿...| 　　 |／..　　 |
.　　　　　￣　　　　　 |
┌───────┘
↓
488 ：仕様書無しさん：2007/09/14(金) 16:55:31
C言語なんかで、オブジェクト指向パターンなんか
実装したら、大変なことになりそうだｗ
489 ：仕様書無しさん：2007/09/14(金) 16:57:26
>構造体とか関数の第一引数に構造体のポインタを入れるとか
>newしたいときに初期化関数を呼び出すとか、面倒な実装。

struct car mpv = car_init('matuda','MPV');
kakaku = car_price(mpv);
array_calor_list = car_color_all(mpv);
490 ：仕様書無しさん：2007/09/14(金) 16:59:53
>>479
それは、関数ですむようなことを
オブジェクト指向でやるから違いを感じられ無いわけ。

最初に目的がある。その目的にオブジェクト指向パターンを適用すべき
という場合に、それをC言語でやろうとすると苦労するわけさ。
491 ：仕様書無しさん：2007/09/14(金) 17:01:30
>>489
そしたら次は
コンストラクタ・デストラクタパターン
継承パターン、
抽象メソッドパターンを
実装してみてください。
492 ：仕様書無しさん：2007/09/14(金) 17:06:40
>>491
http://www.sage-p.com/process/cool.htm
抽象メソッドは関数ポインタで代替

あと>>489と、このレスは>>484の反論では無いです
493 ：仕様書無しさん：2007/09/14(金) 17:13:07
>>492
そのリンク先を見ての通り大変ですよね？
という結論。
494 ：仕様書無しさん：2007/09/14(金) 17:17:28
そうですねえ

「継承しようとしたら、継承できなきゃ大変ですよね？
ですのでオブジェクト指向は便利なんです」

と聞こえるのですが
まずは継承(やその他のパターン)の便利さを説明する必要があるのでは？
495 ：仕様書無しさん：2007/09/14(金) 18:29:29
>>494
なんかずれているんだよなぁ。

「継承が便利」だから使うのではなく、何かを作っていたら
継承を使うべき自体になったから使っているの。



「継承はどういうときに使うんですか？」という質問をしないのはなぜ？
496 ：仕様書無しさん：2007/09/14(金) 19:03:54
使うべき事態だから使う？
頭が痛いから頭痛である、みたいなもんだなw
497 ：仕様書無しさん：2007/09/14(金) 19:40:34
「継承を使うと便利な時」に「使うと便利であろう継承」を使うわけだから
どっちかを疑問に思う事がずれてるとは思わないな
>>496は何言ってるかわからんが
498 ：おじゃばさま ◆GxjxF3yEw6 ：2007/09/14(金) 21:08:47
>>421
DBでも利点は同じ。Javaの場合は抽象化が進んでいるので、ORACLEやpostgresへの変更も容易だ。
C++の場合はベンダーにより差があるのでJDBCのようにはいかないが、ベンダー内の製品同士、例えば
ORACLEからTimestenへの変更なども、C++のライブラリを使用していれば比較的容易だ。
しかしSQL構文自体は標準を使用する必要がある。
これを書くと、OOでなくてもモジュール化していれば出来ると言う人がいるが、OOの利点は
全てのクラス単位で抽象化がされていると言う事だ。モジュール化の場合は、モジュール化した所しか
抽象化されていない。

>>420
一番の分かりやすいのはWindowプログラミングだ。
オブジェクト指向を使わずにWindowプログラムを作ってみるといい。
つまり継承も使わず、クラスも使わず、C言語の構文でWondowプログラムを作る。
VCだと自動生成などで分かりにくいので、UNIXのX-WindowでCとC++を使って比べてみるといい。
出来たら、それにボタンを追加したり、メニューを追加してみたりするといい。
地獄が見られるだろう。
499 ：仕様書無しさん：2007/09/14(金) 21:32:07
VCとか、フレームワークはオブジェクト指向かもしれんけど、現場じゃ自動生成された
コード以外はぜんぜんオブジェクト指向じゃないってコードばっかりだよ。
500 ：仕様書無しさん：2007/09/14(金) 21:36:07
今時継承なんてフレームワーク作る時位しか使わないのだが
継承多用するやつは頭悪いわな
501 ：仕様書無しさん：2007/09/14(金) 21:46:54
イベントドリブンで育ったやつってグローバル変数つかうのに躊躇ないな。
一応フォームにはローカルになってるけど、フォームのメンバ変数が数十以上、ルーチンも数十以上で、無秩序に
メンバ変数にアクセスしまくりだから、手続き型でグローバル変数つかいまくりと同じ状態になってたり。
502 ：仕様書無しさん：2007/09/14(金) 22:07:09
> イベントドリブンで育ったやつってグローバル変数つかうのに躊躇ないな。
> 一応フォームにはローカルになってるけど、

フォームはクラスなので、それはクラス変数であって、
グローバル変数じゃありません。
503 ：仕様書無しさん：2007/09/14(金) 22:12:36
>>496

> 496 名前：仕様書無しさん[age] 投稿日：2007/09/14(金) 19:03:54
> 使うべき事態だから使う？
> 頭が痛いから頭痛である、みたいなもんだなw

お前は頭が悪いなｗ

「頭が痛い」場合に、「頭がいたいのを直すための手法」として、「頭痛薬を使う」だろ？
継承とはそういうことだよ。

「基本的には同じ機能だがちょっとだけ違う機能がある」場合に、「それを解決するための手法」として、「継承を使う」んだよ。

そりゃ頭痛薬じゃなくても治るかもしれん。だが頭痛薬のほうがより簡単に解決できるんだよ。

504 ：仕様書無しさん：2007/09/14(金) 22:26:08
継承が便利なのはOOPLの話であって、OOとはあんまし関係無いんじゃね？
OOPL使ってるからってOOな設計やコーディングになってるとは思えない。
単なるモジュール化のツールとしてもOOPLの機能は便利。
505 ：仕様書無しさん：2007/09/14(金) 22:29:44
オブジェクト指向なんてコーディングがすべてだろ。
設計でオブジェクト指向どうとかってインチキくせえ。
506 ：仕様書無しさん：2007/09/14(金) 22:35:41
>>504
すでに前のレス出ていることからわかるように、
継承を使うような場面ってのはある。

それを継承を使わないで設計するとしたらどういう設計をする？
507 ：仕様書無しさん：2007/09/14(金) 22:36:09
俺が今やってる仕事が過去の製品のソースを流用して動かすってやつなんだが、
継承が多いわ、やけに依存関係にあるクラスが多いわでもう最悪だよ。
で、上の連中は流用すれば工期は短縮するし品質は保証されてるしとか言って俺の意見は全然聞かねーしもうやだ。
C++とかjava使う奴はほんと半年はきっちり基礎理論を勉強してからオブジェクト指向って言葉を口にして欲しいわ。
508 ：仕様書無しさん：2007/09/14(金) 22:39:33
お、スモルトーカさんですか？
509 ：仕様書無しさん：2007/09/14(金) 22:41:12
>>506
継承が便利に使えるのはOOだけじゃないってだけの話
510 ：仕様書無しさん：2007/09/14(金) 22:46:12
>>509
OOだけじゃないというのなら、それ以外は何ですか？
511 ：仕様書無しさん：2007/09/14(金) 22:49:52
継承が便利に…なんだろう。
512 ：仕様書無しさん：2007/09/14(金) 22:49:58
OOを使った設計 = デザインパターン、PofEAA

デザインパターン、PofEAAの設計では
継承を便利に使っていますよ。
513 ：仕様書無しさん：2007/09/14(金) 22:50:36
意味不明。
514 ：仕様書無しさん：2007/09/14(金) 22:51:50
設計をしていて、あっこれデザインパターンの○○が使えるじゃん。
って思ったとき、そういう設計をする。


それをコードに置き換えるとき、それがC言語だと
苦労するだろうな。
515 ：仕様書無しさん：2007/09/14(金) 22:52:58
LispでもOOできるよ
516 ：仕様書無しさん：2007/09/14(金) 22:53:48
今は設計の話。
517 ：仕様書無しさん：2007/09/14(金) 22:55:35
デザインパターンでは設計に普通にクラス図とか継承とかでてくるんだけど、
これをOOではない設計で書くとどうなるんだろうな？
想像もできない。
518 ：仕様書無しさん：2007/09/14(金) 22:56:46
>>510
単なる機能分割されたモジュール。
モジュール指向とかいうマイナーな言葉もあるらしいけど。
519 ：仕様書無しさん：2007/09/14(金) 22:57:21
大体なんで継承なんて使うんだよ。
設計はめんどくさい、ソースの可読性最悪。
障害おきても訳分からん。
スーパーマンが作ったライブラリじゃないと害悪にしかならんだろ。
520 ：仕様書無しさん：2007/09/14(金) 23:02:12
>>519
COBOLの時代のように、流れ作業だけじゃできない処理が増えたから。
521 ：仕様書無しさん：2007/09/14(金) 23:21:21
係員にしかできないこと
来訪者にしかできないこと
係員にも来訪者にもできること。

そんなとき、人というクラスを用意して継承(というか多態性)を使う。

人の情報を表示する画面があったとする。人が係員だろうと来訪者だろうと構わない。
係員クラスや来訪者クラスが変更されても、人クラスのインターフェイスが変更されない限り、この画面は変更する必要がない。
いわゆるOCPってヤツだ。
522 ：仕様書無しさん：2007/09/14(金) 23:26:02
>>521が全然わかって無いアホだというのはよーくわかった
523 ：仕様書無しさん：2007/09/14(金) 23:27:55
>>521
これ見て判るとおり、どうもC++屋のOOPは今一なんだよな
OOP理解度に関して言えば、オプソ慣れしてるJava厨の方が上と言わざるを得ない
524 ：仕様書無しさん：2007/09/14(金) 23:28:58
>>522
全然わかってないって言う理由を言ってくれ。
525 ：仕様書無しさん：2007/09/14(金) 23:29:48
>>521
そんなもん、係員と来訪者にそれぞれコードを書けばいいだけだろ？
係員にしかできないことなら、係員だけに書いて、
来訪者にしかできないことなら、来訪者用だけに書いて、
両方できることなら、両方書く。

そうすると重複するコードができるって？それのどこが悪い。
二パターンに対応するのだからコードは二倍必要。わかりやすいじゃないか。
526 ：仕様書無しさん：2007/09/14(金) 23:35:27
>>525
> それのどこが悪い。 

ふつうにメンテナンス性が悪くなるだろ。
527 ：仕様書無しさん：2007/09/14(金) 23:36:27
戸籍謄本に載ってる項目に関して、これが頻繁に追加されたりとか考えられないから
人のスーパークラスが戸籍謄本の情報を持つのはまあ問題ない。
で、就職すると人のサブクラスのブルーカラーになりつつ、同時に納税インターフェースも持つことになる。
この納税インターフェースをヌルオブジェクトで実装するのが脱税野郎なので、visiorパターンで調査して追徴課税をさせる。
528 ：仕様書無しさん：2007/09/14(金) 23:37:08
だれそれが出来ることとかもうね、痛々しい。
どうせ憂鬱本とか読んでわかった気になってんだろ。
529 ：仕様書無しさん：2007/09/14(金) 23:39:30
係員と来訪者じゃメソッドもフィールドも明らかに一致しないのに何でわざわざ継承するんだよ…
アホすぎる
530 ：仕様書無しさん：2007/09/14(金) 23:41:01
>>526

> ふつうにメンテナンス性が悪くなるだろ。

それのどこが悪い？

そんなメンテナンスするかどうかもわからないもののために
オブジェクト指向なんか使っているから時間かかるんだよ。
531 ：仕様書無しさん：2007/09/14(金) 23:42:38
>>530
ああ、そういうレベルの話か。
532 ：仕様書無しさん：2007/09/14(金) 23:43:25
要するにアレだろ？
スーパークラスはコアファイターで
サブクラス次第でガンダムにもガンタンクにもなれるって事だろ？
思いっきり無駄じゃん。
じおん軍みたいにMSなんか量産兵器なんだからシンプルかつ頑丈にっての方が良いって絶対。
533 ：仕様書無しさん：2007/09/14(金) 23:43:42
522以降、クラス抽出やらメソッドやらの話してる奴等も同じレベルだな
所詮この程度か
534 ：仕様書無しさん：2007/09/14(金) 23:45:16
原理主義者はもういないのか・・・
535 ：仕様書無しさん：2007/09/14(金) 23:45:47
アホが決め付けで叩くから、あきれてどっかいったんだろ
536 ：仕様書無しさん：2007/09/14(金) 23:46:11
>>523 ここからの話の流れを見ると、Javaのオープンソースのプロダクトは、
オブジェクト指向っぽい組み方はしてないってことか?
537 ：仕様書無しさん：2007/09/14(金) 23:47:23
>>536
うんにゃ完璧にオブジェクト指向だよ
538 ：仕様書無しさん：2007/09/14(金) 23:50:54
つまり、業界が効率を求めてきたから
オブジェクト指向が普及したわけか。

まあ、効率を求めない低レベルなやつは
いらないと思うだろうなｗ
539 ：仕様書無しさん：2007/09/14(金) 23:52:09
オブジェクト指向って単に機能の切り分けだよ。
継承ってのは切り分けた機能を組み立てる手法の一つ。
たかがこれだけの事に何でそんなに話し込まなきゃならんの？
540 ：仕様書無しさん：2007/09/14(金) 23:53:08
>>539
またそういう抽象的なこといって煙に巻こうとするｗ
具体例を出せ具体例を
541 ：仕様書無しさん：2007/09/14(金) 23:53:32
C++使いは比較的OOに慣れてる人は見かけるけどJavaオンリーの人間でOO理解してる人はあまり見ない
多分Java流行っていきなりJavaならった子ばっか見てるからだと思う
542 ：仕様書無しさん：2007/09/14(金) 23:54:45
>>541
はああ？>>521書いたのC++オンリーの奴だろ？
見た瞬間にわかったけど
543 ：仕様書無しさん：2007/09/14(金) 23:54:58
具体例って言われてもな。
具体例あげなきゃならんほど難解な話か？
544 ：仕様書無しさん：2007/09/14(金) 23:55:56
>>542
いや違うけど
実際現場ではそう感じるだけだよ
Java使いが全部OO理解してないという意味ではないので勘違いしないように
545 ：仕様書無しさん：2007/09/14(金) 23:55:57
>>543
簡単だったらなおさら具体例出せるんじゃない？
546 ：仕様書無しさん：2007/09/14(金) 23:56:08
>>542
じゃあお前>>521をjava風に書いてみろよ。
547 ：仕様書無しさん：2007/09/14(金) 23:56:58
>>544
誤解はしてないつもり
C++オンリーの奴のOOP理解度はいまひとつだなーってだけ
548 ：仕様書無しさん：2007/09/14(金) 23:57:51
エセOO厨乙
549 ：仕様書無しさん：2007/09/14(金) 23:57:53
>>546
あほか。設計がいまいちだっつってんのにJava風もC++風もあるかよ
550 ：仕様書無しさん：2007/09/14(金) 23:58:37
Javaのオブジェクト指向はC++直系のオブジェクト指向なんだがね
551 ：仕様書無しさん：2007/09/14(金) 23:59:00
あぁ、例が悪かったな。てきとーな例を挙げちまって悪かったよ。


>>521
妄想癖あるみたいだね。
どこをどうしたらC++屋と断定できるんだ？
オレはC#屋だが。

>>525, >>530
YAGNIとか言いたいの？
一度目の重複で対策しときなよ。

>>528
君はちょっと論点ずれてそうだね。
できればもうレスしないでくれ。

>>529
来訪者って命名が悪かったかな。
オレは図書館のシステムを思い浮かべて書いたんだよ。
だから、来訪者っつってもちゃんとシステムに登録されているんだ。
552 ：仕様書無しさん：2007/09/15(土) 00:00:51
>>551
C++だったら>>521の設計はありえないだろ
テーブルモジュールってしってっか？
553 ：仕様書無しさん：2007/09/15(土) 00:01:23
わりまちがえた
>>552

×C++
○C#
554 ：仕様書無しさん：2007/09/15(土) 00:01:52
>>549
ならお前ならどう設計するのか書いてみろよ。
555 ：仕様書無しさん：2007/09/15(土) 00:02:28
>>552
C++は知らんから、C++でありえるかどうかは知らんし、
C++屋って決め付けてきたのに「C++ではありえない」って・・・？

>> テーブルモジュール
PofEAA
556 ：仕様書無しさん：2007/09/15(土) 00:03:15
>>555
すまん>>553参照のこと
557 ：仕様書無しさん：2007/09/15(土) 00:03:57
あぁ、書き間違いか。
で、C#だと何でありえないんだ？？
558 ：仕様書無しさん：2007/09/15(土) 00:04:25
>>554
これだけの情報じゃなんともいえんよ
逃げじゃないよ
559 ：仕様書無しさん：2007/09/15(土) 00:08:20
なんで設計の話をしているのに、
コードの話になるんだ。
ばかじゃねーかｗ
560 ：仕様書無しさん：2007/09/15(土) 00:08:21
もしかして、

＞ 人というクラスを用意して継承(というか多態性)を使う。

が、「係員・来訪者を派生して人を定義」って解釈されてる・・・？
だとしたら、書き方が悪かったなごめんよ。
人から派生させるって意味で書いたんだ。
561 ：仕様書無しさん：2007/09/15(土) 00:10:17
>>557
テーブルモジュール前提なら>>521は一般的な設計じゃないってことはわかるか？
ありえないってのは言い過ぎたかもしれん。だがまあ、ほとんどない。
562 ：仕様書無しさん：2007/09/15(土) 00:12:01
> テーブルモジュール前提なら>>521は一般的な設計じゃないってことはわかるか？

わからないので、ちゃんと説明してください。
一般的な設計じゃないといったあなたに説明責任があります。
563 ：仕様書無しさん：2007/09/15(土) 00:12:04
おれ実務でOOPやった事ないんだよね。
実際の現場じゃどうやって設計するの？
俺の頭じゃ大人数でクラスライブラリ設計する方法が想像できないんだよ。
564 ：仕様書無しさん：2007/09/15(土) 00:12:39
>>561
オレはテーブルモジュールは適用しない。
つーか普通オブジェクト指向スレでテーブルモジュールを前提に話しないんじゃね？
565 ：仕様書無しさん：2007/09/15(土) 00:13:42
>>562
別におまえが理解しようがしまいが知ったこっちゃねーよ
バカか？

超ヒントだしてやってるのに、噛み付く始末だ。あきれたね
566 ：仕様書無しさん：2007/09/15(土) 00:14:44
>>565
言っとくけどオレ(>>521)は>>562じゃないからな。
>>564がオレだ。
567 ：仕様書無しさん：2007/09/15(土) 00:16:25
なんで>>521の設計がテーブルモジュールと決め付けてるんだよ。
C++だったらテーブルモジュールしか実装できないのか？
568 ：仕様書無しさん：2007/09/15(土) 00:16:30
C#でテーブルモジュール使わずに、どーしてもORマッパー使いたいってわけ？
あんまねーよそんなの。つか一切無い
569 ：仕様書無しさん：2007/09/15(土) 00:17:47
>>568
だから、今は設計の話しをしている。
言語を持ち出してくんな
570 ：仕様書無しさん：2007/09/15(土) 00:18:28
>>569
わりい、すっこんでてくれるか？レベル低くてみてらんないし
571 ：仕様書無しさん：2007/09/15(土) 00:18:50
>>570
お前が市ね
572 ：仕様書無しさん：2007/09/15(土) 00:19:07
>>570
お前が市ね
573 ：仕様書無しさん：2007/09/15(土) 00:19:46
>>568
テーブルモジュール以外知ってる？
あんたの会社でC#つかってようが、テーブルモジュールだけを使ってようが、
そんな狭い世界の常識を持ち出してこないでね。
574 ：仕様書無しさん：2007/09/15(土) 00:21:05
結局、誰もOO分かってないようだ。
575 ：仕様書無しさん：2007/09/15(土) 00:21:57
>>573
ORM出してる時点でドメインモデルも知ってるに決まってんだろ
あーあ、なんだこのスレ。雑魚同士で勝手にやってろバーカ
576 ：仕様書無しさん：2007/09/15(土) 00:22:24
設計は言語と関係なくどんな言語であっても
設計できるもんだがね。
C++だとこうなるとかC#だとありえないとか。馬鹿すぎ。
577 ：仕様書無しさん：2007/09/15(土) 00:22:27
みんなして俺OOPを主張し合ってるから話がかみ合わないんだよ。
578 ：仕様書無しさん：2007/09/15(土) 00:22:40
>>506
DI
579 ：仕様書無しさん：2007/09/15(土) 00:23:27
>>575
それを知っているのなら>>521が
ドメインモデルの設計の可能性もあることを知っているよな？
テーブルモジュールと決め付ける理由は何？
580 ：仕様書無しさん：2007/09/15(土) 00:23:46
OOってのは人によって、意味が違うのか？

ダメじゃん・・・・。
581 ：仕様書無しさん：2007/09/15(土) 00:24:03
>>579
C#だから。らしいぜｗｗｗ

誰が言ったかC#
582 ：仕様書無しさん：2007/09/15(土) 00:24:25
OOはあなたの心にあるのです！
神を信じなさい！
583 ：仕様書無しさん：2007/09/15(土) 00:25:10
>あんたの会社でC#つかってようが、テーブルモジュールだけを使ってようが、
>そんな狭い世界の常識を持ち出してこないでね。

>設計は言語と関係なくどんな言語であっても
>設計できるもんだがね。

上の2つは話になんないほど痛々しいね
ほんと、ド素人としかいいようがないわ
584 ：仕様書無しさん：2007/09/15(土) 00:25:54
>>583
お前、他人を素人呼ばわりしているだけで、その理由がないな。
お前こそが素人だって言っていいか？理由はいわなくてもわかるだろ？ｗ
585 ：仕様書無しさん：2007/09/15(土) 00:25:57
そもそも「オブジェクト指向」とは何かすら、
コンセンサスが取れないようでは、普及は無理だねw
586 ：521：2007/09/15(土) 00:26:16
>>568
>>521でドメインモデルの話をしてて、テーブルモジュールじゃ
ありえないと言われたってことは>>568はテーブルモジュール主義？

>>570
オレもC#がどうのの話はするつもりないんだが。
継承の話をしたかったのに話が逸れてる・・・。
587 ：仕様書無しさん：2007/09/15(土) 00:27:33
横槍で良く分かってねぇかもだが。

＞人の情報を表示する画面があったとする。人が係員だろうと来訪者だろうと構わない。
＞係員クラスや来訪者クラスが変更されても、人クラスのインターフェイスが変更されない限り、この画面は変更する必要がない。
＞いわゆるOCPってヤツだ。

テーブルモジュール云々言うてるのはココの部分だろ。

「テケトーに画面を変更する必要が無い」を
「テーブル管理の部分と内部にある情報のインスタンスのインターフェースを変更する必要が無い」とか
そんな感じで読み変えたら済むだけの話じゃねぇの？

誰も画面の作り方の話なんてしてぇワケじゃ無いべ
588 ：仕様書無しさん：2007/09/15(土) 00:27:46
>>521がC#使いだってカミングアウトしたから、C#でその設計はありえないっていったわけ
文盲かおまえら？
589 ：仕様書無しさん：2007/09/15(土) 00:27:53
>>585
だから機能の切り分けだって。
元は本当に簡単な話なんだよ。
590 ：仕様書無しさん：2007/09/15(土) 00:28:07
よく会議で、設計の話をしているのに、
実装の話を持ち出して話を混乱させるやついるよな？

このスレにもいるようだｗ
591 ：仕様書無しさん：2007/09/15(土) 00:28:28
オブジェクトってのはメモリ上に展開されたクラスで、
クラスってのは抽象データ型をプログラミング言語で表現したもので、
オブジェクト指向プログラミングは抽象データ型とクラスを構成単位としてプログラミングする技法のことだ。
わかったか？

ま、ここにいる奴にはわからんだろうし、わからんでも別にどーでもいいんだが
問題は会社の同僚がわかってねーことなんだよなぁ…
592 ：仕様書無しさん：2007/09/15(土) 00:28:58
>>588
お前C#つかっていたら、必ずテーブルモジュールを使うものだと
そういいたいのかね？
593 ：仕様書無しさん：2007/09/15(土) 00:33:02
>>590
おまえ何も使えない環境だったら、ORMマッパやADO.NETに相当するものを
PGにスクラッチで書かせるつもりか？ｗ
冗談は顔だけにしといてくださいよｗｗｗｗ
594 ：仕様書無しさん：2007/09/15(土) 00:34:41
普段C#使っていたら、データモジュールの設計をしちゃいけないのかよｗ
その設計をC#で実装するなんて誰が決めた。
595 ：仕様書無しさん：2007/09/15(土) 00:39:17
ぶち壊しだよお前ら
596 ：仕様書無しさん：2007/09/15(土) 00:39:28
>>591
細かい突っ込みでスマンが、ていうか個人的な疑問なんだけど。

それオブジェクトじゃなくてインスタンスじゃない？
よく分かんないけど、用語としてインスタンス＝オブジェクトな文化の言語ってあるの？
597 ：仕様書無しさん：2007/09/15(土) 00:41:01
>>590
流れがよく分からんけど、クラスだの継承だのなんて詳細設計の
底のほうの話なんだし、実装と切り分ける必要はあるのか？
実装の話を持ち出されて混乱するってことは設計が練りきれて
ないんじゃないのか？
598 ：仕様書無しさん：2007/09/15(土) 00:52:48
今まであえて言わなかったけどさあ
おまいらアホコテとかいってバカにしてるけど
おじゃばより自分の方がずーーっと雑魚って
自覚したほうがいいよマジで
599 ：仕様書無しさん：2007/09/15(土) 00:55:09
おまえらホント駄目だな。
俺がオブジェクト指向について教えてやるよ。

オブジェクト指向ってのはな、
animalクラスを作ってから、それを継承して
dogクラスやcatクラスを作ることなんだよ。

これがオブジェクト指向の本質。
600 ：仕様書無しさん：2007/09/15(土) 00:56:39
>>599
エサより釣り針の方が目立ってますよ。
601 ：仕様書無しさん：2007/09/15(土) 00:56:39
>>598

おじゃば 乙
602 ：仕様書無しさん：2007/09/15(土) 01:02:05
>よく分かんないけど、用語としてインスタンス＝オブジェクトな文化の言語ってあるの？

文化も何も定義だよ。
ちゃんとしたオブジェクト指向の本なら説明されてる。
少なくとも今手元にあるオブジェクト指向入門とコードコンプリートには書いてある。
日本人が書いてる本ってどれもこれもオブジェクトは世の中の「もの」を表したものだって書いてあるけど、
この意味不明で何の役に立つかわからん解説って誰が広めたんだ？
…なんか、まつもとゆきひろのRuby本でもオブジェクトは「もの」だって書いてあるな
603 ：仕様書無しさん：2007/09/15(土) 01:02:30
>>598
コテ叩きしか能がない池沼は１人か２人しかいないだろ。
その池沼が空気読まずに頑張ってくれるせいでますます
マトモな人間が寄り付かないスレになってるだけで。
604 ：仕様書無しさん：2007/09/15(土) 01:03:07
結局なんで>>521は>>542とかにC++オンリーの奴って言われてたんだ？
605 ：仕様書無しさん：2007/09/15(土) 01:03:48
>>602
批判はいい。お前が説明しろ。
606 ：仕様書無しさん：2007/09/15(土) 01:04:23
日本人でオブジェクト指向の本書いてる奴の3割ぐらいは
ホントはオブジェクト指向を理解してないらしいよ。
知ってた？
607 ：仕様書無しさん：2007/09/15(土) 01:06:12
>>603
ちょっとあんたからも言ってやってよｗ
こいつら絶対勘違いしてるんだってｗ
608 ：仕様書無しさん：2007/09/15(土) 01:07:16
勘違いしているんだ！はいい、お前が説明しろ。
609 ：仕様書無しさん：2007/09/15(土) 01:09:29
>>608
何を説明させるんだよｗ
どのレスが低脳っぽいかってことか？ｗ
610 ：仕様書無しさん：2007/09/15(土) 01:11:09
勘違いしているという理由に決まっているだろ。
611 ：仕様書無しさん：2007/09/15(土) 01:12:06
誰も「オブジェクト指向が普及しないのは○○だからだ」
「オブジェクト指向のメリットは○○である」と明言できないスレ。
612 ：仕様書無しさん：2007/09/15(土) 01:15:34
>>611
メリットの話題になると「具体的な話をしろ」
具体的な話題になると「メリットを挙げろ」
613 ：仕様書無しさん：2007/09/15(土) 01:15:52
>>610

>>598
>>603
>>607
>>608
>>609
>>610
ちゃんとお読みですか？ｗ
614 ：仕様書無しさん：2007/09/15(土) 01:16:06
説明しろ厨には絶対に教えてやらねーよｗ
自分で勉強しろボケが
615 ：仕様書無しさん：2007/09/15(土) 01:16:56
>>613
頭大丈夫ですか？ｗ
616 ：仕様書無しさん：2007/09/15(土) 01:18:11
>>614
やっぱりそうきたかｗ
結局

あいつはわかっていない ← じゃあお前が説明しろ ← うっせばーかばーか

このパターンなんだなｗ
617 ：仕様書無しさん：2007/09/15(土) 01:19:22
>>615
池沼みっけｗ
618 ：仕様書無しさん：2007/09/15(土) 01:29:32
「説明してください。お願いします。」
って言えば教えてやるのに。
幼稚な奴って、いつでも他人のせいして自分を省みないのな。
619 ：仕様書無しさん：2007/09/15(土) 01:30:33
>>618
わかっているから、説明しなくていい。
620 ：仕様書無しさん：2007/09/15(土) 01:32:26
たとえってのはわかりやすくするために使うのに、
それを難しく説明する馬鹿っているよね。
621 ：仕様書無しさん：2007/09/15(土) 01:33:13
どうせ説明したって聞きゃしねーよ
622 ：仕様書無しさん：2007/09/15(土) 01:34:33
なんだ、結局説明しないのかｗ
623 ：仕様書無しさん：2007/09/15(土) 01:35:42
空気も読めないときたもんだｗ
624 ：仕様書無しさん：2007/09/15(土) 01:37:32
別にろくでもない説明ってわかっているから、説明なんて不要。

でも口だけじゃなくて本当に説明ができるといいたいのなら、
勝手に説明すれば？

無理だと思っているけどね。
625 ：仕様書無しさん：2007/09/15(土) 01:38:12
「お願いします」が無いよボクちゃん
そんなんだから周りに相手にされないのよ
626 ：仕様書無しさん：2007/09/15(土) 01:39:20
説明なんて要らないのに、なんでお願いなんていう必要があるの？ｗ
むしろ、説明させてくださいとお願いしてほしいくらいだ。
627 ：仕様書無しさん：2007/09/15(土) 01:42:07
>>625
ほっとけよ。だいたい話の裏付けなんて各自が取るもので、
ここで誰かが説明したら、それ鵜呑みにするのかって話だし。
そもそも説明なんて不要。
628 ：仕様書無しさん：2007/09/15(土) 01:42:35
お前らにいい事教えてやるけどOO理解して説明できる事より美人を一人でも多く口説ける方が世間の評価は高いんだよ
629 ：仕様書無しさん：2007/09/15(土) 01:43:57
そうそう説明なんて不要。
ただ、他人の説明がなってないというのなら、
それを上回る説明ができないとだめというだけ。

駄目なのは誰の目にもわかっていることだから、説明は不要。
630 ：仕様書無しさん：2007/09/15(土) 01:52:39
こりゃ普及しないわw
631 ：仕様書無しさん：2007/09/15(土) 01:54:15
お前ら、OOの前にまず大人になれよ。
性的な意味で。
632 ：仕様書無しさん：2007/09/15(土) 01:55:29
そんなレス付けて勝ったと思えるのが幸せだね。
自分以外の人間の知能を低く見積もり過ぎなんじゃないの？
633 ：仕様書無しさん：2007/09/15(土) 01:58:11
>>632
少なくともお前の知能は低いだろうな
634 ：仕様書無しさん：2007/09/15(土) 02:05:34
やれやれ。
635 ：仕様書無しさん：2007/09/15(土) 02:11:20
分かったつもりで誰も分かっていなのがOO
636 ：仕様書無しさん：2007/09/15(土) 02:25:10
最近自分の意見を言わず（言えず）に他人の意見を批判するやつ多いな。
637 ：仕様書無しさん：2007/09/15(土) 02:43:19
>>604
オブジェクト指向をあんまり分かってない俺ですら、>>521の例は
違う種類のデータを画面を基準に一つにまとめてる部分が気持ち悪い
と思うんで、普段使ってるライブラリを通して出来の良いクラス構造に
自然と触れ続けてるJavaプログラマからみたら大きな違和感が
あるんでないかな？
638 ：仕様書無しさん：2007/09/15(土) 02:50:47
>>636
それ以前に、理屈と感情の切り分けが出来てないのをなんとかして欲しい
639 ：仕様書無しさん：2007/09/15(土) 03:16:43
普及しないのは思ってたよりもオブジェクト指向を必要とする場面が少なかったからじゃないか？
640 ：仕様書無しさん：2007/09/15(土) 03:18:32
アホが理解できんからでそ
641 ：仕様書無しさん：2007/09/15(土) 07:10:29
例えば製品カスタマイズで、カスタムコマンド的なものを作るときは
interfaceベースか、もしくはabstractベースで作るのが基本となる。
テンプレートメソッドパターンに嵌め込むとレビューや引継ぎがしやすいんだよね。

ただ重度のオブジェクト指向言語使ってるからって、何でもかんでもクラス化てのはないな。
最適化のために引数12,3個を使った再起処理みたいな泥臭いことは相変わらず。
642 ：仕様書無しさん：2007/09/15(土) 11:59:58
　＿＿＿__　見えませ～ん
　||　 　 　 |　　　　∨
　|| 現実 ∧_∧　　ﾊ_ﾊ
　||　 ＼( ･∀･)　(ﾟA●)
　||￣￣⊂　　)　 ( と)
. 凵　　　し`Ｊ　 　U U


　＿＿＿__　読めませ～ん
　||　 　 　 |　　　　∨
　|| 空気 ∧_∧　　ﾊ_ﾊ
　||　 ＼( ･∀･)　(ﾟA●)
　||￣￣⊂　　)　　( と)
. 凵　　　し`Ｊ　 　U U


　＿＿＿__　知りませ～ん
　||　 　 　 |　　　　∨
　|| 常識 ∧_∧　　ﾊ_ﾊ
　||　 ＼( ･∀･)　(ﾟA●)
　||￣￣⊂　　)　　( と)
. 凵　　　し`Ｊ　 　U U


　＿＿＿__　ありませ～ん
　||　 　 　 |　　　　∨
　|| 未来 ∧_∧　　ﾊ_ﾊ
　||　 ＼( ･∀･)　(ﾟA●)
　||￣￣⊂　　)　　( と)
. 凵　　　し`Ｊ　 　U U
643 ：仕様書無しさん：2007/09/15(土) 17:16:01
これからは関数型だろ
644 ：仕様書無しさん：2007/09/15(土) 18:03:36
これからは無形の型が主流
645 ：仕様書無しさん：2007/09/15(土) 19:30:33
軽量言語だと効率良いっていうのを伝えるときに、
JAVAで書くと20行になるのが、
軽量言語だとわずか2行で済むっていう
説明はわかりやすい。

でも、オブジェクト指向だと、手続き型だと20行になるのが、
オブジェクト指向で書くと40行になったりするからなあ。
ここだけみれば完全にデメリット

このデメリットをトレードオフし、さらに上回るくらいのメリットが
あると説明するのは至難。
646 ：仕様書無しさん：2007/09/15(土) 19:34:56
お前らガキか。
OOPって言葉を出せば単価が上がるからOOPなんだよ。
OOPの本を書いてる奴らも同じだ。
647 ：仕様書無しさん：2007/09/15(土) 19:38:49
それはないね。
発注者は要件を実現できればいいだけ。
実装技術なんかに興味は無い。
OOPだから、金額上積みするなんてありえん。
648 ：仕様書無しさん：2007/09/15(土) 19:44:54
でもね
OOは別に悪くないけどね
OO的なプロジェクトってクラス本体を修正したり作成したりする人がいて、この人らはいいよ。
Pearなどのパッケージがないと何もできないエンジニアが増えてるのも事実。
パッケージに頼りすぎるとエンジニアが育たない
けどまあ確かに車輪の再発明するのも手間っちゃ手間。
649 ：仕様書無しさん：2007/09/15(土) 19:48:56
パッケージ作ってる部隊の糞ライブラリで顧客にカスタマイズ提供しなきゃいけない苦痛。
おまえのそのありえない実装を俺が入れ替えてやるから、ソースよこせやと叫びたい毎日。
650 ：仕様書無しさん：2007/09/15(土) 19:59:52
小島よしおが流行ってるから
OOPを「おっぱっぴー」って呼ぼうぜ
オブジェクト指向とかごちゃごちゃいいだす奴が職場にいたら
「でもそんなの関係ねー！でもそんなの関係ねー！」
って連呼しよう
651 ：仕様書無しさん：2007/09/15(土) 20:49:10
コンサルがＳＡＰやCOBOLを使いたがる現状で、
OOが陽の目を見ることがないのは明らか。
細々と一部で使われるだけ。
普及には程遠いな。
652 ：仕様書無しさん：2007/09/15(土) 22:02:09
>>649
そしてそれを使う奴らがこんな「糞ライブラリ使えね！」
以下ループ
653 ：仕様書無しさん：2007/09/15(土) 22:54:52
まあ、OOのメリットって目に見えないほど小さいからね。
654 ：仕様書無しさん：2007/09/15(土) 22:56:29
Windowsアプリ作るのにSTLもMFCもWTLも全部使うなって言われたら発狂するが。
655 ：仕様書無しさん：2007/09/15(土) 23:33:04
Win32APIでアプリ作る程度で発狂するなんてレベル低いな。

さておき、それは上位レイヤのライブラリを使えばプログラム作成が楽ってだけであって、
オブジェクト指向関係無いじゃん。
656 ：仕様書無しさん：2007/09/15(土) 23:37:55
>>645
Windowsのプログラムは、Cで書いたら、ウインドウ表示するだけで100行だけど、
VC++(MFC)で書いたら10行だよ。

って説明は、手続き型でもフレームワークに相当するライブラリが用意してあれば
短く書けるからOOPのメリットの説明にはならないな…

WindowsのAPIをラップするライブラリをCとC++で書いて比較すればいいけど、Windowsの
ウインドウ周りのAPIって、オブジェクト指向っぽくなってるから、それをCでラップしても、
あるていどはOOっぽくなってしまうな。

十数年前くらい前にMacのコードを見たら、もろ手続き型だったんで、そこらあたりと比べると
おもしろくなるかも。(Winみたいに、イベントが発生したら、そのウインドウのコールバック関数が
呼ばれるみたいなスタイルじゃなくて、どのウインドウがクリックされたか自分で探すみたいな感じだった)
657 ：仕様書無しさん：2007/09/15(土) 23:48:30
このまえやった仕事は、画面に図形を表示して、それをマウスで操作してって、
教科書にでてくるようなOOPむけのシステムだったけど、ぜんぜんOOっぽく組まれてなかったな。
継承とかぜんぜんつかってなくて、画面のシンボルのごとに個別にクラスがあって、
コードのあちこちで、シンボルを判定するifの嵐だったよ。
しかもすごいヘタクソなコードで、シンボルごとに、ほとんど同じだけど微妙にちがうってコードが大量にかかれてたし。
これはオブジェクト指向どうこう以前の話だけど。
658 ：仕様書無しさん：2007/09/15(土) 23:54:23
>>657
まぁサンプルとかにはよくShapeクラスとか出てくるけど、実際にそれで実用的なアプリを組むというところまで話は進まないもんな～
659 ：仕様書無しさん：
gtkはモジュール指向か？オブジェクト指向か？