オブジェクト指向は本当に正しいのか？

1 ：デフォルトの名無しさん：2012/03/11(日) 14:30:55.03

議論する

2 ：デフォルトの名無しさん：2012/03/11(日) 14:59:59.48

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

3 ：デフォルトの名無しさん：2012/03/11(日) 15:33:37.36

高慢と偏見（1）隣は何をする人ぞ
http://el.jibun.atmarkit.co.jp/pressenter/2010/11/1-828a.html

　高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、
というのは広く世に知られた真理の1つである。

　K自動車ICTシステム部の三浦技術担当マネージャは、そのようなエンジニアの生き見本のような人だった。
初めに言葉ありき。私が聞いた三浦マネージャーの最初の言葉はこうだ。

　「オブジェクト指向など、実業務では使いものにならない！」

　私は思わず手を止めてしまい、壁を見つめた。

　隣に座っていた男性プログラマも同じように手を止めて、まるで隣の会議室が見えるかのように壁をまじまじと見つめている。

　声は続いている。

　「オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、オブジェクト指向なんてものは、
理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばGUIのコンポーネントとかは
オブジェクト指向に基づいて作られているようだから、そういうツールとかを作る人には必要なものなのかもしれない。
しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。
どうもこの業界、オブジェクト指向でなければダメ、というような風潮がまかりとおっているけどな、
オブジェクト指向なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、カプセル化とかポリ何とかとか、
どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな……」

　おいおいおいおい。私は思わず壁の向こうの顔も知らない講師に突っ込んだ。もちろん心の中で、だが。

　――あなたはオブジェクト指向をほとんど使ったこともないくせに、
オブジェクト指向は「使えない！」と断言しているわけですか？

4 ：デフォルトの名無しさん：2012/03/11(日) 15:41:56.22

そんなことより、手続き型、オブジェクト指向、関数型に代わる新しいパラダイム考えようぜ

5 ：デフォルトの名無しさん：2012/03/11(日) 15:42:11.09

高慢と偏見（終）　エピローグ
http://el.jibun.atmarkit.co.jp/pressenter/2011/02/post-6b95.html

　疲労による脱落者を数人出しながらも、3月末に何とかカットオーバーした――というかさせた――新部品調達システムは、
4月1日に本番稼働した。三浦マネージャは自分の功績を大いに吹聴したらしいが、
その栄華はほとんど1日しか続かなかったとのことだった。

　初日から立て続けにいくつかの機能でトラブルが発生した。最初のうちは、本番サーバと予備サーバを切り替えることでしのいでいたものの、
数日後に、とうとうシステムを停止せざるを得なくなった。同じようなコードをコピペして、複数のモジュールで使っていたため、
バグが複製されてしまったのが原因だったようだ。無用なドキュメント作成に時間を取られたために、
十分なテストができなかったことも遠因だったに違いない。数々のトラブル対して、
大量のドキュメントがまったく役に立たなかったのは言うまでもない。

　それでも三浦マネージャは、「この程度のバグは、新しいシステムの初期段階では大抵起こりうる程度にすぎない」などと
強気な発言をしていたらしい。が、バグを修正することが新たなバグを作り込んでしまうという悪循環が続き、
新部品調達システムは、予定の半分以下の機能だけが辛うじて稼働しているだけになってしまった。

　とうとう業を煮やした経営層が、トラブルシューティング専門のコンサルティング会社に、システム全体の調査を依頼した。
三浦マネージャはICTシステム部だけで対応できると言い張ったらしいが、すでにその言葉を額面どおりに受け取る人間は少なくなっていた。

　ソースを調査したコンサルティング会社のエンジニアは、あまりに効率の悪い
前時代的なコーディングに絶句したらしい。そりゃそうだろう。私だって、事前知識なしであのソースを見たら驚く。

　「時代錯誤も甚だしい」

　「保守性というものをまった考慮していない」

　「最低でも6カ月を要する、根本的な大改造が必要」

6 ：デフォルトの名無しさん：2012/03/11(日) 15:44:08.27

　最新の日記は、
　「オブジェクト指向など、実業務では使いものにならない！」
　間違いない。あの人だ。

　日記の内容はというと、「私は20年以上、企業システムのプログラミングを続けているが、
その中でオブジェクト指向などというものが役に立ったことは一度もない」と始まっていて、
　「staticを使えば、わざわざインスタンスを作る必要などない」
　「独自にクラスを作る必要などない。クラスは使うものだ。作るものではない」
　「20年にわたる経験から明白である」
と、どこかで聞いた言葉が並んでいる。

　吹き出したのは、
　「……私はカプセル化もポリモリズムも意味がよく理解できなかった。従って私はこれは不必要なものだと結論づけた……」
のくだりだった。案の定、コメント欄は炎上状態だった。
最初の方では、懇切丁寧にオブジェクト指向の利点を解説してくれている人たちもいたのだが、
　「あなたの経験は何年だ？私は20年だ」
　「あなたの出身校はどこだ？私はT大学大学院卒だ」
　「あなたはSIerだろう。私は客側の人間だ。客の言うことは絶対だ」

などのように、火に油どころか爆弾を投下するような発言が続いたため、親切なコメントはなくなっていた。
　その後も、たまに覗いてみると、
　「ベテランが提案する非オブジェクト指向開発」
　「使えるパターンと使えないパターン」
　「デザパタなどは時間の無駄である」

といったタイトルの日記が定期的に更新されていた。中身はというと、自分が理解できないことを経験だけで批判しているか、
オブジェクト指向を解説しているWebサイトのささいな誤字脱字を針小棒大に批判するか、どちらかでしかなかった。

　たまに別のWebサイトのコメント欄に、オブジェクト指向批判を書くこともあった。当然、技術的な裏付けも何もない、
思い込みによる批判だから、正論で完膚なきまでに叩きのめされてしまう。正面から議論を展開できるだけの知識がないから、
スリービーチさんにできることは、「その日本語はおかしい」とか「若い人はすぐに感情的になるから議論にならない」などと、負け惜しみを書くことだけだった。

7 ：デフォルトの名無しさん：2012/03/11(日) 16:22:15.04

クラスの継承で再利用できるってこと実務でありえるの？

8 ：デフォルトの名無しさん：2012/03/11(日) 16:39:24.67

どんな糞職場で働いてんだ。

9 ： ◆khwKd8pYFQ ：2012/03/11(日) 16:39:55.95

>>4
すでに俺は考えてある。

10 ：デフォルトの名無しさん：2012/03/11(日) 16:42:17.28

>>8
まともな職場教えてくれよ。

11 ：デフォルトの名無しさん：2012/03/11(日) 16:45:45.80

>>7
社内用のライブラリとか無いのか？

12 ：デフォルトの名無しさん：2012/03/11(日) 16:46:05.47

長文が貼ってあるけど
プロジェクトが破綻した理由とオブジェクト指向やデザパタがつながってないように見える

13 ：デフォルトの名無しさん：2012/03/11(日) 16:47:05.83

今、アプリ開発でフレームワークを使わないことは
まず無いと思うけど、ちょっと前までは自前で作ってた。

フレームワークのコードを見ればわかるけど
継承や各種オブジェクト指向のオンパレード。

それ（フレームワーク）によって何が持たされるかというと、
大幅な開発効率の向上。

あるものを使ってるだけだと、オブジェクト指向の恩恵に
気づかないかもしれないけど、自分でフレームワークに近いものを
作るようになれば、そのメリットが分かる。

ようは下っ端はわからない。

14 ：デフォルトの名無しさん：2012/03/11(日) 16:48:27.68

単なる老害が関わったせいでプロジェクトが崩壊する典型的な一例だな
こういった老害は、どんな方法論を与えても同じことを繰り返す

15 ：デフォルトの名無しさん：2012/03/11(日) 16:48:51.32

アプリそのものの実装で、再利用を考えた設計をすることってあんまないな
ライブラリ作るときは使いまくるけど

16 ：デフォルトの名無しさん：2012/03/11(日) 16:52:48.19

>>15
似た奴を２個目つくるときは再利用するだろ。で、３個目も考慮して一部ライブラリ化される。

17 ：デフォルトの名無しさん：2012/03/11(日) 16:54:35.52

アプリそのものを単純に作れるようにするために、
共通部分をライブラリやフレームワークとして分離する。
そのライブラリやフレームワーク側でオブジェクト指向を使う。

だから、それらを使うだけの人は、誰かが頑張ってくれたお陰で
自分は単純に作れると知りましょう。

18 ：デフォルトの名無しさん：2012/03/11(日) 16:58:14.74

>>13
そうかなぁ？
それらを非オブジェクト指向でラップしちゃってもやっぱり同じことになると思うよ
オブジェクト指向関係ないじゃない

19 ：デフォルトの名無しさん：2012/03/11(日) 16:58:26.10

オブジェクト指向でも最近は継承使わずに委譲だな
委譲を使って必要なメソッドだけを使って必要なメソッドだけを実装するほうが、仕様が爆発しなくて済む。
継承だと親のメソッドを引き継いで、下流が「なんかこんなメソッド有ったんで使っときましたよ^^」「はぁ仕様書に書いてないだろ」「いや、つかえましたよ^^」とか面倒な事が減る

20 ：デフォルトの名無しさん：2012/03/11(日) 17:03:32.36

>>19
javaにはC++のような多重継承がない。
これは多重継承みたいな事をやりたいときは多重委譲にしろって事なのかもね。
でも委譲で十分じゃんとは思う。オーバーライドの整合性を考える余計な労力が減るし。

21 ：デフォルトの名無しさん：2012/03/11(日) 17:04:14.64

俺はライブラリ制作側と使う側のスタイルは分けて考えないとダメだと思ってる
俺等は使う側なので極度の抽象化は作業効率が落ちるだけ

それとライブラリ制作にもまた複数あると思う
ＭＳみたいに一度リリースしてしまったら不具合も含めて仕様・・・となってしまうライブラリ制作と
同じ会社のどっかのライブラリチームみたいに不具合がみつかり次第修正
仕様も簡単に変えて修正してもらいますじゃ適用するもんが全然違う

22 ：デフォルトの名無しさん：2012/03/11(日) 17:05:26.17

>>18
そりゃ、使う側から見れば
おなじに見えるだろうなｗ

だけど、作る側の開発効率がぜんぜん違うわけで。

オブジェクト指向は言語にあらず。
非オブジェクト指向言語でも
オブジェクト指向で作られてる。

オブジェクト指向で作るならば
オブジェクト指向言語が相性がいい。

23 ：デフォルトの名無しさん：2012/03/11(日) 17:07:23.21

>>22
じゃ、ＭＳのライブラリを使ってるという視点でみれば
必ずしもオブジェクト指向は正しい選択じゃないと
そういえるわけだよね？

24 ：デフォルトの名無しさん：2012/03/11(日) 17:09:44.81

>>21
> 俺はライブラリ制作側と使う側のスタイルは分けて考えないとダメだと思ってる
> 俺等は使う側なので極度の抽象化は作業効率が落ちるだけ

極度の抽象化が必要になったら、それはライブラリとして
分離するべき所ってこと。そうすればもっと作業効率が上がる。

だがまともな技術とセンスを持った人がいなければ使いにくいものができてしまう。
だけどそれはただだの、「技術力が低いと使いにくいものが出来る」という
当たり前の話しに過ぎない。

25 ：デフォルトの名無しさん：2012/03/11(日) 17:12:20.30

>>24
>だがまともな技術とセンスを持った人がいなければ使いにくいものができてしまう。
その場合のオブジェクト指向の使用の有無はどういう風に影響を及ぼすわけ？
とりあえず会社的には特定の技術者に特別な処置をしてもらうよりも
馬鹿を長時間働かせて解決する方向へもっていきたいと考えるようだから

ご立派な人にしか理解できないはメリットにはならないと思うが
オブジェクト指向は人を選ぶのだろうか？

26 ：デフォルトの名無しさん：2012/03/11(日) 17:12:41.71

>>23
それは正しいかどうかを語る資格が無いだけ。

飛行機に乗るだけの俺が
航空理論はほんとうに正しいのか？なんて
議論しても意味がないだろう？

俺は航空理論を使ってなくても、飛行機乗れるといっても
何の説得力があるだろうか。

オブジェクト指向が正しいかどうかを語っていいのは、
オブジェクト指向を適用するライブラリや
フレームワーク開発者だけだ。

27 ：デフォルトの名無しさん：2012/03/11(日) 17:14:41.19

>>25
だから、お前には無関係の世界なんだろ？
それだけだよ。
無関係の人は語らないでくれ。

ただ、便利なライブラリやフレームワークを
作ってる人たちに感謝するのは忘れるなよ。

お前が感謝している人たちが感謝をしている
オブジェクト指向を信じろ。

28 ：デフォルトの名無しさん：2012/03/11(日) 17:14:45.69

.net Frameworkの開発者ぐらいしか発言できないなこのスレｗ

29 ：デフォルトの名無しさん：2012/03/11(日) 17:15:20.45

>>27
なんで怒ってるの？
ＭＳの社員じゃないと発言できないぜ？

30 ：デフォルトの名無しさん：2012/03/11(日) 17:15:27.12

.net frameworkだけがライブラリやフレームワークなのだろうか？

31 ：デフォルトの名無しさん：2012/03/11(日) 17:16:00.04

>>29
なんで、MSの社員じゃないと発言できないって思い込んでるの？

32 ：デフォルトの名無しさん：2012/03/11(日) 17:17:17.37

社内のショボチンライブラリをフレームワークと表現するかい？
とりあえずどの規模からフレームワークと定義するの？
俺の休日に作ったコントロールのイベントをすべて監視してログに残すdllもフレームワークでおｋ？

33 ：デフォルトの名無しさん：2012/03/11(日) 17:18:54.11

ちまちま議論してないでacmの論文でも探して読めよ^^

34 ：デフォルトの名無しさん：2012/03/11(日) 17:19:02.14

> 社内のショボチンライブラリをフレームワークと表現するかい？

しない。

なぜなら「ショボチン」だから。
逆に言えば、ショボチンでなければ
ライブラリ（フレームワーク？）と表現する。

35 ：デフォルトの名無しさん：2012/03/11(日) 17:19:36.80

>>34
ショボチンとデカチンの基準を決めてくれるかい？

36 ：デフォルトの名無しさん：2012/03/11(日) 17:20:36.50

> コントロールのイベント
これ、オブジェクト指向だろ？ｗ

37 ：デフォルトの名無しさん：2012/03/11(日) 17:21:21.39

>>35
あぁ、ソムリエじゃないと
ワインの味はわからないよねｗ

38 ：デフォルトの名無しさん：2012/03/11(日) 17:21:50.10

>>32
それはただのアプリケーションだろ。

39 ：デフォルトの名無しさん：2012/03/11(日) 17:22:14.92

>>36
え？
今はライブラリやフレームワーク開発者じゃないと
このスレで語るに値しない
って発言から参加権があるかどうかを決定してるのだよ

君は話がわかっているのかい？

40 ：デフォルトの名無しさん：2012/03/11(日) 17:22:27.08

>>22を見て思いついたんだが、>>6 の老害は、
非オブジェクト指向言語でやるようなオブジェクト指向プログラミングを、
オブジェクト指向言語でやってたりするんだろうか。

41 ：デフォルトの名無しさん：2012/03/11(日) 17:23:16.32

>>39
うん。感謝はしろ。
だけど、良し悪しは語るな。

42 ：デフォルトの名無しさん：2012/03/11(日) 17:23:38.86

>>41
は？
日本語でおｋよ？

43 ：デフォルトの名無しさん：2012/03/11(日) 17:24:44.31

だからオブジェクト指向を使うような
仕事をしていないで、

単に（オブジェクト指向で作られたものを）
使うだけのやつは語る資格ないってことだよ。

お前が便利に使っているものに
オブジェクト指向が使われてるのに
それを否定して説得力があると思うか？

44 ：デフォルトの名無しさん：2012/03/11(日) 17:26:42.09

>>43
関係ないラインがあるってさっき自分で言っただろｗ
だからライブラリ、フレームワーク開発者に参加者を絞ったんだろ
自分で言っといて忘れるなよクズ

45 ：デフォルトの名無しさん：2012/03/11(日) 17:27:43.79

もう>>1のチンゲ全部むしりたくなってきた
発言があまりにもクズ過ぎる

46 ：デフォルトの名無しさん：2012/03/11(日) 17:27:50.77

>オブジェクト指向は正しいか。
コンパイラーがエラーを出さない限り正しい。

47 ：デフォルトの名無しさん：2012/03/11(日) 19:13:33.99

実はオブジェクト指向ってしっくりこないんです

48 ：デフォルトの名無しさん：2012/03/11(日) 19:18:17.01

どこらへんがしっくりこないのか気になる。

49 ：デフォルトの名無しさん：2012/03/11(日) 19:30:28.03

オブジェ区都市高

50 ：デフォルトの名無しさん：2012/03/11(日) 19:43:00.26

staticおじさんは他人のブログに糞コメ混ぜてくるから困る

51 ：デフォルトの名無しさん：2012/03/11(日) 20:05:35.46

自分の庭で暴れても相手にされなくなったんで、でばって暴れて回ってるのかw

悪名が広まって結構なことだ。

52 ：デフォルトの名無しさん：2012/03/11(日) 20:21:27.24

実は構造化ってしっくりこないんです、って若いころおっさんが言ってたら
ムキになって否定してそうなのが余計ムカツクこのタイプ。

53 ：デフォルトの名無しさん：2012/03/11(日) 20:24:41.84

gotoを使うなとかbreakを使うなとか、そういうおかしい人とは関わりたくないな。
こんなのがいると、ifの行の最後にに{を書く奴がマシに見えてしまう。

54 ：デフォルトの名無しさん：2012/03/11(日) 20:26:26.85

　ショボチンでも要件みたせるなら、それはそれで有りだと思う。
下手に凝って、納期を外したらあほやろ？　ニーズに応じて作りこんで行けばいい。

55 ：デフォルトの名無しさん：2012/03/11(日) 20:49:32.46

if の行の最後に { は、C の神様が C の次に作った limbo や、
その次に作った Go でそういう風に構文を変更した程だぞ。

56 ：デフォルトの名無しさん：2012/03/11(日) 20:53:38.59

そりゃ失策だ。

57 ：デフォルトの名無しさん：2012/03/11(日) 21:05:15.37

if () {
}
else if () {
}

普通降格だろ？

58 ：デフォルトの名無しさん：2012/03/11(日) 21:11:30.05

いや、こうだな

if () {
} else if () {
} else {
}

59 ：デフォルトの名無しさん：2012/03/11(日) 21:18:54.67

多様性を使ってif自体を消しておこうか。

60 ：デフォルトの名無しさん：2012/03/11(日) 21:21:40.93

せっかく匿名ifが使えるんだからそうさせてくれよ

61 ：デフォルトの名無しさん：2012/03/11(日) 21:34:49.26

oh!豚痔ェ苦怒嗜好

62 ：デフォルトの名無しさん：2012/03/11(日) 21:44:02.92

そんなに漢字が好きなら中国にでも行くといいよ。

63 ：デフォルトの名無しさん：2012/03/11(日) 21:45:19.46

高慢と偏見（1）隣は何をする人ぞ
http://el.jibun.atmarkit.co.jp/pressenter/2010/11/1-828a.html

　高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、
というのは広く世に知られた真理の1つである。

　K自動車ICTシステム部の三浦技術担当マネージャは、そのようなエンジニアの生き見本のような人だった。
初めに言葉ありき。私が聞いた三浦マネージャーの最初の言葉はこうだ。

　「関数型言語など、実業務では使いものにならない！」

　私は思わず手を止めてしまい、壁を見つめた。

　隣に座っていた男性プログラマも同じように手を止めて、まるで隣の会議室が見えるかのように壁をまじまじと見つめている。

　声は続いている。

　「オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、関数型言語なんてものは、
理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばパーサコンビネータなんかは
関数型言語が向いてるみたいだから、トイ言語を作る人には必要なものなのかもしれない。
しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。
どうもこの業界、関数型言語でなければダメ、というような風潮がまかりとおっているけどな、
関数型言語なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、モナドとか参照透明性とかモノイドとかとか、
どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな……」

　おいおいおいおい。私は思わず壁の向こうの顔も知らない講師に突っ込んだ。もちろん心の中で、だが。

　――あなたは関数型言語をほとんど使ったこともないくせに、
Haskellは「使えない！」と断言しているわけですか？

64 ：デフォルトの名無しさん：2012/03/11(日) 21:48:28.81

>>63
こちらにどうぞ。
http://toro.2ch.net/test/read.cgi/tech/1331328955/

65 ：デフォルトの名無しさん：2012/03/12(月) 00:32:56.16

オブジェクト指向プログラミングは間違いだったか?
http://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang

66 ：デフォルトの名無しさん：2012/03/12(月) 00:48:01.86

マ板か、ここ

67 ：デフォルトの名無しさん：2012/03/12(月) 00:55:34.78

いや、プ板だ。

68 ：デフォルトの名無しさん：2012/03/12(月) 02:28:33.69

aとtheの区別がつかない日本人には基本的に必要ない機能だよねコレｗ

69 ：デフォルトの名無しさん：2012/03/12(月) 05:15:06.79

またstaticおじさんか

70 ：デフォルトの名無しさん：2012/03/12(月) 10:58:57.39

ポリフォーリズムは正しい

71 ：デフォルトの名無しさん：2012/03/12(月) 11:59:56.39

パラダイムの一つでしかないんだから正しいも糞もない
効率が良いと思う人が使えばいいだけの話

72 ：デフォルトの名無しさん：2012/03/12(月) 22:02:51.78

オブジェクト指向は役に立つという迷信は本当に正しいのか？

73 ：デフォルトの名無しさん：2012/03/12(月) 22:10:20.55

世の中からオブジェクト指向でできたものを
取り除こう。

74 ：デフォルトの名無しさん：2012/03/12(月) 22:22:47.58

オブジェクト指向だと思っていたらただの構造化だった

75 ：デフォルトの名無しさん：2012/03/13(火) 00:42:58.33

クラス図を書いたと思ったら、ただのE-R図だった。

76 ：デフォルトの名無しさん：2012/03/13(火) 02:14:17.72

せいぜい１００個しか変数の動きを追えない俺が
１００万行以上のプログラムを開発できるのはＯＯＰのおかげ。

77 ：デフォルトの名無しさん：2012/03/13(火) 07:38:31.48

>>73
世の中のOSからウィンドウシステムが消えそうだな

78 ：デフォルトの名無しさん：2012/03/13(火) 08:56:09.17

>>72 おまえの脳味噌が迷信、というのが正しいよ。

79 ：デフォルトの名無しさん：2012/03/13(火) 09:32:13.57

>>72 に脳味噌があるなんて迷信だった

80 ：デフォルトの名無しさん：2012/03/13(火) 12:30:27.63

>>77
ウィンドウハンドラなんて概念を持ってるくらいだし、あれはオブジェクト指向じゃない。

81 ：デフォルトの名無しさん：2012/03/13(火) 12:43:27.97

ハンドラ持つとオブジェクトじゃない！入りました～

82 ：デフォルトの名無しさん：2012/03/13(火) 13:46:57.43

ウインドウ "メッセージ" ハンドラな
ちまたにあふれるニセooよりよほど忠実

83 ：デフォルトの名無しさん：2012/03/13(火) 14:11:05.31

ちまたにあるれるニセoo
って例えば何だよ

84 ：デフォルトの名無しさん：2012/03/13(火) 15:11:22.82

private:
public:

こんなやつ

85 ：デフォルトの名無しさん：2012/03/13(火) 16:42:17.86

bless

86 ：デフォルトの名無しさん：2012/03/13(火) 16:45:57.51

Perl6のキャメルブックまだー？

87 ：デフォルトの名無しさん：2012/03/13(火) 23:39:21.05

言語とか環境によるかもしれないけど
ファイルアクセスもオブジェクト指向に近い

88 ：デフォルトの名無しさん：2012/03/14(水) 06:37:45.40

ファイルへのアクセスは
シェルスクリプトやバッチファイルでは非OOP的だけど
大半のプログラミング言語はOOP的なところあるよね

89 ：デフォルトの名無しさん：2012/03/14(水) 08:00:50.66

様々な対象をファイルとして抽象化するのが
極めてオブジェクト指向的

90 ：デフォルトの名無しさん：2012/03/14(水) 08:48:58.89

そもそもファイルをファイルとして扱うのがオブジェクト指向的じゃない

91 ：デフォルトの名無しさん：2012/03/14(水) 09:52:24.06

>>89-90
どっちだよw

92 ：デフォルトの名無しさん：2012/03/14(水) 11:45:19.60

ストリームならＯＫなん？

93 ：デフォルトの名無しさん：2012/03/14(水) 11:55:18.71

ストリームでファイルでもオブジェクト指向的に扱うことは可能。
ストリームやファイルそのものがオブジェクト指向かどうかは関係ない。
Cのファイル操作関数は非オブジェクト指向、
Javaだとストリームはオブジェクト、ファイルもオブジェクトっぽく扱える。
しかし読み込みなどのやり方がいかにもな手続き型。

94 ：デフォルトの名無しさん：2012/03/14(水) 13:53:29.34

?
fopenでインスタンス生成
以後生成したインスタンスを渡してサービスを呼び出す
オブジェクト指向だと思うが

95 ：デフォルトの名無しさん：2012/03/14(水) 20:00:22.35

fopenっていうかその先のOSのシステムコールの中身が
関数ポインタ+構造体でまんまオブジェクト指向な作りになってるよ

96 ：デフォルトの名無しさん：2012/03/14(水) 21:19:22.61

fopenとpopenで同じ関数が使えるところは多態だよな

97 ：デフォルトの名無しさん：2012/03/15(木) 00:20:03.53

多態と言えばstdoutだろやっぱ
コンソール出力とファイル出力とパイプ出力なんて全く別のものなのに

98 ：デフォルトの名無しさん：2012/03/15(木) 00:52:28.84

インターフェースの標準化、抽象化が目指すのは多態ではあるが、オブジェクト指向では無い。

99 ：デフォルトの名無しさん：2012/03/15(木) 01:07:28.02

理由を示すことはできないが、オブジェクト指向では無い。

100 ：デフォルトの名無しさん：2012/03/15(木) 07:19:53.21

>>97 stdout はファイルデスクリプタを指定して write(2) を叩いてるだけ。
ファイルデスクリプタと write(2) の実装が >>95 のようになっている。

これを、オブジェクト指向的でない、と言う奴はバカだと思っていい。

101 ：デフォルトの名無しさん：2012/03/15(木) 07:48:41.80

「これ」ってのはどれのことか。
オブジェクト指向で書かれたコードを呼び出しているだけの奴は
オブジェクト指向とは限らないよな。

102 ：デフォルトの名無しさん：2012/03/15(木) 10:51:14.91

お勧めのオブジェクト指向設計の本ある？

103 ：デフォルトの名無しさん：2012/03/15(木) 10:53:22.17

今時無理に設計から入らず、パターンが使えそうならパターンを使う、
って感じで使ってみたほうがいいんじゃね？

104 ：デフォルトの名無しさん：2012/03/15(木) 18:15:47.70

>>100
クラスに似てるだけじゃん

105 ：デフォルトの名無しさん：2012/03/15(木) 18:20:28.06

クラス？？

106 ：デフォルトの名無しさん：2012/03/15(木) 19:01:19.66

クラスベースのオブジェクト指向っぽいものを実装するときのvtblにそっくりなだけで、
それはオブジェクト指向じゃない、と言いたいのだろう。

107 ：デフォルトの名無しさん：2012/03/15(木) 19:13:58.73

新しいインスタンスを作って再利用できなきゃだめって言いたいのかな

108 ：デフォルトの名無しさん：2012/03/15(木) 19:16:38.19

OOPLとOOPの違いがわかってないな

109 ：デフォルトの名無しさん：2012/03/15(木) 19:23:44.67

抽象化とか、分割統治の原則とかは、オブジェクト指向に固有のもんじゃない、
という指摘は当たってるけども、staticおじさんはそもそも抽象化も分割統治の原則も
わかってないよなw

110 ：デフォルトの名無しさん：2012/03/15(木) 19:26:41.67

それはともかく大阪場所がけっこうおもしろいな

111 ：デフォルトの名無しさん：2012/03/16(金) 08:06:00.44

staticおじさんてのは>>6 に書いてある人だよな。このスレに来てるの？

112 ：デフォルトの名無しさん：2012/03/16(金) 09:30:41.61

6はフィクションですよ

113 ：デフォルトの名無しさん：2012/03/16(金) 17:23:34.57

>>111
staticおじさんは「気分はstatic！」の筆者のあだ名です。
下記記事が>>6のネタ元でしょう。

実はオブジェクト指向ってしっくりこないんです！
http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html
>メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい
→「staticを使えば、わざわざインスタンスを作る必要などない」

>Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。
→「独自にクラスを作る必要などない。クラスは使うものだ。作るものではない」

>非常に失礼なのですが、あなたは九州大学農学部卒という経歴で、
>何か私に対しひがみを感じているのではないのすか？
>私は学部は東北大学で大学院が東工大です。
→「あなたの出身校はどこだ？私はT大学大学院卒だ」

>私はIS部門の人間なんです。SIerの客なんですよ。
>私に嫌われたらどうなりますか？皆さん生きていけないですよ！
→「あなたはSIerだろう。私は客側の人間だ。客の言うことは絶対だ」

114 ：デフォルトの名無しさん：2012/03/18(日) 23:11:51.79

これはこれはご親切にどうも。

115 ：デフォルトの名無しさん：2012/03/20(火) 12:05:33.42

>>102
無いんだな、それが。
どの入門本を手にとてってもなんかピンとこない。

116 ：デフォルトの名無しさん：2012/03/20(火) 12:37:01.61

オブジェクト指向のこころ

117 ：デフォルトの名無しさん：2012/03/20(火) 12:37:40.59

俺はこれおすすめ
トランプゲームをまず手続き型で実装して、次にオブジェクト指向設計で実装する。
例多いし、実際に手を動かしてくから超身にしみる

なぜ、あなたはJavaでオブジェクト指向開発ができないのか―Javaの壁を克服する実践トレーニング
ttp://www.amazon.co.jp/dp/477412222X

118 ：デフォルトの名無しさん：2012/03/21(水) 14:11:43.45

オブジェクト指向なんて時代によって解釈が変わる
とりあえず予備知識なしで言語を学ぶほうがいい

119 ：デフォルトの名無しさん：2012/03/21(水) 20:07:29.44

いや、クイズじゃないし
理念を理解せずに知識の寄せ集めをしろうといかのー！！

120 ：デフォルトの名無しさん：2012/03/21(水) 20:13:33.50

理念とか知識とかいらんから。

ツールとして使えて便利であれば十分。

121 ：デフォルトの名無しさん：2012/03/21(水) 20:26:46.92

なにも知らずに便利に使えるといいけどね

122 ：デフォルトの名無しさん：2012/03/21(水) 21:16:44.74

わんわんにゃーにゃーなんて不要だろ

123 ：デフォルトの名無しさん：2012/03/21(水) 21:19:43.61

>>122
入門書の動物の例えは要らないって意味なら同意

124 ：デフォルトの名無しさん：2012/03/21(水) 22:07:41.32

批難ばっかりしてないで代案を出すべき

125 ：デフォルトの名無しさん：2012/03/21(水) 22:12:46.78

いらないって言ってるのに代案ってあーた何をおっしゃる

いらないからなくせばいいんだよ

126 ：デフォルトの名無しさん：2012/03/21(水) 22:22:07.78

はぁ？
馬鹿じゃん
著者だって好きでにゃんにゃん言ってるわけじゃねーぞ
継承の説明がしたくてにゃんにゃん言ってたんだろが
したらお前等でもっといい説明のしかたを出さなきゃダメだろが
まー、クズがレスつけちゃうよりかはいい解決方法がうかんじゃうかもね

127 ：デフォルトの名無しさん：2012/03/21(水) 22:22:35.86

Personの山田で

128 ：デフォルトの名無しさん：2012/03/21(水) 22:23:33.37

>>126
いらないから無くせ

129 ：デフォルトの名無しさん：2012/03/21(水) 22:24:40.51

現場の実例を出せば良いんだと思うの

130 ：デフォルトの名無しさん：2012/03/21(水) 22:24:53.72

>>128
自分の好きなようにしたいなら御自分で本でも書いたらいーんじゃないですか？

131 ：デフォルトの名無しさん：2012/03/22(木) 00:06:46.67

非ＯＯＰで苦しんだ経験がないとＯＯＰの有り難味は解らんよ。
もちろんこれはプログラマだけの特権だ。

132 ：デフォルトの名無しさん：2012/03/22(木) 00:07:27.86

>>120
そうそうgotoとか便利だからねー
グローバル変数も使いたいときにいつでも使えるから便利だし

133 ：デフォルトの名無しさん：2012/03/22(木) 00:10:11.50

でもぶっちゃけ継承はいらねーよな

134 ：デフォルトの名無しさん：2012/03/22(木) 00:18:00.74

要らないとまでは思わんが
現状では第二のGOTOになりかねん気もする

135 ：デフォルトの名無しさん：2012/03/22(木) 00:19:13.83

GOTO>>134

136 ：デフォルトの名無しさん：2012/03/22(木) 00:20:51.41

そんなのクラスブラウザのない間抜けな処理系だけの話じゃん

137 ：デフォルトの名無しさん：2012/03/22(木) 01:51:26.57

>>136
kwsk

138 ：デフォルトの名無しさん：2012/03/22(木) 04:35:00.47

第2のgotoといったら多重継承じゃなかろうか。

139 ：デフォルトの名無しさん：2012/03/22(木) 10:12:10.04

>>133
ベンダー提供のもんを使うときは便利だと思うけど
自社で継承なんてさせないほうがいいよね

140 ：デフォルトの名無しさん：2012/03/22(木) 14:09:37.70

プログラムって、建築物とよく似てるから、
現存してる建築物で古くても現在も不便なく
しっかり使われてる建築物の設計思想を参考に
するといいとおもう。

141 ：デフォルトの名無しさん：2012/03/22(木) 14:16:50.99

サグラダファミリアはデスマの元祖

142 ：デフォルトの名無しさん：2012/03/22(木) 15:52:48.71

最初からスケジュールもへったくれもない構想だからなぁ

143 ：デフォルトの名無しさん：2012/03/22(木) 15:57:35.96

プログラミングはまだ歴史が浅い
設計思想は根本的に進化し続けている
藁葺き屋根にも風情があっていいとは思うけどね

144 ：デフォルトの名無しさん：2012/03/22(木) 17:07:37.03

家内制手工業から工場制手工業へ

145 ：デフォルトの名無しさん：2012/03/22(木) 20:50:12.65

>>141
むしろ永遠にああでもないこうでもないと
いじくることが許されたプログラマの天国だろ

146 ：デフォルトの名無しさん：2012/03/22(木) 21:02:54.54

>>145
元祖オプソと考えたほうがいいのか

147 ：デフォルトの名無しさん：2012/03/22(木) 21:03:25.75

>>140
「最も美しいプログラミング言語は？」からコピペ

　156 名前: デフォルトの名無しさん Mail: sage 投稿日: 2009/10/10(土) 20:03:39
　>>153

　ソフトウェアの研究というのは、おそらく「ソフトウェア工学」を意味してる。
　それでは工学とは何か？だけど、土木/建築の分野では、数学を基礎とする理論に
　基づいて設計が行われ、想定された状況下では絶対に崩壊しない設計値が算出できる。
　それらは、いわゆる土木工学/建築工学と呼ばれている。

　ではソフトウェアの分野ではどうか？現状は、未だに個人の能力に依存している。
　言い換えると、プロジェクトの成功/失敗は、職人の「技能/技法」に頼っており、
　とても「工学」と呼べる代物ではない。この問題を何とか打開しようとする試みが
　ソフトウェアの研究(狭義のソフトウェア工学)である。

　以下は、C.A.R. ホーアの論文「プログラミング - 魔術か科学か？」からの引用。
　全文は以下の書籍(論文集)を参照。
　・IEEE ソフトウェア '88, IEEEソフトウェア編集委員会編, 岩波書店

　　職業としてプログラミング業務を行うためには、基礎となる数学理論に基づき、
　　すでに確立された他の工学分野の先例にならわなければならない。
　　これは教育を改善することによって実現することができる。

　土木/建築工学の分野には様式(アーキテクチャ)という概念があり、その「美しさ」も
　評価の観点の一部である。同様に、ソフトウェア工学の分野であっても、
　プログラミング言語のアーキテクチャ(手続き型/関数型/論理型/代数型)を評価したり、
　それらの「美しさ」を評価の観点として考えることは、決して間違いではないと考える。

148 ：デフォルトの名無しさん：2012/03/22(木) 21:08:15.00

何か言ってるようで何も言ってなかった

149 ：デフォルトの名無しさん：2012/03/22(木) 21:10:41.61

教養がないことを自慢する奴は痛いな

150 ：デフォルトの名無しさん：2012/03/22(木) 21:12:00.86

建築工学 ⇔ 実際の土方の施工
ソフトウェア工学 ⇔ 実際のIT土方の施工

というだけの話だな
どちらも現場で上手くいったり駄目だったりするという

151 ：デフォルトの名無しさん：2012/03/22(木) 21:19:15.87

まあプログラミングのほうは設計するのもIT土方という致命的欠点はあるわな

152 ：デフォルトの名無しさん：2012/03/22(木) 21:21:34.06

作ろうとするものが東京タワー並のデカさでも平然と作れると思ってしまう恐ろしさよ

153 ：デフォルトの名無しさん：2012/03/22(木) 21:49:42.05

つまりソフトの複雑さを「高さ」に換算して
建築基準法の高さ制限に引っかかることにすればいいんだ

154 ：デフォルトの名無しさん：2012/03/22(木) 21:51:20.52

また行数数えるのかよｗ

155 ：デフォルトの名無しさん：2012/03/22(木) 22:05:27.55

まずその前に「ソフトの複雑さ」というモノを
(建築工学と同様に)「定量化」できる一般的方法論が必要になるね
それはいわゆる「ソフトの見積もり」という
(ソフトウェア工学における)歴史的に難解な問題を問うことから始めないことには....

156 ：デフォルトの名無しさん：2012/03/22(木) 22:40:46.68

プログラミングが他の業種と違うのは
同じ物を作らないという所なんだよな。

157 ：デフォルトの名無しさん：2012/03/22(木) 22:45:15.19

まったく同じじゃなくても似たようなものはしょっちゅう作ってるんだから
こういうサンプルケースだとこれぐらいお金がかかりますよって業界共通の
価格表を公表すりゃいいのにとは思う。

158 ：デフォルトの名無しさん：2012/03/22(木) 22:47:15.69

「なんだそのサンプルソースは。もうできてるということだな。ただで寄越せ」

159 ：デフォルトの名無しさん：2012/03/22(木) 22:51:58.73

>>157
そこもこの業界が特殊なところだな。
サンプルケースを作ってしまったら、
その後はコピーすればいいから
サンプルケースを一回目に作る金と
二回目以降で無限の違いが出てくる。

160 ：デフォルトの名無しさん：2012/03/22(木) 22:54:23.62

うん。プログラマを土方とか例えるけど、
それ全然わかってないんだよね。

プログラマが作ってるのは土木作業を
自動的に行うロボット。

161 ：デフォルトの名無しさん：2012/03/22(木) 22:56:26.97

実際ロボット作ってるのはドカタだろうし、
パッケージ販売だって普通にやってる。

162 ：デフォルトの名無しさん：2012/03/22(木) 23:03:29.95

>>161
作ってるのはロボットではなく、
ロボットの設計図。

設計図＝ソースコードを書けば
あとは自動でロボットが作られる。

163 ：デフォルトの名無しさん：2012/03/22(木) 23:08:18.20

Aというものを作るのに1時間かかりました。

Aと全く同じ物を作るのに、コピーして一瞬で終わりました。

Aと少し違うだけのBを作るのには数分で終わります。

AとBに少しだけ違うC、D、E、Fがあります。Aを作る時間＋αですべてが作れます。

こんなことが出来る業界、他にあるのか？

164 ：デフォルトの名無しさん：2012/03/22(木) 23:14:29.75

>>163
>Aと少し違うだけのBを作るのには数分で終わります
>AとBに少しだけ違うC、D、E、Fがあります。Aを作る時間＋αですべてが作れます。

本当にそれらが現実であれば、いわゆる「ソフトウェア工学」は生まれなかったんだろな....

165 ：デフォルトの名無しさん：2012/03/22(木) 23:23:31.72

ソフトウェアを実行する為にはサーバが必要
そのサーバは一瞬で作れるわけじゃないよ

166 ：デフォルトの名無しさん：2012/03/22(木) 23:26:27.41

>>165
ハードウェアの話はすれ違い。
ソフトウェアならディスクコピーすれば終わり。

167 ：デフォルトの名無しさん：2012/03/22(木) 23:37:55.46

>>163
コンテンツ産業全般

168 ：デフォルトの名無しさん：2012/03/22(木) 23:39:48.88

>>167
例えば？
映画もゲームも音楽も当てはまらないと思うが？

169 ：デフォルトの名無しさん：2012/03/22(木) 23:53:18.89

>>168
>>163ってデジタルデータならなんでもそうじゃん。

デジタルでなくともコピー機があれば書類のコピーは一瞬。（「一瞬」を定義したけりゃどうぞ）
音楽やゲームはCDをプレスするだけ。
何か問題でも？

170 ：デフォルトの名無しさん：2012/03/22(木) 23:53:44.05

>>166
ドカタやロボットっていうハードウェアの話してたのにいきなり手のひら返すなよｗｗｗ

171 ：169：2012/03/22(木) 23:55:33.94

>>音楽やゲームは
デジタルでした^^（てへぺろ）

172 ：デフォルトの名無しさん：2012/03/23(金) 00:10:02.87

>>168
音楽なんかはリミックス盤とか有名なDJミックスとかオリジナルの録音からいろいろ派生があるね
映画もディレクターズカットとか出たりする

173 ：デフォルトの名無しさん：2012/03/23(金) 00:26:57.63

OOAとOOD

174 ：デフォルトの名無しさん：2012/03/23(金) 01:12:50.47

劣化しないコピーができる産業はみんな食う側が割を食ってると感じているようです。

175 ：デフォルトの名無しさん：2012/03/23(金) 02:33:00.89

つまりだ、プログラミングというのは
作曲と同じというわけ。

生産業とは全く違う考えをしないといけないんだよ。

176 ：デフォルトの名無しさん：2012/03/23(金) 02:38:01.51

システムはひとつの作品。

いくらたくさん人を集めたからといって
ある程度までしか製作速度が上がらないの所も
映画なんかと似ているよな。

177 ：デフォルトの名無しさん：2012/03/23(金) 09:31:36.35

下っ端は文句は言うけど作業しか能力ないっていうのも同じだね

178 ：デフォルトの名無しさん：2012/03/23(金) 10:34:13.16

コンテンツ指向からオブジェクト指向へ

179 ：デフォルトの名無しさん：2012/03/23(金) 13:50:41.50

プログラムで、一番コストになるのは、"時間"。

つまりいかに短期間に制作できるか、時間を節約できるかが
理想的な、設計思考といえる。

プログラムで一番時間を奪ってるのは、
設計を考えるのでも、スパゲティソースの修正でもない。

記述が１文字でもつづりが間違ってると動かなくなる仕様。

厳密にルールに沿ったテキストを書かなければならないわりには、
それを書くのは機械的にではなく、かなりアナログな手書き。
支援するツールこそあれど、最終的には人間が
テキストをちまちま作成していく。

べつにもっと、直感的にドラッグドロップ感覚で積み木を積み上げるように
作れてもいいんじゃないかと思う。
どうせ、最終的に出力されるのは厳密なルールに沿ったテキストなんだから。

180 ：デフォルトの名無しさん：2012/03/23(金) 14:05:58.04

と最底辺コーダーが申しております

181 ：デフォルトの名無しさん：2012/03/23(金) 14:39:27.01

プログラミングはオブジェクト指向以外あり得ない、は本当に正しいのか？
というスレタイなら賛同していた。
オブジェクト指向の有用性はもはや議論する段階は過ぎてる。
間違いなく正しいものと言える。正しく使えない人間が悪い。

182 ：デフォルトの名無しさん：2012/03/23(金) 14:44:25.64

>>179
Delphi使えばいいじゃん

183 ：デフォルトの名無しさん：2012/03/23(金) 14:45:28.98

>>182
そこはsmalltalkだろ

184 ：デフォルトの名無しさん：2012/03/23(金) 18:22:29.80

十数年前の話だがボーランドはＲＡＤに関しては光ってたな。その後登場したVisualナントカと比べても良かった。

185 ：デフォルトの名無しさん：2012/03/23(金) 20:48:51.06

Delphi (デルファイ)

186 ：デフォルトの名無しさん：2012/03/23(金) 20:55:30.12

1位 Java
3位 C#
4位 C++
5位 Objective-C
9位 Python
11位 Delphi / Object Pascal
13位 Ruby

TIOBE Programming Community Index for March 2012
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

187 ：デフォルトの名無しさん：2012/03/23(金) 20:56:44.14

7位 Visual Basic

188 ：デフォルトの名無しさん：2012/03/24(土) 00:03:04.66

>>186
飛び飛びに書いた理由を聞きたいんだが。

1 1 Java 17.110% -2.60% A
2 2 C 17.087% +1.82% A
3 4 C# 8.244% +1.03% A
4 3 C++ 8.047% -0.71% A
5 8 Objective-C 7.737% +4.22% A
6 5 PHP 5.555% -1.01% A
7 7 (Visual) Basic 4.369% -0.34% A
8 10 JavaScript 3.386% +1.52% A
9 6 Python 3.291% -2.45% A
10 9 Perl 2.703% +0.73% A
11 13 Delphi/Object Pascal 1.727% +0.73% A
12 30 PL/SQL 1.418% +1.01% A
13 11 Ruby 1.413% -0.09% A
14 23 Transact-SQL 0.925% +0.38% A
15 15 Lisp 0.922% -0.01% A
16 22 Visual Basic .NET 0.784% +0.22% A-
17 18 Pascal 0.771% +0.07% A
18 32 Logo 0.717% +0.31% A--
19 17 Ada 0.633% -0.09% B
20 19 NXT-G 0.604% -0.04% B

189 ：デフォルトの名無しさん：2012/03/24(土) 05:15:47.00

Objective-Cがこんなに順位が高いとは俄に信じがたいな
マカーのおれでさえそう思う

190 ：デフォルトの名無しさん：2012/03/24(土) 07:59:57.86

JavaがPHPより上にいる理由を考えた事があるなら
そんなに驚かないはず

191 ：デフォルトの名無しさん：2012/03/24(土) 13:54:45.11

業界人以外も使っている、Objective-C☆

192 ：デフォルトの名無しさん：2012/03/24(土) 15:07:24.49

金になるかならないか、それが重要って事だな

193 ：デフォルトの名無しさん：2012/03/24(土) 21:01:24.35

え？つまり上位にある言語の方が
金になるってこと？

194 ：デフォルトの名無しさん：2012/03/24(土) 21:05:11.19

１０位以下は金にならない。

195 ：デフォルトの名無しさん：2012/03/24(土) 22:28:06.05

一番小銭を稼げるのはPHP
Javaなんてアンドロイドがなかったら死滅してた
C#の技術はどこで換金できるんだ？そろそろVB6と入れ替わったのか？

196 ：デフォルトの名無しさん：2012/03/24(土) 22:30:32.35

そいつが生きてる世界が
よくもわるくも露呈するな

197 ：デフォルトの名無しさん：2012/03/24(土) 22:31:01.06

JavaもC#もスマフォは最近で、メインは鯖だろ

198 ：デフォルトの名無しさん：2012/03/25(日) 14:39:40.27

アンドロイドなんて稼げる額小銭程度だろうが
Javaで一番金稼げる分野は基幹系だよ

199 ：デフォルトの名無しさん：2012/03/25(日) 14:42:16.92

全体として大きな金が動くのと
プログラマ一人当りに入る金額の大小は
分けて考えないとね

200 ：デフォルトの名無しさん：2012/03/25(日) 14:49:18.79

>>199
?
>>188のランキングに貢献するのはどっちだい?

201 ：デフォルトの名無しさん：2012/03/25(日) 14:52:39.02

そりゃ前者だろう

202 ：デフォルトの名無しさん：2012/03/25(日) 15:02:14.32

後者じゃね？

203 ：デフォルトの名無しさん：2012/03/25(日) 15:28:02.74

そもそも金になるかどうかのランキングなのか？

204 ：デフォルトの名無しさん：2012/03/25(日) 15:50:38.68

金にならないものをわざわざ調査するか？
「プログラミングが趣味です」何てやつはクラスに一人か二人程度だっただろ。

205 ：デフォルトの名無しさん：2012/03/25(日) 17:27:32.99

Javaプログラマは大量に居るので単価が安い
この事実とランキングをどう結びつけるかだね

206 ：デフォルトの名無しさん：2012/03/25(日) 17:29:15.76

プログラマが少ないからって単価が高いわけじゃないぞ。
ユーザーが金だすのは言語に対してじゃなくて、
作ったものに対してだからね。

207 ：デフォルトの名無しさん：2012/03/25(日) 17:31:28.07

そりゃそうだ
だから一人当たりの単価とランキングは連動してないと考えるべき

208 ：デフォルトの名無しさん：2012/03/25(日) 17:34:36.70

>>204
お前の思い込みなど誰も聞いてない。
金になるかどうかのランキングだというなら、
>>186リンク先のどこにそれが書いてあるのか示してくれ。

209 ：デフォルトの名無しさん：2012/03/25(日) 18:32:16.64

>>186のランキングがどう集計されたかくらい、リンク先読めばわかるだろ。。

210 ：デフォルトの名無しさん：2012/03/25(日) 18:53:09.45

>>204
中学の時で5人、高校の時で3人いたわ
高校は工業高校だったからわかるけど中学は異常にプログラミングが流行ってた

211 ：デフォルトの名無しさん：2012/03/25(日) 18:54:05.14

>>186のリンク先を見ると、
金になるかどうかを表す指標とはずいぶん外れているようだが。

212 ：デフォルトの名無しさん：2012/03/25(日) 18:57:30.08

そもそも金になるとはどういう事なのか？

213 ：デフォルトの名無しさん：2012/03/25(日) 19:00:54.42

金になるかどうかを表すランキングなんて作りようがないと思ったから
>>203の質問をしたんだが、答えが一向に返ってこない。

214 ：デフォルトの名無しさん：2012/03/25(日) 19:11:09.20

>>186
リンク先のページに集計方法を説明したページへのリンクがあります。
ある言語の順位は、その言語について書いたページ数で決まります。
要点を翻訳します。

TIOBEプログラミングコミュニティ順位定義
http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm
>TIOBE順位の決め方について質問がたくさんくるので特別ページでしっかり定義するぞ。
>●プログラミング言語の基準
>・Wikipediaに項目があり、プログラミング言語だと書かれている事
>・チューリング完全である事
>●格付け方法
>有名検索エンジンでヒットした件数を数えて計算する。
>検索に使うのは"<言語名> programming"だ。
>基準を満たす以下の検索エンジンを使っている。
>・Google: 　 30%
>・Blogger: 　30%
>・Wikipedia: 15%
>・YouTube:　 9%
>・Baidu: 　　 6%
>・Yahoo!:　　 3%
>・Bing: 　　　3%
>・Amazon:　　3%

215 ：デフォルトの名無しさん：2012/03/25(日) 19:19:57.81

金になるかどうかを表すどころか、金とは全然関係ない集計方法だよな。

216 ：デフォルトの名無しさん：2012/03/25(日) 19:48:11.69

検索回数じゃなかったのか　ずっと騙されてたわ

まあそれでも「金になりそう」に近い順位だな

217 ：デフォルトの名無しさん：2012/03/25(日) 20:21:27.89

>>213
英語くらい読めるようになろうよ。。

218 ：デフォルトの名無しさん：2012/03/25(日) 20:25:15.11

>>217
読んだ英語が、金とはおよそ関係ないはなしだったから根拠を示せといったんだよ。。

219 ：デフォルトの名無しさん：2012/03/25(日) 20:26:58.82

なんだ金(キム)の話か

220 ：デフォルトの名無しさん：2012/03/25(日) 20:32:41.86

キムクラスは最近継承したな。

221 ：デフォルトの名無しさん：2012/03/25(日) 21:01:57.69

>>218

根拠って程じゃないけど、上位10位以内にある言語は、どれも鯖・デスクトップ・組込み・スマフォの各分野でデファクトスタンダードの地位にあるものばかりだな。と思った
どの分野も、金になる分野

VBだけは、金になるというより、社内ツール用言語としての地位が確立してるからだと思うけど

222 ：デフォルトの名無しさん：2012/03/26(月) 03:13:36.88

>>221
英語を読めてないって書き込みに対する反省はないのかよ

223 ：デフォルトの名無しさん：2012/03/26(月) 03:34:30.19

この期に及んで感想とかどうかしてる
英語で書いてあるだろうに

224 ：デフォルトの名無しさん：2012/03/26(月) 12:25:40.56

感想だったら別にこの期に及んでなくね?

225 ：デフォルトの名無しさん：2012/03/26(月) 21:55:29.29

激論を交わしているところ悪いんだが、
>188のランキングってこのスレ的にどういう意味があるの？

226 ：デフォルトの名無しさん：2012/03/26(月) 22:03:45.75

暇潰しのためのネタ
Matzが脱いだとかGuido激怒とかPythonのMLでPerl開発者大暴れとかそんなのでもぜんぜん

227 ：デフォルトの名無しさん：2012/03/26(月) 22:54:25.10

>>225
>>186は上位のオブジェクト指向言語を抜粋しているから
英語圏でオブジェクト指向言語が廃れる気配がないと言いたいのでは？

228 ：デフォルトの名無しさん：2012/03/26(月) 22:57:39.77

NXT-Gって何だ？どんな所で使われてんの？初めて聞いたよ。

229 ：デフォルトの名無しさん：2012/03/26(月) 23:49:27.00

nxtというとあのa=a++のあれか

230 ：デフォルトの名無しさん：2012/03/27(火) 08:42:40.23

nxtは、ンクストって読めばいいのかな？

231 ：デフォルトの名無しさん：2012/03/28(水) 14:07:03.28

>>228
レゴブロックが発売しているロボットおもちゃ用
GUIプログラミング
http://www.brickshelf.com/gallery/brdavis/NXT/NXT-G/remote.png

232 ：デフォルトの名無しさん：2012/03/28(水) 19:15:24.19

>>231
こんなのがそんなに普及してるのか！！

233 ：デフォルトの名無しさん：2012/03/28(水) 19:16:45.23

普及度じゃなくて
「人に教えたくなる」ってことだろ

234 ：デフォルトの名無しさん：2012/03/28(水) 19:17:40.50

プロトタイプ作るときにはレゴってのはこの業界の定番。

235 ：デフォルトの名無しさん：2012/04/23(月) 13:00:52.22

>>231
わかりにくい

236 ：デフォルトの名無しさん：2012/04/23(月) 13:16:41.86

でも仕事なんだから、自分の理解出来ない勢力を抑えようとするのは当たり前。
お前らもじきにそうする。それをどうこうするのは経営の仕事。

237 ：デフォルトの名無しさん：2012/04/24(火) 05:50:21.86

つまり、事業継続が不可能な方向に経営を向けるのが当たり前、だと？

そんなバカがどこにいる。

238 ：デフォルトの名無しさん：2012/04/24(火) 09:54:53.43

あれそのstatic氏は経営側なの？

239 ：デフォルトの名無しさん：2012/04/25(水) 12:39:47.61

れごじゃないが！
ttp://www.jst.go.jp/pr/info/info877/

240 ：デフォルトの名無しさん：2012/04/26(木) 00:03:43.84

前スレ
http://toro.2ch.net/test/read.cgi/tech/1327414519/

このスレはオーバーライドされました

241 ：デフォルトの名無しさん：2012/04/26(木) 16:20:27.97

前スレで多態が流行った
このスレでは何が流行んの

242 ：デフォルトの名無しさん：2012/04/26(木) 20:17:19.94

MCV

243 ：デフォルトの名無しさん：2012/04/26(木) 20:19:01.30

貧血か

244 ：ネタレスの名無しさん：2012/04/26(木) 20:26:59.57

■アンチスレ
オブジェクト指向に弊害はない。メリットのみ
http://toro.2ch.net/test/read.cgi/tech/1335361193/

245 ：デフォルトの名無しさん：2012/04/26(木) 21:15:10.57

正しいとか正しくないとか　ｗ　そもそもスレタイがナンセンス。

246 ：デフォルトの名無しさん：2012/04/27(金) 08:50:37.97

おかしなスレタイ=隔離スレ。

247 ：デフォルトの名無しさん：2012/04/29(日) 13:05:52.33

http://d.hatena.ne.jp/asakichy/touch/20090712/1247352722
の
「いくつもの層を経由してオブジェクトインスタンスを渡すのが面倒だったり困難だったりする場合には、設計が複雑になる」
が解決出来ずにオブジェクト指向に疑問が起こる。
グローバル変数をオブジェクト指向的に上手く使うデザインパターンなんかないのかな。

248 ：デフォルトの名無しさん：2012/04/29(日) 13:36:20.81

>>247
DIを使えば良いだけ。

249 ：デフォルトの名無しさん：2012/04/29(日) 13:37:59.79

>>248
どうもです聞いた事ありますやっぱそれですか。学んでみます。

250 ：デフォルトの名無しさん：2012/04/29(日) 13:38:02.24

D...Do It

251 ：デフォルトの名無しさん：2012/04/29(日) 13:53:51.53

それで納得していいのかどうか

Singleton使わずにインライン化しようぜ
→でもインライン化さるとレイヤーまたぎで複雑になるけどね

が発端なのにDIが解でいいのかね

252 ：デフォルトの名無しさん：2012/04/29(日) 14:08:23.81

良いわけないじゃん
アホなんだよDI使えば良いだけとか言ってる奴は
問題意識を理解出来てない

253 ：デフォルトの名無しさん：2012/04/29(日) 14:19:45.51

>>251
DI使えば層なんて関係なく
直接インジェクション出来るじゃん。

もともとシングルトンなんだよ？
DIコンテナが生成しても問題無いだろ。

254 ：247：2012/04/29(日) 14:33:32.83

http://d.hatena.ne.jp/unageanu/touch/20070805/1186317201
ですよね。まだ理解出来てませんが。

255 ：uy：2012/04/29(日) 16:11:45.01

オブジェクト指向って、効率いいよ
今の人間の頭の平均的スペックにとって、オブジェクト指向こそが一番ちょうど良い

ただ人間の頭のスペックが高まれば、
たとえば現在のネームスペースの中にいくつオブジェクトがあっても混乱しなくなったり、
特殊変数等や再帰等を使いまくっても、混乱せずにソースコードをかけるレベルのやつばかりになれば
オブジェクト指向など勝手に廃れる

forでかくより再帰とかでかいたほうがコード量が少ない＝タイプ量が少ないんだ

再帰が使えるのはループ構文だけじゃない、
if{
　if{
　　if{ } } }
こういう場所だって、再帰でのコード圧縮は可能

つまり何がいいたいかというと、オブジェクト指向（笑）でクラスいっぱい定義するよね
それらは、再帰でのコードで圧縮が可能だという事
それができればクラス（笑）なんて宣言は1個でいい、つまり、処理系側に最初から1個クラスを定義しとけばいい、
つまり、プログラマがクラス（笑）なんてものを宣言する事はなくなる

でも誰もやらないよ、そこに至ってもやらないだろう、今の人間の平均的な思考能力では使いこなせない
使いこなせるやつばかりが集まれば、何か変わるかもしれない

256 ：デフォルトの名無しさん：2012/04/29(日) 16:15:41.25

…と意気揚々とstack overflowを乱発する>>255であった

257 ：uy：2012/04/29(日) 16:18:19.24

結局OOになってしまうんだよ
世界の平均的な人間が使える設計思想はそれしかない

もっと優れている設計思想など無限にあるさｗ

ただ、人が使いこなせないってだけ

おｋ？？？？？？？？？？？？？？

258 ：uy：2012/04/29(日) 16:21:08.08

かのソースコードの前に立った時、
人は人の無力を知る

259 ：デフォルトの名無しさん：2012/04/29(日) 16:21:34.56

何が結局なのか
>>255での謎な自説展開をみるに
OOマンセーに見せかけたネガキャンとみた

260 ：デフォルトの名無しさん：2012/04/29(日) 16:28:58.11

ヒント uy でググれ

261 ：デフォルトの名無しさん：2012/04/29(日) 16:31:32.54

なんだ糞コテか

262 ：デフォルトの名無しさん：2012/04/29(日) 16:56:52.42

>>258
＞かのソースコードの前に
何？

263 ：デフォルトの名無しさん：2012/04/29(日) 17:06:49.59

だから蚊だよ

264 ：uy：2012/04/29(日) 18:14:26.00

そうやって悩み続けるがいい

力なき者は力ある者よりも余分に勉強し、
余分に知識をつけなければついてはこれない

265 ：デフォルトの名無しさん：2012/04/29(日) 18:28:34.94

エサやるな

266 ：デフォルトの名無しさん：2012/04/29(日) 18:35:44.41

え？蚊に？

267 ：デフォルトの名無しさん：2012/04/29(日) 18:50:28.37

専用スレが落ちたせいで出てきちゃってる
http://logsoku.com/thread/kohada.2ch.net/prog/1316933376/

268 ：デフォルトの名無しさん：2012/04/29(日) 20:44:21.51

スルーしろって

269 ：デフォルトの名無しさん：2012/04/30(月) 12:16:01.91

プログラミング言語を覚えることは手段であって目的ではない。

なるべく簡単な言語を使った方がいいです。
大切なのは「難しい言語を使えること」ではなく、「どんな言語を使ってでも、作りたいものを作れること」。

270 ：デフォルトの名無しさん：2012/04/30(月) 12:17:50.62

作りたいものを作るのは
最低条件。

その上で、付加価値をつけないといけない。
質を上げる、短期間で作る、コストを下げる

271 ：デフォルトの名無しさん：2012/04/30(月) 12:27:36.23

よく訊かれる質問、特に、主として C 言語を利用しているプログラマの方からの質問なのですが、
「C# は初入門の言語として適切か」と言うものを受けることがあります。

多いのは、「C 言語 → C++ というように段階を経て学んでいくべきなのではないか」という意見です。
「Java や C# だと、class や static など、最初に説明しないといけない“おまじない”が多いし・・・」とか、
「Java や C# などのオブジェクト指向言語を学ぶにしても、その基本は構造化プログラミング言語だし」というのが、
これらの意見の理由です。

この質問に対する（僕個人の私的な）答えですが、結論から言うと、初めから C# を学ぶ方がいいと思います。

例えば、C 言語なら最初から理解するのが難しい“おまじない”の部分がないかと言うとそんなはずもなく、
#include などはやはり“おまじない”ですし、 Java や C# などの新参の言語は、
構造化プログラミング言語としても見た場合でもかなり優秀な言語です。

むしろ、C 言語など、長い歴史を持つ言語は、昔からの悪習を引きずっていて、
下手に学ぶと悪い癖が付いたまま抜けなくなる危険性の方が高いです。

272 ：デフォルトの名無しさん：2012/04/30(月) 12:37:43.49

>>271
悪い癖が付いて抜けなくなるヤツはどんな言語を習っても悪い癖が付く。

273 ：デフォルトの名無しさん：2012/04/30(月) 12:38:14.78

そういえばC#ってCSではあまり注目されてない気がする

274 ：デフォルトの名無しさん：2012/04/30(月) 12:39:36.29

>>273
CS?

275 ：デフォルトの名無しさん：2012/04/30(月) 12:44:10.15

>>274
Chinese Society

276 ：デフォルトの名無しさん：2012/04/30(月) 12:50:44.39

>>275
つまらない。

277 ：デフォルトの名無しさん：2012/04/30(月) 12:55:54.93

>>269
最初の文と二番目の文は論理的な繋がりがない
それに気づけないのに。。。

278 ：デフォルトの名無しさん：2012/04/30(月) 15:00:13.00

コピペにいちいち反応しないでよ。

279 ：デフォルトの名無しさん：2012/04/30(月) 15:25:20.81

>>181
その使えない人間が多いのが問題だと思うよ
中でも酷いのが中途半端に知ってて車輪の再発明を繰り返す人

280 ：デフォルトの名無しさん：2012/05/01(火) 03:17:16.84

>>279
そうやって馬鹿にするけどお前もやってみたことあるのか？と聞きたい

ライブラリＶの共通パーツＡ、Ｂ、ＣとあってプロジェクトＰ、Ｑ、Ｒで使ってたとするだろ？
プロジェクトＰでパーツＡの不具合の修正が必要になったと
したらライブラリＶを更新するときのプロジェクトＱとＲはどうなんのかと？
これが納品先が別でもＱとＲはコンパイルかけるのかと？
また、納品時のバージョンにしておかなくていいのかと？
ライブラリＶの更新によるＮｅｗＱとＮｅｗＲはどういう位置になるのかと？

そして、開発が進んでくればプロジェクトＰ用のＶ、Ｑ用のＶ、Ｒ用のＶが必要になってくるわけだが
これを車輪の再開発と馬鹿にするのがお前等なわけだが、そもそも解決策をもっているのかと？

本当に使えない人はなにもやっていないのに
分かった気になってるだけでなんの解決策ももっていない人

281 ：デフォルトの名無しさん：2012/05/01(火) 05:26:50.16

パーツAの不具合を修正したライブラリVをV'とする。
V'を使用するのは、当面プロジェクトPだけとして、
プロジェクトQとRはVを使いつづける。
(プロジェクトPでライブラリVを使ったプロダクトをP(V)としよう)
QとRは、次回のメンテナンス時(これをQ',R'としよう)に
Vのどのバージョンを使うべきかを決定する。
いずれにせよ、Q'(V)とQ'(V')でテスト項目は変わらず、コストは変わらない。

> そして、開発が進んでくればプロジェクトＰ用のＶ、Ｑ用のＶ、Ｒ用のＶが必要になってくるわけだが
これは、ただ共通ライブラリとしての機能の切り出しかたが下手なだけで、
上手くなってくださいとしか言いようがないのでは。

282 ：デフォルトの名無しさん：2012/05/01(火) 05:49:46.14

スレ違い

283 ：デフォルトの名無しさん：2012/05/01(火) 07:46:29.59

>>281
そんなのライブラリごとバージョン毎にチェックしなけりゃいけないなら
わざわざライブラリＶとか切り出す必要ないじゃん

この場合、明らかにライブラリの管理コストのがでかいだろ？
車輪作ってしまったほうが楽なパターンもあるんじゃないですかね？

284 ：デフォルトの名無しさん：2012/05/01(火) 09:21:32.88

>>283
いみふ

285 ：デフォルトの名無しさん：2012/05/01(火) 09:31:25.08

>>274
通信衛星のことだ。

286 ：デフォルトの名無しさん：2012/05/01(火) 09:42:57.86

>>284
どこが？

287 ：デフォルトの名無しさん：2012/05/01(火) 09:52:04.67

> そんなのライブラリごとバージョン毎にチェックしなけりゃいけないなら
> わざわざライブラリＶとか切り出す必要ないじゃん

まず、ライブラリの用途について浅学
そもそも面倒と感じるような時代遅れのやり方
今時どこの現場もやってないだろ

碌に知りもしないで批評ぶってるまに
コードかけ
自分で構成管理しろ
そーすりゃわかる

288 ：デフォルトの名無しさん：2012/05/01(火) 10:02:11.01

何を楽と感じるかは
その人の技術レベルに大きく依存する

289 ：デフォルトの名無しさん：2012/05/01(火) 10:49:34.35

>>281 みたいなやりかたしたら、V, V', V'' …となって収拾付かなくなる

って言うところがほとんど。

うまくやってるところもあるけど、相当コストかけてメンテしている。

なので、それなりの規模がないところでないとうまくいかない。

少なくとも、>>281 みたいなのは机上の空論としか思えない。

290 ：デフォルトの名無しさん：2012/05/01(火) 11:40:21.37

>>289
だよね
やってみたこと無い人は>>281が机上の空論だってことがわからないんだよね

291 ：デフォルトの名無しさん：2012/05/01(火) 11:40:44.74

構成管理してれば余裕

292 ：デフォルトの名無しさん：2012/05/01(火) 11:42:00.51

>>290
世の中のオープンソースはどーやってるんだよ
まぎれもない現実だ
空論は無知なおまえのほう

293 ：デフォルトの名無しさん：2012/05/01(火) 11:42:09.80

>>291
それは上記のようなライブラリいくつぐらいまで余裕？

294 ：デフォルトの名無しさん：2012/05/01(火) 11:43:19.58

>>292
馬鹿か
メンテなんてしてねーだろ
あるバージョンのソースとってきてごっそり組み込んで終りだろ
なにしったかぶってんだよ
はーずかしーいｗ

295 ：デフォルトの名無しさん：2012/05/01(火) 11:44:42.47

自分の無知を必死で晒してますなw

296 ：デフォルトの名無しさん：2012/05/01(火) 11:46:12.62

>>293
個数は関係ない

297 ：デフォルトの名無しさん：2012/05/01(火) 11:46:43.69

>>294
>>294
>>294

298 ：デフォルトの名無しさん：2012/05/01(火) 11:47:15.41

結局、そんな規模もない、糞開発ばっかだから
世の中のほとんどは車輪の再開発＋αでどうにかするしかないし
それしか市場が望んでない
これが理解できてないのは素人かＭＳかＧｏｏｇｌｅかＡｐｐｌｅの開発者かぐらい

299 ：デフォルトの名無しさん：2012/05/01(火) 11:47:59.53

何年前の現場だよ

300 ：デフォルトの名無しさん：2012/05/01(火) 11:48:03.63

>>289
V, V', V'''のようにライブラリのバージョンが上がっていくのは別に問題ないだろ？
それぞれのプロジェクトでどのバージョンのライブラリを使うのか(or使えるのか)
さえ管理しておけばいい話。

301 ：デフォルトの名無しさん：2012/05/01(火) 11:48:19.86

>>296
え？もしかしてクラス１個とか関数１個でもバージョン管理するっていってる？
君といっしょの開発メンバーに同情

302 ：デフォルトの名無しさん：2012/05/01(火) 11:50:00.57

>>300
え？その場合のＱとＲの修正ってどうなるの？
ちゃんと頭使えてる？
Ｐの修正で３００項目ぐらいＶに変更加えたもんもＱとＲには適用されちゃうわけ？

303 ：デフォルトの名無しさん：2012/05/01(火) 11:50:01.96

>>301
文盲か。読み直せ

304 ：デフォルトの名無しさん：2012/05/01(火) 11:53:12.63

>>302
適用するかしないか好きな方を選べばいい

305 ：デフォルトの名無しさん：2012/05/01(火) 11:53:15.21

>>300←まともにバージョン管理なんてやったことない奴代表みたいなレスありがとうって感じだなｗ

306 ：デフォルトの名無しさん：2012/05/01(火) 11:53:17.30

>>302
QとRでどのバージョンのライブラリを使うのか(or使えるのか) さえ管理しておけばいい話。

307 ：デフォルトの名無しさん：2012/05/01(火) 11:54:44.10

もしかしてバージョン管理システム使えって話じゃなくて、台帳で管理、レベルの話をしてるのか。

308 ：デフォルトの名無しさん：2012/05/01(火) 11:56:50.90

>>306
はぁ？
じゃあ、今回の修正にあたってＱとＲに適用するＶのバージョンは何がいいですかね？

309 ：デフォルトの名無しさん：2012/05/01(火) 11:57:03.34

>>302の現場って、P、Q、Rそれぞれ固有のプロジェクト用のコードが
ライブラリVに入り込んでるから大変なことになってるんじゃない？

310 ：デフォルトの名無しさん：2012/05/01(火) 11:57:12.10

>>307
それなんて無理ゲー

311 ：デフォルトの名無しさん：2012/05/01(火) 11:58:03.75

いや
>>302の現場は構成管理どころか
ソースのバージョン管理すらしてないとみた

312 ：デフォルトの名無しさん：2012/05/01(火) 11:58:14.30

>>309
いや、入ってないよ
ライブラリＶはライブラリＶの問題

313 ：デフォルトの名無しさん：2012/05/01(火) 11:59:15.63

>>308
QとRは、もともとのライブラリVで正常に動いてたんだろ？
じゃぁ、そのままでいいよ。
V'で問題なく動くことが確認できれば、次のリリースからV'使ってもいいと思うけど。

314 ：デフォルトの名無しさん：2012/05/01(火) 12:01:05.80

>>313
でも今回のＱとＲの修正でライブラリＶにも手を入れる必要があるんですよね

315 ：デフォルトの名無しさん：2012/05/01(火) 12:04:15.07

>>314
QとRの修正でVにまで影響が出るってのは、
やっぱり、>>309で指摘した通りの状況になってるんじゃないかな。
共通ライブラリってのをあきらめるほうがいいかもね。

316 ：デフォルトの名無しさん：2012/05/01(火) 12:05:26.41

>>314
APIで後方互換性を確保しとけよ

317 ：デフォルトの名無しさん：2012/05/01(火) 12:06:07.60

>>315
いや、どれでも使ってるけどＱとＲで不具合が出てるだけ
Ｐでも使ってるけど
不具合が出てないだけ

318 ：デフォルトの名無しさん：2012/05/01(火) 12:10:37.46

>>317
じゃぁ、V'をもとにV''を作ればいいんじゃない？

319 ：デフォルトの名無しさん：2012/05/01(火) 12:11:22.45

な、こんな普通の運用でもＰ用のＶ、Ｑ用のＶ、Ｒ用のＶができちゃうだろ？
共通化なんて無理orかなりの管理コストが必要になる

320 ：デフォルトの名無しさん：2012/05/01(火) 12:12:28.61

>>317
多分、Vとしての「正しい仕様」を決めないからgdgdになってるんだと思うよ。

321 ：デフォルトの名無しさん：2012/05/01(火) 12:14:46.43

>>292
>世の中のオープンソースはどーやってるんだよ

オープンソースのライブラリって、バグ見つかったら大抵最新版しか直さないでしょ？
古い版使ってる使ってる奴は、自分で直すか新しい版を適用してね、が普通だろ。

残念ながら企業内ではこうは出来ない。
古い版のライブラリを使ってる製品が複数あるなら (と言うか複数ないとライブラリの意味ないし)
それらを全て新しい版にするなんてとても無理だから、その版を直して再テストするしかない。

つまり、古い版のライブラリも維持メンテが必要で、それをきちんとできる組織と規模がないとまず無理。

構成管理の問題と思ってる奴は現実を知らないか、ソースができればＯＫと思っている素人さん。
構成管理がちゃんと出来てるのは当然で、その上でライブラリをどうメンテしていくかの話だから。

322 ：デフォルトの名無しさん：2012/05/01(火) 12:15:27.36

>>319
ライブラリの不具合なのか、アプリの不具合なのかも見極めずに
「不具合が出た」→「ここ書き換えればうまく動く」とか行き当たりばったりなこと
やってるからそんなことになるんだよ。

323 ：321：2012/05/01(火) 12:16:41.37

>>321
ありゃ、なんか typo ってるな。

× 古い版使ってる使ってる奴は
○ 古い版使ってる奴は

まあ、意味取れない奴はいないと思うが。

324 ：デフォルトの名無しさん：2012/05/01(火) 12:18:11.69

>>320
ふぅん
じゃ、正しい仕様とやらを考えてみれば？

俺は色んなところ派遣でまわったけどこの問題を解決出来てる企業にあたったことはないな

325 ：デフォルトの名無しさん：2012/05/01(火) 12:19:38.56

>>319
> Ｐ用のＶ、Ｑ用のＶ、Ｒ用のＶができちゃうだろ？
行うのは、Vのバグ改修であって、〇〇用のVなんてものはできないよ？

326 ：デフォルトの名無しさん：2012/05/01(火) 12:21:09.68

>>325
は？話聞いてた？

327 ：デフォルトの名無しさん：2012/05/01(火) 12:25:17.06

動的リンクと
静的リンク+アドホックな修正
で話が噛み合ってないように見える

328 ：デフォルトの名無しさん：2012/05/01(火) 12:27:31.19

もしかして共通ライブラリ用のリポジトリ用意せずに使いまわしてるの？
それでフィードバック先も無くプロジェクト毎に修正してたら管理とか無理だろうね
コピペプログラミングと同じだし

329 ：デフォルトの名無しさん：2012/05/01(火) 12:28:05.74

>>321
妄想はいいからぐぐってこい
そしてさわれ

330 ：デフォルトの名無しさん：2012/05/01(火) 12:29:29.90

結局、車輪の再開発だなんだと馬鹿にしてる奴だって
いざ共通化の仕様を決めさせてみればこんなもん
２度とえらそうな口聞くんじゃないよボーヤｗってことでＥＮＤ

↓はい、次の方どーぞ

331 ：デフォルトの名無しさん：2012/05/01(火) 12:32:59.70

勝利宣言＋議論放棄とはまたテンプレな・・・

332 ：デフォルトの名無しさん：2012/05/01(火) 12:37:02.06

>>329
>妄想はいいからぐぐってこい

反論を具体的に示せない負け犬さん乙。(w

333 ：デフォルトの名無しさん：2012/05/01(火) 12:37:21.27

まあ、どうとってくれてもかまわないよ
俺はこの解決策はないと思ってるから

334 ：デフォルトの名無しさん：2012/05/01(火) 12:40:01.58

>>324
俺は成功してるケースも失敗してるケースも見てるけど、
アプリに合わせてライブラリを書き換えてるようなところはまず失敗してるな。

335 ：デフォルトの名無しさん：2012/05/01(火) 12:42:41.12

Rubyはバージョン変わると動かなくなるからな
こわいこわい

336 ：デフォルトの名無しさん：2012/05/01(火) 12:43:33.51

> 俺は色んなところ派遣でまわったけどこの問題を解決出来てる企業にあたったことはないな

これ相当恥ずかしい発言だけど気づいてんのかな

337 ：デフォルトの名無しさん：2012/05/01(火) 12:55:44.70

そうでもないと思うよ。

マジで成功しているところって、ホントに数少ないもの。

なんかの発表を鵜呑みにしてるんじゃなければ、わかると思うけど。

あと >>334 の２行目は、俺も同意見。

338 ：デフォルトの名無しさん：2012/05/01(火) 13:48:32.62

えらそうに言ってるけど
ＱとＲの不具合はどう直すの？
この回答にどう答えられるか？ってだけの話でしょ？

339 ：デフォルトの名無しさん：2012/05/01(火) 14:00:48.98

Q, R の不具合なら当然個別修正だから今回関係ないよね。

なら、ライブラリの不具合だから当然ライブラリを直す。
Q, R は、修正版ライブラリで再テスト (不具合でてたんだから当然だよね)
同じライブラリを使ってた他の製品は不具合原因をみて、修正版を適用するかどうかを決める。

普通のことのように思えるが、これをきちんとやるのは結構大変。

あと、原因も書かずに「どう直す」とか能天気なことを書いてる奴は、本質を何も理解してない
アホだと思う。

340 ：デフォルトの名無しさん：2012/05/01(火) 14:09:33.78

いい加減スレ違い
http://toro.2ch.net/test/read.cgi/tech/1178723829/

341 ：デフォルトの名無しさん：2012/05/01(火) 14:10:27.85

>>339
え？どのライブラリのバージョンをどう直すの？
現行客先で動いてるＱとＲに適用されてるライブラリは初版のなんだけど？

342 ：デフォルトの名無しさん：2012/05/01(火) 14:33:36.30

>>341
その初版のライブラリを直すのに決まっていると思うけど、理解力ないの？
最新版 (と言うかいわゆる trunk) も直す。
中間的な版を直すかどうかは、原因と使ってる製品で決める。

> どう直すの？
>> あと、原因も書かずに「どう直す」とか能天気なことを書いてる奴は、本質を何も理解してない

学習能力もないのか…

343 ：デフォルトの名無しさん：2012/05/01(火) 15:43:46.80

>>333
そのとおり。解決策はない。お前の中では、な。

344 ：デフォルトの名無しさん：2012/05/01(火) 15:45:33.09

>>338
ここはおバカさんに手取り足取り教える幼稚園じゃねーんだよ

345 ：デフォルトの名無しさん：2012/05/01(火) 15:49:12.77

ライブラリを独立させて管理出来ないチームは
ライブラリの使いまわしをしちゃ駄目ってことで

ところでここ何のスr

346 ：デフォルトの名無しさん：2012/05/01(火) 16:47:56.00

オブジェクト指向と何の関係が有るんだ？
しいて言えば、OOを過信しすぎて何でもかんでも公開して共有して依存して、
と、考えなしに特攻したら死ぬって程度。
オブジェクト指向でバージョン管理が出来るのなら、
誰もバージョン管理はしねぇよ。
なんであれ、ライブラリ間の依存関係を極力下げるのは当たり前だろう。
はっきり言って、完全に分離してしまったほうが良い。
フレームワークの類を使うときは、完全に依存するから、
そこはもうあきらめろ。それが嫌なら極力使うなってことで。
一見泥臭いが、現場レベルのすり合わせは立派な仕事。
絶対無くならない飯の種だから、むしろ極めろ。

347 ：デフォルトの名無しさん：2012/05/01(火) 17:13:06.33

>>342
したらどう管理されんの？
ＱとＲに関してはライブラリＶの初版からなるバージョンのみが適用されるんでいいの？
Ｐが使ってるＶと、ＱとＲの使ってるＶはもう完全にブランチわかれて合流することはないんだよねｗ

Ｐで直した不具合もＱとＲには適用されない構造になっちゃってるよね？
これ、お前の嫌いな再開発ちゃうの？

348 ：デフォルトの名無しさん：2012/05/01(火) 17:14:25.96

>>342
えらそーに能書きたれる割にはなんも解決しとらんやんけクズが

349 ：デフォルトの名無しさん：2012/05/01(火) 17:26:56.00

おちつけよ

350 ：デフォルトの名無しさん：2012/05/01(火) 17:30:19.60

>>347
何、俺に突っかかってきてるのか知らんけど、俺は再開発どうのこうなんて言ってないぞ。

> Ｐが使ってるＶと、ＱとＲの使ってるＶはもう完全にブランチわかれて合流することはないんだよねｗ

後出しで P がどうのこうの言われてもなぁ。
P が使ってる V と Q, R が使ってる V は同じバージョンなのか？とかによって違うだろ。

あと適切な構成管理ツール使ってるなら、ある修正内容を他のブランチに適用することが出来る。
これすらお前が「再開発」とかと定義しているなら、そう思ってればいい。俺には関係ないから。

>>348
はいはい、お前のところに適用することは無理だから、確かに解決にならない。
まあ、頑張れや。

351 ：デフォルトの名無しさん：2012/05/01(火) 17:44:04.51

共通化に失敗した人が
「ほら、こうすれば失敗するじゃないか。共通化なんてろくなもんじゃない」
って言ってるだけに聞こえるんだなー。

352 ：デフォルトの名無しさん：2012/05/01(火) 17:52:34.75

メンテしてるマイナーバージョンが複数あって
そいつらのリビジョンが1つ上がるだけの話じゃねえか
マイナーバージョン違いをマージとかありえないから

メンテ終了したバージョンなら基本バージョンアップを検討

353 ：デフォルトの名無しさん：2012/05/01(火) 17:53:52.66

ま、結局、こんなもん
ハイハイ、共通化頑張ってくださいねー
意味ないと思うけどｗ

354 ：デフォルトの名無しさん：2012/05/01(火) 18:02:30.56

各プロジェクトで似ている処理を集めて共通ライブラリみたいの作るやり方だと、
結局このスレで示された失敗パターンに陥りがちだと思うね。

355 ：デフォルトの名無しさん：2012/05/01(火) 18:03:34.32

スタート時点で既に失敗パターンですしね

356 ：デフォルトの名無しさん：2012/05/01(火) 18:07:35.06

あーそりゃだめだわ。
せめて外部に販売できるレベルの完成度じゃないと。
そしてオブジェクト指向と関係ないね。

357 ：デフォルトの名無しさん：2012/05/01(火) 18:14:43.97

結局俺のいうことがわかる奴は>>289,321だけだったな
後はただのドリーマー

>>354-356
えー、本当にそこが問題？（笑）
それじゃ同じ問題おこるんじゃないのー？
最近のＰＧって理詰めで考えるの嫌いな奴ばっかだしな
くっだらね
話だけ時間の無駄なのな

358 ：デフォルトの名無しさん：2012/05/01(火) 18:19:49.01

なにだったら、共通処理を単一アプリとして実装して、
プロセス間通信かソケットでやり取りするとか、
コマンドラインでキックして結果もらうとか
の方が確実だね。変な気が起きないという意味で。
金融関係なんかだと、穴があったら困るから
シェルを自前で用意していたりするんだけど、
そういう単位で共有すればよいわけで。

359 ：デフォルトの名無しさん：2012/05/01(火) 18:25:29.75

また、いきなりあさっての方向の議論？

ウザイので、どっか行ってくれないかなぁ。

360 ：デフォルトの名無しさん：2012/05/01(火) 18:26:38.07

>>357
出来ないと思うならやらなきゃいいじゃん

361 ：デフォルトの名無しさん：2012/05/01(火) 18:44:03.74

DIでFA

362 ：デフォルトの名無しさん：2012/05/01(火) 20:34:37.05

オブジェクト指向スレなのにOCPにまったく言及されない不思議

363 ：デフォルトの名無しさん：2012/05/01(火) 22:45:42.83

>>348
お前以外は誰も困ってない
何年も前に解決済だわ

364 ：デフォルトの名無しさん：2012/05/01(火) 23:42:18.57

共通化もできないのでオブジェクト指向は役に立ちませんｗ

365 ：364：2012/05/01(火) 23:47:15.14

”俺には” 共通化もできないのでオブジェクト指向は役に立ちませんｗ

366 ：デフォルトの名無しさん：2012/05/01(火) 23:53:54.84

ここのクズどもは本当に誰も説明できないからなｗ

車輪の再開発舐めてるからご自慢の共通化（笑）について聞いてやったのに
自分はやったことすらないとかｗもうねｗ
どうやって何を共通化するつもりだったんだ？
それすらわかってねぇのに自分はそこらの馬鹿とは違うとか思いこんでるんだから
ホント救いようが無いよお前らｗ

って言葉で表現できるのもここじゃ俺がはじめてなんだろうなｗ
笑っちゃうぜーｗ

367 ：デフォルトの名無しさん：2012/05/02(水) 00:07:45.57

>>366
煽っても態度の悪いあなたには誰も何も教えてくれませんよ
皆がはるか昔に解決済の問題をただ一人解決できず、
延々とレスを繰り返す>>366の存在が車輪の再発明

368 ：デフォルトの名無しさん：2012/05/02(水) 01:44:47.45

>>367
お前みたいなクズからはなんもでないだろｗ
魅力ないのに背伸びするなｗ

369 ：デフォルトの名無しさん：2012/05/02(水) 01:53:23.27

時代遅れさんかわいそうだろ
誰か教えてやれよw

370 ：デフォルトの名無しさん：2012/05/02(水) 01:55:08.65

面倒だし詰まらんからパス
そもそもスレチだから終了～

371 ：デフォルトの名無しさん：2012/05/02(水) 08:29:27.94

>>369-370
１人で何やってんの？ｗ

372 ：デフォルトの名無しさん：2012/05/02(水) 16:55:38.15

折角、俺が連休中に遊ぼうと解決不能な１０００年問題で煽りを入れたのに
ＧＷ中の２ｃｈの広域規制で参加人数が少ないのか・・・

373 ：uy：2012/05/02(水) 19:46:11.43

あーーわかった
ゴールデンウィークか

ゴールデンウィークになって普段社畜やってるPGが、休日になって
やることなくって荒ぶってるわけね

なんか変なスレ多いと思ったよ

374 ：デフォルトの名無しさん：2012/05/02(水) 21:20:37.04

「OOは銀の弾丸じゃ無いからクソ」みたいな感じで持論を展開してる人は
何が言いたいのかよくわからん

ソース丸コピーで修正してても管理が大変なのは変わんないじゃん

375 ：uy：2012/05/02(水) 22:02:47.75

OOの次がまだ厳密には見つかっていないとしても、
「OOが最適解ではない」。その事すらわかってない奴が問題なんだよ

OOではないコード見た瞬間に「読めない、もっと綺麗にかけ」とかいって
自分のソースリーディング能力の低さを認めずに発狂するから

376 ：デフォルトの名無しさん：2012/05/02(水) 22:04:08.90

未だにソフトウェア最大の銀の玉はC言語だと思うよ。
OOとかは無くても耐えられるけど、C言語未満は無理。

377 ：デフォルトの名無しさん：2012/05/02(水) 22:11:27.97

OOとC言語は並べて語るもんじゃなくね？

378 ：デフォルトの名無しさん：2012/05/02(水) 22:17:22.90

金じゃなくて銀？

379 ：デフォルトの名無しさん：2012/05/02(水) 22:18:57.19

取り合えず単一ディスパッチのOOでは、
オブジェクトがメソッドを持っている、っていう限定的なモデルしか
表現できないんだけど、それを知らずに銀の玉と勘違いして、
適切でない箇所にまで適用しだすと終わる。
しかし元々、道具ってのは、進化すればするほど細分化されて
適用範囲が狭まるものなので、
銀の玉ってのは発想そのものがもうダメだね。

380 ：デフォルトの名無しさん：2012/05/02(水) 22:19:57.80

あ、ごめん銀の玉じゃなくて銀の弾丸なのな。なぜボケたか。

381 ：デフォルトの名無しさん：2012/05/02(水) 22:38:14.48

銀のスプーンでしょ

382 ：デフォルトの名無しさん：2012/05/03(木) 01:00:45.21

くだらない煽り合いしかできないのか

383 ：デフォルトの名無しさん：2012/05/03(木) 01:03:20.55

オブジェクト指向自体がくだらないからね
使いこなせない奴は論外としても

384 ：デフォルトの名無しさん：2012/05/03(木) 02:09:38.60

>>375
いるよね
自分のヒューマンリーディング能力の低さを認めずに、他人を問題だとかすぐ決めつけちゃう奴

385 ：デフォルトの名無しさん：2012/05/03(木) 02:32:43.94

信じられないかもしれないけど、
mapとかreduceとかfilterとか使っただけで
読めないとか言い出す馬鹿は本当に居るよ

386 ：デフォルトの名無しさん：2012/05/03(木) 03:18:50.32

OOが良いか悪いか別にして理解出来ていない人間がここには多い。

上の方で言っている”バージョン管理”の話だと言っていることも
OOだと本来はクラス管理の話で、そのためにOOではメタクラスという機構がある。

コードの話も、OOではコードを理解する必要性は低い。
機能させ分かれば継承でき、差分プログラミングが出来る。

>>375
>OOではないコード見た瞬間に「読めない、もっと綺麗にかけ」とかいって
>自分のソースリーディング能力の低さを認めずに発狂するから
そもそもOOでないから、コードを理解する必要性が出てくると思わないのか？
OOだと必要ない事をやらされるのだから「読めない、もっと綺麗にかけ」と言いたくなる気持ちもわかる。

全体的にOOの理解力が一定水準になっていないから、話の焦点が全てぼやけている。

387 ：デフォルトの名無しさん：2012/05/03(木) 03:20:52.97

バージョン管理の話ではないところがミソなのに

388 ：デフォルトの名無しさん：2012/05/03(木) 03:21:21.89

×機能させ分かれば継承でき、差分プログラミングが出来る。
○機能さえ分かれば継承でき、差分プログラミングが出来る。

389 ：デフォルトの名無しさん：2012/05/03(木) 03:27:58.70

>>386
> 上の方で言っている”バージョン管理”の話だと言っていることも
> OOだと本来はクラス管理の話で、そのためにOOではメタクラスという機構がある。

予想の斜め下を突き抜けて大気圏外の珍説

390 ：デフォルトの名無しさん：2012/05/03(木) 03:30:18.94

お前ら毎回ゼンブ、ゼロから書き起こしてるのかよ。

どんだけ非効率なんだｗ

391 ：デフォルトの名無しさん：2012/05/03(木) 03:36:06.69

バージョン管理→クラス管理→メタクラス
脳の配線ががが

392 ：デフォルトの名無しさん：2012/05/03(木) 03:45:45.86

>>385
それはOOP信者というより、関数的プログラミングに対して無理解な人じゃね？
俺も割と複雑な関係を表現出来るのとか楽しくて相当にOOP脳だと思うが
関数的プログラミングを否定するつもりは無いぞ
本格的な関数型プログラミングは解らないけど、
その3つくらいはOOP脳でも理解出来てかつ便利だと思うし

393 ：uy：2012/05/03(木) 04:14:57.26

>>386
結論から言うと、後からの仕様変更が100%ありえないとわかってるプログラム開発でOOはいらないだろ

例えば君がオセロやテトリスを作るときに、まず「class」とタイプして構造体だかクラスだかを作るんだろうけど
まずそこからしてオセリストやテトリストからしてみたら嘲笑ものなんだよ

OO以外でオセロやテトリスを小さく効率良く実装した事がある人にとっては、
OOで書かれたソースコードのほうがウザいし読みにくい

394 ：デフォルトの名無しさん：2012/05/03(木) 04:20:36.43

>>393
自分の発言の矛盾にくらい気づけば？
仕様変更なくて書きっぱ、メンテ一切なしなんだろ？
じゃ、オセリストだか、テトリスとだかがソース見る必要もないんだよ

395 ：デフォルトの名無しさん：2012/05/03(木) 04:25:45.45

OOをきちんと理解出来てない人にとっては、
OOで書かれたコードはウザいし読みにくい
つまりOOは不要ということにしたい

396 ：386：2012/05/03(木) 04:40:44.36

もう少し詳しく書いてみると
OOでライブラリ変更は、クラスを継承して別クラス名を作ること。
別クラス名だから、バージョンの変更ではなく、クラスの追加となる。
クラス名が同じで処理を変えるバージョンアップなら、そのプロジェクト開発自体がOOに基づいて行っていない。

まっ、この説明でどれだけ理解出来るか分からないが
とにかく、OOのライブラリ管理は”バージョン管理”ではなく、”クラス管理”になる。
（クラスをバージョンで管理っておかしいと思わないのか？）

>>393
>結論から言うと、後からの仕様変更が100%ありえないとわかってるプログラム開発でOOはいらないだろ
仕様変更が有ってもOOが必ずしも必要だとは思わない。
別にOOの開発がベストだと思ってはいない。

397 ：uy：2012/05/03(木) 05:34:55.22

>>394
お前の中じゃ仕様変更＝メンテなの？
非OOで書いたってメンテはする
ただ後から基幹クラスにオブジェクトを追加するような真似をしないならOOじゃなくても良いと言っている

ある程度の雛形的なアルゴリズムはすでに存在していて
それをコピペあるいは自分で書いて、そこから改良していくようなケース
使い捨てコードとも言われるが
今後、多少のパラメータ等の変更はありえるとしても、
何か大きな変更はほぼ来ないような場所（アルゴリズムが枯れた場所?）は、OOじゃないほうがサッパリする

>>386
なんだ、継承とかまだやってるただの初心者か
＞>結論から言うと、後からの仕様変更が100%ありえないとわかってるプログラム開発でOOはいらないだろ　○
＞仕様変更が有ってもOOが必ずしも必要だとは思わない。　×
＞別にOOの開発がベストだと思ってはいない。　×

398 ：デフォルトの名無しさん：2012/05/03(木) 06:14:36.61

何でこんな展開。
バージョン管理はそれ用のソフトがあるんだからそれ使えばよいし、
OOは多態が派手な機能なんだけど、大抵はカプセルか目的で使われるから、
そんな感じで使ってればよいし。
なにの問題があるのかよくわからんね。

399 ：デフォルトの名無しさん：2012/05/03(木) 06:21:14.30

>>397
>ただ後から基幹クラスにオブジェクトを追加するような真似をしないならOOじゃなくても良いと言っている
「基幹クラスにオブジェクトを追加」って、クラスとオブジェクトの違いもわからないのか。

>なんだ、継承とかまだやってるただの初心者か
自虐的自己紹介乙ｗ

400 ：デフォルトの名無しさん：2012/05/03(木) 07:24:26.69

テトリスだろうと仕様変更は見越して書くよ
一口にテトリスっつーても複数の仕様が並立してるから
どの仕様を基準にするかユーザが選べるかも知れないし(事実市販品でそういうテトリスがある)
作られた物を軸に全く別の独自ルールも実装するかも知れんし
そもそもゲームなんて後からの仕様変更は日常茶飯事だろ

401 ：デフォルトの名無しさん：2012/05/03(木) 07:25:47.50

バージョンアップの度に継承ってどんだけクラス増えんねん。

402 ：デフォルトの名無しさん：2012/05/03(木) 07:29:21.87

仕様変更ってOOで対応するようなものじゃないと思うが。

403 ：デフォルトの名無しさん：2012/05/03(木) 07:34:18.07

>>402
某コテが「100%仕様変更が無いと判っている」例にテトリスを持ち出したからね
どう考えても例としては不適切だと思ったから

404 ：デフォルトの名無しさん：2012/05/03(木) 09:04:02.56

ＯＯで書かれたライブラリを使うのは良いがオツムの弱いやつ
が作ったオレオレＯＯは使い物にならん。
ちったぁメンテの事も考えろ！

オツムの弱いやつとは>>1-404の事ね。

405 ：デフォルトの名無しさん：2012/05/03(木) 09:12:11.27

自ら学ぼうとせず、他人を煽って答えを得ようとする奴は永遠に彷徨っていればいいよ。

406 ：デフォルトの名無しさん：2012/05/03(木) 09:47:58.69

よし、じゃあ、ミサイルとホーミングミサイルの多態から綺麗に実現してみようか？

407 ：デフォルトの名無しさん：2012/05/03(木) 09:53:10.62

基本的にはカプセル化なんだから、有るべきメソッドは
setter/getter相当だけで良いんだよ。
相互作用は外でやったほうが良い。

408 ：386：2012/05/03(木) 09:56:31.93

>>397
OOを理解出来ていない。

>>401
>バージョンアップの度に継承ってどんだけクラス増えんねん。
>>402
>仕様変更ってOOで対応するようなものじゃないと思うが。
OOでのバージョンアップ／仕様変更は、クラスを継承していくもの。（どれだけクラスが増えても仕方がない）
OCPを守るように、継承して仕様変更するのがOOでの開発。

409 ：デフォルトの名無しさん：2012/05/03(木) 10:00:54.81

>>407
それ、ぜんぜんカプセル化されてないし。

410 ：デフォルトの名無しさん：2012/05/03(木) 10:03:34.84

>>407
ばーか

setter/getterなんてカプセル化まったく理解してない奴のやることじゃん
決められたメッセージ以外での変数へのアクセスを避けるためのカプセル化なのに
setter/getterなんて作ったらどのタイミングでもアクセスできちまうじゃん
お前の書いたシーケンス図とか全部無駄、書いても書かなくてもまったく意味ない
だって君のシーケンスはsetter/getterで表現できちゃうからｗ
なんでもできる＝なんでもおこる
これが脳みそから抜けちゃうからsetter/getterなんて作っていい気になっちゃうんだよ

411 ：デフォルトの名無しさん：2012/05/03(木) 10:04:57.53

>>406
ミサイルの制御システムがＯＯで書かれていたら
人類は既に滅びているであろう

412 ：デフォルトの名無しさん：2012/05/03(木) 10:07:22.73

>>410
setter/getter相当

413 ：デフォルトの名無しさん：2012/05/03(木) 10:09:00.81

Eclipseのsetter/getterを勝手に生成してくれる機能とか爆笑モノだな
作った奴オブジェクト指向まったく理解してないんだろうなｗ
カプセル化なんて邪魔としか感じてないんだからＯＯなんてやめちゃえよｗ
java坊はうんこ、ツールの文化からいって馬鹿の影響受けすぎ＆まわりにも馬鹿しかいない
ＰＧなんかやめて漫才でもやってろｗ

414 ：デフォルトの名無しさん：2012/05/03(木) 10:30:47.22

もう一度言っとくか。
他との相互作用は外でやれ。
カプセルとカプセルをコンピュートしていく発想は、
コンピュータの原点で揺らがない。
OOの悪用良くない。

415 ：デフォルトの名無しさん：2012/05/03(木) 10:40:55.04

> カプセルとカプセルをコンピュートしていく発想

は？

日本語でおk

416 ：デフォルトの名無しさん：2012/05/03(木) 10:43:21.08

そうとも限らなくね？
関連さえわかってれば引数にぶち込んで中でやるのもアリだと思うよ
結局誰かに依存するんだから誰に依存するのか決めておけばいいだけの話だと思う

ゲームの例ですまないけど
シーンに配置された自機と敵との衝突判定など
これは自機に書くのか？敵に書くのか？シーンに書くのか？
プログラム的に綺麗なのはシーンだよね
敵に書いたら自機がいないと動かない敵クラスになっちゃうし

でもね

どこに書いても動くんだよｗ
なにもまずいことはないしｗ
頑なにＯＯまもった先にはなにもない
これは覚えておくべきだと思うねｗ

417 ：デフォルトの名無しさん：2012/05/03(木) 10:54:19.13

厳密に言えば自機も敵もいないシーンがあってもいいわけだから
自機や敵が存在しないと実行できないようなシーンはダメだな

そうすると関連を記述するなにかが必要になるけどそれってそんなに重要じゃないと思うんだよね

上の例だと俺が勝手にシーンに依存させただけでちゃんと組みたいなら依存関係をあらわすなにかを
作るべきなのかもしんないねｗ
面倒臭そうだからやってないけど

418 ：デフォルトの名無しさん：2012/05/03(木) 11:04:34.08

> ゲームの例ですまないけど
> シーンに配置された自機と敵との衝突判定など
> これは自機に書くのか？敵に書くのか？シーンに書くのか？
> プログラム的に綺麗なのはシーンだよね

うん。衝突判定はシーン。
衝突した後どうなるかは、自機や敵だろうね。

419 ：デフォルトの名無しさん：2012/05/03(木) 11:10:54.52

ここは素人ＯＯばかりのスレだな。

420 ：デフォルトの名無しさん：2012/05/03(木) 11:14:21.21

>自機や敵が存在しないと実行できないようなシーンはダメだな

シーンが自機や敵を管理しているという構図なのだから、
シーンが自分を構成するコンポーネントに依存するのは当たり前だし、
素直な設計だと思うが。シーンの方が上流なわけだから。

421 ：デフォルトの名無しさん：2012/05/03(木) 11:19:31.70

自機や敵、終了条件が定義されていないシーンは
ただの無限ループであるが、それは正しい実装。

422 ：デフォルトの名無しさん：2012/05/03(木) 11:22:40.07

>>418
>衝突した後どうなるかは、自機や敵だろうね。
当たるものにもよるからそうもできないけどな

>>420
でもシーンとシーンをまたぐときにシーンに依存してると
無茶が効かなくなるときもあるね
両方で用意してもいいけど
だから面倒だからやらないけど厳密には違うんじゃないかって思うわけよ

423 ：デフォルトの名無しさん：2012/05/03(木) 11:24:08.70

オブジェクト思考長年やって最近関数型に手を出したが、両者のハイブリッドが正解だと思うお(´・ω・｀)
UIの画面なんかはオブジェクト思考が適してると思うし、パイプライン的な処理が適してるのは関数型がいい。
上のシーンと自機敵機云々は関数型のほうがいい希ガス。

424 ：デフォルトの名無しさん：2012/05/03(木) 11:24:25.39

>>422
自分が何にあたったかがわかればいいでしょ？

425 ：デフォルトの名無しさん：2012/05/03(木) 11:25:12.52

>>423
正解っていうか、

オブジェクト指向は、構造、設計部分の話で
関数ってのは、その中身の処理の話だからね。

426 ：デフォルトの名無しさん：2012/05/03(木) 11:30:52.02

>>422
その場合はオブジェクト管理クラスとシーンクラスに分けたほうが良いだろうね。
ただ、シーンクラスというより、シーンメソッドもしくはシーン関数って格好だろうが。

427 ：デフォルトの名無しさん：2012/05/03(木) 11:34:01.30

>>397
> 何か大きな変更はほぼ来ないような場所（アルゴリズムが枯れた場所?）は、OOじゃないほうがサッパリする

そう感じるのはお前がOO苦手だからだよ

428 ：デフォルトの名無しさん：2012/05/03(木) 11:35:40.82

>>404
自己紹介込みかw

429 ：デフォルトの名無しさん：2012/05/03(木) 11:37:57.67

>>414
煽りとかじゃなく
日本語で頼む

430 ：デフォルトの名無しさん：2012/05/03(木) 11:41:47.72

>>422
あたりはシーンとなった

431 ：デフォルトの名無しさん：2012/05/03(木) 11:50:50.60

OOはwikipediaの先頭にある
オブジェクト指向（オブジェクトしこう）とは、オブジェクト同士の相互作用としてシステムの振る舞いをとらえる考え方である。
のシンプルで強力なコンセプトのことだと思う。

これと例えばOOPLの基本的な機能であるカプセル化ですら次元をわけて考えるべき。

432 ：デフォルトの名無しさん：2012/05/03(木) 11:53:44.24

次元を分けてとかどう繋がるのかさっぱりわからんがｗ

433 ：デフォルトの名無しさん：2012/05/03(木) 11:54:49.93

え？

434 ：デフォルトの名無しさん：2012/05/03(木) 11:58:26.73

OOの考え方をスマートに実装しやすくしたのが
OOPLです。そんだけ。

435 ：デフォルトの名無しさん：2012/05/03(木) 12:03:53.18

>>431
>オブジェクト指向（オブジェクトしこう）とは、オブジェクト同士の相互作用としてシステムの振る舞いをとらえる考え方である。

間違いではないが、入門書だとオブジェクト＝物とか犬、猫、車みたいな説明が多くて、初学者を混乱させている。
振る舞いをカプセル化したものがオブジェクトだから、「システムを、振る舞いの集合体とみなす」くらいのほうが適切。

436 ：デフォルトの名無しさん：2012/05/03(木) 12:06:17.00

いえ不適切です

437 ：デフォルトの名無しさん：2012/05/03(木) 12:06:19.90

英語に文句いってんの？

http://eow.alc.co.jp/search?q=object&ref=sa

object
【名】
〔視覚や触覚で感知できる〕物、物体

438 ：デフォルトの名無しさん：2012/05/03(木) 12:07:58.82

>>435
> オブジェクトだから、「システムを、振る舞いの集合体とみなす」

ほうほう。その説にしたがって
Intオブジェクトとはどういうものかを語ってみてください。。

439 ：デフォルトの名無しさん：2012/05/03(木) 12:10:53.23

特性＋振る舞い＝オブジェクト

440 ：デフォルトの名無しさん：2012/05/03(木) 12:11:34.95

まあ、3Dゲームをオブジェクト指向で作るとして、
そこの犬や猫や車が出てくる場合、

1000人中999人が犬や猫や車をオブジェクト
（正確にはクラス）として作るでしょうね。

441 ：デフォルトの名無しさん：2012/05/03(木) 12:11:36.30

>>437

オブジェクト指向
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91

>なおオブジェクトという用語は時に「もの」という直訳語で認識される場合があるが、
>英語のobjectには「目的語」、または「目的となる対象物」という意味がある。
>従ってオブジェクト指向は本来「述語（機能）よりもその対象を中心に据える」というニュアンスをもつ用語である。

442 ：デフォルトの名無しさん：2012/05/03(木) 12:12:22.07

>>441
wikipediaの信用度は
２ちゃんねるの俺の信用度と同じです。

443 ：デフォルトの名無しさん：2012/05/03(木) 12:13:45.18

特性＋振る舞い＝オブジェクト・・・例＝犬や猫、理由＝特性や振る舞いを持っているから

444 ：デフォルトの名無しさん：2012/05/03(木) 12:15:29.24

>>441
>「述語（機能）よりもその対象を中心に据える

ようするに、機能（メソッド）を取り除いたのが
オブジェクト指向ってことだよね。

445 ：デフォルトの名無しさん：2012/05/03(木) 12:16:21.22

1. 〔視覚｛しかく｝や触覚｛しょっかく｝で感知｛かんち｝できる〕物、物体｛ぶったい｝
2. 〔関心｛かんしん｝や意識｛いしき｝などの〕中心｛ちゅうしん｝、焦点｛しょうてん｝
3. 〔動作｛どうさ｝や行為｛こうい｝の〕目的｛もくてき｝、目標｛もくひょう｝
4. 《言語学》〔動詞｛どうし｝の〕目的語｛もくてきご｝
5. 《言語学》〔前置詞｛ぜんちし｝の〕目的語｛もくてきご｝
6. 《哲学》客体｛きゃくたい｝、客観｛きゃっかん｝◆【対】subject
7. 〔カメラなどの光学系｛こうがくけい｝の〕被写体｛ひしゃたい｝
8. 《コ》オブジェクト◆オブジェクト指向プログラミングにおける、変数、データ構造、手続きが一体になったもの。

446 ：デフォルトの名無しさん：2012/05/03(木) 12:20:17.26

>>444
全然違う。機能よりも対象を中心した考え方。
つまり、関数よりも引数を中心とした考え方って事。
その証拠にfunc( obj ) を obj.method() とかく。

447 ：デフォルトの名無しさん：2012/05/03(木) 12:20:51.95

オブジェクト＝猫なのは全然間違ってないけど、
メソッドの扱いが違う。

猫オブジェクトのtalkメソッドは
「猫が話す」ではなく
「猫よ、話せ！」なんだよ。

そうするとmeowと鳴く。

448 ：デフォルトの名無しさん：2012/05/03(木) 12:21:05.47

>>446
珍説考えるの疲れただろ？

449 ：デフォルトの名無しさん：2012/05/03(木) 12:22:13.77

>>446
それと、オブジェクトは猫ではないと何の関係が？

450 ：デフォルトの名無しさん：2012/05/03(木) 12:22:41.92

>>447
フニャ！って鳴きました
この場合は猫オブジェクト嗜好でしょうか？

451 ：デフォルトの名無しさん：2012/05/03(木) 12:22:55.81

？

452 ：デフォルトの名無しさん：2012/05/03(木) 12:23:08.11

>>450
？

453 ：デフォルトの名無しさん：2012/05/03(木) 12:24:13.73

>>449
物以外もオブジェクトになりえるから。

454 ：デフォルトの名無しさん：2012/05/03(木) 12:25:23.55

>>453
はい、知っています。

ノイマン型コンピュータでは
コード（処理も）データです。

455 ：デフォルトの名無しさん：2012/05/03(木) 12:26:59.95

山岡「オブジェクト至高」

456 ：デフォルトの名無しさん：2012/05/03(木) 12:29:27.50

まあ、関数がその処理を表す
バイナリ列だとすれば、
そのデータも物なわけで。

やっぱりオブジェクト＝物だよな。

457 ：デフォルトの名無しさん：2012/05/03(木) 12:30:47.23

オブジェクト私考

458 ：デフォルトの名無しさん：2012/05/03(木) 12:31:30.24

>>444
違うよ。
機能でまとめるんじゃなくて、その対象でまとめましょうってのが
オブジェクト指向。

459 ：デフォルトの名無しさん：2012/05/03(木) 12:32:17.51

>>458
いや知ってるｗ

> 「述語（機能）よりもその対象を中心に据える」
への皮肉ｗ

460 ：デフォルトの名無しさん：2012/05/03(木) 12:32:51.23

オブジェクト私考

461 ：デフォルトの名無しさん：2012/05/03(木) 12:33:40.14

>>458
そんなことない

462 ：デフォルトの名無しさん：2012/05/03(木) 12:37:04.23

>>456
引数にとったら対象になるってだけで、
引数にとらないのであれば、関数は関数だ。
立場はその時々によって変わる。

>>461
マルチメソッド場合の話だろ。
オブジェクト指向の定義は実にあいまいで困る。

463 ：デフォルトの名無しさん：2012/05/03(木) 12:42:05.28

> オブジェクト指向の定義は実にあいまいで困る。

あいまいだが困らない。
なぜなら、オブジェクト指向以外でもあいまいだから。

それにオブジェクト指向の考え方を
サポートするための言語仕様が1つ以上含まれているもの
という俺のオブジェクト指向の定義はあいまいではない。

464 ：デフォルトの名無しさん：2012/05/03(木) 12:43:10.05

>>462
お前は、関数も物であるという
理解が足りないだけ。

465 ：デフォルトの名無しさん：2012/05/03(木) 12:46:28.46

コミュ障がわめくスレ

466 ：デフォルトの名無しさん：2012/05/03(木) 12:46:43.02

>>462

foo(callback) {
　　callback();
}

callbackは引数にとっているので物であるが
その物を引数にとらずに使っているので関数。

すなわちcallbackは物であり関数でもある。
関数は物である証拠。

467 ：デフォルトの名無しさん：2012/05/03(木) 12:46:57.20

関数がものかどうかは言語による

468 ：デフォルトの名無しさん：2012/05/03(木) 12:48:04.66

>>466
関数は物ではありません
オブジェクトです

469 ：デフォルトの名無しさん：2012/05/03(木) 12:48:33.66

>>468
物＝オブジェクト

470 ：デフォルトの名無しさん：2012/05/03(木) 12:49:02.54

>>469
違います
ダメな翻訳にふりまわされてはなりません

471 ：デフォルトの名無しさん：2012/05/03(木) 12:49:21.77

>>470
違うなら違うという理由を言ったら？ｗ

472 ：デフォルトの名無しさん：2012/05/03(木) 12:49:37.33

オブジェクト＝メモリ＝状態でなにが問題だかわからん
それに相互作用のメッセージによる状態遷移

473 ：デフォルトの名無しさん：2012/05/03(木) 12:49:45.67

歴史的に考えてもオブジェクトとはそもそも…

オブジェクト史考

474 ：デフォルトの名無しさん：2012/05/03(木) 12:50:28.46

>>471
>>445

475 ：デフォルトの名無しさん：2012/05/03(木) 12:51:54.79

関数なんて、ソースコードに書かれた文字を
そのまま保存したものか、コンパイルなどして、
バイナリにしたデータなんだから物だよ。

楽譜は物か？物だろう。

476 ：デフォルトの名無しさん：2012/05/03(木) 12:52:37.53

>>464
関数も引数に取れるから、引数にとったらオブジェクトだね。
でも、引数にとらないで呼び出したのなら、それは述語・機能だね。
よく考えろ。
お前の言い分だと、コンピュータ上に存在しているものは、
全てオブジェクトってことになっちまう。
では、オブジェクトで無いものって一体何？
全てオブジェクトなら、オブジェクトって言葉の意味が無いよな。
一々オブジェクトって言う必要ないんだから。
つーわけで、お前の言ってることは言葉遊びに過ぎないんだよ。
実際には、述語との対比としてオブジェクトって言葉は意味を持ちえるんだよ。
相対的価値観なんですよ。立場は時々で変わるのです。

477 ：デフォルトの名無しさん：2012/05/03(木) 12:55:46.12

我思うゆえに我あり
オブジェクト思考ゆえにオブジェクト指向あり

478 ：デフォルトの名無しさん：2012/05/03(木) 12:55:46.03

たとえば、int foo() {return 1}なんて関数があったとする。

このプログラムをコンピュータ内で複数実行すると、
違うアドレスにこのコードのバイナリが読み込まれることになる。

これはすなわち、int foo() {return 1}がクラスであり
違うアドレスに読み込まれたバイナリがインスタンスである。

関数を変数に入れるというが、これはインスタンスの参照を
変数に入れるというのがより正確な意味である。

479 ：デフォルトの名無しさん：2012/05/03(木) 12:58:00.27

>>476
コンピュータに存在しているものは全てオブジェクトだよ。
何を言ってるのかね？

オブジェクト指向というのは、コンピュータに存在しないもの
つまり、人間の考え方のことだよ。

指向なんだから当然だろ。

480 ：デフォルトの名無しさん：2012/05/03(木) 12:58:15.13

>>475
コメントもオブジェクトなんだろうか？

481 ：デフォルトの名無しさん：2012/05/03(木) 13:00:50.20

>>480
はい。

ソースコードのコメントが
オブジェクトとして取れる言語もあります。

たいていの言語では、コンパイルすると消されますけどね。

482 ：デフォルトの名無しさん：2012/05/03(木) 13:01:26.45

>>480
オブジェクトだね。

483 ：デフォルトの名無しさん：2012/05/03(木) 13:02:23.13

foo(callback) {
　　callback();
}
これだと、
一行目の引数にとってるcallbackはオブジェクト。
二行目の関数呼び出しをしているcallbackは述語。
性質はその時々で変わるんですよ。
性質ってのは周りとの相対的な関係で初めて決まるんです。
ここいらの理解の無さは、オブジェクトの性質を、
自身のクラス内のメソッドで完結したがる、
自己の性質を自己自身で証明したがるOOのマズさにも繋がる。
相対性の観点が欠けてるんですよ。
そこいらのこと良く分かってないでOOを使うと抜け出せなくなる。
だから、相対性、つまり、他オブジェクトとの相互作用は
クラスの外に書けって言ってるわけで。
いわばOO病なんですよ。

484 ：デフォルトの名無しさん：2012/05/03(木) 13:03:57.20

OO批判病かね？ｗ

485 ：デフォルトの名無しさん：2012/05/03(木) 13:04:35.10

>>482
コメントをコンパイルオプションで残らないようにしたら
オブジェクトじゃなくなるん？

486 ：デフォルトの名無しさん：2012/05/03(木) 13:06:36.11

つまり、関数はオブジェクトにも成れるってだけで、
関数をオブジェクトと見なすかどうかは、記述しだい。
英語の文型で、SVOCとかあるだろ。Oはオブジェクトだよな。
単語がオブジェクトかどうかは、
出現する位置で決まる、文法的な意味で決まる。

487 ：デフォルトの名無しさん：2012/05/03(木) 13:06:39.06

>>483
関数も含めて、全てはオブジェクトであり
オブジェクトは引数にもできるし、
関数タイプのオブジェクトであれば実行することも可能。

バイナリ列はデータであり、
機械語タイプのバイナリ列は実行も可能。それと同じ。

物事は簡単に考えようぜ。

488 ：デフォルトの名無しさん：2012/05/03(木) 13:07:18.65

>>485
そりゃ、無になってしまったら、それはオブジェクトじゃないよｗ
コンピュータ内に表現されてもいない。

489 ：デフォルトの名無しさん：2012/05/03(木) 13:08:26.55

>>483
> 性質はその時々で変わるんですよ。

かわらないよ
かわるんなら
foo("I'm NOT a function");
が述語として変わってくれないとね

490 ：デフォルトの名無しさん：2012/05/03(木) 13:10:19.14

>>486
> つまり、関数はオブジェクトにも成れるってだけで、
> 関数をオブジェクトと見なすかどうかは、記述しだい。

違う。すべての関数はオブジェクトであり、
そのオブジェクト実行できるかは、オブジェクトの型しだい。

動物として扱えるオブジェクトがあるのと同様
関数として扱えるオブジェクトがある。

全てはオブジェクトであるが、そのオブジェクトにどんな
事ができるかは、オブジェクトの型次第。

491 ：デフォルトの名無しさん：2012/05/03(木) 13:10:32.42

その、こうものがはさまったような言い方はなんとかならんのか。
オブジェクト歯垢

492 ：デフォルトの名無しさん：2012/05/03(木) 13:12:05.65

>>487
もう言ってることが無茶苦茶って分かってるのか？
全てをオブジェクトといってしまうことは当然出来るが、
そう言ってしまうと、オブジェクト志向の言葉の意味が無くなる。
何と対比してのオブジェクトなのかって観点が無いと、
「オブジェクトを中心に考える」の意味もなくなるんだよ。
言葉の意味をなくしてまで包括的に考えて
自己の主張を押し通したって意味無いだろ。

493 ：デフォルトの名無しさん：2012/05/03(木) 13:13:32.23

var a = foo.bar

このbarは値かもしれないし関数かもしれない。
文法で決まるとか言っている人は、
その言語のことしか知らない。

オブジェクト指向っていうのは考え方なので
文法とは全く関係ない。

494 ：デフォルトの名無しさん：2012/05/03(木) 13:15:03.96

>>492
意味はなくならない
全てをオブジェクトとして捉えない世界との対比として
全てをオブジェクトとして捉えるというパラダイムシフトした後の世界がオブジェクト指向だからだ

495 ：デフォルトの名無しさん：2012/05/03(木) 13:15:55.71

>>492
何と対比してのオブジェクトなのか？
そりゃ、対比するのは手続き型や関数型だろｗ

オブジェクト指向とはすべてがオブジェクト
すべてを物としてあつかう考え方だ。
言語上の制約は別の話。

496 ：デフォルトの名無しさん：2012/05/03(木) 13:20:28.12

>>493
> var a = foo.bar
> このbarは値かもしれないし関数かもしれない。

という言語でbarがオブジェクトじゃない言語はない

497 ：デフォルトの名無しさん：2012/05/03(木) 13:21:32.87

そりゃな、値も関数も
オブジェクトの一種だしｗ

498 ：デフォルトの名無しさん：2012/05/03(木) 13:24:46.40

>>493
>var a = foo.bar

この場合、
=が述語で、aとfoo.barがオブジェクト。
foo.barそのものは述語でもオブジェクトでもない。
相手が居ないから、相対的な立場も生まれない。
単にfoo.barの値が評価されるってだけ。

499 ：デフォルトの名無しさん：2012/05/03(木) 13:24:54.57

OO使う人ってかっこいいよね
オブジェクト氏好

500 ：デフォルトの名無しさん：2012/05/03(木) 13:26:12.35

>>498
barが関数である可能性については考えないのか？ｗ

501 ：デフォルトの名無しさん：2012/05/03(木) 13:26:49.38

>>498
うーん。そのレスはいまいち。

502 ：デフォルトの名無しさん：2012/05/03(木) 13:27:16.90

>>498
fooオブジェクトにある
publicなbarオブジェクトである可能性については考えないのか？ｗ

503 ：デフォルトの名無しさん：2012/05/03(木) 13:28:43.55

>>498
foo.barはオブジェクトだよ
toStringだったり、既定メソッドだったりが内部的に呼ばれるだけで

504 ：デフォルトの名無しさん：2012/05/03(木) 13:29:06.70

>>500
関数であろうが変数であろうが、
引数なしの評価なのだから、述語/オブジェクトといった、
相対的価値観は生まれない。
しいて言えば、述語ではある。しかし少なくともオブジェクトではない。
なにせ、引数=オブジェクト無しでの評価なのだからな。

505 ：デフォルトの名無しさん：2012/05/03(木) 13:30:26.62

>>504
括弧つけなくても関数が呼ばれる言語系あるけど？

506 ：デフォルトの名無しさん：2012/05/03(木) 13:31:55.40

>>505
だからいっているとおり、引数無しで評価するということは、述語だろ。

507 ：デフォルトの名無しさん：2012/05/03(木) 13:35:56.05

>>506
述語かどうかはわからないが
少なくともオブジェクトではある

が正しい。そんな言語系しかvar a = foo.bar な書き方できません

508 ：デフォルトの名無しさん：2012/05/03(木) 13:38:03.81

つまりだねぇ。
a + b は、式全体で言えば、
+ が述語で a, b がそれに対するオブジェクト。
a, b だけ抜き出したのなら、これらは述語。
a, b が変数か関数かは関係ないよな。
単にネストしているだけ。

509 ：デフォルトの名無しさん：2012/05/03(木) 13:42:04.15

いや違う
aもbもオブジェクト結果のa+bもオブジェクト

510 ：デフォルトの名無しさん：2012/05/03(木) 13:48:39.47

>>509
そういう言い方をすると、全てがオブジェクトになってしまうだろ。
何に対して「指向」しているのか、意味が無くなる。
オブジェクト指向は、それまでの述語中心の分割手法に対する、
パラダイムシフトなわけだから、述語と目的語の対比で考えなきゃ意味が無いんだよ。

511 ：デフォルトの名無しさん：2012/05/03(木) 13:50:41.40

>>510
> 何に対して「指向」しているのか

オブジェクト

512 ：デフォルトの名無しさん：2012/05/03(木) 13:52:04.62

> そういう言い方をすると、全てがオブジェクトになってしまうだろ。

何か問題があるの？

> 何に対して「指向」しているのか、意味が無くなる。
すべてがオブジェクトって考え方を指向してるんだけど？

513 ：デフォルトの名無しさん：2012/05/03(木) 13:52:53.66

> aもbもオブジェクト結果のa+bもオブジェクト

さらに+も関数オブジェクトだったりするｗ

514 ：デフォルトの名無しさん：2012/05/03(木) 13:54:39.60

>>510
> パラダイムシフトなわけだから、述語と目的語の対比で考えなきゃ意味が無いんだよ。

a.add(b); ならどーすんの？その説だと。

515 ：デフォルトの名無しさん：2012/05/03(木) 13:59:50.17

>>512
オブジェクト指向
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91

>なおオブジェクトという用語は時に「もの」という直訳語で認識される場合があるが、
>英語のobjectには「目的語」、または「目的となる対象物」という意味がある。
>従ってオブジェクト指向は本来「述語（機能）よりもその対象を中心に据える」というニュアンスをもつ用語である。

さっさとWikipedia書き直してこいよ。

516 ：デフォルトの名無しさん：2012/05/03(木) 14:02:46.43

>>515
>>512と何の矛盾もない

517 ：デフォルトの名無しさん：2012/05/03(木) 14:04:31.23

キチガイホイホイスレ

518 ：デフォルトの名無しさん：2012/05/03(木) 14:04:31.22

>>514
分かりきったこと。
add が述語で a, b が目的語だろ。
aとbをそれぞれ単体で着目して評価するなら述語になるのも同じ。
一見奇妙だが、シングルディスパッチだとこうなる。
OOのキモさの最たる部分ではある。

519 ：デフォルトの名無しさん：2012/05/03(木) 14:06:26.10

>>515
この修正を消せばいいのか？
http://ja.wikipedia.org/w/index.php?title=%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91&diff=566408&oldid=555885

520 ：デフォルトの名無しさん：2012/05/03(木) 14:06:45.95

>>518
シ～ン～グ～ル～ディ～ス～パッ～チw
分かってないのに背伸びするな

521 ：デフォルトの名無しさん：2012/05/03(木) 14:10:28.20

>>518
へー。subjectは？

522 ：デフォルトの名無しさん：2012/05/03(木) 14:10:31.37

>>518
だが、addは関数オブジェクトなのだよ。

すべてがオブジェクトというのは
述語もオブジェクトである。

523 ：デフォルトの名無しさん：2012/05/03(木) 14:11:58.29

↓以下>>521に答えようとして混乱する>>518のショーをお楽しみください

524 ：デフォルトの名無しさん：2012/05/03(木) 14:18:03.41

>>496
Rubyは様々なものをオブジェクトとして扱うけれど
メソッドは例外的にオブジェクトではないな
メソッドをオブジェクトのように扱う為のラッパークラスはあるんだけど

525 ：デフォルトの名無しさん：2012/05/03(木) 14:22:29.51

特定の言語特有の問題なんか知らん。

526 ：デフォルトの名無しさん：2012/05/03(木) 14:23:09.35

>>522
関係ないよ。addが何であろうと述語であることには変わりない。

527 ：デフォルトの名無しさん：2012/05/03(木) 14:24:25.41

>>526
英語の記事読んできたほうがいい
オレオレ理解になってる

528 ：デフォルトの名無しさん：2012/05/03(木) 14:30:54.68

オブジェクト施工
非OOなプロジェクトをOO化すること

529 ：デフォルトの名無しさん：2012/05/03(木) 14:32:10.63

>>526
述語がオブジェクトってだけで、
別に述語であることを否定してないから問題ないね。

関数もオブジェクト
関数じゃないとは言ってない。

530 ：デフォルトの名無しさん：2012/05/03(木) 14:35:37.24

オブジェクト指孔をついた
このスレはあと3秒で・・・

531 ：デフォルトの名無しさん：2012/05/03(木) 14:37:08.91

>>424
それだと自機に他オブジェクトが入っちゃう（＝自機以外についてのコードが入っちゃう）ので
書くならシーンがいいと思うね
当たった後でその後の情報がすべて決定してるなら後は自機で処理すればいいけど
関連するところは

for(j=0;j<敵の数;j++){
　　switch(敵の種類){
　　case TEKI_A:
　　・
　　・
　　・
}

ってなっちゃうんじゃないかな？
当たるものによって必要な情報が変わる的意味で
追加効果もあったら相手によってもらわなきゃいけない情報かわるっしょ？
また、相手の攻撃が拘束状態にするものだったら遷移するステータス自体変わるし
色んな状況考えるとベタで書いておいたほうが楽だと思う

532 ：デフォルトの名無しさん：2012/05/03(木) 14:37:14.72

爆発する

533 ：デフォルトの名無しさん：2012/05/03(木) 14:38:23.78

しない

534 ：デフォルトの名無しさん：2012/05/03(木) 14:39:06.05

>>531
自機に他オブジェクトが入るのが
必然なことであれば、入れるしか無いし
いれればいいだけ。

だが入れる必要がないのなら入れる必要はない。

535 ：デフォルトの名無しさん：2012/05/03(木) 14:40:44.71

>>531
> 当たった後でその後の情報がすべて決定してるなら後は自機で処理すればいいけど

つまり、あたった後でその後の情報がすべて決定
するかどうかは、シーンにはわからないので
オブジェクトが判断するしか無い。

536 ：デフォルトの名無しさん：2012/05/03(木) 14:41:07.46

>>531
>for(j=0;j<敵の数;j++){
>　　switch(敵の種類){
>　　case TEKI_A:
>　　・
>　　・
>　　・
>}

OO本当に理解出来てるのなあ

537 ：デフォルトの名無しさん：2012/05/03(木) 14:44:14.95

>>534
それ（同列オブジェクトのインスタンス保持）やるとバグるよー
これやるぐらいだったら必要な情報をコピーとっちゃって保持しちゃうか
毎フレーム必要になっちゃうなら第３者機関をシーンに用意して
そいつに管理させたほうがいいと思う
（関連アクション実行中に片方消滅時の動作も定義する形ですべての状態を定義する（＝しっかり作る））

538 ：デフォルトの名無しさん：2012/05/03(木) 14:44:57.25

>>536
ん？
それまとめようとするとミサイルとホーミングミサイルの問題がおきるでしょ？
また、議論したい？

539 ：デフォルトの名無しさん：2012/05/03(木) 14:45:11.79

>>537
ばぐらないよーｗ

相手が何も言ってないのだから
これが最善の反論だなｗ

540 ：デフォルトの名無しさん：2012/05/03(木) 14:46:06.61

シーン厨うざい

541 ：デフォルトの名無しさん：2012/05/03(木) 14:46:31.82

>>537
誰も、他のオブジェクトの参照を常に持っとけという話はしていない。

542 ：デフォルトの名無しさん：2012/05/03(木) 14:47:00.14

>>538
起きないよ

543 ：デフォルトの名無しさん：2012/05/03(木) 14:48:26.04

>>539,541
だって参照保持ったオブジェクトの消滅をどうやって知るの？

544 ：デフォルトの名無しさん：2012/05/03(木) 14:49:57.39

現実世界の物の話をすると、
ボールはいろんなものに衝突させられるけど、
衝突相手の情報は全く持っていない。

衝突した時に、衝突情報を渡せば、
そのあとはボール自身でどうなるかが
決まるはずだ。

545 ：デフォルトの名無しさん：2012/05/03(木) 14:49:59.77

>>543
>>541読み直せ100回くらい

546 ：デフォルトの名無しさん：2012/05/03(木) 14:51:20.47

>>543
シーンから、どのオブジェクトが死んだかという
イベントが発生する。

547 ：デフォルトの名無しさん：2012/05/03(木) 14:52:30.57

OOスカウターの結果
>>544 ＞＞＞他

548 ：デフォルトの名無しさん：2012/05/03(木) 14:52:45.04

>>546
それって第三者機関を用意するって方法といっしょじゃん

549 ：デフォルトの名無しさん：2012/05/03(木) 14:53:25.76

>>548
全く違う

550 ：デフォルトの名無しさん：2012/05/03(木) 14:53:41.27

>>544
いましてるのはボールをつかんだときの話だろう・・・

551 ：デフォルトの名無しさん：2012/05/03(木) 14:54:33.97

>>549
俺とお前の認識が違うだけで
オブジェクトＡとＢが関連するときにＣを用意するって点が同じなんだよ
これ以外の要素は俺はみてないので同じと表現している

552 ：デフォルトの名無しさん：2012/05/03(木) 14:55:44.01

>>551
恣意的に同じ点だけ取り出して、同じなんだよ！ってそりゃただのトートロジー

553 ：デフォルトの名無しさん：2012/05/03(木) 14:56:47.57

>>551
俺とお前は2ch使ってる点が同じなんだよ
これ以外の要素は俺はみてないので同じと表現している

554 ：デフォルトの名無しさん：2012/05/03(木) 14:57:08.20

>>552
え？アクセス方法にこれ以外の要素があるの？
あったらいってくれ
お前がなにが違うって主張してるのかさっぱりわかんない

555 ：デフォルトの名無しさん：2012/05/03(木) 14:58:32.50

>>550
ボールを掴むという話であれば、

掴まれたボールからすれば、誰（何）に掴まれたかなんてわからない。

掴む方から見れば、掴んだのが人間であればセンサー（目）が付いているから
ボールを掴んだというのはわかるが、機械であれば何を掴んだのかはわからない。

掴まれる方、掴む方、両方共、相手が何かはわからないのが原則なんだ。

その上で解るためには目のようなセンサーが必要。
接触時に接触相手が何かを取得するメソッドだ。

556 ：デフォルトの名無しさん：2012/05/03(木) 14:59:33.07

>>554
X それって第三者機関を用意するって方法といっしょじゃん
O それって第三者機関を用意する点だけがいっしょじゃん

全く違う結果がもたらされる

557 ：デフォルトの名無しさん：2012/05/03(木) 15:02:08.69

>>555
どういう状態かによってリアクション変わるじゃん
運動エネルギーバリバリ状態でさすがにつかむとはいかないだろ
超熱かったら手が解ける物体かもしんねーよ

>>556
この議論に関して重要な情報はなに？

558 ：デフォルトの名無しさん：2012/05/03(木) 15:05:09.32

>>555
ボールも誰に掴まれたかわかるよ。OO的には

それにセンサーがなくても解るよ
痛覚触覚がない人間がいたとしても壁にぶつかればそれ以上進めない

559 ：デフォルトの名無しさん：2012/05/03(木) 15:06:21.16

>>557
運動エネルギーバリバリ状態でもつかもうとすることはできる。

運動エネルギーというのは、要するに衝突情報だ。
つかもうとした時（＝衝突）　その時の運動エネルギー（衝突情報）さえあれば
衝突相手がなんであれ、どうなるかは自分自身で決められる。

熱も同じ。すべてのオブジェクトは熱情報を持っているんだから
あとは衝突情報（衝突相手の熱もわかる）からどうなるか
自分自身で判断すれば良い。

560 ：デフォルトの名無しさん：2012/05/03(木) 15:07:35.07

>>559
え？だからそれじゃ何に当たったか？だけじゃダメだろ？
って言いたいんだけど・・・

561 ：デフォルトの名無しさん：2012/05/03(木) 15:09:51.63

>>558
> それにセンサーがなくても解るよ
> 痛覚触覚がない人間がいたとしても壁にぶつかればそれ以上進めない

ボールが壁だと知る必要はない。

衝突相手に衝突ダメージを与えて
自分の勢い上回ってっていれば、突き抜けるし、
そうでなければ、止まる。

衝突相手が壁だろうが人間だろうが、
ボールが知らないし知る必要もないだろう？

562 ：デフォルトの名無しさん：2012/05/03(木) 15:11:02.29

今から外に出るんだけど、目隠ししながら。

程なく、犬のうんちや子供や大人や車やトラックにぶつかると思うんだけど
ぶつかった対象が何であるか認知する前に、衝突の結果が発生するよね？

これってOO的にはどう表現するの？

563 ：デフォルトの名無しさん：2012/05/03(木) 15:11:12.76

この箱に触るとゾンビに変わる！

564 ：デフォルトの名無しさん：2012/05/03(木) 15:11:52.66

>>560
> え？だからそれじゃ何に当たったか？だけじゃダメだろ？
「何にあたったか」は不要
必要なのは、衝突相手が何かではなく衝突情報なのだよ。
あとはそれぞれのオブジェクトが自分自身でどうなるかを判断できる。

565 ：デフォルトの名無しさん：2012/05/03(木) 15:12:18.83

>>562
馬鹿すぎるからあっちいってくんね？

566 ：uy：2012/05/03(木) 15:13:25.97

>>416
真理に近い場所にいるな
>>417-430
何をどこに書いたって動くし
読みやすいかどうかは、それを見る人やエディターのほうの問題

俺がゲーム作る時は、当たり判定とかシーンに書いたりもするし
自機や敵とかのオブジェクトの中に書いたりもするし
はっきりいって気分

オブジェクト指向的には～ここにかくのが正しくて～
とかいってるボケカスは死すべし
そんな議論に意味はない

勝手に決まりごと作って、決まりごと通りじゃないと読めないほうが問題だと気づくべき
雛形に頼りすぎれば、雛形に対応してないプログラムは作りにくくなってる

567 ：デフォルトの名無しさん：2012/05/03(木) 15:14:53.66

>>561
掴むばあいじゃなく衝突の場合で考えると
ボールがぶつかったのが壁なのな豆腐なのかで
ボールの跳ね返り方が変わるだろ
つまり、ボールは何にぶつかったを見分けている
壁と豆腐を直接見分けているかはともかく

568 ：デフォルトの名無しさん：2012/05/03(木) 15:15:33.60

>>564
処理によらね？
拘束状態系の攻撃で相手が死ぬかつかんでる腕が吹き飛んだら解除なんてのは間違いなく相手情報いるし
っていうか汎用処理にまとめることもできるけど
ここまでくるとまとめないほうが楽だよ

569 ：uy：2012/05/03(木) 15:16:57.11

てかシーンの話まだ続いててわろｗｗｗｗｗ

オブジェクトA　、　オブジェクトB　の判定の為に　オブジェクトC（シーン）で当たり判定をするってのが
気に食わないんだろう？

答えを教えてやれば
オブジェクトA
オブジェクトB
オブジェクトC
の全部に当たり判定を書けるように設計するのが正しいよ
現実世界でものは考えなくて良い、プログラム的にはそれが最強なだけだから

でも、そこまでやらなくてもオブジェクトCにちょっと書いちゃえばゲームは完成する
ゲームを完成させるのと、ゲームプログラムのソースコードを完璧にさせるのは少し目的がズレている

570 ：デフォルトの名無しさん：2012/05/03(木) 15:18:48.92

>>564
オブジェクトの種類の組み合わせの数だけ
衝突の結果何が起こるか？を用意しなきゃならなくなる
言い換えるなら
衝突可能なクラスの組み合わせの数だけ衝突の結果何が起こるか？を用意しなきゃならなくなる
なんかおかしくね？

571 ：デフォルトの名無しさん：2012/05/03(木) 15:20:33.40

>>570
それは定義しないとダメじゃないかな？
デフォルト処理ならデフォルト処理で動くよって定義は絶対に必要
ロジックの結果デフォルトで動く・・・ようなソースは書いてはならないと思う

572 ：デフォルトの名無しさん：2012/05/03(木) 15:20:39.90

>>567
> ボールがぶつかったのが壁なのな豆腐なのかで
> ボールの跳ね返り方が変わるだろ

壁なのか豆腐なのかで跳ね返り方が変わるのではない。
豆腐のように柔らかい壁や、壁のように型い豆腐の場合だってあるだろう。

必要なのは衝突情報。その衝突情報に
衝突相手の硬さが含まれていればいいだけの話。

573 ：デフォルトの名無しさん：2012/05/03(木) 15:21:40.08

>>570
> オブジェクトの種類の組み合わせの数だけ
> 衝突の結果何が起こるか？を用意しなきゃならなくなる

それは、俺が言っていることと
真逆のことだ。

俺は、オブジェクトの種類なんか知る必要はないといっている。
知る必要があるのは、衝突情報だけだ。

574 ：デフォルトの名無しさん：2012/05/03(木) 15:23:31.90

>>572
その衝突情報には、何が含まれていれば必要十分なのかな？

575 ：デフォルトの名無しさん：2012/05/03(木) 15:24:13.22

基本的にあるオブジェクトＡとＢがあったら
ＡのステータスｘＢのステータス分の当たりは定義しないとダメ
（結果としてデフォルト処理になったとしてもね）
これが組み合わせ分いるってのはもう削れない作業だと思うよ

デバッグできねぇからｗ
大手に派遣にいくとそういう資料がない場合作れって言われるからロジックでやっちゃうと痛い目みるぜ
これはテーブルで定義できる形にしないとだめだな（俺の経験上）

576 ：デフォルトの名無しさん：2012/05/03(木) 15:26:11.70

>>569
> オブジェクトA　、　オブジェクトB　の判定の為に　オブジェクトC（シーン）で当たり判定をするってのが
> 気に食わないんだろう？

当たり判定をするのは、オブジェクトCであるのは当たり前。
ただし、あたったあとのどうなるのかは、A、B自身で決まる。

なぜ当たり判定をするのがオブジェクトCなのかというと、
当たり判定は神の仕事だからだ。

現実世界において、AとBが全く同じ場所（＋同じ時間）に重なって
存在することは出来ない。これは世の中がそうなっているから。

577 ：uy：2012/05/03(木) 15:27:05.24

色々と考えてるようだけど
とりあえずSTGでも作ってみたらいいじゃん

ゲームとアプリは根本的に違うのに、同じように応用で作れると勘違いしてる奴いるけど、
同じように作りやがるからゴミカスソースコードが作られて俺をイラつかせるんだよ

578 ：デフォルトの名無しさん：2012/05/03(木) 15:27:10.96

>>574
> その衝突情報には、何が含まれていれば必要十分なのかな？
仕様による。

シミュレータを作りたいのなら、様々な情報をいれれば良い。
ゲームなら適当でいいだろ。

579 ：デフォルトの名無しさん：2012/05/03(木) 15:30:48.32

一旦神の視点を仮定するなら、全てで全うしないと混乱する。

580 ：デフォルトの名無しさん：2012/05/03(木) 15:32:50.67

>>575
> 基本的にあるオブジェクトＡとＢがあったら
> ＡのステータスｘＢのステータス分の当たりは定義しないとダメ
> （結果としてデフォルト処理になったとしてもね）
> これが組み合わせ分いるってのはもう削れない作業だと思うよ

オブジェクトと衝突情報を分離すればまだ削れる。

まずオブジェクトAだけでいい。単体テストになる。

あとはそのオブジェクトAに様々な衝突情報を渡して
その反応を記述すればいい。

そうすればオブジェクトAは、オブジェクトB（壁）とよく似た性質の
オブジェクトC（鍵の掛かったドア）にぶつかっても期待通り同じ反応をするだろう。

581 ：デフォルトの名無しさん：2012/05/03(木) 15:33:28.38

>>579
理由が抜けてるのでコメントする価値なしｗ

582 ：uy：2012/05/03(木) 15:34:46.29

>>576
俺だったら、
オブジェクトCで当たり判定を書いた場合は
オブジェクトCで、AやBの「存在フラグ」っていうものをまず消して
オブジェクトAやBでは、「存在フラグ」が生きているかどうかを判定させて、処理をさせる感じかな

あと言ったように現実世界にならって作る意味もないけどな
それ以外の方法で読みやすくまとめる方法はいくらでもある

583 ：デフォルトの名無しさん：2012/05/03(木) 15:37:41.87

>>582
存在フラグじゃなくて衝突フラグでいいだろ？

584 ：uy：2012/05/03(木) 15:38:25.25

そもそもオブジェクト全てをスレッドにして作る手段だってあるし
そういう場合は、すべてのオブジェクトに当たりをつけて自立させたほうが

シーンで当たり判定するよりはわかりやすいソースコードになるよね？

今までの考え全部無駄にしちゃったかな？＾＾＾＾
ゲームプログラムってこういうものだよ＾＾＾＾

585 ：デフォルトの名無しさん：2012/05/03(木) 15:39:05.55

>>584
少なくとも俺は、最初からその話をしてる。

586 ：uy：2012/05/03(木) 15:39:52.26

>>583
どっちでもいいよ
そもそも俺シーンに当たり判定書かないし

587 ：デフォルトの名無しさん：2012/05/03(木) 15:41:35.48

「シーン」というのは例えばの話で
ゲームシステムを管理する物のことだ。

途中から会話に入ってきたからわからんのだろう？

588 ：uy：2012/05/03(木) 15:43:35.78

>>585
普通はスレッド化はせずタスクシステムだよ

全部をスレッド化するのは、オーバーヘッドやメモリを考えなくちゃいけないから
言語によって作り方が変わって面倒だし

589 ：デフォルトの名無しさん：2012/05/03(木) 15:43:44.96

> そうすればオブジェクトAは、オブジェクトB（壁）とよく似た性質の
> オブジェクトC（鍵の掛かったドア）にぶつかっても期待通り同じ反応をするだろう。

これが優れているのは、オブジェクトBとオブジェクトCは継承関係にないってこと。

継承関係にないオブジェクトにぶつかっても、ぶつかった時の情報が同じなら
オブジェクトAは同じ反応をする（もちろんするべき）

590 ：デフォルトの名無しさん：2012/05/03(木) 15:45:42.25

>>588
> 普通はスレッド化はせずタスクシステムだよ

どっちでもいい。

そんなのはゲームシステム外の環境で
決めることだ。

591 ：uy：2012/05/03(木) 15:47:50.30

>>587
それを言ってるよ
現実世界で例えていうと、神がいない状態

>>590
議論するならどっちでもよくないだろ、オブジェクトはスレッド派ですって名前欄にでも入れとかないと
お前以外の奴みんなタスクシステムだと思って会話してるよ

592 ：デフォルトの名無しさん：2012/05/03(木) 15:48:50.96

>>591
スレッドでもタスクでも
同じように作れるのでどっちでも良い。

どこにCPUを割り振るかの違い。

593 ：デフォルトの名無しさん：2012/05/03(木) 15:51:41.96

>>589
いや、それ以前に一クラスですやん

594 ：デフォルトの名無しさん：2012/05/03(木) 15:52:35.31

uyってコテ
偉そうなわりに言ってることしょぼいよな
見てて恥ずかしくなるんだが

595 ：デフォルトの名無しさん：2012/05/03(木) 15:56:46.48

>>579
それは無い。神もただのオブジェクトだから。

596 ：デフォルトの名無しさん：2012/05/03(木) 15:59:06.71

>>580
しっくりきた

597 ：デフォルトの名無しさん：2012/05/03(木) 16:00:52.27

不可知論者なので、神の視点には物理法則クラスという命名にします

598 ：デフォルトの名無しさん：2012/05/03(木) 16:20:20.25

>>580
削れないよ
じゃあ、オブジェクトＡが状態１のときにオブジェクトＢが状態２に当たったときに
それぞれのオブジェクトはどうなの？
ってのはどうせ定義しなきゃならねぇんだよ

もう一度いうけどデバッグどうすんだよ
ここでクッションをいれようがいれまいが俺等は他のメンバーにこの仕様を周知する役目がある
作って終りじゃねーぞ

599 ：デフォルトの名無しさん：2012/05/03(木) 16:22:11.77

>>598
削れるだろw
レスは理解してからにしよーぜ

600 ：デフォルトの名無しさん：2012/05/03(木) 16:25:15.96

>>598
状態1のAオブジェクト(以下A1)が
状態1のＢオブジェクト(以下B1)とぶつかった場合、
状態2のＢオブジェクト(以下B2)とぶつかった場合、
それぞれどういう違いがでる仕様なんだ？

それ書いてくれたら問題なく削れることをレスするよ。誰かが。

601 ：デフォルトの名無しさん：2012/05/03(木) 16:30:26.78

>>598
オブジェクトAが状態1の時に、
"B2"ってオブジェクトをぶつければいいよ。

別にオブジェクトBは作る必要はない。

602 ：uy：2012/05/03(木) 16:31:04.29

俺ならこう書くよ
自機のところに当たり判定
http://codepad.org/7tMtNya9

シーンって何っていう

603 ：デフォルトの名無しさん：2012/05/03(木) 16:33:13.28

>>600
俺の話理解してからレスしてくんないかな？
どうなんの？ってのに回答をもってなきゃダメでしょ？
って話をしてるの
クッションいれてそれでロジックが動いたからどうだって話

604 ：デフォルトの名無しさん：2012/05/03(木) 16:35:08.58

>>603

設計もシンプルになって作りやすい。
単体テストができて嬉しい。

って話だろ。

605 ：デフォルトの名無しさん：2012/05/03(木) 16:35:36.80

クッション入れて構造をシンプルにするのは
よくあるテクニックだね。

606 ：デフォルトの名無しさん：2012/05/03(木) 16:36:37.90

>>603
解答は既に出てるだろw
おまえがよく嫁

607 ：uy：2012/05/03(木) 16:37:51.50

ショット打たせるとこんな感じだよ
もうコードで語ればいいんじゃないの？？口だけなの？？
http://codepad.org/JCZ038JE

608 ：デフォルトの名無しさん：2012/05/03(木) 16:38:04.74

>>604
なんないじゃん
オブジェクトＡのステータス１状態
オブジェクトＢのステータス２状態
がそれぞれ内部でどういう扱いになってるか調べて
その結果「ああ、なるほどね」って理解しなきゃいけない構造だろそれ

そんなのお前１人でオナニーやってろよって話じゃん
出してほしいのは
オブジェクトＡのステータス１状態と
オブジェクトＢのステータス２状態が
かちあったときの処理を知りたいんだから
無駄にわかりにくくなってる上に誰も喜ばない

609 ：デフォルトの名無しさん：2012/05/03(木) 16:38:45.86

>>607
お前、邪魔
俺等と語れるレベルに届いてない

610 ：デフォルトの名無しさん：2012/05/03(木) 16:39:52.58

>>608
理解出来てないの確定だから、
上のほうのレスの流れを10回くらい読み直して来い

611 ：デフォルトの名無しさん：2012/05/03(木) 16:42:25.51

>>608
両方同時に処理しようと思っているから
お前は複雑になってるんだろ。

オブジェクトAの処理と
オブジェクトBの処理って2つに分けろよ。

そしてオブジェクトAだけまず作ればいいじゃないか。

両方を一般に作ろうとするから
複雑になってるんだよ。

612 ：デフォルトの名無しさん：2012/05/03(木) 16:43:43.66

>>610
いや、わかってないのはお前のほうだよ
この構造がなんにもシンプルになってないむしろ邪魔なだけって気がついてないのがダメ

613 ：デフォルトの名無しさん：2012/05/03(木) 16:50:43.98

>>611
いやでもその場合、爆発してください（オブジェクトＣ生成）ってときに
２つの状態だけじゃ表せないよねｗ

614 ：uy：2012/05/03(木) 16:54:11.28

だからさー結局、>>569 でいったように最強なのは
全部のオブジェクトに当たり判定かけるようにする形だよ
http://codepad.org/MKENerbj

ここまで至っていない子がシーンとかに当たり判定を書いちゃうだけ
オブジェクトA,Bの判定をするオブジェクトC（シーン）で当たり判定をかくと
変数ふえまくるんだよね
衝突判定変数と、存在判定用の変数とか、その後もどんどん増えていく

615 ：uy：2012/05/03(木) 16:57:25.54

でもそれを別に悪いとは思っていない
ゲームは完璧に作らなくても完成するし

動的言語じゃない言語でこういう作り方しようとすると壁にぶつかるからね
理論は通ってても静的言語ではコードかいていられないのが事実
かけるだろうけど面倒くさい

616 ：デフォルトの名無しさん：2012/05/03(木) 17:20:13.38

uy静かにしてよ

617 ：uy：2012/05/03(木) 17:24:12.92

ごめんね、ちょっと結論書きすぎたよね･･･
君たちがかくゲームのソースコードってこんなんでしょ？
http://codepad.org/wYYdk3Wx

とりあえずレベルをあわせてみるよ

618 ：片山博文MZボット ◆0lBZNi.Q7evd ：2012/05/03(木) 17:50:16.55

>>617 バグってる

619 ：デフォルトの名無しさん：2012/05/03(木) 18:01:29.49

>>614
日本語でおｋ

620 ：デフォルトの名無しさん：2012/05/03(木) 18:43:29.30

オブジェクト指向が使えない開発手法の原因は？

オブジェクト指向技術が使えないから？
オブジェクト指向技術者（自称）が使えないから？

621 ：デフォルトの名無しさん：2012/05/03(木) 18:51:49.38

その上司が部下を使えないから。

622 ：デフォルトの名無しさん：2012/05/03(木) 19:12:08.55

>>620
日本語でおｋ

623 ：uy：2012/05/03(木) 19:31:34.80

そろそろ日本語での議論にも飽きたらソースコードさらせばいいのに
俺は>>614,617この辺りを30分もかからずかいてるんだから
ソースコードかけないのか
議題の抽象化にはソースコードをあげる事が一番良い
この程度をさらっとかけないレベルでなにが正しいとか間違っているとか言えるのかね.

624 ：デフォルトの名無しさん：2012/05/03(木) 19:53:23.43

>>612
わかってないなあ

625 ：デフォルトの名無しさん：2012/05/03(木) 19:54:24.97

>>623
OOの意味わかってる？

626 ：uy：2012/05/03(木) 20:06:58.39

そーすこーど

627 ：デフォルトの名無しさん：2012/05/03(木) 20:09:29.50

>>626
連休だから普通に外出中だろ

628 ：デフォルトの名無しさん：2012/05/03(木) 20:10:52.13

設計概念伝えるのにコードをいきなり見せるような奴に
オブジェクト指向がわかってるやつはいない

629 ：デフォルトの名無しさん：2012/05/03(木) 20:18:21.98

>>613
> いやでもその場合、爆発してください（オブジェクトＣ生成）ってときに
> ２つの状態だけじゃ表せないよねｗ

え？ Aに爆発してくださいという
メッセージを送った時に、Aがどうなるのか？

爆発するでしょ。

今、Aとメッセージしか、出てきてないよね？

630 ：デフォルトの名無しさん：2012/05/03(木) 20:43:35.52

>>629
は？
ゲームやったことある？
オブジェクトＡはやられモーションとれよ
それとは別に爆発オブジェクト出せよ

631 ：uy：2012/05/03(木) 20:46:02.11

>>629
爆発してくださいって何？

普通は、
オブジェクトA（敵）だとして、
爆発エフェクトをつけるなら
オブジェクトAから、オブジェクトA-01とかいう爆発オブジェクトを生成するよ？
>>630
(*´･д･)(･д･`*)ﾈｰ

はい雑魚決定

632 ：デフォルトの名無しさん：2012/05/03(木) 20:53:40.02

>>630
オブジェクトAは
やられモーションを表示すればいいし、
新たに爆発オブジェクトをnewすればいい。

何か難しいことでもあるのですか？

633 ：デフォルトの名無しさん：2012/05/03(木) 20:54:45.33

っていか、後から仕様増やすな。

634 ：デフォルトの名無しさん：2012/05/03(木) 21:51:59.42

>>632
え？どこで？
おたくは処理をシーンにかかないでオブジェクトＡの中でやんでしょ？

>>633
当たり前の処理だけど
想定外だったとしても仕様変更にめちゃくちゃ弱いってレベルじゃねーぞｗ

635 ：606：2012/05/03(木) 22:00:54.47

一人で騒ぐなよ
なに難しいことないだろ

636 ：デフォルトの名無しさん：2012/05/03(木) 22:06:30.68

>634
> おたくは処理をシーンにかかないでオブジェクトＡの中でやんでしょ？

え？オブジェクトAでやるのは、
自分自身の処理だけだよ。

爆発オブジェクトは爆発オブジェクトがやる。
当たり前の話だが、オブジェクト指向わかってないのか？

637 ：デフォルトの名無しさん：2012/05/03(木) 22:07:52.18

>>634
> 想定外だったとしても仕様変更にめちゃくちゃ弱いってレベルじゃねーぞｗ
は？
仕様変更簡単にやってのけただろ。

俺が言ってるのは、最初にそういう仕様を言わないでおいて、
なんで対応してないんだよとか、言うなってことことだ。

638 ：uy：2012/05/03(木) 22:17:42.62

最初から「想定」して作ってない時点で
あ、こいつゲーム作ったことないなってわかる
アプリケーション開発が出来るからって同じようにゲームも作れるとか勘違いして話にはいらなければいいのにって思う

639 ：デフォルトの名無しさん：2012/05/03(木) 22:19:35.82

>>638
読解力無いのか？

拡張の想定はしている。だから仕様変更は簡単。
仕様に機能を搭載してないだけ。

640 ：デフォルトの名無しさん：2012/05/03(木) 22:19:58.08

仕様に無い機能を搭載してないだけ。

641 ：uy：2012/05/03(木) 22:23:10.48

>>639
お前が言ってるのは「仕様変更」じゃない
ゲーム作った事があれば最初っから「想定」してなきゃおかしい部分

642 ：デフォルトの名無しさん：2012/05/03(木) 22:24:27.83

仕事でも仕様にない機能を勝手に実装しても
無駄になるだけ。

そんな機能があったらいい思ったら、まず提案する。
そうやって話し合って決まってから実装する。
場合によってはベータ機能として実装したのを見せながら
提案することもある。

実際の仕事ではそうやって提案することは重要だが、
今お前はこのスレで、○○機能あったほうが良くないですか？
みたいなの話をしたかったのか？

スレタイ見ろよドアホ。

643 ：uy：2012/05/03(木) 22:27:00.37

だからさー
敵→爆発　のところだろ
最初から続けて書いていけるように作ってあるんだよ普通は。

敵→消滅
を
敵→爆発

にするというのが仕様変更だと頭の中で思っているなら
すげーどうしようもない設計だなってわかる。　そーすこーど。

644 ：デフォルトの名無しさん：2012/05/03(木) 22:27:21.01

>>641
オブジェクトが衝突した時に、
爆発するか、そのまま消えるか
何もしないかは、仕様による。

爆発するならば、爆発オブジェクトを生成すればいいだけ
衝突した時にどうなるかは、当然仕様だし、
それが変わったら、もちろん仕様変更。

で、オブジェクトが別のオブジェクトを生成するなんて、
オブジェクト指向なら簡単にできます。
一番単純な方法は、newするだけ。

645 ：デフォルトの名無しさん：2012/05/03(木) 22:27:29.76

>>641
おまえはOO満足に出来ないんだから黙ってろ

646 ：uy：2012/05/03(木) 22:28:14.20

>>644
その生成タイミングでみんなが悩んでいるわけですけど。

647 ：デフォルトの名無しさん：2012/05/03(木) 22:29:02.99

>>643
> 敵→消滅
> を
> 敵→爆発
>
> にするというのが仕様変更だと頭の中で思っているなら

明らかに仕様変更だろｗ

設計変更じゃないがな。
設計は同じまま、仕様を変更できる。
言ってる意味わかりますか？

648 ：uy：2012/05/03(木) 22:30:47.40

このレベルなんですよ･･･

レスするのもアホらしい
だから、そーすこーど見せろよ
それで全部わかるよ

649 ：デフォルトの名無しさん：2012/05/03(木) 22:31:41.15

>>646
衝突したタイミングで、爆発するほうが
爆発オブジェクトを生成すればいいよ。

650 ：デフォルトの名無しさん：2012/05/03(木) 22:32:55.21

>>648
お前はまず、本を読め。
ここらで書かれていることは、
すべてゲーム関連の書籍に書いてあることだ。

651 ：uy：2012/05/03(木) 22:36:48.46

>>649
答えになっていないよ
君がどういうソースコードかいてるか俺知らないもん

>>650
何の本を読んだか知らないけど、ゲーム関連の書籍を真に受けてる子って･･･
セガの新人教育の本以外はゴミしかないと思う

652 ：デフォルトの名無しさん：2012/05/03(木) 22:37:42.82

>>651
あぁやっぱり勉強不足なだけだなｗ

653 ：uy：2012/05/03(木) 22:38:52.84

>>647
＞敵→爆発
これは、最初から想定して作るんだよ

で、爆発エフェクトいらないよって時は、
爆発エフェクトを普段書くべき場所に何も書かず空っぽにするだけ

仕様変更でもなんでもなくて

654 ：uy：2012/05/03(木) 22:39:32.49

>>652
では君のそーすこーどを見せてもらおうか
俺は>>614これです

655 ：デフォルトの名無しさん：2012/05/03(木) 22:40:26.85

>>651
ゲーム管理システムが、オブジェクト同士の衝突判定を行った後
各オブジェクトに対して、衝突メッセージを送る

衝突メッセージを受け取った各オブジェクトは、
それぞれ衝突情報を元に、自分自身の変化を記述すれば良い。
自分自身が変化してもいいし、新たなオブジェクトを生成して
自分は消えても良い。

ここまで言えば普通は理解できる。

656 ：uy：2012/05/03(木) 22:41:00.59

爆発オブジェクトの生成を、
敵オブジェクト内でやろうと、シーンでやろうと別にどうでもいいんだよ
根幹の作り方の問題だからね

ただどんな作り方をするにしたって、最低限そこまでは最初から想定して作っていない時点で
あ、初心者だなってわかる

何の話だっけ？

657 ：デフォルトの名無しさん：2012/05/03(木) 22:41:28.15

>>653
> これは、最初から想定して作るんだよ
>
> で、爆発エフェクトいらないよって時は、
> 爆発エフェクトを普段書くべき場所に何も書かず空っぽにするだけ

それだと、爆発にしか対応できないだろ。

658 ：デフォルトの名無しさん：2012/05/03(木) 22:41:43.49

>>654
シンタックスエラーって？

659 ：デフォルトの名無しさん：2012/05/03(木) 22:42:51.29

爆発を想定していると、爆発にしか対応できない。
これは拡張性がないと言わざるをえない。

オブジェクトの変化、新しいオブジェクトの生成として
考えておけば、爆発以外にも対応できる。
変身とかね。

660 ：uy：2012/05/03(木) 22:43:43.03

>>655
メッセージを送るって事は
変数のフラグを変えるわけではなく
オブジェクトごとにWinAPIのイベントドリブンみたいにメッセージ解読用のcase文でもあるのかな？

まぁ、そういう作り方もあるかもしれませんね

661 ：デフォルトの名無しさん：2012/05/03(木) 22:46:09.84

>>660
ifでもcaseでもStateパターンでも
規模や手間を天秤にかけて、
好きに実装すれば良い。

662 ：デフォルトの名無しさん：2012/05/03(木) 22:48:55.38

想定の意味がずれてるなぁｗ

爆発するかもしれない、変身するかもしれない。
そういうのを想定していたらきりがないだろ。
そんなのは想定する必要はない。

「想定」っていうのはそういうことではなく、
他のオブジェクトに変わるかもしれない。ということ
具体的に何になるかは想定しないし、してはいけない。

「”何か”に変わることを想定する」

663 ：uy：2012/05/03(木) 22:49:12.70

>>659
それは当たり前だ
爆発エフェクト＝ただのオブジェクトなんだから
爆発エフェクトが作れるなら何でも作れるよ

>>661
別にそんなカス設計の説明しなくていいぞ
俺はその設計を見下してるんだから

つーかなんで教えてもらってる分際で、徐々にuyに教えてるみたいになってんだ？
立場を知れよ
長いものにはまかれろと言っています

664 ：デフォルトの名無しさん：2012/05/03(木) 22:51:13.16

>>663
お前に教えてるつもりはないぞｗ

お前がどう感じているかはお前自身が決めること。
オブジェクト指向だからなｗ

お前は「教えられてるなぁ」と感じてるんだろ？
じゃあ、そうなんだろうな。

665 ：uy：2012/05/03(木) 22:51:56.70

>>662
いや想定しろよｗ

どんだけ経験ないのにしゃべってんだよ

雛形のスケルトンプログラムっていうのがあるよな？
ゲームを作る時には、基本的にそこからやっていくわけだけど

何度も作っていくうちにその雛形は進化していかなきゃおかしい
経験がないから「想定」が甘いんですよ

666 ：デフォルトの名無しさん：2012/05/03(木) 22:52:30.49

>>663
なんでも作れるのであれば、
わざわざ爆発なんて言わなくていい。

オブジェクトが新しいオブジェクトを生成できることを
知っていれば、爆発はどうなんだ！とか聞く必要すらないわけだ。

667 ：デフォルトの名無しさん：2012/05/03(木) 22:54:04.56

>>663
おまえ>>582は存在フラグとか言っちゃう壊滅的なセンスなんだから
身の程をわきまえるのおまえだ

668 ：デフォルトの名無しさん：2012/05/03(木) 22:54:28.32

>>665
だから、想定してるだろ。

オブジェクト自身が変化する。
他のオブジェクトを生成する。

これ以外何を想定しろと言うんだ？

爆発エフェクト＝ただのオブジェクトなんだから
オブジェクトの変化と生成に対応していれば、なんでも対応できるよ。

669 ：uy：2012/05/03(木) 22:54:30.78

>>664
知識がないのにがんばるなぁって思いながら読んでる

>>666
このスレのレベルに合わせないと、混乱するからわざわざ"爆発"と言うしかないんだろうが
俺は>>614これだよ
出来るならば俺は614のソースでしゃべりたいのに、わざわざ617に譲歩して喋ってんだぞ

で、何を聞きたいのかいまいちわからない

670 ：デフォルトの名無しさん：2012/05/03(木) 22:54:36.82

っていうか、フラグw

671 ：デフォルトの名無しさん：2012/05/03(木) 22:55:14.22

>>669
> このスレのレベルに合わせないと、混乱するからわざわざ"爆発"と言うしかないんだろうが
じゃあ、今度から爆発なんて言わなくていい。

672 ：uy：2012/05/03(木) 22:56:03.86

>>668
あ、そこまでやっと理解した？
お前が　647や657を　書いたのかは定かではないけど、

とりあえず、ソースコードはまだうｐないけど理論だけはそこに行ったわけだね
おめでとうございます

673 ：デフォルトの名無しさん：2012/05/03(木) 22:57:59.00

※「爆発」と言うの禁止

話をまとめると、衝突検出自体はシステムが行って
各オブジェクトに衝突メッセージを送る。

オブジェクトが衝突した時にどうなるかは
オブジェクト自身しか知らないわけだから、
オブジェクト自身に記述する。

オブジェクトは衝突メッセージが送られてきた時に
無視する、自分自身を変化させる、新しいオブジェクトを生成する
などの動作を行う。

674 ：デフォルトの名無しさん：2012/05/03(木) 22:58:19.47

>>672
最初からそう言ってるだろｗ

675 ：デフォルトの名無しさん：2012/05/03(木) 23:06:15.13

>>669
スレのレベルのせいにするなよ
それがおまえのレベルなんだろ

676 ：uy：2012/05/03(木) 23:09:07.45

>>673
＞衝突検出自体はシステムが行って
それが無難だと思うよ
メッセージ云々のところにはちょっと賛同しかねるけどな

>>674
速報：最初からそう言ってた

>>675
>>614で語れるの?

677 ：デフォルトの名無しさん：2012/05/03(木) 23:14:06.69

キャラ管理クラス
シーン管理クラス
得点管理クラス

多神教でオケ。キャラクラスに自分を管理させようとするから、シーンクラスに違和感を持つ。

678 ：デフォルトの名無しさん：2012/05/03(木) 23:21:19.18

キチガイ相手しすぎ
伸びすぎ

679 ：uy：2012/05/03(木) 23:23:42.38

シーン管理クラスは
オブジェクトのそれぞれが自立するように書いていけばなくてよくなる
俺はシーン管理クラスじゃなくて、
作るとしてもシーンオブジェクト
基本通りにいくなら、複数のクラスやオブジェクトが必要な判定等は
シーンクラスに頼ったほうがいいんだろうね

680 ：デフォルトの名無しさん：2012/05/03(木) 23:24:58.42

なんでもかんでもシーンにするな

681 ：デフォルトの名無しさん：2012/05/03(木) 23:30:18.58

>>679
だからそのご都合主義が気持ち悪い人がいるんだろうし、
統一概念が緩いと、細部にも理解が行き難くなる。

682 ：デフォルトの名無しさん：2012/05/04(金) 00:12:28.53

>>636
え？シーンで処理しないならどこで爆発オブジェクトを生成するの？
ここをシーンでやるなら俺と代わらないからレスいらないや

683 ：デフォルトの名無しさん：2012/05/04(金) 00:16:23.48

俺だけが分かってるOO

684 ：デフォルトの名無しさん：2012/05/04(金) 00:16:56.81

工数でどのくらい削れるか測定不能なＯＯ

685 ：デフォルトの名無しさん：2012/05/04(金) 00:22:28.28

>>682
現実世界で考えてみろよ。

何が爆発する？
いきなり神がある空間に爆発を作り出すわけじゃないだろ。

爆弾に火が接触した時、何が爆発に変わるんだ？

686 ：デフォルトの名無しさん：2012/05/04(金) 00:24:47.87

設計レベルではOO有効だろ指針として
実装の詳細では無視してもいいけど

687 ：デフォルトの名無しさん：2012/05/04(金) 00:29:22.71

>>685
芸術

688 ：デフォルトの名無しさん：2012/05/04(金) 00:31:22.12

>>684
測定すると箱の中の猫が死んじゃうから

689 ：デフォルトの名無しさん：2012/05/04(金) 00:32:46.46

>>687
爆弾が仕込まれた絵画が
あるってこと？

690 ：デフォルトの名無しさん：2012/05/04(金) 00:34:20.46

>>684
> 工数でどのくらい削れるか測定不能なＯＯ

測定は可能だよ。
実際に作ってかかった時間を調べれば良い。

具体的なかかる時間は、内容や人にとって違うから
OOにかぎらず、ここで言えるわけないことだが。

691 ：デフォルトの名無しさん：2012/05/04(金) 00:36:04.76

人形劇だと思えば、キャラが持っていい独自の情報は形、色、関節、棒ぐらいだと分かる。単純。

692 ：uy：2012/05/04(金) 00:55:37.14

人形型、（ほとんどの共通処理を神オブジェクトで行う）
カラクリ人形型、（いくつかの処理を人形に任せるが、大半の共通処理を神オブジェクトで行う）
自立した人形型、（神オブジェクトを捨て、すべてを人形にやらせる）

ここら辺で彷徨ってるだけ

別にどれが正しいとかはないと思う
でも、ほとんどの奴はカラクリ人形型
人形型か、自立した人形型方面に特化し始めると、普通の人には読めなくなってくる

俺は自立した人形型

693 ：uy：2012/05/04(金) 00:59:54.94

>>685
なんか頭悪そうだよね君
現実世界で考えなくていいのに

ディスプレイに写す映像は、箱庭の中の世界なので
いきなり神がある空間にオブジェクト（爆発）を作り出すこともできるんだよ

俺としては、オブジェクトを別のオブジェクトに摩り替えるような設計はイヤだな
どんなゴミカスソースコードか興味がある
中学生か何かなの？

694 ：uy：2012/05/04(金) 01:01:29.63

>>636 >>685

どういう事？？？？

695 ：デフォルトの名無しさん：2012/05/04(金) 01:05:14.24

＞いきなり神がある空間にオブジェクト（爆発）を作り出すこともできるんだよ
できるってだけ。

通常はやらない。

696 ：デフォルトの名無しさん：2012/05/04(金) 01:05:20.84

自立した人形と言う矛盾

697 ：uy：2012/05/04(金) 01:05:53.26

もしかしてアレか、
最初に255とかオブジェクトを作って
その範囲内でゲーム作るとかそういう設計じゃなかろうな

やっぱどう考えても
1度作ったオブジェクトを別のものに変えていくっていうのはおかしいだろう
敵が被弾とかして、やられモーションになるとしても、
それはただ状態1が状態2になるとか、
あるいは敵オブジェクトを破棄して直後に敵やられモーションオブジェクトを生成でもいいし

オブジェクトを何かに変えるってのはおかしい
＞爆弾に火が接触した時、何が爆発に変わるんだ？

何もかわらねーよｗ
プログラムの世界で、それは爆弾オブジェクトは消滅して爆発オブジェクトが生成されるだけだよ

698 ：デフォルトの名無しさん：2012/05/04(金) 01:07:05.49

＞俺としては、オブジェクトを別のオブジェクトに摩り替えるような設計はイヤだな
すり替えなくてもいい。

さっきも言ったとおり
> オブジェクトは衝突メッセージが送られてきた時に
> 無視する、自分自身を変化させる、新しいオブジェクトを生成する
> などの動作を行う。

699 ：デフォルトの名無しさん：2012/05/04(金) 01:07:59.77

> プログラムの世界で、それは爆弾オブジェクトは消滅して爆発オブジェクトが生成されるだけだよ

正確に言えば、爆弾オブジェクトが、爆発オブジェクトを生成して
自分は消えるってことだ。

700 ：uy：2012/05/04(金) 01:09:37.37

>>695
はぁ？
もうだめdaこいつ

知識ないのに無理に会話してるのが見え見え･･･

>>699999
そんなのどうでもいいよｗ
作り方の問題なので

701 ：デフォルトの名無しさん：2012/05/04(金) 01:09:42.41

爆弾オブジェクトが、爆発オブジェクトに
摩り替わるってことね。

702 ：デフォルトの名無しさん：2012/05/04(金) 01:10:07.81

>>700
反論ないなら黙ってろ。

703 ：デフォルトの名無しさん：2012/05/04(金) 01:11:09.98

uyよ。

さっきから俺が言っていることに
お前が後からついてきているだけになってるぞ。

704 ：uy：2012/05/04(金) 01:11:43.81

>>698
>>701
ひとつ言わせてもらうと
「摩り替える」のはおかしいよ

>>702
当たり前のことを書き込みすぎて困る

705 ：デフォルトの名無しさん：2012/05/04(金) 01:12:12.81

> 「摩り替える」のはおかしいよ
全くおかしくない。

なぜならおかしいの理由が書いてないからだ。

706 ：デフォルトの名無しさん：2012/05/04(金) 01:13:19.02

> それは爆弾オブジェクトは消滅して爆発オブジェクトが生成される

爆弾オブジェクトが、爆発オブジェクトに摩り替わる。

同じ意味です。

707 ：uy：2012/05/04(金) 01:14:42.88

>>706
同じじゃない
「見た目」的な意味で摩り替わるといっているのか
「メモリー」上で摩り替わるといっているのか

708 ：uy：2012/05/04(金) 01:16:45.48

>>705
オブジェクトの状態を変えていく時に、
破棄、生成をせずに内容を摩り替え続けるような処理を書いていたら
1つのオブジェクトが巨大になりすぎる

どういうゲーム製作でそのようなコードの書き方をした？

709 ：デフォルトの名無しさん：2012/05/04(金) 01:16:59.69

>>707
「摩り替わる」と最初に言ったのはあなたです。

違う意味であるというのなら、
「新しいオブジェクトを生成して自分は消える」
ということを「摩り替わる」と言わないで下さい。

「摩り替わる」と最初に言ったのはあなたです。

710 ：デフォルトの名無しさん：2012/05/04(金) 01:17:12.71

>>685
えー、おかしいよー
ロボだったらスクラップになって吹っ飛ぶステータスに移る必要がある
爆発は爆発で必要だろうよ

711 ：デフォルトの名無しさん：2012/05/04(金) 01:18:11.98

673 名前：デフォルトの名無しさん[sage] 投稿日：2012/05/03(木) 22:57:59.00
※「爆発」と言うの禁止

話をまとめると、衝突検出自体はシステムが行って
各オブジェクトに衝突メッセージを送る。

オブジェクトが衝突した時にどうなるかは
オブジェクト自身しか知らないわけだから、
オブジェクト自身に記述する。

オブジェクトは衝突メッセージが送られてきた時に
無視する、自分自身を変化させる、新しいオブジェクトを生成する
などの動作を行う。

712 ：デフォルトの名無しさん：2012/05/04(金) 01:18:12.72

>>703
しー
もう少し泳がせれば面白かったのに

713 ：uy：2012/05/04(金) 01:19:06.27

>>709
俺は>>685 このレスをみて「摩り替える気か？」と察しただけ
>>685 が摩り替えるという意味ではない書き込みだとすれば
どのような処理を考えているのか、10行程度でいいので日本語ではなくソースコードをかいてくれないかね？

714 ：デフォルトの名無しさん：2012/05/04(金) 01:19:42.05

> 俺は>>685 このレスをみて「摩り替える気か？」と察しただけ

お前が間違って思っただけ。

自分を正当化するな。

715 ：デフォルトの名無しさん：2012/05/04(金) 01:20:43.14

>>713

最初からオブジェクトが新しいオブジェクトを生成して
自分は消えるということしか話してないよね？

君は一体何を見て「摩り替える」と思ったんだい？

716 ：uy：2012/05/04(金) 01:20:50.04

>>714
ん？
>>685 ここに
＞いきなり神がある空間に爆発を作り出すわけじゃないだろ。
ってあるから

新規に爆発オブジェクトを作り出すわけじゃないんだろ？ｗ

ちょっと、そーすこーどｐｌｚｗｗ

717 ：デフォルトの名無しさん：2012/05/04(金) 01:21:31.07

uyが「摩り替える」をどういう意味で使っているのか気になるな。

そして、その話がこのスレで出てきたのか？

718 ：uy：2012/05/04(金) 01:22:58.39

いやマジ謎なんだけど>>685

＞いきなり神がある空間に爆発を作り出すわけじゃないだろ。

･･･つまり？

719 ：デフォルトの名無しさん：2012/05/04(金) 01:23:20.39

>>716
なんで、文章を中途半端に引用するの？

わ・ざ・と？

それとも、ば・か？

現実世界は神がいきなりある空間に
爆発を作り出すわけじゃなく、
現実世界では何かが変化するって書いてあるだけだろ。

なんで一行だけ抜き出すの？

720 ：デフォルトの名無しさん：2012/05/04(金) 01:24:28.82

>>713
abstract class 爆発あぶる {
public 爆発あぼーん(衝突);
}

721 ：デフォルトの名無しさん：2012/05/04(金) 01:25:16.07

そもそもの話は、
爆発オブジェクトをどこで生成するのかわからないって書いてあるレスに対して
現実世界を見習えば簡単にわかるって書いてあるだけの話だね。

なんで、uyは読解力がないの？

722 ：uy：2012/05/04(金) 01:25:40.90

>>719
＞現実世界で考えてみろよ。

＞何が爆発する？
＞いきなり神がある空間に爆発を作り出すわけじゃないだろ。

＞爆弾に火が接触した時、何が爆発に変わるんだ？

なんでこのレスをしたの？
プログラムの話をしているところに、現実世界の話をもってきたっていうことは
現実世界と同じようにプログラムを書くとか、そういうこといってるようにしか聞こえないけど？

ちょっとそーすこーどあげてくださいよ

723 ：デフォルトの名無しさん：2012/05/04(金) 01:25:53.54

>>721
uyの仕様です

724 ：デフォルトの名無しさん：2012/05/04(金) 01:26:43.93

>>722
はぁ？現実世界を見習えば
どこで爆発オブジェクト生成するか、
簡単にわかるって話だろ。

読解力無いなｗ

725 ：uy：2012/05/04(金) 01:26:59.57

>>720
それが限界か？

>>721最初に君のレスに触れたのは俺じゃなくて、違う奴だよｗ

つまり、>>685はなかったことにしたいって事かね

726 ：デフォルトの名無しさん：2012/05/04(金) 01:27:54.06

> >>721最初に君のレスに触れたのは俺じゃなくて、違う奴だよｗ

誰も、俺のレスに最初に触れた奴の話なんかしてない。

馬鹿なのか？

727 ：デフォルトの名無しさん：2012/05/04(金) 01:28:47.61

>>725
だからね。現実世界を見習えば
どこで爆発オブジェクトを生成すればいいかは
わかるって話だよ。

これ何回いった？
何回言えば理解できる？

728 ：デフォルトの名無しさん：2012/05/04(金) 01:29:13.47

>>725
限界とかw
おまえの小汚いバグありコードより
明確だわ

729 ：uy：2012/05/04(金) 01:29:46.19

>>724
え？ｗｗｗ現実世界を見習えばどこで爆発オブジェクト生成するか、
簡単にわかるって話になっちゃったの？ｗｗｗｗｗｗｗｗ

うまい言い訳を見つけたねｗｗｗ

でも、残念だけど
>>668ここに
＞オブジェクト自身が変化する。
＞オブジェクトの変化と生成に対応していれば、なんでも対応できるよ。

こんな事が書かれてるよ？

730 ：デフォルトの名無しさん：2012/05/04(金) 01:30:17.53

で、uyはどういう処理を
「摩り替える」処理だと思ったの？

たしか、新しいオブジェクトを生成して
自分は消えるということではないと
言っていたよね？

731 ：デフォルトの名無しさん：2012/05/04(金) 01:30:55.20

>>729
日本語読む力なさすぎだ
状態変化だろ？バカだろおまえ

732 ：デフォルトの名無しさん：2012/05/04(金) 01:31:34.08

>>729
重要な所を引用してやろうか？

いいわけじゃない。書いてあることそのまんまだ。

682 名前：デフォルトの名無しさん[sage] 投稿日：2012/05/04(金) 00:12:28.53
>>636
え？シーンで処理しないならどこで爆発オブジェクトを生成するの？

685 名前：デフォルトの名無しさん[sage] 投稿日：2012/05/04(金) 00:22:28.28
>>682
現実世界で考えてみろよ。

733 ：デフォルトの名無しさん：2012/05/04(金) 01:32:13.34

>>730
uyの底は>>729で割れてる。
しょせん狭視野の決めつけ君だよ

734 ：uy：2012/05/04(金) 01:32:27.88

>>731
あｗｗ君は、やっぱり、オブジェクト自身を変化させるんでしょ？

やっぱそうじゃん
オブジェクトを、状態1→状態2→状態3ってやっていくんでしょ

735 ：デフォルトの名無しさん：2012/05/04(金) 01:33:14.16

>>734

最初っから↓と書いたとおりだ。

＞オブジェクト自身が変化する。
＞オブジェクトの変化と生成に対応していれば、なんでも対応できるよ。

736 ：デフォルトの名無しさん：2012/05/04(金) 01:33:49.53

>>734
ライフがへる。
あとお前が思う君じゃないよ俺は

737 ：uy：2012/05/04(金) 01:34:45.11

>>735
ん？そこのレスは「なかったこと」にしなくて大丈夫なの？

オブジェクトを、状態1→状態2→状態3ってやっていくようなソースコードかいていたら
オブジェクトが巨大になっちゃうから
俺は
状態1,2,3ごとに別オブジェクトにして
破棄、生成を繰り返せといっているのに

ちょっとこれに答えてほしい、なんのゲームでそのソースコードの書き方をしたのか

>>708 ：uy：2012/05/04(金) 01:16:45.48
>>705
オブジェクトの状態を変えていく時に、
破棄、生成をせずに内容を摩り替え続けるような処理を書いていたら
1つのオブジェクトが巨大になりすぎる

どういうゲーム製作でそのようなコードの書き方をした？

738 ：デフォルトの名無しさん：2012/05/04(金) 01:35:13.31

> あｗｗ君は、やっぱり、オブジェクト自身を変化させるんでしょ？

最初っからその話ししてるだろｗ
やっと追いつたのか

739 ：デフォルトの名無しさん：2012/05/04(金) 01:35:51.31

> 俺は
> 状態1,2,3ごとに別オブジェクトにして
> 破棄、生成を繰り返せといっているのに

みんなその話を最初からしていたんだよ。

やっと追いついたのか？

740 ：デフォルトの名無しさん：2012/05/04(金) 01:36:35.09

>>737
ちょっと自機のライフの増減を表現してくれないか？
おまえの大好きなコードでいいから

741 ：デフォルトの名無しさん：2012/05/04(金) 01:37:17.14

誰が、破棄と生成をするなっていったんだぁ？

最初から、新たなオブジェクトを生成して
自分は消えるという話しかしてないよね？

742 ：uy：2012/05/04(金) 01:37:49.69

>>709
＞違う意味であるというのなら、
＞「新しいオブジェクトを生成して自分は消える」
＞ということを「摩り替わる」と言わないで下さい。

これ、新しいオブジェクトを生成して自分は消える　という事を摩り替わるとはいっておらず、

＞オブジェクト自身が変化する。
＞オブジェクトの変化と生成に対応していれば、なんでも対応できるよ。

ここに対しての突っ込みですよ＾＾；；

変化させるんでしょ？　　処理を変化させることと処理を摩り替えることは同義

743 ：デフォルトの名無しさん：2012/05/04(金) 01:38:09.51

uyが理解してないから
もう一回書いておくわｗ

673 名前：デフォルトの名無しさん[sage] 投稿日：2012/05/03(木) 22:57:59.00
※「爆発」と言うの禁止

話をまとめると、衝突検出自体はシステムが行って
各オブジェクトに衝突メッセージを送る。

オブジェクトが衝突した時にどうなるかは
オブジェクト自身しか知らないわけだから、
オブジェクト自身に記述する。

オブジェクトは衝突メッセージが送られてきた時に
無視する、自分自身を変化させる、新しいオブジェクトを生成する
などの動作を行う。

744 ：デフォルトの名無しさん：2012/05/04(金) 01:38:59.01

> 処理を変化させることと処理を摩り替えることは同義

またいきなり、変な話を始めたぞ・・・
誰がそんな話をしていたんだ？

745 ：デフォルトの名無しさん：2012/05/04(金) 01:39:44.84

変化するのはオブジェクトだろ
摩り替わるのもオブジェクトだろ。

何をいってるんだこいつは・・・

746 ：デフォルトの名無しさん：2012/05/04(金) 01:39:59.15

uyは自分の知識が狭いんだろう
決めつけが多すぎてがっかりだよ

747 ：uy：2012/05/04(金) 01:40:30.84

>>741
生成、破棄ならわかる
でも「変化」させるって言ってる奴がいるんだよ

>>673
＞自分自身を変化させる、新しいオブジェクトを生成する

>>668
＞オブジェクト自身が変化する。
＞オブジェクトの変化と生成に対応していれば、なんでも対応できるよ。

>>655
＞それぞれ衝突情報を元に、自分自身の変化を記述すれば良い。
＞自分自身が変化してもいいし、新たなオブジェクトを生成して
＞自分は消えても良い。

＞自分自身が変化してもいいし
＞自分自身が変化してもいいし
＞自分自身が変化してもいいし

748 ：デフォルトの名無しさん：2012/05/04(金) 01:40:56.79

A または B と言ってるのに

uyはAだろ？
Aって言っただろ。
Aのみだろ？

って変な話をしてる。

749 ：デフォルトの名無しさん：2012/05/04(金) 01:41:44.33

キャラ自体が爆発を管理するか、
神がキャラも爆発も同等な物として管理するか
って事だろ？

750 ：デフォルトの名無しさん：2012/05/04(金) 01:42:07.45

>>747
生成、破棄も変化も両方ありえます。

↓ここにちゃんと書いてます。
＞自分自身が変化してもいいし、新たなオブジェクトを生成して
＞自分は消えても良い。

> 新たなオブジェクトを生成して自分は消えても良い。
> 新たなオブジェクトを生成して自分は消えても良い。
> 新たなオブジェクトを生成して自分は消えても良い。
> 新たなオブジェクトを生成して自分は消えても良い。

751 ：uy：2012/05/04(金) 01:42:49.23

>>748
どこで、どういう状況で、どんなゲームを作るときに
「自分自身が変化」させるソースコードが適任になるのか見てみたいよね

そのコードをかいた時のゲームのジャンルは何？規模は？
答えられないのでしょうかね

752 ：デフォルトの名無しさん：2012/05/04(金) 01:43:17.93

>>747
ライフ増減は都合悪いからシカトですかー？
状態を変化させないコードさっさとかけや

753 ：デフォルトの名無しさん：2012/05/04(金) 01:44:19.41

uyの敗退既に確定してるんだから
おまえらもうその辺にしといてやれ

754 ：デフォルトの名無しさん：2012/05/04(金) 01:45:01.38

>>751
> 「自分自身が変化」させるソースコードが適任になるのか見てみたいよね

自分自身にHP回復の魔法をかけた時。

755 ：uy：2012/05/04(金) 01:45:49.38

>>750
んで、どんなときに「変化を」使うんだい？

>>752
ライフ？ｗ　それオブジェクトの状態つうか変数の値じゃん
そんなのx,y座標だって常に変わり続けているだろう

↓君が言っている変化はライフポイントやx,y座標のことではないと思う

>>673
＞自分自身を変化させる、新しいオブジェクトを生成する

>>668
＞オブジェクト自身が変化する。
＞オブジェクトの変化と生成に対応していれば、なんでも対応できるよ。

>>655
＞それぞれ衝突情報を元に、自分自身の変化を記述すれば良い。
＞自分自身が変化してもいいし、新たなオブジェクトを生成して
＞自分は消えても良い。

756 ：デフォルトの名無しさん：2012/05/04(金) 01:46:09.52

もうやめてあげて！
uyのライフはゼロよ！！

757 ：デフォルトの名無しさん：2012/05/04(金) 01:47:48.80

>>755
だから、変化するのはオブジェクトの状態だって言ってるだろ？

お前は何が変化すると
勘違いしているのか？

758 ：デフォルトの名無しさん：2012/05/04(金) 01:48:39.28

>>755
> ライフ？ｗ　それオブジェクトの状態つうか変数の値じゃん
> ライフ？ｗ　それオブジェクトの状態つうか変数の値じゃん
> ライフ？ｗ　それオブジェクトの状態つうか変数の値じゃん

く・・・苦しい言い訳キター

┐(´ｰ｀)┌

759 ：uy：2012/05/04(金) 01:50:24.16

え・・・終わり・・・？

話のすり替えがうまいのはよくわかった
3回もやられたｗｗｗ
1回
>>668
>>672

2回
>>735
>>737

3回
>>754
>>755

ふええ・・・すりかえられたよお

760 ：デフォルトの名無しさん：2012/05/04(金) 01:50:30.62

>>756
問題ない。

死んでも生き返らせればいい。

761 ：uy：2012/05/04(金) 01:51:04.79

>>758

↓君が言っている変化はライフポイントやx,y座標のことではないと思う

>>673
＞自分自身を変化させる、新しいオブジェクトを生成する

>>668
＞オブジェクト自身が変化する。
＞オブジェクトの変化と生成に対応していれば、なんでも対応できるよ。

>>655
＞それぞれ衝突情報を元に、自分自身の変化を記述すれば良い。
＞自分自身が変化してもいいし、新たなオブジェクトを生成して
＞自分は消えても良い。

762 ：デフォルトの名無しさん：2012/05/04(金) 01:51:18.40

uy老年の主張：

　ライフ増減は状態変化じゃない
　「つうか変数の値じゃん」

763 ：デフォルトの名無しさん：2012/05/04(金) 01:51:45.08

>>759
問題ない。

何度も生き返らせればよい。

764 ：uy：2012/05/04(金) 01:52:21.88

>>762
つまり
----
>>673
＞自分自身を変化させる、新しいオブジェクトを生成する

>>668
＞オブジェクト自身が変化する。
＞オブジェクトの変化と生成に対応していれば、なんでも対応できるよ。

>>655
＞それぞれ衝突情報を元に、自分自身の変化を記述すれば良い。
＞自分自身が変化してもいいし、新たなオブジェクトを生成して
----
これらの発言の中の「変化」とは、ライフポイントのことだったのか！！！！！ｗｗｗｗｗｗｗそりゃ気づけないわｗｗｗ

765 ：デフォルトの名無しさん：2012/05/04(金) 01:52:40.84

>>762
OOスレでこれ>>755は恥ずかしい ///

766 ：デフォルトの名無しさん：2012/05/04(金) 01:52:42.20

>>761
> ↓君が言っている変化はライフポイントやx,y座標のことではないと思う

お前がそう思った。

それがそもそも間違いだった。

読解力がないのがuyである。

767 ：デフォルトの名無しさん：2012/05/04(金) 01:54:04.25

>>764
> これらの発言の中の「変化」とは、ライフポイントのことだったのか！！！！！ｗｗｗｗｗｗｗそりゃ気づけないわｗｗｗ

これに気づかないのは恥ずかしいｗ

オブジェクト指向で、オブジェクト自身の状態の変化といえば、
ライフポイントのことなどに決まってる。

768 ：uy：2012/05/04(金) 01:54:36.54

>>766
でもよく読め読んでよ

>>668
＞オブジェクト自身が変化する。
＞オブジェクトの変化と生成に対応していれば、なんでも対応できるよ。

n・・・？
「に対応していれば、なんでも対応できるよ。」
「なんでも対応できるよ。」

「　な　ん　で　も　」

「なんでも」てことはライフポイントのことだけじゃなさそうだねｗ

769 ：uy：2012/05/04(金) 01:55:30.68

>>767
それは気づけないわ･･･････････

770 ：デフォルトの名無しさん：2012/05/04(金) 01:55:47.20

オブジェクト指向で状態といえば、
内部の変数のこと。

「状態を持っている」いうのは
オブジェクトの内部に
（オブジェクトスコープの）変数があるってこと。

状態の変化といえば、その変数の値が変わること。

これは常識だよ。

771 ：736：2012/05/04(金) 01:56:26.48

>>764
なあuy
俺は>>655じゃないんだが、普通に想定出来たぞ？
>>665読み直してきたらどうかな。うん。

772 ：デフォルトの名無しさん：2012/05/04(金) 01:56:42.63

>>769
だからみんなが、お前は馬鹿だって言ってるの。

やっとみんなの理解に追いつけたのかｗ

773 ：uy：2012/05/04(金) 01:57:56.50

あ、変化をライフポイントって文字入れてみたらしっくりきたｗｗｗｗｗｗ
これは俺の負けでいいわｗｗｗｗｗｗｗｗｗ

>>673
＞自分自身をライフポイントを変化させる、新しいオブジェクトを生成する

>>668
＞オブジェクト自身がライフポイントを変化する。
＞オブジェクトのライフポイントを変化と生成に対応していれば、なんでも対応できるよ。

>>655
＞それぞれ衝突情報を元に、自分自身のライフポイントを変化を記述すれば良い。
＞自分自身がライフポイントを変化してもいいし、新たなオブジェクトを生成して
----

774 ：デフォルトの名無しさん：2012/05/04(金) 01:58:08.22

uyは教えてもらっている気がすると言っていたが、

本当に教えてもらってるなｗ

775 ：デフォルトの名無しさん：2012/05/04(金) 01:59:20.19

UGL
uyの自作してきたGameにはLifeはなかったから想定出来ません

776 ：デフォルトの名無しさん：2012/05/04(金) 02:00:17.09

もうやめてあげて！
uyのゲームにライフは無いよ！！

777 ：デフォルトの名無しさん：2012/05/04(金) 02:02:02.99

なんかしらんが、変なコテハンを
コテンパンにしたらしい。

なんか面白い。

コテハンをコテンパン

778 ：uy：2012/05/04(金) 02:03:55.16

引き続きゴールデンウィークをお楽しみください

779 ：デフォルトの名無しさん：2012/05/04(金) 02:05:11.81

もう終わったのか？
1日、2日は仕事だったから

俺にとってはGW後半4連休の
初日なんだが。

時間的には2日目だが。

780 ：デフォルトの名無しさん：2012/05/04(金) 02:05:44.10

　　 _, ,_ 　ﾊﾟｰﾝ
　（　‘д‘）
　　⊂彡☆))Д´） >>777

781 ：デフォルトの名無しさん：2012/05/04(金) 02:07:42.40

殴るなよ。俺大活躍だっただろｗ

782 ：デフォルトの名無しさん：2012/05/04(金) 02:13:02.72

自立は諦めなさい。さすれば道は開けるであろう。

783 ：デフォルトの名無しさん：2012/05/04(金) 02:13:41.30

つまり、毎日日曜日になれってこと？

784 ：デフォルトの名無しさん：2012/05/04(金) 02:14:09.09

uyはゴールデンウィークなさそう。

毎日日曜日だから。

785 ：デフォルトの名無しさん：2012/05/04(金) 02:16:07.63

uyは潔いな
まぁ本当の実力は分かる人には分かるからな

むしろ勝ったと思い込んでる人らが哀れに見えるな
実は周回遅れだとも気づかずに…

786 ：デフォルトの名無しさん：2012/05/04(金) 02:17:44.97

uyに教えてあげた。

uyは少し力がついた。

そして、俺の凄さを理解できるようになった。

787 ：デフォルトの名無しさん：2012/05/04(金) 02:24:57.95

>>785
潔い部分は評価してもいい
だがそれ以前がウザ杉た
>>582の命名センスや晒したコードからして出自が関数型つーの？OOは初心者レベルだ
もっとしおらしくしてればいいのに粋がるから>>665がブーメランになるんだよ

788 ：デフォルトの名無しさん：2012/05/04(金) 02:57:26.81

プログラム全体を一本で書くのを効率的だ、なんて言う奴に関数型もクソもねぇだろ。

789 ：デフォルトの名無しさん：2012/05/04(金) 03:39:57.80

面白いおもちゃを一つなくした

790 ：uy：2012/05/04(金) 04:35:58.30

俺は自分の技術を知ってる
俺が本当にディスりたいのは初心者ではなく、
調子に乗ってしまっている中級者、上級者

こんなスレなど初心者との戯れに過ぎない

791 ：デフォルトの名無しさん：2012/05/04(金) 05:01:06.80

じゃあ、自分自身をdisらないといけないなｗ

792 ：uy：2012/05/04(金) 05:13:18.18

俺は上級者ではない
上級者をdisれるのは、更なる高みにいる者だけだ

793 ：デフォルトの名無しさん：2012/05/04(金) 05:14:26.67

　　　　　　｜　　　　 |／)+}∠..ノ: :+:∠: : +: ∠: :+:!: :.! 　 |
　　　　　　｜　　　　Ｌノノ: :+: :(...／ゝ: : ／_:_:_:_.ノ∠Ｌ　|
　　　　　　｜　　　ﾉ　厂￣￣￣厂￣ﾉハﾊ:.!ヽ: : : : :＼|
. 　　　　 |/　ｰ=彡' : : : :/: : :／:.:.／　 !　　`トハ l: :.厂 !
.　　　　　 /　　　　/: : ﾉ: /: :∠../∠厶ｲﾉ　　｣ﾉ__｣ハﾊ.　| 　　　　　ハァーーーーー？
　　　　　 /　　　　厶イ: :/／＿＿＿___ｰ　　　 ´弋ﾝ{　｜/
.　　　　 /　　　　　 |: : {　ヽ　弋Ｚソ　　　　　ｰ''＾|　 |,′
　　　　/　　　　　 /|: : |　　＾''ー一' 　　 ,　　　　八 .!
.　　　/　　　　　 /‐|: : |　　　 /､＿＿＿, 　　 /|:::ヽ', 　　　 __ .、
　{｀ヽ｀ヽ. 　　　 /ム|: : |｀ﾄ .　　{　　　　∨　　..ｲ: |::::::／）　／／ﾉ
. （｀ヽ｢ヽ＼i｀ヽ /く:.:.:!: : !、＼｀　ヽ..＿_,ノ　 .イヽｊ: :|:::/　ムイ／／ﾉ
　＼ |　i ヽ＼　＼.> |: : |:.＼　` ｰﾆ二厂｢　ｒ=ミ.|: :|/ 　　　／／ﾉ
　　/∧ ゝ、　　　ヽ.!: : ! :.:.:.＼　　イ:.: :l　 Vノﾍ: :|　　　　　　／
.　//　＼　　　　　 }: : l:.:.:.:.:.:.:.＼　ﾉ:.:.:/　　＼|: :| 　　　 . イ

794 ：デフォルトの名無しさん：2012/05/04(金) 05:16:27.36

>>792
調子にのってる初心者だろ？

795 ：デフォルトの名無しさん：2012/05/04(金) 05:44:37.12

アンカーつけるなバカ

796 ：デフォルトの名無しさん：2012/05/04(金) 07:42:35.32

>>732
マジでわかんねー
シーンで処理しないならどこでオブジェクト作るの？

797 ：デフォルトの名無しさん：2012/05/04(金) 08:02:20.60

シーんでナンデモカンデモやるのは良くない。

798 ：デフォルトの名無しさん：2012/05/04(金) 11:05:28.99

ちゃんとかかれたC++のソースコードはコンパクトにまとまっていて使いやすいよ

ひどい目にあってるのは良く判ってない人が作ったものを使っている場合だと思われる。

799 ：デフォルトの名無しさん：2012/05/04(金) 11:32:31.17

ＯＯをきちんと理解していたとしてもセンスの無いやつが
作ったものは使い物にならないw

800 ：デフォルトの名無しさん：2012/05/04(金) 12:29:29.77

Firefoxか何かのソースを読んでみたことがあったが、高度にオブジェクト指向を使いこなしているんだろうけど、
例えばブラウザの中のHTMLパーサー機能だけを切り出して、自分のソフトで使おうとしても全然できない。
芋づる式にいろんなものを引っ張ってこなくてはいけなくて、依存性の根が深くて諦めた。
もうちょっとシンプルに切り分けて貰えないものだろうか。

801 ：デフォルトの名無しさん：2012/05/04(金) 13:48:40.80

>>576
＞現実世界において、AとBが全く同じ場所（＋同じ時間）に重なって
＞存在することは出来ない。これは世の中がそうなっているから。

できるよ。思慮が足りないんじゃないか？

802 ：デフォルトの名無しさん：2012/05/04(金) 13:52:16.64

さて今からどういう場合にできるのか
説明が始まります。

ニヤニヤして屁理屈を聞きましょうｗ

803 ：デフォルトの名無しさん：2012/05/04(金) 13:53:36.21

当たり判定だの爆発だのいってるんだから
戦闘機をモデリングしてるんだろ

その状況で>>801は意味あるの？少しは頭使え

804 ：デフォルトの名無しさん：2012/05/04(金) 14:10:12.06

>>800
禿しく同意。
OOは構造が複雑になり過ぎる。

前に同じアプリを構造化とOOで書き較べた事がある。（数万ステップ規模）
先に構造化で作りそのあとにOOで作ったのから、本来なら後に作ったOOでの作成が有利だが
OOより構造化の方が早く正確に出来た。

OOの最大の問題点は構造が複雑になること。

805 ：デフォルトの名無しさん：2012/05/04(金) 14:12:52.76

OOは構造が複雑になり過ぎる(ｷﾘｯ

806 ：デフォルトの名無しさん：2012/05/04(金) 14:16:15.58

>>804
OO 出来ない自慢のスレじゃないから。

807 ：デフォルトの名無しさん：2012/05/04(金) 14:17:17.46

>>804
ＯＯでもＯＯとしての美しさと汎用性を求めなければ同じじゃないのか？

808 ：デフォルトの名無しさん：2012/05/04(金) 14:19:21.64

>>806
OO原理主義者は引っ込んでろ。
OOにして生産性と保守性が落ちたのでは何の意味もない。

809 ：デフォルトの名無しさん：2012/05/04(金) 14:20:51.25

やっぱり理解できてないのか。
ま、こんなスレのレベルではそんなもんだろうね。

810 ：デフォルトの名無しさん：2012/05/04(金) 14:21:52.01

>>808
うん。おまえには10年速いよ。坊やは巣に帰るんだ

811 ：デフォルトの名無しさん：2012/05/04(金) 14:31:31.17

簡単なものを複雑に実装する
これぞＯＯの極意なり

複雑な割には必要なものがない
これもＯＯの極意

複雑すぎて作ったやつにしか使いこなせない
これもＯＯの極意

812 ：デフォルトの名無しさん：2012/05/04(金) 14:32:56.95

OO出来ない自慢はやってるの？

813 ：デフォルトの名無しさん：2012/05/04(金) 14:37:12.51

時代は関数型です

814 ：デフォルトの名無しさん：2012/05/04(金) 14:39:41.13

関数型じたいは悪くないけど
関数型しか出来ない奴のコードって
想像を絶するほど悲惨なことになってるよね

815 ：デフォルトの名無しさん：2012/05/04(金) 14:40:56.71

>>800
あるね
頑張ってＯＯやってるから機能で切り分けてるのかと思ったら
全然カプセル化できてないの

君、なんのためのＯＯなん？いつも何に頭捻ってるの？
まったく意味を感じないんですけど？

って思わず返したくなるほどなんの機能も切り出せないの
１つ１つのクラスを他の誰かが使う想定で作ってないんだよね

816 ：デフォルトの名無しさん：2012/05/04(金) 14:44:16.66

>>814
関数型しか出来ないやつって現実世界に存在するのか?

817 ：デフォルトの名無しさん：2012/05/04(金) 14:48:43.54

>>816
OO言語＝OOなプログラムじゃないから
関数型でしか使えない奴とかいるだろ

818 ：デフォルトの名無しさん：2012/05/04(金) 14:50:41.77

>>814
関数型しかできない奴なんて滅多にいないぞ
お前が関数型しか出来ないと思ってる奴は、はるか昔にOOを通り過ぎた奴
OOよりも圧倒的に情報量やノウハウ蓄積の少ない関数型プログラミングを出来る奴が
OOしか出来ない奴よりも下って事はないｗ
ちなみに俺のコードはOOでも関数型でもないので、理解しようとしなくていい

>>801
量子力学やってこい
アレも現実世界だろ

819 ：デフォルトの名無しさん：2012/05/04(金) 14:52:26.84

>>818
急に顔真っ赤にしてどうした？

820 ：デフォルトの名無しさん：2012/05/04(金) 14:52:39.19

構造化=処理の追加が容易
OO=データの追加が容易
関数型=並列化が容易

って特徴があるんだから、
これだけで良いって事はないんじゃないかな。

821 ：デフォルトの名無しさん：2012/05/04(金) 14:53:53.49

>>815
OOは手段であって目的ではないから。

>１つ１つのクラスを他の誰かが使う想定で作ってないんだよね

汎用OOライブラリ作るんが目的じゃなきゃそうでしょ。

822 ：デフォルトの名無しさん：2012/05/04(金) 14:53:54.10

関数型とOOともに満足に使いこなせない自慢って流行ってるの？

823 ：デフォルトの名無しさん：2012/05/04(金) 14:55:22.13

関数型しか出来ない奴なんて
研究職とか、趣味で変な方向に行ってる奴だけだろ

そんな奴のソースコードを見る機会が>>814,817にはあるのか？ｗ
その関数型しか出来ない奴のひどいソースコードを見せてくれよｗ

824 ：デフォルトの名無しさん：2012/05/04(金) 14:55:41.10

>>818
量子力学やりなおしてこい
この場合に適用できるのか？すらわからんのだろ

825 ：デフォルトの名無しさん：2012/05/04(金) 14:57:42.55

>>823
残念だが俺にはかけない。
代案としお前自身のコードを見るのはどうだ？

826 ：uy：2012/05/04(金) 14:58:48.41

>>800
それって、元々Firefoxが使わせる気ないんじゃないの？
IEみたいにCOMとしても使えないじゃん

827 ：デフォルトの名無しさん：2012/05/04(金) 15:07:35.54

無能の発想
俺には出来ない→作りが悪い

常人の発想
俺にはできない→調べ方が悪い

Firefoxのパーサーすら使えない調査力とか終わってる

828 ：デフォルトの名無しさん：2012/05/04(金) 15:13:05.12

>>827
Firefoxのパーサーの一部を切り出して使おうとしたら
OOスパテッティ状態だったって事でしょ。

829 ：デフォルトの名無しさん：2012/05/04(金) 15:13:11.96

もし本当に、FirefoxのHTMLパーサーが
取り出しにくいのであれば、こんなことは出来ないだろ？

単に、>>800が馬鹿なだけ。

FirefoxにHTML 5パーサ、Java→C++自動変換で性能改善3%
http://news.mynavi.jp/news/2009/07/13/020/index.html

Mozillaの開発リポジトリにHTML 5パーサの実装が追加された。
これはHenri Sivonen氏が開発したValidator.nu (X)HTML5 Validatorをベースにしたもの。
Validator.nu (X)HTML5 Validatorは初期に実装されたHTML 5パーシングルール実装のひとつで、
Javaで実装されSAX/DOM/XOMインタフェースを提供している。
XHTML 1.0に対応したアプリのXMLパーサをそのまま置き換えることが可能。

830 ：デフォルトの名無しさん：2012/05/04(金) 15:13:35.31

スパテッティ食えない Orz

831 ：デフォルトの名無しさん：2012/05/04(金) 15:15:35.22

実際に使えるレベルのHTMLパーサーで、
オブジェクト指向じゃないものと比較したいわけだが、

オブジェクト指向じゃない、HTMLパーサーって有るのかな？ｗ

832 ：デフォルトの名無しさん：2012/05/04(金) 15:15:43.44

>>828
公開してない範囲は、戦略的に崩す選択肢がある
それはOOのメリットの一つだろ

833 ：デフォルトの名無しさん：2012/05/04(金) 15:16:49.27

OOスパゲッティとはどんな意味ですか？
スパゲッティ中心に食事を考えることですか？

834 ：804：2012/05/04(金) 15:16:51.10

将来の保守性・汎用性のためにOOでは構造を複雑になっているから
新規作成の場合、OOが構造化よりコストが掛かるのは当たり前。
OOが使える人間なら理解出来ていると思っていたが？

機能もGofのデザインパターンを見れば分かるが
クラス群として一つの機能を実装している。
その構造にあった機能ならいいが、一部の機能だけを取り出すのは難しい。

まっSingletonやAdapterパターンぐらいしか使えない人間には分からない世界だが。

835 ：デフォルトの名無しさん：2012/05/04(金) 15:17:01.05

>>832
あほ、Firefoxのパーサーは
オブジェクト指向でかつ
入れ替え可能になってる。

オブジェクト指向のメリットといっても良いｗ

836 ：デフォルトの名無しさん：2012/05/04(金) 15:17:49.09

>>834
逆に言えば、非OOは
将来の保守性と汎用性を
切り捨ててるってことだな。

837 ：デフォルトの名無しさん：2012/05/04(金) 15:18:38.70

そりゃ、将来の汎用性と保守性を
切り捨てれば、コストは削減できるだろうね。

838 ：デフォルトの名無しさん：2012/05/04(金) 15:19:10.57

>>834
低スキル自慢あきた

839 ：デフォルトの名無しさん：2012/05/04(金) 15:20:20.81

>>834
えと、将来の保守性と汎用性を持たせる＝一部の機能を取り出すことが簡単
ってことなんですが？

840 ：デフォルトの名無しさん：2012/05/04(金) 15:22:48.56

>>836
保守性を考えて作っても未来は貴方の思い通りにはならない。

841 ：デフォルトの名無しさん：2012/05/04(金) 15:22:54.63

オブジェクト指向だと、クラス単位で
取り出すことが簡単になるわけだが、

オブジェクト指向を理解していない奴が
「一部を取り出す」と言ったら、
どうせソースコード関数や関数の一部を
コピペするとかだろ？

842 ：デフォルトの名無しさん：2012/05/04(金) 15:25:14.89

>>840
YAGNIと関係ないからこの話

843 ：デフォルトの名無しさん：2012/05/04(金) 15:27:05.31

>>840
保守性を考えずに作ったら、未来は貴方の思い通りになるよ。

保守性がないという未来ｗ

844 ：デフォルトの名無しさん：2012/05/04(金) 15:28:35.59

実際の所、Firefoxがオブジェクト指向であることが
オブジェクト指向は正しいのか？の答えだと思う。

845 ：uy：2012/05/04(金) 15:29:17.57

俺は>>834を擁護する

まともにレスするだけ無駄

「自分に出来ること」と、「理論的に出来ること」に
境界をしけてないアホがいるもの

846 ：デフォルトの名無しさん：2012/05/04(金) 15:30:45.28

>>842
YAGNIってこれのことか
http://ja.wikipedia.org/wiki/YAGNI

内容には禿げしく同意

847 ：デフォルトの名無しさん：2012/05/04(金) 15:30:53.57

>>845
それはお前が「わかっていない」奴だからだよ

848 ：デフォルトの名無しさん：2012/05/04(金) 15:32:48.95

つか、単に保守性と汎用性が高い設計にしたら、
それを考えないよりも、仕組みが必要ってだけじゃないか。

その仕組みを理解しているならば、簡単に見えるし、
理解してない奴には複雑に見える。

ある程度の力を持った人でないと、将棋の強さは理解できないのと一緒。

つまり低スキル自慢は恥ずかしい。

849 ：デフォルトの名無しさん：2012/05/04(金) 15:33:31.80

>>845
よう、コテンパンにされたコテハンさんｗ

850 ：uy：2012/05/04(金) 15:34:39.69

>>847
じゃあさあ
fireFoxからパーサ部分を取り出すのに、どれくらいの時間で出来る？

851 ：デフォルトの名無しさん：2012/05/04(金) 15:35:53.08

>>850
じゃあ、代わりにお前は
非OOのHTMLパーサー部分を
取り出すんだよな？

852 ：uy：2012/05/04(金) 15:37:16.17

>>851
「やる」「やらない」じゃなくて

お前は出来るんだったら、答えてみろよ
どれくらいの時間で出来るのかを

853 ：デフォルトの名無しさん：2012/05/04(金) 15:37:24.90

>>848
クラスの中のロジックを見ないと使えないようなクラスはダメだと思うぞ。
作るのなら完全ブラックボックスで扱えないとね。

854 ：uy：2012/05/04(金) 15:37:49.19

はい論破

また泣かしちゃったか

855 ：804：2012/05/04(金) 15:38:38.28

>>836
>将来の保守性と汎用性を
>切り捨ててるってことだな。
将来の保守性と汎用性を構造に頼らないということ。

>>837
>切り捨てれば、コストは削減できるだろうね。
問題は費用対効果。

>>839
>えと、将来の保守性と汎用性を持たせる＝一部の機能を取り出すことが簡単
>ってことなんですが？
構造が保守性と汎用性に対応しているんだから
その構造から外れたら駄目だろう。

>>841
>オブジェクト指向だと、クラス単位で
>取り出すことが簡単になるわけだが、
クラス単位じゃなくクラス群。なんの為にデザインパターンがある？

>>842
関係ない理由を聞きたい。

856 ：デフォルトの名無しさん：2012/05/04(金) 15:41:46.60

>>852
> お前は出来るんだったら、答えてみろよ
> どれくらいの時間で出来るのかを

10分でできるよｗ

857 ：デフォルトの名無しさん：2012/05/04(金) 15:42:31.10

Firefoxのソースコードのトップに
parserってディレクトリがある。

ほら、取り出せたｗ

858 ：デフォルトの名無しさん：2012/05/04(金) 15:42:54.94

>>856
３分も持たない癖に何を言う

859 ：デフォルトの名無しさん：2012/05/04(金) 15:44:03.66

>>855
> 将来の保守性と汎用性を構造に頼らないということ。

○○しないこと。ではなく○○するという形で答えなさい。

860 ：デフォルトの名無しさん：2012/05/04(金) 15:45:44.52

取り出すの速かったなｗ

↓ここに書いてある通りで、Firefoxのナかにparserってディレクトリがあって
そこにJavaから変換しているというreadme.txtがあったよ。

FirefoxにHTML 5パーサ、Java→C++自動変換で性能改善3%
http://news.mynavi.jp/news/2009/07/13/020/index.html

Mozillaの開発リポジトリにHTML 5パーサの実装が追加された。
これはHenri Sivonen氏が開発したValidator.nu (X)HTML5 Validatorをベースにしたもの。
Validator.nu (X)HTML5 Validatorは初期に実装されたHTML 5パーシングルール実装のひとつで、
Javaで実装されSAX/DOM/XOMインタフェースを提供している。
XHTML 1.0に対応したアプリのXMLパーサをそのまま置き換えることが可能。

861 ：デフォルトの名無しさん：2012/05/04(金) 15:47:09.35

>>855
> 構造が保守性と汎用性に対応しているんだから
> その構造から外れたら駄目だろう。
構造を変換するデザインパターンもある。無知め

862 ：デフォルトの名無しさん：2012/05/04(金) 15:48:29.96

>>860
htmlparserの中にtestsもあるから
それ参考にすれば簡単に動かせるね。
HTMLパーサー用のMakefileもあるし。

863 ：デフォルトの名無しさん：2012/05/04(金) 15:49:58.45

おまえらHTMLパーサーなんて何に使うんだ？
おまえら仮想現実の中の人？

864 ：デフォルトの名無しさん：2012/05/04(金) 15:50:10.92

HTMLパーサーの例から、オブジェクト指向がすごいってのが分かった

865 ：uy：2012/05/04(金) 15:50:23.41

>>856
ほらな
フタをあけさせると空っぽなんだよ

866 ：デフォルトの名無しさん：2012/05/04(金) 15:51:17.03

>>865
だから、parserディレクトリ見ろってｗ

867 ：デフォルトの名無しさん：2012/05/04(金) 15:52:14.13

>>860
オブジェクト指向で作られてると、簡単に外部の
HTMLパーサーに置き換えることが可能なんだね。

868 ：デフォルトの名無しさん：2012/05/04(金) 15:53:44.30

>>867
座布団１０枚取り上げ

869 ：デフォルトの名無しさん：2012/05/04(金) 15:53:47.75

testsの中身みた？

まあユニットテストだから当然なんだけど、
HTMLパーサー以外の部分には依存せずに
HTMLパーサーだけで動くコードになってるよ。

870 ：uy：2012/05/04(金) 15:54:18.57

できる！できる！おれはできるんだ！やらないだけなんだ！

ってか

871 ：デフォルトの名無しさん：2012/05/04(金) 15:54:52.39

いいからさっさとソース見てこい。

872 ：uy：2012/05/04(金) 15:57:40.85

>>856
10分できるんですう
でもやらないだけなんですう

873 ：デフォルトの名無しさん：2012/05/04(金) 15:58:45.18

10分でできるだろ？
ソースコード展開して
parserディレクトリをコピーするだけ。

874 ：デフォルトの名無しさん：2012/05/04(金) 15:59:46.96

>>872
またコテンパンにされちゃったか
実力どうり順当だなw

875 ：デフォルトの名無しさん：2012/05/04(金) 15:59:47.48

だからHTMLパーサーなんぞ何につかうんだよ？

876 ：uy：2012/05/04(金) 16:01:35.55

>>873
コピーｗ
君の中じゃ「取り出す」ってディレクトリ見つけてコピーすることだったのか

877 ：デフォルトの名無しさん：2012/05/04(金) 16:02:55.97

>>876
すごいだろ？
オブジェクト指向なら、たったそれだけで
抜き出すようにすることだって可能なんだ。

オブジェクト指向を知らない君には、
ちょっと想像もできない世界だったかな？

878 ：デフォルトの名無しさん：2012/05/04(金) 16:04:44.27

とあるクラスで全てを一括管理するなんて発想のやつには
一部を抜き出すことがこんなに簡単にできるなんて
想像もできないんだろうなｗ

879 ：uy：2012/05/04(金) 16:04:59.48

>>877
俺は「コピーして取り出したものを自分のプログラムで扱うところまで」
10分で出来るってほざいているのかと思ったよ

では次の段階に行こう
そのコピーしてディレクトリごと取り出したパーサを
自分のプログラムで扱うまでに時間はどれだけかかる？

880 ：uy：2012/05/04(金) 16:07:55.39

ディレクトリをコピーするだけで終わりなら中学生でも出来るじゃないすかー

そんな中学生でも出来る作業の話を、この板でするものではないよｗ
実際にソースコードを扱う段階の話をしてくれよ･･･

881 ：uy：2012/05/04(金) 16:13:17.87

少なくともさあ
>>800-841このあたりでは、ディレクトリをコピーペーストの話ではなく
ソースコードの話をしていたのに、また話を途中から摩り替えたのかこいつ

コピペ脳もここまでいくとすげえな･･･

882 ：デフォルトの名無しさん：2012/05/04(金) 16:14:30.26

>>880
ちったあ自分で調べろよ。本当使えないクズだな
既に動いたぞ

883 ：デフォルトの名無しさん：2012/05/04(金) 16:15:44.74

ソースの解凍の仕方がわからないお！
*.bundleってなんお！

884 ：uy：2012/05/04(金) 16:16:45.94

動いたそうですｗｗｗｗｗｗ
うｐあるのかな？

>>882
別に俺がfirefoxからパーサ部分取り出したいわけじゃないしそれは>>800だろ

885 ：804：2012/05/04(金) 16:18:40.40

>>861
>構造を変換するデザインパターンもある。無知め
OO以前に言語の基本が分かっていない。
Gofのデザインパターンは静的言語で書かれている。
静的言語で構造を変換することは不可能。

886 ：デフォルトの名無しさん：2012/05/04(金) 16:20:59.67

>>885
静的言語を最大限に柔軟にするためのパターン集だぞあれ

887 ：デフォルトの名無しさん：2012/05/04(金) 16:21:07.76

>>885
デザインパターン＝GOFだと思ってる？まさかね・・・

888 ：uy：2012/05/04(金) 16:25:54.22

あー泣かせちゃったか

889 ：デフォルトの名無しさん：2012/05/04(金) 16:30:47.88

もう「uyが恥を晒し続けるスレ」にスレタイかえろよ

890 ：デフォルトの名無しさん：2012/05/04(金) 16:33:56.38

次スレはこっちな
わざわざ立てるなよ

オブジェクト指向に弊害はない。メリットのみ
http://toro.2ch.net/test/read.cgi/tech/1335361193/

891 ：uy：2012/05/04(金) 16:39:32.23

10分で出来る

コピーペーストｗ

892 ：デフォルトの名無しさん：2012/05/04(金) 16:44:10.66

まだ解凍が終わらないお！

893 ：デフォルトの名無しさん：2012/05/04(金) 16:48:02.60

おまえらが昨日いじめるから壊れちゃったじゃないか

894 ：804：2012/05/04(金) 16:58:13.54

>>886
>静的言語を最大限に柔軟にするためのパターン集だぞあれ
だから何？
デザインパターンを使えば、コンパイル時には
構造が決まっている静的言語でも、構造を自由に変換出来るとでも？

>>887
>デザインパターン＝GOFだと思ってる？まさかね・・・
俺はGofのデザインパターンと書いているが。

895 ：デフォルトの名無しさん：2012/05/04(金) 17:09:12.45

>>894
>>861には書いてないのに、なんでGOFだって決めつけたの？
それしか知らなかったんじゃ・・・

896 ：デフォルトの名無しさん：2012/05/04(金) 17:13:18.41

このスレって
わかってない奴が決めつけで
できないできない！
って騒ぐのがお家芸なの？

897 ：デフォルトの名無しさん：2012/05/04(金) 17:13:52.66

静的言語なんて化石と同じ

898 ：デフォルトの名無しさん：2012/05/04(金) 17:15:28.58

>>894
> デザインパターンを使えば、コンパイル時には
> 構造が決まっている静的言語でも、構造を自由に変換出来るとでも？

誰がそんなことを言ったんだ？
思い込み、禿しいなｗ　禿ｗ

もうお前わかってるよね？
構造を自由に変換できるって。コンパイル前にだよ。

899 ：uy：2012/05/04(金) 17:19:58.30

>>896
レベル高い側が荒ぶる初心者を奉って遊ぶスレ

900 ：デフォルトの名無しさん：2012/05/04(金) 17:21:32.00

レベル高い側（当社比）

901 ：デフォルトの名無しさん：2012/05/04(金) 17:21:41.75

>>896
オブジェクト指向のメリットの説明と
ミサイルとホーミングミサイルの多態のメリットの説明はまだ誰も出来てないよ
君が挑戦してみたら？

902 ：デフォルトの名無しさん：2012/05/04(金) 17:23:16.15

>>901
> ミサイルとホーミングミサイルの多態のメリット

これだけじゃお題がよくわからん

903 ：デフォルトの名無しさん：2012/05/04(金) 17:24:21.99

ミサイルのようなものを例えに出して
机上の空論を振り回すのがＯＯなのかwww

904 ：デフォルトの名無しさん：2012/05/04(金) 17:25:30.94

ミサイルとか知らんわ
ミリオタじゃあるまいし

905 ：デフォルトの名無しさん：2012/05/04(金) 17:25:59.26

ゲームのミサイルの話だろｗ
机上でもなんでもないわ。

906 ：デフォルトの名無しさん：2012/05/04(金) 17:27:21.22

>>905
ゲーム屋のスレなのか？

907 ：デフォルトの名無しさん：2012/05/04(金) 17:27:26.01

ミサイルとホーミングミサイルはそれぞれどういう仕様なんだ？
それ明確にしなきゃ誰も答えんだろんなの

908 ：デフォルトの名無しさん：2012/05/04(金) 17:28:05.03

>>906
ライフなしゲーム屋のスレです

909 ：デフォルトの名無しさん：2012/05/04(金) 17:28:07.90

ミリオタでもミサイル作ったこと有る奴いないだろ
何の話をしてるんだかｗ

910 ：デフォルトの名無しさん：2012/05/04(金) 17:29:21.10

>>908
生きる価値なしのゲーム屋廃人のスレか
なっとくだ

911 ：デフォルトの名無しさん：2012/05/04(金) 17:29:58.01

ゲームなんかしてるから、頭が悪くなるんだよ。
ゲーム脳の話知らないのか？

912 ：デフォルトの名無しさん：2012/05/04(金) 17:30:31.17

>>909
爆竹改造ミサイルなら

913 ：デフォルトの名無しさん：2012/05/04(金) 17:31:17.16

>>909
ペットボトルミサイルなら

914 ：uy：2012/05/04(金) 17:31:34.63

まとめると

ライフポイントは変化し続ける爆発ホーミングミサイルの
ゲームスレは10分で出来るコピーペーストのスレ

915 ：デフォルトの名無しさん：2012/05/04(金) 17:31:34.28

ということで、ミサイルとホーミングミサイルの話は
ここで終わり。解散。

916 ：デフォルトの名無しさん：2012/05/04(金) 17:32:07.08

ＯＯなんて作り手の仕様でつくれるものにしか実用にならんって事だな。

917 ：デフォルトの名無しさん：2012/05/04(金) 17:32:36.23

はい、馬鹿が解散したところで、
ミサイルとホーミングミサイルの多態の話再開です。

918 ：デフォルトの名無しさん：2012/05/04(金) 17:34:33.73

だから実現したい仕様がわかんねーんだよ
ミサイルとかミリオタ位しか興味ないお題なんだから

919 ：デフォルトの名無しさん：2012/05/04(金) 17:35:40.84

>>918
じゃあシューティングゲームに興味はあるかい？

920 ：uy：2012/05/04(金) 17:35:43.54

>>916
むしろ作り手以外にも使えるように設計してるほうが異常
OOじゃなくても。

他の奴にもすぐ使えるようにさせるなら
ソースコード流用しやすくさせるよりもCOMやプラグインみたいなもので公開すべき

921 ：デフォルトの名無しさん：2012/05/04(金) 17:37:47.61

>>919
ないな

922 ：uy：2012/05/04(金) 17:38:02.45

んで結局>>882はうｐなしなのか

コピペじゃ動かないもんねｗ

923 ：デフォルトの名無しさん：2012/05/04(金) 17:38:48.20

>>920
COMとクラスは使う側からすれば、
ほとんど同じですよ。

だからクラスにしていればいいし、
きちんと単体テストが出来るように
作られていれば、作り手以外でも再利用できる。

924 ：デフォルトの名無しさん：2012/05/04(金) 17:38:59.84

>>920
コロコロと頻繁に変わる客の要求仕様に合わせて作るのなら
ＯＯじゃないほうが早くねってことだけど。

925 ：uy：2012/05/04(金) 17:39:06.93

STGはよく作ってきたけど
ミサイルとホーミングミサイルとかいわれても意味がわからない

ホーミングはわかるが、ミサイルって何？
まっすぐ直進するショットって事でいいんか

926 ：デフォルトの名無しさん：2012/05/04(金) 17:40:16.48

>>924
OOじゃない方が確実に遅いな。

927 ：デフォルトの名無しさん：2012/05/04(金) 17:41:03.74

>>926
なんで？
オブジェクトの構成が根本から変わるような仕様変更でも？

928 ：uy：2012/05/04(金) 17:42:38.38

>>923
クラスだときちんと作られている保障がないだろ
いちいちソースを見に行くのがだるいからCOMってものがあるんだよ

929 ：デフォルトの名無しさん：2012/05/04(金) 17:43:44.91

>>927
そのとおり。

根本から変わったとしても、
クラス単位で影響範囲が小さく固まっているので
インターフェースを変換するレイヤーをはさみながら
一つづつ安全に変更する方法が確立されている。

リファクタリングっていうんだけど、
これもOOを使うことが基本となってる。

930 ：デフォルトの名無しさん：2012/05/04(金) 17:44:22.06

逆に、オブジェクトじゃない方は
構成が根本から変わるような仕様変更が来た場合、
ほぼ作り直しになる。

931 ：デフォルトの名無しさん：2012/05/04(金) 17:44:33.09

>>928
そりゃＣＯＭも同じでしょう。

932 ：デフォルトの名無しさん：2012/05/04(金) 17:44:51.84

>>928
> クラスだときちんと作られている保障がないだろ
お前が作ると、そうなるのか？

933 ：uy：2012/05/04(金) 17:47:32.85

>>931
COMを使うためにお前はいちいちソースを見に行くのか？

>>932
世の中にたくさんあるソフトウェアの中ですべてがきちんと作られているのか？

934 ：デフォルトの名無しさん：2012/05/04(金) 17:48:26.11

>>929-930
それってＯＯに限った話ではないでしょう。
影響範囲が小さく固まれるのは関数型の方が有利だし。

935 ：デフォルトの名無しさん：2012/05/04(金) 17:49:25.84

>>933
クラスを使うためにお前はいちいちソースを見に行くのか？

世の中にたくさんあるCOMの中ですべてがきちんと作られているのか？

936 ：デフォルトの名無しさん：2012/05/04(金) 17:50:01.03

>>933
自己矛盾してますよ。
COMだからと言ってきちんと作られている保証はない。

937 ：デフォルトの名無しさん：2012/05/04(金) 17:51:05.43

みなさーん新説はいりましたよー

>>934
> 影響範囲が小さく固まれるのは関数型の方が有利だし。

938 ：デフォルトの名無しさん：2012/05/04(金) 17:51:14.88

>>934
誰かがオブジェクト指向に限っては
駄目だみたいな話をしていたが？

だからOOに限った話じゃないね。
悪い意味も。

939 ：デフォルトの名無しさん：2012/05/04(金) 17:52:26.55

別にオブジェクト指向だから
複雑になるわけでも工数が多くなるわけでもない。

どんな言語を使ったとしても、
柔軟性や保守性を上げるならば

940 ：デフォルトの名無しさん：2012/05/04(金) 17:52:33.90

GWの釣堀はいいなぁぁぁ

941 ：デフォルトの名無しさん：2012/05/04(金) 17:52:34.41

COMかクラスかの違いと
きちんと作られているいないかとは
論理的な相関はない

942 ：uy：2012/05/04(金) 17:52:42.62

>>935
クラスを使うために、コピペするのにソースコードは見ないのか
目隠しでもしながら作業するのか

そもそもMS以外が作ったソフト以外のCOMは仕様が見つからないからほぼ使えないが

943 ：デフォルトの名無しさん：2012/05/04(金) 17:53:15.92

オブジェクト指向を使っていれば、
大きなアプリの設計で必須となる構造を、
スマートに実現できる。

944 ：804：2012/05/04(金) 17:53:28.95

>>898
>構造を自由に変換できるって。コンパイル前にだよ。
実行もしていないのに、どう変換するんだ？
ソースを書き換えると言うデザインパターンでもあるのか？

お前が言っているの、”機能を選択できる”構造があると言うことだ。
具体的なパターン名を書いたらどうだ？

しかし動的言語かなにかで、実行時に構造を自由に変換することを想定している
ある程度知識のある人間かなと思っていたが、レベルの低い人間でがっかりだ。

945 ：uy：2012/05/04(金) 17:53:43.97

そもそもｗ
COMとクラスってまったくの別物なのに同等に語ってる時点でおかしい

初心者煽るのおもしれーｗ

946 ：デフォルトの名無しさん：2012/05/04(金) 17:54:38.10

>>944
このスレにいる人間はお前以外みんなわかってる

947 ：デフォルトの名無しさん：2012/05/04(金) 17:54:46.32

>>942
> クラスを使うために、コピペするのにソースコードは見ないのか
> 目隠しでもしながら作業するのか

見ないよ。Boostのソースコードとか
見なくて使えてるし。

948 ：デフォルトの名無しさん：2012/05/04(金) 17:55:26.90

>>945
オマエはＣＯＭとクラスの上っ面しか見ていないからな。

949 ：デフォルトの名無しさん：2012/05/04(金) 17:55:27.92

>>945
抽象的指向が苦手ならOOスレで荒ぶるのヤメレ

950 ：uy：2012/05/04(金) 17:55:40.75

>>941
COMはそもそも外部から使えるようにするためのもの

クラスはそれを想定しないものも含まれる

951 ：デフォルトの名無しさん：2012/05/04(金) 17:56:28.81

>>944
Adapterパターンとかだよ。

952 ：uy：2012/05/04(金) 17:56:48.99

>>947
なんでCOMの話をしているのにBoostの話になるんだよｗｗｗ
やっぱり全然理解してねーじゃねーかｗｗｗｗ

953 ：デフォルトの名無しさん：2012/05/04(金) 17:57:04.59

>>947
BoostってＯＯなの？

954 ：デフォルトの名無しさん：2012/05/04(金) 17:57:50.38

>>952
ソースコード見ないでクラスを使う話だからだろ。

馬鹿なのか？

955 ：uy：2012/05/04(金) 17:58:50.99

>>954
COMの話しているところに、「クラス」の話を持ってくるまでが限界だよｗｗｗ
それ以上まで斜めにそれたらさすがに話がズレすぎてる

馬鹿なのか？

956 ：デフォルトの名無しさん：2012/05/04(金) 17:58:59.95

>>950
内部的な機能をうっかり公開したCOMはどー違うの？
COMかクラスかは本質に関係ないよ

957 ：デフォルトの名無しさん：2012/05/04(金) 17:59:23.17

ソースコードの端から端まで見ないと再利用できない
クラスなんて再利用できないのも同じ。

958 ：デフォルトの名無しさん：2012/05/04(金) 17:59:38.87

>>955
そもそもクラスの話をしているのに
COMの話を持ってくるなよｗ

959 ：デフォルトの名無しさん：2012/05/04(金) 18:00:19.56

>>958
COMもオブジェクト指向なんだから問題無いだろ。
Component Object Modelの略だぞ。

オブジェクト指向の素晴らしさの
一端じゃないか。COMの存在は。

960 ：デフォルトの名無しさん：2012/05/04(金) 18:00:30.85

COMって外から見るとＯＯじゃないの？

961 ：デフォルトの名無しさん：2012/05/04(金) 18:01:10.63

やっぱりオブジェクト指向は素晴らしいね。
COMとか

962 ：uy：2012/05/04(金) 18:02:43.37

>>956
内部的な機能をうっかり公開してるCOMって例えば何？
エラーがでるなら、実行時に停止すると思うよ
COMとクラスは別物なので

COMはそもそも外部から使えるようにするためのもの

クラスはそれを想定しないものも含まれる

それを想定しないものも含まれるクラスの中から、
上手い事プログラムの1機能を引っ張りだしてくる苦労とｗｗｗ
COMをちょっと使う苦労、どちらが楽なんて何でもいいからCOM触ったことあれば一目瞭然なのに

963 ：デフォルトの名無しさん：2012/05/04(金) 18:03:57.81

>>962
外部から使われることを想定するからpublicつけるんだよ

お前ができなくても、世の中みんなそうやってる

964 ：デフォルトの名無しさん：2012/05/04(金) 18:04:25.90

>>962
COMをVC++から使うと余りの面倒さで死ねる

965 ：uy：2012/05/04(金) 18:04:37.62

>>958
このスレでのCOMの初出は>>826
COMを知らないのでいいならお前がレスをしなければよい

966 ：uy：2012/05/04(金) 18:05:36.64

>>963
釣りなのか？
その外部じゃねーよカスｗｗｗｗｗｗ

967 ：デフォルトの名無しさん：2012/05/04(金) 18:05:42.86

>>962
構造体内に参照型オブジェクトが含まれており、そのオブジェクトの型がCOM標準以外の型になっている場合。

968 ：デフォルトの名無しさん：2012/05/04(金) 18:07:19.52

>>966
おまえはCOMとクラスの共通性に気づけないんだから仕方ないな

969 ：デフォルトの名無しさん：2012/05/04(金) 18:07:21.64

>>965
uyよ、>>826はお前の書き込みだ。
お前にクラスの話でCOMを持ってくるなって言ってるんだよ。

826 名前：uy[sage] 投稿日：2012/05/04(金) 14:58:48.41
>>800
それって、元々Firefoxが使わせる気ないんじゃないの？
IEみたいにCOMとしても使えないじゃん

970 ：uy：2012/05/04(金) 18:07:55.33

>>964
VC++は使わないのでよくわかりませんね
自分がCOMを使うのは基本的にRubyからなので

>>967
何か例だせる？
何のアプリのどのCOMがそういう状態になっているとか。
なるべく有名なアプリでよろｗｗ

971 ：デフォルトの名無しさん：2012/05/04(金) 18:08:34.99

>>970
有名なものはちゃんとなっている。

972 ：uy：2012/05/04(金) 18:08:41.36

>>968

955 ：uy：2012/05/04(金) 17:58:50.99
>>954
COMの話しているところに、「クラス」の話を持ってくるまでが限界だよｗｗｗ
それ以上まで斜めにそれたらさすがに話がズレすぎてる

馬鹿なのか？

----

流石にBoostはCOMじゃないですよ･･･

973 ：デフォルトの名無しさん：2012/05/04(金) 18:09:31.70

> 流石にBoostはCOMじゃないですよ･･･

一体誰が、BoostはCOMだと言ったのか。

uyは読解力がない。
これは昨日も言われていることである。

974 ：デフォルトの名無しさん：2012/05/04(金) 18:09:48.77

uyがいると低レベルの罵り合いになるのがこのスレの恒例行事？

975 ：デフォルトの名無しさん：2012/05/04(金) 18:10:47.56

まあ、uyは読解力がなくて
コテンパンにされたコテハンだからなｗ

976 ：デフォルトの名無しさん：2012/05/04(金) 18:11:18.54

ハンドルuyよりkyのが良いんじゃないの

977 ：デフォルトの名無しさん：2012/05/04(金) 18:11:33.37

また、今日も俺はuyに教えてやってるよｗ

978 ：uy：2012/05/04(金) 18:12:14.15

>>971
有名なものはちゃんとなってるならそれでいいじゃん
有名アプリ以外のCOMを使う機会とかないだろ
普通に公開されてる仕様がないから調べられない
>>973
ん？COMの話してるところにBoostがどうのとかいってきたバカ君は>>947こいつだよｗ

979 ：デフォルトの名無しさん：2012/05/04(金) 18:12:25.41

>>975
uyだけじゃなくて皆、脊髄反射でレスしてるでしょうwww

980 ：デフォルトの名無しさん：2012/05/04(金) 18:13:32.11

残念ながら>>947はクラスの話に対するレスですｗ

981 ：デフォルトの名無しさん：2012/05/04(金) 18:14:44.40

>>978
おれは>>947ではないが>>947は、ソースコード見なくて使えるクラスの例を挙げただけだろ
おまえの読解力は本当に斜め下をいくなw

982 ：デフォルトの名無しさん：2012/05/04(金) 18:15:26.22

オブジェクト指向は本当に正しいのか？ → YES！×2
http://toro.2ch.net/test/read.cgi/tech/1336122899/

983 ：デフォルトの名無しさん：2012/05/04(金) 18:15:59.67

uyはRuby厨みたいだけど皆はどの言語でＯＯやってんの？

984 ：uy：2012/05/04(金) 18:16:05.45

>>980
はいタゲそらしきたー
でも、COMの話をしているところで話されているクラスとは
COMから話題継承されたクラスの話題なので
それに対してBoostをあげてきたってことは、まさかBoostとCOMの関連性について君は何かを知ってしまったのか？

985 ：デフォルトの名無しさん：2012/05/04(金) 18:16:25.99

>>983
Ruby

986 ：デフォルトの名無しさん：2012/05/04(金) 18:17:10.94

>>984
> でも、COMの話をしているところで話されているクラスとは
> COMから話題継承されたクラスの話題なので

つまり、それはCOMとは全く関係ない、
普通のクラスの話ですよね？

987 ：デフォルトの名無しさん：2012/05/04(金) 18:17:55.74

つまり、以下の【クラス】のクラスは
COMとは全く関係ない、普通のクラスの話ですよね？

947 名前：デフォルトの名無しさん[sage] 投稿日：2012/05/04(金) 17:54:46.32
>>942
> 【クラス】を使うために、コピペするのにソースコードは見ないのか
> 目隠しでもしながら作業するのか

見ないよ。Boostのソースコードとか
見なくて使えてるし。

988 ：804：2012/05/04(金) 18:18:05.16

>>951
>Adapterパターンとかだよ。
それは構造へのAdapterじゃなく機能へのAdapterだ。

しかし俺が>>834で書いた
>その構造にあった機能ならいいが、一部の機能だけを取り出すのは難しい。
>まっSingletonやAdapterパターンぐらいしか使えない人間には分からない世界だが。
本当にAdapterパターンぐらいしか使えない人間だったのか。

989 ：デフォルトの名無しさん：2012/05/04(金) 18:18:51.87

>>988
Adapterは構造へのAdapterでもあるよ。

知らないなら黙ってればいいのに・・・

990 ：デフォルトの名無しさん：2012/05/04(金) 18:19:06.46

ここは誤読と決めつけを競うスレです

991 ：デフォルトの名無しさん：2012/05/04(金) 18:19:43.33

参加資格：読解力が欠落していること

992 ：デフォルトの名無しさん：2012/05/04(金) 18:19:49.95

>>985
オワコン言語

993 ：デフォルトの名無しさん：2012/05/04(金) 18:20:24.30

なおuyはシードです
>>804もあと少しでシード権もらえます

994 ：uy：2012/05/04(金) 18:20:27.73

>>986
関係あるよ
話題継承されているって事はその上層にCOMがあるってことだから
俺の脳内でRubyでancestorsをやったらこのように表示された
[Boost, class, COM, Object, Kernel, BasicObject]