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

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

オブジェクト指向の先には一体何があるんですか?

1 :デフォルトの名無しさん:2009/01/28(水) 02:21:42
何が見えてるんですか?

2 :デフォルトの名無しさん:2009/01/28(水) 02:25:45
アイちゃんはそんな難しいこと気にしなくていいんだよ

3 :デフォルトの名無しさん:2009/01/28(水) 02:31:09
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

                  京都大学霊長類研究所

4 :デフォルトの名無しさん:2009/01/28(水) 02:35:14
また新しいオブジェクト指向が広がるだけだよ。

5 :デフォルトの名無しさん:2009/01/28(水) 02:41:10
未来

6 :デフォルトの名無しさん:2009/01/28(水) 02:54:54
オブイェクト指向

T-72神は偉大なり、オブイェークト!


7 :デフォルトの名無しさん:2009/01/28(水) 03:29:08
>6
46サンチか88かそれが問題だ

8 :デフォルトの名無しさん:2009/01/28(水) 03:32:46
Javaの先には何も見えない

9 :デフォルトの名無しさん:2009/01/28(水) 03:35:28
>Javaの先には何も見えない
節穴じゃなかろうか?




10 :デフォルトの名無しさん:2009/01/28(水) 06:07:28
空っぽのスパゲッティ

11 :デフォルトの名無しさん:2009/01/28(水) 09:46:23
マジレスすると、C++のようなマルチパラダイム言語
すべてをオブジェクト指向でやろうとするJavaは気持ち悪すぎ

12 :デフォルトの名無しさん:2009/01/28(水) 11:05:17
>>11
なんでもじゃないだろ
プリミティブな変数が残ってる時点でうんこ

13 :デフォルトの名無しさん:2009/01/28(水) 15:09:17
じゃあ、Rubyがいいの?

14 :デフォルトの名無しさん:2009/01/29(木) 16:34:49
このあたりでSmalltalk原理主義者とLisp原理主義者登場

15 :デフォルトの名無しさん:2009/01/29(木) 20:35:26
細胞指向が登場します。

16 :デフォルトの名無しさん:2009/01/29(木) 21:17:07
棟方志功

17 :デフォルトの名無しさん:2009/01/29(木) 22:49:03
2100年頃には人間指向プログラミング言語(NOPL)が台頭しはじめる。
これは当時普及していたC↑が仕様を拡大しすぎたため、
プログラミング言語にヒトへの優しさを取り戻すことを謳って提唱された。

端的にいえば、当時は高度な文脈判断能を持つコンパイラが完成していたため、
NOPL系言語では、かなり適当にプログラムを組んでも大丈夫である。

例:NOPL系の代表的な言語HUMANによるHello Worldプログラム

"hello, world.";

この1行だけである。includeもusingもclassもmainも要らない。

また、主要な「アプリケーション型」も始めから組み込まれており、

TextEditApp app;

これだけでワードパッドのようなアプリケーションは完成してしまう。
もちろん細かく仕様を設定することもできる。

18 :デフォルトの名無しさん:2009/01/30(金) 05:02:34
オブジェクト指向でも不足で、もっと、というとこれかな

Equivalent transformation programming 等価変換型プログラミング
ttp://assam.cims.hokudai.ac.jp/eti/index.html

19 :デフォルトの名無しさん:2009/01/31(土) 01:07:11
オブジェクト爪向

20 :デフォルトの名無しさん:2009/01/31(土) 11:09:05
且つ分散型

21 :デフォルトの名無しさん:2009/01/31(土) 15:47:20
至高のオブジェクト

22 :デフォルトの名無しさん:2009/02/06(金) 21:39:49
JAVAはC++が使いにくすぎだから
使いやすいように整理しただけの言語
JAVAが凄いなら、C++はその2倍

23 :デフォルトの名無しさん:2009/02/07(土) 01:36:52
ウェルベール指向(←多分だれもわからない)

24 :デフォルトの名無しさん:2009/02/07(土) 08:11:12
>>17
ただのシェルスクリプトやん

25 :デフォルトの名無しさん:2009/02/08(日) 00:05:33
オブジェクト指向なんて所詮一時的な暇つぶしに過ぎない。
小学生でも綺麗なコードを書ける指向が次の志向。

26 :デフォルトの名無しさん:2009/02/08(日) 14:03:45
>>23
知ってるベル
とでも反応すればいいのか?


27 :デフォルトの名無しさん:2009/02/09(月) 14:40:25
>>25
自分に解らないものは全部「汚い」で済ませるのか。

28 :デフォルトの名無しさん:2009/02/10(火) 15:32:53
初恋指向

29 :デフォルトの名無しさん:2009/02/27(金) 13:50:16
玄人指向

30 :デフォルトの名無しさん:2009/02/27(金) 22:35:48
VBだったり

31 :デフォルトの名無しさん:2009/02/27(金) 23:33:52
シコシコウ

32 :デフォルトの名無しさん:2009/02/28(土) 18:48:56
あらゆる現場で開発本題そっちのけでオブジェクト指向にはまって
文明終了

33 :デフォルトの名無しさん:2009/03/04(水) 17:17:31
オブジェクト指向

34 :デフォルトの名無しさん:2009/03/04(水) 18:24:26
はい、ここまでエージェント指向無しw

アプリケーション型とかねーなww

35 :デフォルトの名無しさん:2009/03/04(水) 18:36:25
うんこー

36 :デフォルトの名無しさん:2009/03/04(水) 21:45:51
ここに「社会党」という、なんの役にも立たないオブジェクトがある。
管、ポッポ、オザワというプロキシオブジェクト(それぞれ憎み合ってる)を作って、
「社会党」オブジェクトを管理させ、全体としてラッピングして民主党の出来上がり。

自民党と同等のメソッドがあるように見えるが、
ほとんどのメソッドはNotImplementedException例外を送出する。

37 :デフォルトの名無しさん:2009/03/05(木) 13:55:28
例外を出してくれるならいいが得体の知れてる外国籍の
特定団体にdelegateしかねないから実装は計画的に

38 :デフォルトの名無しさん:2009/03/05(木) 21:19:13
Smalltalkの生みの親であるアラン・ケイの予測:

 ハイレベルなコミュニケーションの3番目の、そして最も新しい方式は
オブザーバ言語である。メッセージ=機能言語はデータ=手続き方式から見れば
前進ではあるが、様々な機能面の関連は独立的であり分析的である。
しかし、多くの概念は非常に混交しており分析しようとすれば実質上、
霧消するするほどである。例えば20世紀の物理学ではある現象とその状況に
同等の重要性を認めてる。これは状況が異なった観察者は違った風に
知覚するためである。
 オブザーバ言語では、機能は互いにくっついて概念と概念とが対応する「視点」に
置き換えられる。例えば犬は、抽象的には「動物」として、分析的には「器官、
細胞、分子から成る存在」として、実用主義的には「子供の乗り物」として、
比喩的には「童話の中の人間的存在」として、そして前後関係を考えれば
「骨が芝生の材料となる過程」と見ることができる。オブザーバ言語は
開発段階にあるが、1980年代のコミュニケーション手段となるだろう。

ASCII, Vol.4, #3 March, 1980「特集:パーソナルコンピュータ」から引用
原題は "Microelectoronics and The Personel Computer" sep '77

39 :デフォルトの名無しさん:2009/03/07(土) 12:58:28
今何年だよ

40 :デフォルトの名無しさん:2009/03/07(土) 20:19:29
オブジェクト指向より棟方志功のほうが好き

41 :デフォルトの名無しさん:2009/03/08(日) 01:09:53
劇団ひとり乙

42 :デフォルトの名無しさん:2009/03/13(金) 23:39:00
憧れのアーキテクトに会いに行こうぜ
待ってる。
http://www.microsoft.com/japan/msdn/vstudio/events/agileseminar.aspx


43 :デフォルトの名無しさん:2009/03/14(土) 09:07:04
経済危機を脱する処方箋はすでに解っている。量的緩和だ。
なのに日銀はかたくなにその実行を拒否している何故か?

不況を脱出する政策もすでに解っている。給付金だ。(ただし額が足りない。今の100倍は必要。
それを毎年やることだ)
なのに国民にはきわめて評判が悪い。何故か?

今の日本(いや世界は)は生産力余りまくり。足りないのは需要。未来はIT化とロボット導入が
ますます進み、失業者は増加する。
金は、配ればよい。その裏付けとなる生産力はあるのだから。

なのに、「働かざる者食うべからず」「モラルハザードだ」という旧来の道徳・価値観が
これらの人類の次のステージを邪魔している。

この道徳教育は糞。これを推進すれば、未来の日本人は人類の中でもっとも割をくうだろう。

そして、予言しておく。アメリカは消費大国として復活する。

「人間は、労働から解放されつつあるし、そうあるべきだ」この新時代の真理に
気づくべきだ。


44 :デフォルトの名無しさん:2009/03/14(土) 13:08:40
>>43
>不況を脱出する政策もすでに解っている。給付金だ。
>(ただし額が足りない。今の100倍は必要。それを毎年やることだ)

荒唐無稽にもほどがある

45 :あぼーん:あぼーん
あぼーん

46 :デフォルトの名無しさん:2009/06/20(土) 00:51:52
            __  ‐ ''" ̄ ̄ `゙' ..、
.           | . / : : : : : : : : : : : : :.' ,
          ≠ / : : : : : : : : : : : : : : : : : ∨゙\
          | _イ. /: : : :/ ハ: :、: 、: : 、: : r‐┴| く
         イ:/: /: /:/:Χ./ .}: 八:.|::!:.:.|: : !  :| .ノ
         {:::{: /:|/レ|ィ心≧ |/ .ィナ什ノ: : L...ノイ.、
.        //|',::::(,| .ヒ::リ゙. ′ 匕:::リレ∨: : |\冫
        //::ハ: : : : :', :::::::     `'-'゙ :: ハ:.: レイ S(そんな)O(オカルト)A(ありえません)!
       / : ノ ∨: : : ヘ   __   :::::: ,≠ヽ',: : ::ト、
     ,./: : : :/._,.-∨: ::_丶  _ .  イ    ∨: :.!: \
.    , '>.-‐''二>''.´\ ,.二つ ̄ ̄ ̄二>.  ',: :',: : : :\
   く    く//__.ハ .i\.ヾ{_:_: : :_ : : :__ミ、__  マ: :ヾ、: : ::ゝ
.  ,' .\  .{|::|─、U (/゙ .二⊃|ヽ\  {:::::::|:|.、  マ:..'., ヽ: : : : :>ー - 、
     { .\_.>‐ "  ̄ ゙̄´!.: :: :.∨\\|:::::::|:}. ',.  ',: :..'.,   × : : : : : : : : :ヾ
     ∨: : ├──.!  /      マ::::::┐::://::k.}  マ: :...'.,       ̄ ヾ´
.     ∨: : \.  |.Y.        ヾ.__{_/彡Χ   ',: : : .'.,
.      マ: : : :ー┤| ,'         ∨゙|   \  ∨: : : :\ 
        \_ イ! | :          ∨、     \  ' ,: : : : .:\
            ∨.',          }::::ヽ      ∨ .\: : : : ヾ
.             ∨.' ,     / ,' ノ.::::::::.\   :ノ    \: : :::

47 :デフォルトの名無しさん:2009/06/30(火) 16:03:22
>>44
いや案外荒唐無稽とも言えない

1)技術が進めば進むほど余剰生産が増える
2)金は労働の対価でしかない

この2つを仮定した場合、

技術の進歩=余剰生産増加=労働力が不要になる=対価としての給与は下がる一方

こうなる
もちろん現実はこんな単純ではないが
(生産が余剰になれば会社が潰れて生産力が落ちるわけで・・・)

ひたすら生産し続ければいつまでも儲かり続ける時代は終わった、と言われれば確かにそうかもとは思う


48 :デフォルトの名無しさん:2009/07/09(木) 01:10:35
派遣切り


49 :デフォルトの名無しさん:2009/07/18(土) 00:14:27
Lispは良い言語だ。

なんだっけ、アスペクト志向とかのもあるんだっけ
Earlang見たいな分散型もはやるかもねー
サーバーも小さい奴を組み合わせるのが流行って
みたいだし

50 :デフォルトの名無しさん:2009/07/18(土) 14:10:54
アスペクトって限られたヤツだけ使うべきだよな
あるメソッド呼んだ時に副作用ある処理が勝手に呼ばれたとか
ヘボが組むと結構悲惨な事態になる予感。

51 :デフォルトの名無しさん:2009/07/19(日) 03:43:19
アスペクトって言うと難しく聞こえるけど、要はアスベストのこと

52 :デフォルトの名無しさん:2009/07/19(日) 05:03:08
アスベスト渦がオブジェクトの世界にまで
広がっていたとは…


53 :デフォルトの名無しさん:2009/07/20(月) 11:42:06
アスペクト指向でうまくいった例って、
セミナー屋のインチキ講師以外にあるのか?

54 :デフォルトの名無しさん:2009/07/20(月) 11:44:22
アスペクト指向の元が腐ってると

55 :デフォルトの名無しさん:2009/07/20(月) 11:45:03
えらいめにあうがアスペクト指向をありがたがるです



56 :デフォルトの名無しさん:2009/07/20(月) 14:14:46
高度なツールほど、馬鹿には使いこなせない。


57 :デフォルトの名無しさん:2009/07/20(月) 19:18:08
馬鹿が使うと

58 :デフォルトの名無しさん:2009/07/20(月) 19:19:39
高度なツールほど、馬鹿でも使えるようになっている。

59 :デフォルトの名無しさん:2009/07/20(月) 19:32:57
高度なツールほど、賢い奴には使いづらい



60 :デフォルトの名無しさん:2009/07/22(水) 01:17:23
オブジェクト指向の先?今のトレンドだと、関数型じゃない?

61 :デフォルトの名無しさん:2009/07/22(水) 07:07:26
ここ数年で関数型界隈で何か画期的な進展があったかというと、何もない。
単にヤマ師が「次は関数型の時代」とわめいているだけで、
中の人達は、みんなさめてるよ。

62 :デフォルトの名無しさん:2009/07/22(水) 08:02:17
C#は関数型になりつつあるけど

63 :デフォルトの名無しさん:2009/07/22(水) 08:19:17
それって何てF#?

64 :デフォルトの名無しさん:2009/07/22(水) 19:19:04
何もないといえば何もないが
そもそもC言語のようなものがなぜ広まったかというと

65 :デフォルトの名無しさん:2009/07/22(水) 19:24:05
なぜ広まったかというと

66 :デフォルトの名無しさん:2009/07/22(水) 21:55:48
OSを記述するための…ってのが、なんかあれだったんじゃないの
Web用言語として売り出したphpとかも
あれだけどあれじゃないか

67 :デフォルトの名無しさん:2009/07/23(木) 00:41:23
つまり共通項は何かに特化してるってこと
特定の分野をこなす最適解だと
半端な言語はいらねえってことだ

68 :デフォルトの名無しさん:2009/07/23(木) 01:22:48
http://pc12.2ch.net/test/read.cgi/tech/1248205502/

69 :デフォルトの名無しさん:2009/07/24(金) 18:05:00
>>67
しかしそうなると、作るソフトによっていちいち言語から覚えなければならなくなるのでつらい、と。
Cは軽くて高速に組めるので、いろいろ潰しがきくところが便利なので使われているだけだと思う。
ただ、規模が大きくなるとそのうち誰も保守できなくなるので、高速性より保守性優先なら
比較的コード量が少なくて保守しやすいオブジェクト言語が使われるということだと思う。

70 :デフォルトの名無しさん:2009/07/24(金) 19:06:00
そこでメタ言語だろ。

71 :デフォルトの名無しさん:2009/07/25(土) 01:45:04
マクロとかテンプレートとか

72 :デフォルトの名無しさん:2009/07/25(土) 15:39:23
うちの会社に使用書からCOBOLを吐き出すツールがあるけど、
そのうち他の言語でも当たり前になるんだろうな。
(モックレベルじゃなくて即本番稼働できるレベル)

73 :デフォルトの名無しさん:2009/07/25(土) 15:53:23
UMLからC++のクラス定義を吐き出すレベルじゃなくて
もっとすごいの?

74 :デフォルトの名無しさん:2009/07/25(土) 16:52:45
だからモックじゃねなくて即本番稼動って書いてるだろ

75 :デフォルトの名無しさん:2009/07/25(土) 18:47:25
>>72
てことはプログラマいらないってことだよね。
仕事で、作りたくもないプログラム組まされる苦労がなくなるのはいいことかも。
言語のことで悩まなくてもいいし,仕様変わってもすぐ対応できる。
つまりオブジェクト指向の次に来るのは「仕様書→ソースジェネレータ」てことか?

76 :デフォルトの名無しさん:2009/07/25(土) 19:08:27
それ、なんて4GL?

77 :デフォルトの名無しさん:2009/07/25(土) 19:56:20
>>75
既にそうなってるフレームワークはいくつかあるぞ

78 :デフォルトの名無しさん:2009/07/25(土) 22:47:46
クラウドに決まってるだろ
そんなことも分からないから、日本のITプログラマは馬鹿にされるんだろ

79 :デフォルトの名無しさん:2009/07/25(土) 23:09:02
sage も分からん馬鹿は黙ってろ

80 :デフォルトの名無しさん:2009/07/25(土) 23:13:29
http://www.jma-net.go.jp/sat/data/web/suneclipse_img/mtsat2_20090722_0900-1400_enhanced.gif

81 :デフォルトの名無しさん:2009/07/25(土) 23:52:18
コピペ君って馬鹿だな、まで読んだ。

82 :デフォルトの名無しさん:2009/07/26(日) 15:36:24
クラウド(笑)

83 :デフォルトの名無しさん:2009/07/26(日) 15:55:14
ITプログラマってw

84 :デフォルトの名無しさん:2009/07/26(日) 16:43:21
      /    /  /   /  /   /     /
            __,____
       /.  /// |ヽヽ\    /  /  /
          ^^^^^.|^^^^^^
    . /  /   ∧__∧
          ( ´・ω・)∧∧
     /     /⌒ ,つ⌒ヽ)   //  /  /
           (___  (  __)
    "''"" "'゛''` '゛ ゛゜' ''' '' ''' ゜` ゛ ゜ ゛''`
    もし、またメール送っても嫌いにならないでね。

85 :デフォルトの名無しさん:2009/07/27(月) 23:04:36
ITプログラマってすげーぞおいw

86 :デフォルトの名無しさん:2009/07/29(水) 21:48:05
よし、明日からは「俺はITプログラマだ」って言うよw

87 :デフォルトの名無しさん:2010/01/03(日) 18:08:09
オブジェクト指向を理解するのならば、
下記が良書だな

http://www.amazon.co.jp/exec/obidos/ASIN/4798104183/randokubunkok-22


88 :デフォルトの名無しさん:2010/01/03(日) 19:45:46
エクセルのマクロみたいに、やりたいことを行動で教えるプログラミングが好き。
ソースが見えるから修正も楽だし。

89 :デフォルトの名無しさん:2010/01/03(日) 21:52:21
>>88
そんなあなたにwsh

90 :デフォルトの名無しさん:2010/01/06(水) 22:41:20
>>87
今さらオブジェクト指向を学ぶなんて歴史的価値しかないけどな
はじめからλ計算をベースにしておけばよかったものを、
人類は無知のために横道にそれた時期がありました、という歴史

91 :デフォルトの名無しさん:2010/01/07(木) 15:51:55
ITプログラマ吹いた
なんでこんなのがム板に紛れ込んでるんだろ

92 :デフォルトの名無しさん:2010/01/07(木) 15:57:13
>>90
それじゃあまるでOOPとλ計算が同じ用途で、排他的な関係みたいじゃない
両者は全く別物であって、排他的でも何でもないんだが

93 :デフォルトの名無しさん:2010/01/07(木) 16:54:47
>>90
まったくもってその通りだな。

ラムダ計算をモデルとする関数型言語が近代的な構文を備えるようになったのは、
KRCやMirandaあたりの80年代から。そして言語の進化が続き、
今ではHaskellやOCamlが普通のプログラマに注目されるまでに成長した。

もしLISPが発表されていた70年代に、LISPのS式のような原始的な構文ではなく、
現在の関数型言語のような近代的な構文を備えた言語が発表されていたのなら、
プログラミングに関する人類の回り道は存在しなかったはずだ。

進化を阻害したすべての原因は、当時の関数型言語研究者の怠慢さにあり、
しかもLISPで満足して自画自賛していたLispプログラマの見識の低さにある。
もし彼らに真摯な姿勢があったのなら、今頃オブジェクト指向は遺物になっていた。

94 :デフォルトの名無しさん:2010/01/07(木) 17:31:15
>>93
そうなったらきっと、モダンな構文のCLOSが誕生したんだろうな。それだけ。

95 :デフォルトの名無しさん:2010/01/07(木) 19:06:33
Dylanはなかったことですかそうですか。

96 :デフォルトの名無しさん:2010/01/08(金) 00:45:53
オブジェクト指向の言語なんて所詮、
 なんかこうしたらうまくいくかも
っていうフィーリングで作られてる
しかも未だにオブジェクト指向とは何かみたいな馬鹿げた議論をしている

一方ラムダ計算をモデルとする言語は、
その表現能力や自動化の限界、最適化の手法まで
全て理詰めで議論されて深まっている

この差は歴然www

97 :デフォルトの名無しさん:2010/01/08(金) 01:13:34
C言語が最高傑作だな
C++はただの改悪で終わった希ガス
導入したもんがすべて〜かもしれない〜っぽくね?の域を出られないとか
ホント落ちたもんだよな>言語開発者

98 :デフォルトの名無しさん:2010/01/08(金) 01:45:30
C言語→NULLあり、破壊的代入のみ、キャストあり、ガベコレ無し
どこがどう最高傑作?

99 :デフォルトの名無しさん:2010/01/08(金) 01:50:20
そうだ、忘れてた、多相型すらないわ>C言語


100 :デフォルトの名無しさん:2010/01/08(金) 05:15:03
オブジェクト指向は構造化されたスパゲッティ

101 :デフォルトの名無しさん:2010/01/08(金) 05:43:34
>>96
>しかも未だにオブジェクト指向とは何かみたいな馬鹿げた議論をしている
馬鹿げた、っつーか、未だに理解できてない馬鹿だからこそ
議論 (の余地なんかないが) してるだけ。

102 :デフォルトの名無しさん:2010/01/08(金) 07:05:54
という議論が繰り返されるわりには誰もメリットいえないよね?
メリットっぽいのだしてもそれが本当にメリットかどうか判断できない内容ばっかり

103 :デフォルトの名無しさん:2010/01/08(金) 07:56:56
君自身が判断できないってだけじゃないのか?

104 :デフォルトの名無しさん:2010/01/08(金) 08:04:38
OOみたいな古典をいまだに最先端だと思いこんでる奴も少なくないのが現実

105 :デフォルトの名無しさん:2010/01/08(金) 09:29:56
>>98
はガベコレ環境であるがゆえの悩みを持ったことがないんだろう。
GCを働かせたくないから、ヒープを使わないように書き換えていくような作業を。

106 :デフォルトの名無しさん:2010/01/08(金) 09:43:24
オブジェクト指向プログラミングを理解できてる奴なんていないよ


107 :デフォルトの名無しさん:2010/01/08(金) 09:52:43
誰も彼もがオブジェクト指向とは何か、という事を適当に書き散らしてるからか
最近ゲシュタルト崩壊気味になってきた

結局オブジェクト指向ってなんなんだ・・・

108 :デフォルトの名無しさん:2010/01/08(金) 11:15:19
>>98
C言語は高級言語とアセンブリの中間の言語としてはかなりのものだと思う
アセンブリや高級言語として見ると非力な感じはするけどな

C++はもうちょっと煮詰めれば良かったんだろうがな…

109 :93:2010/01/08(金) 13:08:07
>>94
CLOSというのはCommon Lisp Object Systemのことかな?
もしそうであれば、「モダンな構文のCLOSが誕生」することはありえない。
S式を捨てたLISPは、LISPと呼べるのか?否である。
従って「モダンな構文のCLOS」は日本語として矛盾している。
近代的な(モダンな)構文を持つ関数型言語の研究が、
S式の否定から始まったことを忘れてはならない。

>>95
Dylanに思い入れがあるのなら、過去にDylanが他の言語へ与えた影響、
あるいは(オブジェクト指向を含む)未来の言語に与えると予測される影響を
大いに語って欲しい。Dylanは名前しか知らないから、それを聞きたい。

110 :デフォルトの名無しさん:2010/01/08(金) 22:28:40
>>105
どんな状況になったら、そんな苦行をしなきゃいけなくなるの?
単純に興味深いわ

111 :デフォルトの名無しさん:2010/01/09(土) 00:22:28
オブジェクト指向よりか関数型だとか言ってる奴がいるが、
そのトレンドの変化は単純にここ数年の計算機の適用領域が変わってるだけなんだよ。

今までは、計算ロジックにリッチなGUIを付ける事が主眼だったからオブジェクト指向のパラダイムが最も重要視された。
今は、GUIよりもそのバックでの文字列処理・大規模分散処理が大きな課題となっているから関数型言語が注目されているだけ。

これからは、大規模分散のバックエンドはいくつかの巨大資本がクラウド上で提供されるようになって、
その他の領域では再びリッチクライアントへの回帰が進むと思う。(というか、並行して進むかな)

そうなると俺は、再び関数型言語の理解よりもオブジェクト指向への理解を求められる時代になるのではないかと思うぜ。

112 :デフォルトの名無しさん:2010/01/09(土) 00:32:44
いまだにオブジェクト指向とか言ってるやつが化石に見えるのは俺だけだろうか・・・w
これからは関数型言語だ!とか言ってるやつが原始人に見えるのは俺だけだろうか・・・w

113 :111:2010/01/09(土) 01:54:33
>>112
実際どちらも素養レベルであって、それより上位の問題を検討するときに選択する低レイヤの道具でしかない。
けど、俺はお前みたいに上から目線で見下ろすだけで満足するって言う考えにはいきつかないなぁ。

お前がオブジェクト指向や関数型言語を既に通過したとして、
その次に出てくる問題が何でそれに対してどういう見識を抱えているかって言うのを
示さないまま優越感に浸ったって、何の意味もない。

114 :デフォルトの名無しさん:2010/01/09(土) 02:26:01
>>111
いいところ突いてると思うけど、実はGUIも関数型言語が牽引していく
そもそもオブジェクト指向の言語でGUI作ろうってのが
間違ってるんだよ
あんな破壊的状態変化を管理しろってのが無理難題
functional styleでGUI作る利点に早く気づくといいよ

115 :デフォルトの名無しさん:2010/01/09(土) 02:53:55
>>109
DylanはS式抜きのCLOSだよ。

116 :デフォルトの名無しさん:2010/01/09(土) 04:52:05
>>114
> あんな破壊的状態変化を管理しろってのが無理難題
> functional styleでGUI作る利点に早く気づくといいよ

GUIをつくれば状態変化を管理する必要がある。
手続型でもOOでもFPでも、それは変わりない。
ただ、管理する方法が変わるだけ。
手続型なら手続で。OOならばオブジェクトの情報隠蔽で。
FPならばMonadやUnique typeなどで。

117 :デフォルトの名無しさん:2010/01/09(土) 08:56:27
しかしFRPはまだ発展途上

118 :デフォルトの名無しさん:2010/01/09(土) 09:36:42
>>110
C#で60FPSのゲーム。
GCが動くと性能がガタ落ちするので、
スタックオブジェクトを効率的に使っていく必要がある。

119 :デフォルトの名無しさん:2010/01/09(土) 10:43:54
>>113
だって、オブジェクト指向のオブジェクトってぜんぜんオブジェクト的じゃないじゃん。
あるオブジェクトを見ているとき、別のオブジェクトは時間が止まったみたいになってるし。

120 :デフォルトの名無しさん:2010/01/09(土) 13:39:14
>>118
60FPSのゲームをC#で!
逆にGCを必死で抑えると60FPSが実現できるんだ
そっちの方が驚き
お疲れさまです

121 :デフォルトの名無しさん:2010/01/09(土) 13:43:31
>>116
>ただ、管理する方法が変わるだけ。
そう、ただ管理する方法が変わるだけ
その方法が変わることによって、
人間がかけなければならない手間と注意の量はずいぶん変わるけどね

122 :デフォルトの名無しさん:2010/01/09(土) 21:01:43
>>121
そのうえで、オブジェクト指向より関数型を推す理由ある?
俺はGUIはオブジェクト指向で考えたほうがわかりやすいと思ってるんだが。
関数型はGUIに向かん。

123 :デフォルトの名無しさん:2010/01/09(土) 21:50:52
>>122
わかりやすいところで言えば、
F#で採用されるfirst class composable eventsとかは
イベントとイベントを合成してfunctionalに新しいイベントを作る優れた手法
.NET用のRxライブラリもそんな感じ
こういうコンビネーター的な考え方は関数型ならでは
元々FRPの一部だしね

もしかしてfirst class composable eventsも知らずに
関数型はGUIに向かないとか言ってる訳じゃないよね?

124 :デフォルトの名無しさん:2010/01/09(土) 21:54:47
RxはC#で使えるでしょ
関数型ならではというのはおかしいんじゃない

125 :デフォルトの名無しさん:2010/01/09(土) 22:14:23
どうでもいいけど、なんで「指向」と「型」を比較してんの?

126 :122:2010/01/09(土) 22:28:23
>>123
一応、何かそんな話はどっかのページかスレで見たけど、GUIでイベント合成すると何がうれしいのか俺の脳では分からなかった。
使いどころがほとんど無いような事が関数型のみで出来てもあんまり意味ないっしょ?
(つーか>>124の言うには関数型ならではのものでもないらしいが)

>>125
わからん。とにかく、マルチパラダイムを認めず、二つのパラダイムを比較しているのがこのスレの流れだと思ったからこう書いた。
関数型とオブジェクト指向が対になる言葉じゃないって言うのは俺も感じていたが関数指向なんて言葉も無いし、どう表現していいか分からなかった。

127 :デフォルトの名無しさん:2010/01/09(土) 22:31:33
たぶん誤解している人もいるかもしれないので補足しておくと
関数型の言語
ではなくて
関数と型理論の言語
という意味なんでよろしく

128 :デフォルトの名無しさん:2010/01/09(土) 22:47:01
>>122
変わらないだろ
クラスは構造体と違ってインスタンスのコピーが気軽にできないだけ不便になったってのならあるけどな

129 :デフォルトの名無しさん:2010/01/09(土) 23:04:53
関数型の簡潔なアルゴリズム表記はいいよね
オブジェクト指向言語の機能モジュールを持ち運べるって感じもいい
要するにクラスの中身を関数型風に記述できるような言語がいいかなって感じ
でまあ、ある程度のユーザー持ってる大方の言語はだいたいそんな感じに進んでると思えるので無問題

130 :デフォルトの名無しさん:2010/01/09(土) 23:18:53
>>126
>一応、何かそんな話はどっかのページかスレで見たけど、GUIでイベント合成すると何がうれしいのか俺の脳では分からなかった。
なんとも残念な感じ
例えばこれのイントロとか読むと分かり易いんだが
www.cs.brown.edu/~greg/thesis.pdf

131 :デフォルトの名無しさん:2010/01/09(土) 23:31:24
ああ・・・一般人+αレベルの2chのム板の「オブジェクト指向の先には一体何があるんですか?」
なんていうタイトルのスレに英語の論文晒してもまじめに読む奴がいるわけないのは
常識的にわかるだろうに・・・
英語なんて生活の一部だぜかっこいいだろ、とか
英語の論文晒しとけば反論できないだろ、とか
晒し主の心情がわかる今日この頃ですが・・・
ここは日本語でおkと返すのが2ch流ですかね

132 :デフォルトの名無しさん:2010/01/09(土) 23:43:41
>>131
日本語だとあんまり無いのよね
ttp://igeta.cocolog-nifty.com/blog/2009/01/reactive.html


133 :デフォルトの名無しさん:2010/01/09(土) 23:54:32
イベントキューの上のレイヤーにリアクティブな高階関数のセットを提供
イベントキューを遅延評価のリストに見立てるとリスト処理のボキャブラリがそのまま使えて便利です
宣言的な記述がやっぱいいです
という話なのかな
結構いいかも

134 :デフォルトの名無しさん:2010/01/10(日) 00:19:59
仮に関数型言語でGUIを扱うのがオブジェクト指向より便利だとするなら、
なぜ関数型言語界隈でオブジェクト指向GUIライブラリラッパーがまかり通っているんだ。

135 :デフォルトの名無しさん:2010/01/10(日) 00:22:46
流行だろ

136 :デフォルトの名無しさん:2010/01/10(日) 00:37:06
オブジェクト指向の代替として今注目されているのがプロセス指向だろ。

137 :デフォルトの名無しさん:2010/01/10(日) 00:41:55
今?注目されてるの?どこで?

138 :126:2010/01/10(日) 00:46:38
>>130
んー、英語の方も日本語の方も読んでみた。
便利&考えることが減る気もするけど、そうでもない気もする。

情報を永続化するタイプのアプリケーションや、
ボタン押したら無意味に派手なアニメーションをさせるようなGUI(Appleみたいな)と相性が悪い気がする。
気がするだけで、どう相性が悪いのかは俺もはっきりしない。明確な反論じゃなくてすまん。

139 :デフォルトの名無しさん:2010/01/10(日) 06:14:26
手続き型言語でジェネリックプログラミングしてるなら非純粋関数型言語は
単にジェネリックな実装を簡潔に記述できるという程度の認識でいい気がする
C++でbindとか使いまくってるなら大差ない。

純粋関数型言語はまだよく分かってない

140 :デフォルトの名無しさん:2010/01/10(日) 07:24:42
だから両方同時に使えば良いじゃない

141 :デフォルトの名無しさん:2010/01/10(日) 07:32:37
イベント合成できるのは関数型だけと思ってる能天気…

142 :デフォルトの名無しさん:2010/01/10(日) 07:34:31
そもそもイベント駆動とGUIは本来別々だっての。
イベント処理の記述や合成が簡単にできるということと、
GUIを容易に構成できるということは全然別問題だろ。

143 :デフォルトの名無しさん:2010/01/10(日) 07:49:23
>>138
>ボタン押したら無意味に派手なアニメーションをさせるようなGUI(Appleみたいな)と相性が悪い気がする。
functional reactive animationでぐぐってみるといいよ

144 :デフォルトの名無しさん:2010/01/10(日) 07:52:26
SmalltalkやXのイベント駆動がアタリすぎて、
今だにGUI=イベント処理という妄想がまかり通ってるらしい。

しまいには、イベント処理さえできればGUIは全てOKとか
あまりにもイタい主張をする人間が現われる始末。

145 :デフォルトの名無しさん:2010/01/10(日) 08:00:12
>>144
誰がそんな主張をしてるの?何番のレス?

146 :デフォルトの名無しさん:2010/01/10(日) 08:06:45
ゴネたところで、
GUIに一番向いているのは関数型だという根拠として
イベント処理しか出てきていないということは、
イベント処理さえできればGUIは全てOKという前提だろ。

147 :デフォルトの名無しさん:2010/01/10(日) 08:35:30
>>131
自分の言葉で説明できない奴はどの世界にいても絶対に認められることはないよね
それがどんなに正しい主張をしていようとも絶対だ

148 :デフォルトの名無しさん:2010/01/10(日) 09:06:19
上っ面でしか説明できないならマ板でやればいいと思うんだ。

149 :デフォルトの名無しさん:2010/01/10(日) 11:41:12
関数型言語はGUI処理を美しく記述できる、という主張を
「自分の言葉」で表現している日本語のblogがあったので紹介。
2006年という古い記事であり、blog主さんの興味が他へ移ってしまったのか、
その後の記事が見つけられなかったのが、とっても残念なところ。

・2006.03.13: [funcgui] GUIで学ぶ関数プログラミングで学ぶGUIアプリケーション
 http://d.hatena.ne.jp/w_o/20060313

・2006.03.14: [funcgui] 続き
 http://d.hatena.ne.jp/w_o/20060314

・2006.03.15: [funcgui] イベント再考
 http://d.hatena.ne.jp/w_o/20060315

150 :デフォルトの名無しさん:2010/01/10(日) 11:51:08
GUIで一番大切なのはペタペタがやりやすいかどうかだろwwww

151 :デフォルトの名無しさん:2010/01/10(日) 13:20:59
関数型言語でも線分や四角形が簡単に書けるから、
GUIに最適な言語は関数型だと?

馬鹿も休み休みに言え。
そういうくだらん強弁を張るから孤立するんだYO!

152 :デフォルトの名無しさん:2010/01/10(日) 22:34:49
つうか画面表示自体が、関数型の考え方でいくと副作用だろ。
その時点で副作用ガンガン使うGUIみたいなアプリを関数型の方が扱いやすいって主張は受け入れがたいんだよ。

153 :デフォルトの名無しさん:2010/01/11(月) 02:11:22
は?意味わかんね
結局落ちてきたメッセージをどう処理するかでしかないのに
わざわざクラスにしておく必要を感じない
微妙なことやると確実にメッセージ飛ばしたりガメたりもう画面単位でどうせ完結できないのに
無理やりクラスにしたところで意味が感じられない

154 :デフォルトの名無しさん:2010/01/11(月) 07:15:41
結局、関数型でGUIをつくるのが簡単だと言ってる人は、
自分ではGUI部品やCGライブラリをつくらずに、
ただ単にイベント処理をつなげるだけでGUIをつくったつもり
になっている人でしかないということ。
HaskellにもGUI toolkitあるけど、ライブラリのソースは
関数型として美しいとは到底言えないシロモノ。

155 :デフォルトの名無しさん:2010/01/11(月) 12:24:22
現実、win32apiをはじめとしてほとんどメッセージの受け渡しで動いてる限りそんなもんじゃね?

156 :デフォルトの名無しさん:2010/01/11(月) 12:32:16
土方にとっては、そんなもんだろうな。

157 :デフォルトの名無しさん:2010/01/11(月) 15:00:34
FRP系の応用の中でもCall By Valueな言語で語られているFrTimeの考え方を理解できれば、
関数型言語でGUIというのが身近に感じられるかなと思うのだが、
急には難しいですね
FrTimeの日本語の解説は、これくらいかなぁ
ttp://d.hatena.ne.jp/propella/20070208/p1
あとはJavaScriptでFRP的なFlapjax
ttp://www.flapjax-lang.org/
Web系の人は参考になると思うよ

158 :デフォルトの名無しさん:2010/01/11(月) 22:38:54
すごいすごい
よくまとまった記事がアップされてる
ttp://d.hatena.ne.jp/maoe/20100109/1263059731
これを読むといいと思う

159 :デフォルトの名無しさん:2010/01/12(火) 00:30:00
>>157
自分の言葉で説明する気がねーならわざわざレスするなよクズ

160 :デフォルトの名無しさん:2010/01/12(火) 00:32:58
>>159
俺は157ではないが、自分の言葉で説明したら1000レス楽勝で埋まると思うが。

161 :デフォルトの名無しさん:2010/01/12(火) 00:35:43
俺らが知りたいのは名無しの誰かさんの有能さを証明することじゃなくて、
新しい技術への知識だろ。
履き違えるな。

162 :デフォルトの名無しさん:2010/01/12(火) 00:54:21
勝手に俺らって括るなよ
俺は名無しの誰かさんの有能さを証明することなんだよ

163 :デフォルトの名無しさん:2010/01/12(火) 00:57:29
>>162
だったらスレ違いだ。
マ板に池。

164 :デフォルトの名無しさん:2010/01/12(火) 01:03:43
関数型は型にはまった事以外をやるとしんどい
まるで書き方を強制されてる気分になる
オ略向は酒飲んでても組める

165 :デフォルトの名無しさん:2010/01/12(火) 01:04:40
>>160
許可する
1000レス埋めてくれ

166 :デフォルトの名無しさん:2010/01/12(火) 01:20:34
結局マルチパラダイム言語Lisp最強という結論に・・・

167 :157:2010/01/12(火) 01:29:58
>>159
自分の言葉かぁ
私が2chに書きちらすより、リンク先を読む方が100倍分かり易くてためになるとおもうけど?
万一参考になるなら読んでくだされ

えっと、GUIの特徴というと、
「イベントがあがったら、あれこれをする」という連鎖や
「ここがこーなったら、あっちがこーなる」という依存関係が
複雑に絡み合っている点が挙げられます
このような仕組みは、抽象的に考えると、
依存関係がグラフ構造を成しており、そこをデータが流れるように見えるので、
Dataflow Programmingなどとも言われます
極端に言うと、この依存関係をfunctionalに(そしてDynamicに)記述することで、
GUIを書こうという方向性が関数型言語界隈にはあり、
それが結構成功しつつある訳です
(続く?)

168 :デフォルトの名無しさん:2010/01/12(火) 01:32:42
>>167
まず何を言いたいのか結論からかけよ
それで詳細をたずねられたらはじめて詳細を答えるように練習しろ
そんなに長い文章になること事態おかしいんだよ

169 :デフォルトの名無しさん:2010/01/12(火) 01:35:03
人と話さないでひきこもって独りよがりなプログラムばっかり組んでるから
掲示板のレスもそうやって聞き手を意識できない

この下手糞が

170 :デフォルトの名無しさん:2010/01/12(火) 01:43:24
>>167
判りやすいから続けてくれ。
168-9みたいな中身スカスカは無視してよし。

171 :デフォルトの名無しさん:2010/01/12(火) 01:52:09
>>159
>自分の言葉で説明する気がねーならわざわざレスするなよクズ
自分の言葉による説明を求めているのに
>>168
説明は要らん。結論だけ言え
とかどうすりゃいいのw

172 :157:2010/01/12(火) 02:05:30
結論から言うと、FRPの仕組みを使えば、関数型言語でもGUIは綺麗にかけますし、
今まで以上に簡単になります

例えば、イベントの連鎖をfunctionalに書こうとすると、
イベントからイベントを生成したり、
複数のイベントを組み合わせて新しいイベントを生成する書き方になります
ボタン1とボタン2のどちらかがクリックされたイベントはこう書けます
(define b1-or-b2
(merge-e b1-click b2-click))
そして、そのイベントが挙がった回数を数えるのはこうです
(define click-count
(accum-b (map-e add-one b1-or-b2) 0))
このような仕組は、所謂コールバックの代わりになるものです
また、click-countという値には、
明示的にset!といった破壊的代入を利用せずとも
常にクリックされた回数が入り込みます
(続く?)

173 :157:2010/01/12(火) 02:20:11
このような依存関係の値(behaviorとかsignalとか呼ばれます)の面白い応用として、
"マウスの現在座標を数秒遅れて追随するアニメーション"が簡単に実現できるデモもあります
ttp://www.flapjax-lang.org/demos/index.html#catchup
(javascriptなのですぐ見れます)

このようなイベントの連鎖や依存関係の記述は、上っ面だけではありません
コンポーネントの描画属性、フォーカス、レイアウト、可視性
GUIツールキット自体にあれこれの依存関係が満載で、
FrTimeは実際にこれらをFRPの枠組で実装しています
(続く?)

174 :157:2010/01/12(火) 02:36:06
残念ながらFRPの仕組みと利用方法は今現在あまり普及していませんが、
Microsoftがかなり強力に.NETの世界へこれらを導入しようとしていますし、
WebUIの世界にも進出しつつあるので、
一般的になってくるのも時間の問題かと思われます

えっと、他に書くことあったっけ?
質問あったらどぞ

175 :157:2010/01/12(火) 02:51:30
少し詳細に踏み込むと、FRPでは入れ子や高階の関係も同様に扱える点が興味深いです
behaviorから別のbehaviorを入れ子に作り続けるbind(monadのbindですね)
behaviorをeventによって別のbehaviorに切替えるswitch
eventのeventをフラットなeventにマージするjoin
これらがあれば、動的な依存関係の組み替えが可能な訳です

176 :デフォルトの名無しさん:2010/01/12(火) 03:28:13
よく判ってないけど、副作用が起きるのは諦めて、
入力を入れ替え続けると解釈することで矛盾の無い形で
実現してみましたって感じ?
CPSで関数が戻らないことを利用して関数の引数を更新し続けるような。

177 :157:2010/01/12(火) 03:51:47
>>176
内部実装の話でしょうかね
純粋関数型言語ではそんな感じで、新しい値を次々と持ち回っています
イベントループの度に新しい値を生成するので、
アプリケーション全体では副作用は無くなります(描画は別)

純粋でない言語では、内部実装的には破壊的代入しちゃってる例が多いですね

178 :デフォルトの名無しさん:2010/01/12(火) 06:26:25
>>172
>結論から言うと、FRPの仕組みを使えば、関数型言語でもGUIは綺麗にかけますし、
>今まで以上に簡単になります
はい、しゃべりすぎはじめの2行から君の話って意味ないんです
聞いておくけどFRPとかいうのを使わなかったら関数型言語だとGUIは綺麗にかけないっていってるのね?

179 :デフォルトの名無しさん:2010/01/12(火) 09:34:44
俺からみるとあんまりGUI関係ないんだよね。FRPの仕組みの利点も。

画面描画がGUIの難しさの一番だろ。
抽象化しすぎると全然パフォーマンスが出なくて、
ある程度下のレイヤでゴリゴリ書かないと実用にならないっていう事が
いつまでたってもなくならない。

結局、どっちらもGUIに対して銀の弾丸にならない事だけは知っておかないとね。
(役に立つ事は認めつつも

180 :デフォルトの名無しさん:2010/01/14(木) 01:01:56
オブジェクト指向の先には関数型言語があるでFA?

181 :デフォルトの名無しさん:2010/01/14(木) 09:29:54
どうしてそれがFAになるんだ。

関数型言語で有用だと分かった技法が既存言語に取り入れられていくって
形になりそうだから、依然メインはオブジェクト指向なのかなぁと俺は感じた。

182 :デフォルトの名無しさん:2010/01/14(木) 12:27:27
先の先の先は自然言語だけどね。その手前に論理型が来るのかな。

183 :デフォルトの名無しさん:2010/01/14(木) 16:32:49
>>1
マイクで、ハローコンピュータとか言うと
勝手にプログラムしてくれるようになるんじゃなかったのか?

ソースはスタートレック。

184 :デフォルトの名無しさん:2010/01/14(木) 16:46:36
んなもん少なくとも俺らが生きているうちは無理だろ
次元が違いすぎる

185 :デフォルトの名無しさん:2010/01/14(木) 16:50:24
最近のグーグルとか見ていると
結構、言葉の解釈はしているじゃん。

中の人はあと10年位したら、ベストな検索結果を1つだけ生成したいと
言っている。

セマンティックウェブって奴?
パソコン君が意味を理解したら、次はどういう手続きでそれが実現するかを
考えられるんじゃねーの。

そうなったらプログラミングもしだすと思う。

186 :デフォルトの名無しさん:2010/01/14(木) 16:56:23
意味と意図は別でしょ。
人間同士のコミュニケーションだって中々うまくいかないから、わざわざチーム内の規定や規則など作って曖昧さを無くそうと必死なのに、
話しかけるだけでコンピュータがやりたいことを理解してくれるとか無理だろ。
脳波でコントロールする入出力装置ができて、思うままに動かせるようになるって方が早いと思う。

187 :デフォルトの名無しさん:2010/01/14(木) 16:57:35
脳波キーボードは早期に実現して貰いたい

188 :デフォルトの名無しさん:2010/01/14(木) 17:01:54
>>186
> 意味と意図は別でしょ。

意図は人間が支持するんでしょ?

意味を理解できれば、どれとどれを組み合わせれば良いのか
どこを変えればよいのか、パソコンでも理解できる。

またそうなるように、人間が部品に意味をつける。
タグの凄い奴が出てくるんじゃねーの。

189 :デフォルトの名無しさん:2010/01/14(木) 17:05:17
人間の発言にはたいてい膨大な前提条件や考え自体の矛盾があるから、
結局コンピューターからものすごい量の質問される事になって実用化は難しそうだと思う。

190 :デフォルトの名無しさん:2010/01/14(木) 17:08:47
>>189
そこはライフログで自動的に属性を判断しましょうって事でしょ。
あとは力技で、

1000万台単位のパソコンを並列化したパワーで
人類の全てのデータを格納して、考え出そうという魂胆。

191 :デフォルトの名無しさん:2010/01/14(木) 17:59:46
>>188
それが「プログラミング」なんだけどね
ビットの並びに意味付けするというのが本質

192 :デフォルトの名無しさん:2010/01/14(木) 18:05:53
そうそう、意味をビットに落とす。
それを簡単にしたい->プログラミング言語とかで。


193 :デフォルトの名無しさん:2010/01/14(木) 18:14:48
>>189
"いろんな言語で宿題スレ" の前スレで、Prologの人が2-3行に達する
長い述語名で定義を繰り返してたでしょ。あれは、ファジィにプログラムを
呼び出すための準備ですね。厳密に解釈していくだけがアプローチではない。


194 :デフォルトの名無しさん:2010/01/14(木) 18:32:46
機械が人類を抹殺する時代が早くやってきてほしい

195 :デフォルトの名無しさん:2010/01/14(木) 18:54:12
>>191
うーん、そういう風に言ったら、いつまででもプログラミングしている
という事になっちゃうので、ここでの議論とは合致しないと思う。

オムレツが食べたい。材料は卵となんかと指定するだけで
オムレツが出てくれば、それはもうプログラミングとは言えないと思う。

196 :デフォルトの名無しさん:2010/01/14(木) 19:00:10
>>195
んー?
どういう立場で喋ってる?そりゃオムレツのレシピがプログラム済であるということでしかないのはプログラム経験あればわかるよね

197 :デフォルトの名無しさん:2010/01/14(木) 19:27:00
セマンティックウェブってあれは80年代のlispでやってたようなAI技術そのまんまでびっくりしたわ

198 :デフォルトの名無しさん:2010/01/14(木) 19:28:51
温故知新

199 :デフォルトの名無しさん:2010/01/14(木) 19:30:26
>>196
卵など個々の材料の意味づけと
オムライスのレシピから
セマンティックウェブで
コンピュータが推測して
オムレツを作っちゃうようなイメージ。

200 :デフォルトの名無しさん:2010/01/14(木) 19:41:52
>>199
卵など個々の材料の意味づけ=プロパティ設定
オムライスのレシピ=焼き方メソッド
オムライスとオムレツは継承関係、みたいなことを指示すると言ってんじゃないのそれは

201 :デフォルトの名無しさん:2010/01/14(木) 19:42:05
>>199
レシピのコーパスがライブラリ
「オムレツつくって」がmain関数

何も新しいことはない。

202 :デフォルトの名無しさん:2010/01/14(木) 19:44:38
また、たとえ話か
そのたとえ話が適切かどうか誰が証明してくれんだろな

203 :デフォルトの名無しさん:2010/01/14(木) 19:45:57
オムライスとかオムレツとか、たとえが混乱して悪いんだけど

コンピュータが既存のソースコードや部品の中身を意味として理解していて
頼んだ人のプロフィールも理解していると

前に似たようなプログラムやアルゴリズムがあったなと
コンピュータが検索して
頼んでる会社は中小企業だから、そんなに重厚な処理は不要だろうとか
この業界だから、こういう処理も必要だなとか
考えて部品を増減したり

ソースコードのこの部分は、こういう意味だから
ここには別の記述を当てはめることが出来るなとか考えて
ソースコードを挿入したり出来ちゃうんじゃないか
というイメージ。

火星に行く為のアプリケーションを作ってくれというのは
切り貼りでは解決しないので無理。

204 :デフォルトの名無しさん:2010/01/14(木) 19:49:57
>>203
> 考えて部品を増減したり

考えてというと語弊が在るのかな。
アマゾンのお勧め本みたいなイメージ。
前例から似たようなものを検索。

前例を作るのは人間で、コンピュータはそれをチョイスしている
だけなんだけど
意味は理解しているので、現在のアマゾンよりは賢い。

205 :デフォルトの名無しさん:2010/01/14(木) 19:55:35
どういう立場で?と聞いたのは、意味を理解できるコンピュータがあったなら、というとこで喋るのか、
「意味を理解させる」というのは突き詰めれば条件分岐であるというとこまで踏み込んで喋るのかということなんだけど
前者みたいね
それだとなんとも言いようがない

206 :デフォルトの名無しさん:2010/01/14(木) 19:57:46
「卵のふわふわしたフライパンで作るおいしいやつ!」って
”俺”が言えばオムレツが出てきて
”オムライス嫌い”の奴が言えば卵焼きが出てくる
ってのは、やっぱり難しいと思うな。

その判断が出来るまでの属性を与えないといけないし、
プライバシーに案外うるさい人類がそこまでデータを提供してくれるとは思えない。

だいたいこんなものをコンピュータの究極と位置付けるのはそもそもおかしい。

考えるのをやめたニートベースの幸せではなくて、
もっと能動的に動く人間のための幸せを追求すべきだ。

と、適当な事を言って見る。オブジェクト指向全然関係ねぇ。

207 :デフォルトの名無しさん:2010/01/14(木) 20:35:11
オブイェークト指向

208 :デフォルトの名無しさん:2010/01/14(木) 21:31:06
>>205
> 条件分岐であるというとこまで

それはおかしいよ。

Amazonみたいな仕組みも、条件分岐なんだから
コンピュータの黎明期から、なにも進歩していません
みたいなシラケタ話にしても仕方が無い。

>>206
> その判断が出来るまでの属性を与えないといけないし、

利益があるなら、与えても何の問題もない。
オムライスの情報なんて、幾らでも与えれば良いじゃん。

また詳細に与えなくても、人間も企業も
ある程度グループ化できる。

プライバシーを全部与えなくてもAmazonでお勧め本は
紹介できる。それだけの話だ。

209 :デフォルトの名無しさん:2010/01/14(木) 21:40:27
しらけてるというか、陳腐だなあということなんだけど

210 :デフォルトの名無しさん:2010/01/14(木) 21:51:18
陳腐とか言われちゃったよw

まあ銀の弾丸を考えると
似通ってくるというのはあるんだろうけど
それなりに面白い話が出来るんじゃねーかと思ったんだ。

お前とは、あんまり話も合わないみたいだし
他所でやるよ。さよなら。

211 :デフォルトの名無しさん:2010/01/14(木) 21:54:20
そりゃあんた意味を理解するコンピュータがあって
会社名入れたらプログラム出てくるといいねと言われたってそれ以外どう言いようがあるんだよw
さようならw

212 :デフォルトの名無しさん:2010/01/14(木) 22:25:53
ただの妄想の話でそこまで熱くならんでも

213 :デフォルトの名無しさん:2010/01/19(火) 08:30:06
少し上の方で自然言語でプログラミングの話あったでしょ。
あれって自然言語の文法を借りて、語彙も制限して使う話で、
コンピュータがなんでも理解できるという意味ではない。

214 :デフォルトの名無しさん:2010/01/19(火) 08:46:39
少し上の方で自然言語でプログラミングの話あったでしょ。
あれって自然言語の文法を借りて、語彙も制限して使う話で、
コンピュータがなんでも理解できるという意味ではない。

215 :デフォルトの名無しさん:2010/01/19(火) 20:52:50
ちょっと気の利いたDSLレベルのものしか作れなさそうだ。
自然言語は複雑な問題を簡潔に記述するのに向いた文法とは思えない。

216 :デフォルトの名無しさん:2010/01/21(木) 18:36:30
>>215
25年以上も後の話でDSLはないだろ。

217 :デフォルトの名無しさん:2010/01/22(金) 12:11:32
その時代には、プログラミングの対象はコンピュータというより
ロボットだと思うけど、それでも自然言語でいけるようになるのかな?


218 :デフォルトの名無しさん:2010/01/22(金) 12:23:37
漫画みたいな人工知能は実現不可能だって結論出ただろ

219 :デフォルトの名無しさん:2010/01/22(金) 12:28:23
ロボットがどうして漫画みたいな人工知能ということになるんだい
動き回るコンピュータ = ロボット ではないのかな?


220 :デフォルトの名無しさん:2010/01/22(金) 15:35:32
>>219
適切な時機にアームを制御できるだけでロボットだね。


221 :デフォルトの名無しさん:2010/01/24(日) 15:44:58
>>219
それが俺たちの望んでいるロボット像かってことだよ。
今ロボット関係の研究しているやつらなんてほとんどが
漫画みたいなロボットに憧れてロボット作ってるわけで。

222 :デフォルトの名無しさん:2010/01/25(月) 12:47:54
ガンダムは作れるけどバルキリーはさすがに無理

223 :デフォルトの名無しさん:2010/01/25(月) 13:26:39
俺はガンダムより最終形態の天元突破グレンラガンがほしい

224 :デフォルトの名無しさん:2010/01/25(月) 18:17:57
デカイだけでダサイメカは嫌い
モスピーダなんてホンダがホントに作りそうじゃないか

225 :デフォルトの名無しさん:2010/01/25(月) 18:29:23
>>217
自然言語は非オブジェクト指向的体系の代表だから、
オブジェクト指向的なロボティクスの動作記述に適していないんじゃないのと
いう疑問と解釈していいのかな。


226 :デフォルトの名無しさん:2010/01/25(月) 18:38:01
>>225
25年とかそれ以上の先のことでしょ。現在だって、
情報家電のユーザインターフェイスにオブジェクト指向なんて
持ってきたらそれだけでアウトですよ。

227 :デフォルトの名無しさん:2010/02/04(木) 03:46:10
てか家電の場合は全体が1つのオブジェクト

228 :デフォルトの名無しさん:2010/02/04(木) 12:25:50
利用者が打ち込むコマンドレベルの話だろ。


229 :デフォルトの名無しさん:2010/02/08(月) 19:01:55
利用者のコマンドとしてのOOねぇ…右クリックメニューみたいな感じ?

230 :デフォルトの名無しさん:2010/03/17(水) 01:17:19
Googleが開発したGoっていう言語のオブジェクト指向が凄いらしい。
オブジェクト指向の良い部分だけを取り入れたハイブリッドな思考
は今後の主流になるかな?

231 :デフォルトの名無しさん:2010/03/18(木) 07:49:14
よく分からんのだが、オブジェクト指向の良くない部分てなに

232 :デフォルトの名無しさん:2010/03/19(金) 21:30:22
>>231
意味がないところ
別にオブジェクト単位にしたところで工数など1hたりとも減らすことはできない

233 :デフォルトの名無しさん:2010/03/20(土) 00:36:58
>>230
対象物をすべてオブジェクトって概念で抽象化しようとするのに無理があるところw

234 :デフォルトの名無しさん:2010/03/20(土) 15:26:43
とりあえず、仕様を記述するための規格化された優秀な言語が欲しいな。
実装は後回しでもいいから、人間の意図の表現とプログラミング言語の間を埋める、
表現の手段が欲しい。


235 :デフォルトの名無しさん:2010/03/20(土) 15:56:31
Prologじゃだめなの?

236 :デフォルトの名無しさん:2010/03/20(土) 20:22:15
>>232-233が何か重大な勘違いをしている気がする件。

オブジェクト指向は一次的な工数を減らすためにやるものではないし、
ましてや、対象を全てオブジェクト化することを目的としてやるものでもないぞ?

237 :デフォルトの名無しさん:2010/03/20(土) 20:46:16
>>236
じゃあ、なんのためにやるの?
成果を数字で表してくんない?

238 :デフォルトの名無しさん:2010/03/20(土) 21:05:38
>>237
なかなかきちんとまとまった説明はないけど、例えばこれとか参考になるんじゃないかな。
http://itpro.nikkeibp.co.jp/article/COLUMN/20060921/248617/

要求の変化に伴う保守性や再利用性、なんてのはなかなか数値化できんわな。

個人的な経験から言えば、OOの基本的な概念を軽く押さえたら、
次はデザインパターンの勉強をするのが理解の早道だと思う。

239 :デフォルトの名無しさん:2010/03/21(日) 00:16:39
>>237
まぁ、グローバル変数をオブジェクトに押し込んでみました、ってだけの技術やからね…
成果なんて出ないと思うよ


240 :デフォルトの名無しさん:2010/03/21(日) 00:45:10
>>239が何を言っているのか分からない

241 :デフォルトの名無しさん:2010/03/21(日) 00:45:57
わかんないんです(><)

242 :デフォルトの名無しさん:2010/03/21(日) 00:46:32
>>238
結局、何が言いたいのかまったくわからない
自分の言葉で単刀直入に結論から言ってよ

243 :デフォルトの名無しさん:2010/03/21(日) 01:18:48
>>242
俺の理解では、

オブジェクト指向の目的:
・複雑な要件を「まとまり」単位で整理することで、人間の手に負えるようにする
・「まとまり」同士を疎結合に保つことで、要求の変化に柔軟に対応できるようにする
(・多人数開発において、個々のコードの影響範囲を限定することでバグの作りこみを減らす)

「まとまり」につく名前は「オブジェクト」だったり、そうでなかったりするけど、基本は同じ。

244 :デフォルトの名無しさん:2010/03/21(日) 02:11:13
>>243
つまり数字ではでてこないのね
気がするだけレベルなのがな

245 :デフォルトの名無しさん:2010/03/21(日) 02:33:13
>>244
どういう種類の数字?

こうした原則に則って粛々とやっていけば、目に見えて保守しやすいコードがアウトプットできるし、
仕様変更に伴う工数も大幅に短縮できるはずだが。

つうか、見ての通り、きちんとコーディングする上でごくごく当たり前の方法論でしかないわけで、
『「工数○○日短縮」って数字で示されないとやる気が起きない』とかいう話になること自体が不思議。

246 :デフォルトの名無しさん:2010/03/21(日) 02:41:06
>>245
>仕様変更に伴う工数も大幅に短縮できるはずだが。
だったら数字をだせよ

247 :デフォルトの名無しさん:2010/03/21(日) 02:43:21
>>245
逆に考えよう
それが自分のただの思い込みだったら?
ぶっちゃけC++とC言語とで比べてまったく同じ処理をするソースを書いたことないでしょ?

248 :デフォルトの名無しさん:2010/03/21(日) 02:56:25
>>246
そりゃ、書いてるコードや仕様変更の内容による。

>>247
異なる言語で同じ処理を「試しに」書けてしまうような規模の開発でやったら、
そりゃ、「効果が薄いわりに冗長なコーディングを強要される」と感じるに決まっている。

個人的な経験で言えば、数千NCSS程度のコードでも、こういうことをきちんとやるだけで
保守性にかなり差が出てくると思う。

249 :デフォルトの名無しさん:2010/03/21(日) 03:01:26
>>248
>保守性にかなり差が出てくると思う。
「思う」以上のこと言えないよね?

250 :デフォルトの名無しさん:2010/03/21(日) 03:03:51
>>249
実体験と書いてあるわけだが。

251 :デフォルトの名無しさん:2010/03/21(日) 03:05:24
>>250
だったら「思う」じゃなくて事実を書けばいいじゃん

252 :デフォルトの名無しさん:2010/03/21(日) 03:11:45
>>251
揚げ足取りがやりたいならよそでやってくれ。

253 :デフォルトの名無しさん:2010/03/21(日) 03:19:46
>>252
どこが上げ足とってんだよw

工数を大幅に短縮できるっていうからそれはどうして?って聞いてるのに
これこれこういう理由で具体的にこう減らせる
って話をしなきゃいけないのに「思う」とかそんなあいまいなレスつけるからだろ
知らなきゃレスしなきゃいいだろ

254 :デフォルトの名無しさん:2010/03/21(日) 03:28:33
>>253
実体験に基づいて、実際にオブジェクト指向を採用することによる効果が出てくるコード規模について、
推測を交えて話したら、君の中では俺が全てについて憶測で話していることになるの?

255 :デフォルトの名無しさん:2010/03/21(日) 04:15:50
>>254
だから知らないなら無理してレスしなくていいって
別に俺の問題に対する答えをもってるわけじゃないんでしょ?

256 :デフォルトの名無しさん:2010/03/21(日) 04:30:53
>>255
えーっと、君の問題って何だっけ?

257 :デフォルトの名無しさん:2010/03/21(日) 04:31:57
>>255
一人でコード書くなら差はあまり感じられないかもしれない

オブジェクト指向は、クラスのカプセル化と
小規模なクラス群からの継承やコンポジションで開発を進めていく
クラス型の選択で仕様変更を楽にできるメリットや
複数人で開発するにあたり、機能を細かく開発したり、拡張部分を楽に開発可能だし
カプセル可により、他人が安全に機能を運用できるメリットもある

特筆すべきなのは、直感的にソースがよめるため可読性が高くなること
部品を集めて組み立てるかのように、機能の選択で構築するから分かりやすい

言い換えると、中途半端なオブジェクト指向が一番読みづらい
スパゲティコードとなんら変わらないものになる

258 :デフォルトの名無しさん:2010/03/21(日) 04:39:17
>>257
だから具体的な答えをもってないのになんでレスするの?
無理しなくていいよ

259 :デフォルトの名無しさん:2010/03/21(日) 04:44:18
>>258
可読性の向上や、想定していない使用方法からくるバグとデバッグ時間
コードの修正による再コンパイル時間
諸々の理由からくる余計な時間が省けるだけ

元より開発能力の高い人だけの少人数開発で
再開発しない単発の開発なら
おそらく工数は変わらないか
余計な時間がかかるかもしれない

まあ本当に開発能力が高いなら微々たる時間だろうけど

260 :デフォルトの名無しさん:2010/03/21(日) 04:52:08
>>259
>可読性の向上や、想定していない使用方法からくるバグとデバッグ時間
向上してるかどうかなんてわかんないんでしょ?

261 :デフォルトの名無しさん:2010/03/21(日) 04:52:22
>>258
お前の言っている数値ってなんだ?
基準は相対基準か絶対基準か?

工数は普通相対基準で計るもの
相手が工数が減ったと言っているから充分だが

相手に、何の数値を求めている?
何も分かっていないで言ってないか?
お前馬鹿だろう

262 :デフォルトの名無しさん:2010/03/21(日) 04:59:09
>>261
あー、わからないならレスしなくていいって
そこからいってなにをすれば証明にいたるのかわからない奴相手にしたくないから

263 :デフォルトの名無しさん:2010/03/21(日) 05:00:16
>>260
可読性がってこと?
まあそうだね
数値化はできないな

だけど、開発規模がでかくなればでかくなるほど
自分が作成していないコードが増えることになる
そのとき、ヘッダ名(クラス名)と
外部に公開されたメソッド(publicなメンバ関数名)さえ分かれば
何をする部品なのかすぐわかる

コメント残せばいいじゃんと思うかもしれないが
他人が作ったコードと、他人が書いたコメントが一致してるかどうかなんてはっきりいって信用できん

後はUMLの設計図、クラス図さえあれば
どのクラスと関係を持ってるのかがわかればより早いよ

264 :デフォルトの名無しさん:2010/03/21(日) 05:04:00
>>263
ごちゃごちゃ無駄なこと書いてるけど結局可読性が上がってる云々とは関係ないじゃないか
だからわからないのに無理してレスするなよ

265 :デフォルトの名無しさん:2010/03/21(日) 05:06:40
>>264
ひとつひとつのメソッドを全て読むのと、名前だけの確認で終わるのどっちが早いのかはわからない?

266 :デフォルトの名無しさん:2010/03/21(日) 05:11:03
>>265
なんで全然関係ない話をするの?

267 :デフォルトの名無しさん:2010/03/21(日) 05:13:17
>>266
可読性の話の続きなんだが

268 :デフォルトの名無しさん:2010/03/21(日) 05:14:33
もしかして、プログラミングしたことないのか?
理屈だけで覚えようとしてるなら用語もわからないかもしれないな

269 :デフォルトの名無しさん:2010/03/21(日) 05:17:44
>>267
それがC言語からC++に変わって(オブジェクト指向という意味で)のメリットなの?
君、自分がまったく関係ない話してるの気がついてる?

270 :デフォルトの名無しさん:2010/03/21(日) 05:19:25
人には具体的な答えを求めて
自分は片言の日本語でやりとり
一つでもおかしな点があると思い込んだら全否定
質問して知識の物乞いしてんのに殿様気取り
普通ならぶん殴られてもおかしくないから直せよ

271 :デフォルトの名無しさん:2010/03/21(日) 05:21:12
>>270
だから別に知らないならレスしなくていいって言ってるじゃん

272 :デフォルトの名無しさん:2010/03/21(日) 05:35:05
>>269
外部にみせていいメソッドだけ公開できるのはC++からだろ
カプセル化ができないと全てのメソッドを公開しないといけない
だから全部読むはめになる
どこもずれていない

あといつからCとC++の話になった?
構造指向とオブジェクト指向は両極にある概念じゃない
C++の概念はCの概念を内包する
Cの考え方はわかっているのだろ?
それならオブジェクト指向が延長線上にあるのもわかっているはず
わからないなら、アセンブラからCに変わって発達した
構造化プログラミングのメリットを269なりに述べてみ

あと、はっきり言って認めた部分もあるだろ
理屈がわかるならわかっているはずだ
そうでなければただの荒らし
もうレスは返さない

273 :256:2010/03/21(日) 05:43:24
>>257
代わりに答えてくれてありがとう。
どうも、彼は単に自分の知らない概念を全否定したいだけの人だったみたいだね。
時間を無駄にしてしまった。

274 :デフォルトの名無しさん:2010/03/21(日) 05:46:36
あと開発速度でいえば、CとC++なら二分の一以下になる
コンテナ操作が標準であるし、templateで静的動作(コンパイル時動作)が可能になる
煩雑な型の作成すら汎用化できるため
今まで個別に作っていたクラスを一つのファイルで書ける

正直、これは説明しようにも長くなりすぎるから割愛する

275 :デフォルトの名無しさん:2010/03/21(日) 05:47:26
>>272-273
なんでさっきから知らないのに無理やりレスするの?
いいって言ってるのに押し付けるのやめてよ

276 :デフォルトの名無しさん:2010/03/21(日) 05:48:16
>>273
はっきり言えば、あなたの言い方が
多分オブジェクト指向を理解していると言いづらかったから横槍いれたんです
もっと勉強してください

277 :デフォルトの名無しさん:2010/03/21(日) 05:50:10
>>276
そんなこといって結局メリットに関してなんも具体的な説明できないじゃん
だから知らないならレスしなくていいって言ってたのにやけにつっかかるなぁ

278 :デフォルトの名無しさん:2010/03/21(日) 06:00:07
>>277
再コンパイル時間については?
可読性の向上については?
反論ないようだね

これ以上レスしないから安心していいよ

悪質なあなたの反論を掻い潜ることができたと言うことは
私の理屈は間違いないということだ
なお続けようとするあなたに同情すらしてやらないよ
理論もプログラミングも私より劣っている人に説明できて
理解を簡潔にまとめることができた

279 :デフォルトの名無しさん:2010/03/21(日) 06:26:18
>>278
あれが具体的?
頭おかしいんじゃないか?
工数はいくつ減らせるの?
普段仕事してて1hだって根拠を求められるのに
なんで言語に対してはそういい加減なの?

ちょっとわけありでいい加減なことやってる場合じゃないから
あなたみたいな人普通に邪魔なんだけど

280 :デフォルトの名無しさん:2010/03/21(日) 06:30:10
それと何度もいうけど
知らないなら無理やりレスするのやめてもらえます?
まったく同じ仕様のものをC言語とC++とで比較した経験すらおそらくあなたないですよね?

281 :デフォルトの名無しさん:2010/03/21(日) 06:33:43
>>280
知らないならレスしなくていいよ

282 :デフォルトの名無しさん:2010/03/21(日) 06:45:02
>>279
工数?
1/2以下

283 :デフォルトの名無しさん:2010/03/21(日) 11:11:28
一つの単位で機能を管理・提供できる点がoopじゃないのん。
cのstructじゃ処理(関数)を外側で指定(関数ポインタへの代入)しなくちゃならないんだし。

waveのinとoutの低レベルな関数はcでべた書きで用意して、
waveファイル, waveinストリーム, waveoutストリームってな感じで、
簡単に扱えるようにしたclassはc++で用意してってやると、
利便性も拡張性も供給できて、高レベルも低レベルも両方同じコードで提供できる。

詰まる所、需要と供給の話程度かと。

284 :デフォルトの名無しさん:2010/03/21(日) 13:37:34
>>279
まぁ、貴方のように、既にデスマってしまった人を救済する銀の弾丸ではないかもね。
そもそも、そういう事態に陥らないための方法論がオブジェクト指向。

あるいは、レガシーコードをどうにかしたいって話だったら、こういう本を読んでみると良いんじゃないかな。
http://www.amazon.co.jp/dp/4798116831
http://www.amazon.co.jp/dp/4048676881

285 :デフォルトの名無しさん:2010/03/21(日) 23:42:59
>>283
てか「処理」と「データ」をオブジェクトの名の下に一元管理できるのは大きな要素だと思う

286 :デフォルトの名無しさん:2010/03/22(月) 16:33:30
>>285
処理とデータを関連づけるのはいいが
一緒にするのはダメなオブジェクト指向の典型だ

287 :デフォルトの名無しさん:2010/03/22(月) 17:03:59
>>286
おまえ、手続き抽象ぐらいは理解した上で書いているのか?

288 :デフォルトの名無しさん:2010/03/22(月) 17:57:47
>>287
否定してるわけじゃない
インターフェースとデータは分けて管理するのは当然だろ

289 :デフォルトの名無しさん:2010/03/22(月) 18:56:51
>>288
それって細かい実装技術でしょ?
それが設計にまで影響しちゃうのってないじゃん
なんかこのスレに相応しくない話してない?
インターフェースクラスが本質の設計に影響を与えるのってないでしょ?

290 :デフォルトの名無しさん:2010/03/22(月) 18:57:49
インターフェースクラス??

291 :デフォルトの名無しさん:2010/03/22(月) 19:05:19
>>290
どっちでもいっしょでしょ?

292 :デフォルトの名無しさん:2010/03/22(月) 19:06:11
>>291
え?w 何と何が?w

293 :デフォルトの名無しさん:2010/03/22(月) 19:06:42
>>292
上げ足取りたくてレスしたの?
死ねよ

294 :デフォルトの名無しさん:2010/03/22(月) 19:09:19
>>293
どうせ二行費やすなら>>292答えろよw

とかいいつつゴメンね、ぐぐったら"インターフェースクラス"なるものの正体が分かったわ。

295 :デフォルトの名無しさん:2010/03/22(月) 19:10:19
>>294
まあ、インターフェースが設計に影響与えるのはおかしいでそ?
なのでこの話はここでおしまい

296 :デフォルトの名無しさん:2010/03/22(月) 19:13:58
>>295
なんか誤解していたら申し訳ないので伝えておく。
俺がここまでにレスしたのは>>290 >>292 >> 294だけ。
「インターフェースクラス」っていう謎の用語に怯えただけ。

話の続きは>>288さんとでもやってんろ。

297 :デフォルトの名無しさん:2010/03/22(月) 20:37:29
>>295
だいたいの設計には必要無いかもな

でもひとつのデータに複数種類のアクセス方法(インターフェース)が必要な場合どうする
まさか一つのクラスにまとめるわけないだろ

インターフェースの管理についても設計すべき時なんてプログラムやってたらいくらでもあるだろ

298 :デフォルトの名無しさん:2010/03/22(月) 20:38:36
>>297
ないよ
ないから君の話にはこれ以外のレスしない
おわり

299 :デフォルトの名無しさん:2010/03/22(月) 20:39:12
そんなに実例みたくばboost読んでみろよ

300 :デフォルトの名無しさん:2010/03/22(月) 20:41:30
boostのインターフェース設計がまさか設計無しに作られてるとか低能な言い訳しないでね

301 :デフォルトの名無しさん:2010/03/22(月) 20:44:55
ごめん
Cがどうとか言ってた基地外か
boost読めないから無理だったね

302 :デフォルトの名無しさん:2010/03/22(月) 22:51:31
あたかもboostがいいようにいうけどまったくいいことないと思うよ

303 :デフォルトの名無しさん:2010/03/23(火) 01:29:06
いい悪いの話ではない
話題をそらすなよ

304 :デフォルトの名無しさん:2010/03/23(火) 01:34:20
>>297
javaだとインターフェースクラスを直接作れるね
C++だと、メンバ変数のない純粋仮想関数だけのクラスだと思えばよし

305 :デフォルトの名無しさん:2010/03/25(木) 01:10:49
マルチエージェント指向

306 :デフォルトの名無しさん:2010/03/27(土) 01:07:56
>>303
なら、boostはどんな説明をするために話題に出したの?
こんなのオブジェクト設計なんてしてねーただのオナニーライブラリじゃん

307 :デフォルトの名無しさん:2010/03/27(土) 15:22:24
>>306
論派したいんだろうけど、話題反らしたり無知披露したりで屑認定されてるよ

308 :デフォルトの名無しさん:2010/03/27(土) 15:34:49
>>306
頭悪いんですね…

309 :デフォルトの名無しさん:2010/03/27(土) 18:14:44
オブジェクト指向?なにそれ、おいしいの?
オブジェクトなんて構造体でしょ?なんでそんなに有り難がる必要があるだろう
ましてや構造体でシステム設計とか意味不明


310 :デフォルトの名無しさん:2010/03/28(日) 01:59:40
>>309
勉強して批判しようね屑

311 :デフォルトの名無しさん:2010/03/28(日) 13:46:27
熟練のプログラマって意外とオブジェクト指向で作らないんだよね。
考えが古いのかな?
実はあまり必要ないとか?

312 :デフォルトの名無しさん:2010/03/28(日) 14:05:40
>>311
意味ねーし
オブジェクト指向になって具体的にいいことって出せる奴いねーもん

313 :デフォルトの名無しさん:2010/03/28(日) 14:12:51
>>312
Stringクラスも不要?

314 :デフォルトの名無しさん:2010/03/28(日) 14:17:16
>>313
仮に似たような機能C言語で作ったらいらないな

315 :デフォルトの名無しさん:2010/03/28(日) 14:25:46
>>314
文字列の長さ順にソートするような場合どうする?
strlenを毎回呼ぶつもり?

316 :デフォルトの名無しさん:2010/03/28(日) 15:15:18
>>315
それはC++でないと作れない機能ですか?
ってことだな
同じ労力だと思うぜ

317 :デフォルトの名無しさん:2010/03/28(日) 15:47:16
>>316
ってことだな? 思うぜ?

>>315に具体的に答えることは不可能?
「仮に似たような機能C言語で作ったら」と言ってたのに。

318 :デフォルトの名無しさん:2010/03/28(日) 15:52:23
>>317
は?
それって何か問題あるの?
っていうか話の主旨をどこにしたいの?
俺は別にライブラリの出来不出来の話をしたいわけじゃないんだけど?

319 :デフォルトの名無しさん:2010/03/28(日) 15:53:45
>>318
ライブラリの出来不出来の話などするつもりはない。

320 :デフォルトの名無しさん:2010/03/28(日) 15:55:30
>>319
じゃ、何が言いたいんだよ
さっきから

321 :デフォルトの名無しさん:2010/03/28(日) 15:56:47
>>320
「文字列の長さ順にソートするような場合どうする?
strlenを毎回呼ぶつもり?」

322 :デフォルトの名無しさん:2010/03/28(日) 16:16:25
stringクラスと、そのsize()メソッドがあるから、
そのインスタンスsに対しs.size()とサイズを取得できる。

char *に対してはstrlenを毎回呼び出す必要があるか、
呼び出さないためには値をキャッシュする変数を別途用意する必要があり、
それらの生成破棄など、管理する手間が別途発生してしまう。
また、キャッシュのための変数の中身は、
strlenの結果と同一であるように注意を払う必要も出てしまう。
これは非常に煩わしい。

一方、stringクラスのsize()メソッドを使う場合は、
サイズの再計測もさせないように実装しうるし、
それゆえ、別途キャッシュするような変数も、
その変数との同一性への心配も不要になる。

オブジェクト指向になって具体的にいいことのひとつだと思う。

323 :デフォルトの名無しさん:2010/03/28(日) 17:02:42
>>322
っていうC言語の関数を用意したら?
でお仕舞いな話を出されてもねw

324 :デフォルトの名無しさん:2010/03/28(日) 17:16:18
>>323
そんな手間をかけるくらいなら、
俺はstring#sizeを使って単に、
bool sizegreater(const std::string &a, const std::string &b) {
return a.size() > b.size();
}
こう書いて、sort(v.begin(), v.end(), sizegreater);に渡す。

> っていうC言語の関

ご苦労様ですw

325 :デフォルトの名無しさん:2010/03/28(日) 17:18:23
>>324
だから君が言ってるのはライブラリの有無の話でしょ?
最近、こんな馬鹿が金もらってプログラム組んでるからな

326 :デフォルトの名無しさん:2010/03/28(日) 17:20:11
#include <string>
#include <vector>
bool sizegreater(const std::string &a, const std::string &b) {
return a.size() > b.size();
}
int main() {
using namespace std;
vector<string> v;
sort(v.begin(), v.end(), sizegreater);
return 0;
}
毎回strlenを呼ばずにCで同等のことをするのは大変。
大変じゃないというのならサクッと示してほしいところ。

327 :デフォルトの名無しさん:2010/03/28(日) 17:21:37
>>326
>毎回strlenを呼ばずにCで同等のことをするのは大変
大変(笑)

328 :デフォルトの名無しさん:2010/03/28(日) 17:22:30
>>325
すでに>>322で書いたように、stringに対してs.size()が呼べるからこそ、
>>315の問題の部分は、return a.size() > b.size(); と書ける。

オブジェクト指向じゃないとこうならない。

329 :デフォルトの名無しさん:2010/03/28(日) 17:25:55
>>328
バーカw
しゃべるたびに頭になにも入ってないのがバレバレだなw

330 :デフォルトの名無しさん:2010/03/28(日) 17:26:39
オブジェクト指向不要論みたいなのを掲げて煽ってるヤツって釣りじゃねーの?
本当に不要とか思ってるのなら単なる馬鹿で相手にするだけ時間の無駄だと思うんだが。

331 :デフォルトの名無しさん:2010/03/28(日) 17:27:57
文字列の長さでソートする時、strlenを毎回呼び出さないですむ方法が、
Cでスマートに表現できるのなら俺は>>329をバカと呼んだりはしないよ。

332 :デフォルトの名無しさん:2010/03/28(日) 17:28:06
指摘するほうもオブジェクト指向と全然関係ないところをあげて
サブルーチン単位の細かいことしか挙げないのはどうしてなの?
はじめのオブジェクト指向にテンプレートなんて入ってなかったでしょ?

333 :デフォルトの名無しさん:2010/03/28(日) 17:30:39
>>331
は?意味がわからない
仮に構造体をもって

typedef struct{
  char *str;
  int size;
}MYSTR;

ってやって毎回strlenを呼び出さなくていい状態にしたときに
それは君のいう「毎回」の定義に入ってるの?入ってないの?
前提がスカスカすぎて答えられないんだよバーカ

こんなことも想像できねーのか?

334 :ああ:2010/03/28(日) 17:32:23
同意 
http://d47.decoo.jp/diary/hasseee/?guid=on

335 :デフォルトの名無しさん:2010/03/28(日) 17:33:33
>>333
ほら、そうなる。

>>322
> 呼び出さないためには値をキャッシュする変数を別途用意する必要があり、
> それらの生成破棄など、管理する手間が別途発生してしまう。
> また、キャッシュのための変数の中身は、
> strlenの結果と同一であるように注意を払う必要も出てしまう。

別途に構造体や変数を用意したり使いまわしたりすることなく、
typedef structのsizeを隠し、
サイズ取得へのインタフェースをsize()と*ひとつだけ*用意したのがオブジェクト指向だ。

336 :デフォルトの名無しさん:2010/03/28(日) 17:36:10
>>335
はぁ?
だからC++の場合ライブラリとしてStringが用意されてるのは認めて
C言語ではライブラリの類を認めないってのはどういう理論なの?
Stringはライブラリでしょ?
C言語で俺が書いたMYSTRがそれに当たるんでしょ?

337 :デフォルトの名無しさん:2010/03/28(日) 17:38:13
それとこの辺ってオブジェクト指向関係ないじゃん
なんでこんなサブルーチン出してオブジェクト指向云々の説明をしようとするの?
できっこないじゃない

338 :デフォルトの名無しさん:2010/03/28(日) 17:38:54
データ抽象がオブジェクト指向だっていうならCだって
オブジェクト指向プログラミングできるだろう

>>335 みたいなバカが多いんだよね
オブジェクト指向脳の連中って



339 :デフォルトの名無しさん:2010/03/28(日) 17:40:48
これはさすがに会話続行不能なレベルだよね
ライブラリと言語仕様と設計の区別もついてない

文字列クラス出してなんでオブジェクト指向の説明になるの?

仕事でもすごいトンチンカンなことやってそう

340 :デフォルトの名無しさん:2010/03/28(日) 17:44:12
>>336
> また、キャッシュのための変数の中身は、
> strlenの結果と同一であるように注意を払う必要も出てしまう。

カプセル化を用いるからこそ、size()のみが提供され、
typedef struct{
  char *str;
  int size;
}MYSTR;
streln(str)とsizeの値の整合性を気にする必要がなくなる。

>>337 カプセル化はなんの話題かな?
>>338 Cでオブジェクト指向プログラミングできるか否かについては言及していない。
>>339 カプセル化はオブジェクト指向ならではだろう?

341 :デフォルトの名無しさん:2010/03/28(日) 17:49:12
別に文字列クラスでオブジェクト指向を説明することについては間違ってないと思うが。
つうか、オブジェクト指向を理解しようとしない奴には何を言っても無駄だろう。
「なぜクラスをインスタンス化する必要があるのか」ってのをよく自分で考えてみたらどうなの。
いちいち説明しないとわからんなら発言すんなよ、って言いたいね。

342 :デフォルトの名無しさん:2010/03/28(日) 17:50:17
>>340
なんでそうやって小手先の技にこだわるの?
オブジェクト指向設計の話をしてよ

343 :デフォルトの名無しさん:2010/03/28(日) 17:53:12
>>342
オブジェクト指向設計??
その話をするのはまだ早いとおもう。
今はまだCと比較できる部分のほうがいいかと。

344 :デフォルトの名無しさん:2010/03/28(日) 17:54:21
>>341
なんで仕様書がないサブルーチンなんかでオブジェクト指向の話ができるの?
理解してないのは君のほうなんじゃないの?
だから文字列クラスでオブジェクト指向の話ができるなんていっちゃうんじゃないの?
できないよ

345 :デフォルトの名無しさん:2010/03/28(日) 18:03:27
文字列に関連したオブジェクト指向のメリット
* 色々なエンコーディングの文字列を統一的に扱うことができる。
* 色々なエンコーディングの生文字列と、UNICODE等の内部表現の文字列を統一的に扱うことができる。
* 色々なエンコーディングの文字列間の比較やソートなどを簡単におこなうことができる。
などなど。
こんな簡単なことに気付きもしない生半可な知識でオブジェクト指向を否定するのって、
ほんとうに愚かで馬鹿馬鹿しいことだと思うのだが、どうよ?

346 :デフォルトの名無しさん:2010/03/28(日) 18:15:52
>>345
彼らはカプセル化すら分かってないから…。
内部表現丸出しでも平気らしいし。

347 :デフォルトの名無しさん:2010/03/28(日) 18:17:17
初心者w

348 :デフォルトの名無しさん:2010/03/28(日) 18:29:11
>>315
オブジェクト指向をまったく知らない者ですが。質問です。
ファイルから一行文字列が読み込まれ新しいstringインスタンスが
生成されるとすると、その度にsetof()が実行され属性sizeにsetof()の結果が
セットされるのですか?
そうなら分かるのですが、そうではないとするとsetof()でstrlen()でも
大差ないような気がするのですが。

349 :デフォルトの名無しさん:2010/03/28(日) 19:08:36
>>345
それオブジェクト指向のメリットなのー?(爆笑)

350 :デフォルトの名無しさん:2010/03/28(日) 19:24:02
追い詰められたカスの特徴w 理屈で返事しないw

351 :デフォルトの名無しさん:2010/03/28(日) 19:34:49
はぁ?文字列クラスなんて意味のねーものいじってねぇで
オブジェクト指向設計の説明してみせろよ
なんで文字列クラスなんだよバッカじゃねーのw

352 :デフォルトの名無しさん:2010/03/28(日) 19:35:46
追い詰められたカスの特徴w 理屈で返事しないw

353 :デフォルトの名無しさん:2010/03/28(日) 19:40:26
ソースが読みやすくて綺麗になる

354 :デフォルトの名無しさん:2010/03/28(日) 20:13:07
知識レベルが近ければオブジェクト志向もチームでやるには有効なケースはあるが、
揃ってないなら捨てた方が吉。中途半端な知識の奴とか覚えたてのニワカがいる場合も
クラス設計そのものがスパゲティになるから排除した方が良いw

355 :デフォルトの名無しさん:2010/03/28(日) 20:26:42
知識レベルが低い奴が書いたコードは
オブジェクト指向であろうがなかろうが
スパゲッティーだっつーの

356 :デフォルトの名無しさん:2010/03/28(日) 20:41:34
あと、オブジェクト指向じゃないとデバッグやりにくい
バグが起きないと保障されている場所もチェックして行かないといけない

357 :デフォルトの名無しさん:2010/03/28(日) 21:10:36
>>355
高い低いの問題じゃない。ぶっちゃけ一人だけ知識深い奴がいても、そいつのコードは周りから見れば
さっぱり、なんてことは良くある。

358 :デフォルトの名無しさん:2010/03/28(日) 22:14:51
だいたい自分のコードが見やすいかどうかなんて誰か1人にでも聞いたことあるのか?w

359 :デフォルトの名無しさん:2010/03/28(日) 22:17:46
複数開発なら普通にあるだろ。「見やすい?」とかじゃなくて「わかる?」とかだと思うがw

360 :デフォルトの名無しさん:2010/03/28(日) 22:22:39
オブジェクト指向的な考え方は、メンテしやすいソフトウェアを書く上では
今や教養として必須だと思うけどな。是非を問う段階はとうに通り過ぎてる。

まぁ、一口にオブジェクト指向といっても、切り口によって色々な解釈があるみたいだけど、
# その辺の小難しい話を知りたいなら、例えば以下のエントリが参考になるかもしれない。
# http://d.hatena.ne.jp/sumim/20040525/p1
# http://d.hatena.ne.jp/sumim/20080415/p1
どれも、最終的には「メンテナンス性の向上」が大きな目的であるという点では共通していると思う。

上でstringクラスを例として挙げてる人がいるけど、それにより実現できる機能にのみ
注目すると、利点を示すのが難しくなるんじゃないか。
一番重要なのは、データと処理を統一的な方法でまとめることで、
「より使いやすく」「より分かりやすく」「より安全に」プログラムできるようになることだろう。

一口に言えば、それが「できる」ことと「簡単にできる」ことの間には大きな差があるし、
生産性の向上という量的な変化は、究極的には質的な変化に繋がりうる。

>>348の人も、そういう観点から入門書を読んでみると良いと思うよ。

361 :デフォルトの名無しさん:2010/03/28(日) 22:25:55
>>356
それちがうとおもう
経験的に、関数的にまとまってる設計(副作用のない設計)の方がデバッグは楽


362 :デフォルトの名無しさん:2010/03/28(日) 22:30:29
>>360
たしかにそうなんだけど, 現場ではオブジェクトの名の元に
クラスに隠蔽されたグローバル変数が飛び交ってるんだが


363 :デフォルトの名無しさん:2010/03/28(日) 22:31:47
>>360
>一番重要なのは、データと処理を統一的な方法でまとめることで、
>「より使いやすく」「より分かりやすく」「より安全に」プログラムできるようになることだろう。
脳みそにウジでもわいてるのか?
それのどこが金になるの?

364 :デフォルトの名無しさん:2010/03/28(日) 22:34:51
>>361
副作用のない範囲で済むコードなら良いと思うけど、それは要求次第なわけだし。
副作用が影響を与える範囲を言語仕様的に限定できるのがオブジェクト指向言語の良いところ。
早い話が、自分や他人がアホなコードを書いた時のリスクを低減できる。

非純粋関数型言語が許されるのは小学生までだよね(AA略という話ならまた話が変わるけど。

365 :デフォルトの名無しさん:2010/03/28(日) 22:35:04
プロセス志向で機能分割するのに比べて、実行フローを明確にできないからOODではむしろ難しくなる。
その辺開発者全員で設計段階から意識共有できないと大変なことになる。
だから所謂「ジャンプ」コードの廃止によって少なくなって行ったスパゲティコードが、OODによって復活した。

なんてのは、15年も前にウェブスターなんかが指摘してたことだけどな。

366 :デフォルトの名無しさん:2010/03/28(日) 22:39:25
>>361
そもそもオブジェクト指向を取り入れてない言語のデバッガが低次元になってる

367 :デフォルトの名無しさん:2010/03/28(日) 22:39:40
>>362
そこは継続的インテグレーションと静的解析ツールを使ってコーディングスタイルを強制、
でいいんじゃね。IDEや各種ツールを導入して自動化するのは重要。

368 :デフォルトの名無しさん:2010/03/28(日) 22:40:47
>>364
> 副作用のない範囲で済むコードなら良いと思うけど、それは要求次第なわけだし
それもちゃうとおもう
うまくデザインすれば、副作用のある個所は物凄く減らせる


369 :デフォルトの名無しさん:2010/03/28(日) 22:44:00
オブジェクト指向ってさ、なんで無理にメソッドの集合で全ての物事を抽象化しようとするのかね?
例えば無いかもしれないデータを表現するのにメソッドの集合で定義すると、
template <class T>
class Option {
public:
T get();
bool isNone();
};
という風に抽象化されると思うけど、これだと実体がNoneなのにgetが呼ばれてエラーになる可能性がある
代数的データ型みたいにメソッドの集合と場合分けの構造と両方持てばいいのに

370 :デフォルトの名無しさん:2010/03/28(日) 22:46:24
>>363
手戻りが減らせればコストを減らせて金になると思うけど。

371 :デフォルトの名無しさん:2010/03/28(日) 22:48:58
>>365
ワークフローが中心になるタイプの業務システムとかだとそういう側面はあるかもしれないな。
そこは、オブジェクト指向というよりフレームワークのレベルでどうにかする問題だという気もするけど。

372 :デフォルトの名無しさん:2010/03/28(日) 22:50:25
>>368
デザインによって副作用は減らせると思うけど、完全に取り除くことはできないわけだし。
それに、そういううまいデザインとオブジェクト指向の採用は矛盾しないんじゃない?

373 :デフォルトの名無しさん:2010/03/28(日) 22:50:30
>>363 ではないんだけど
現実には >>362 の様な理由によって
>「より使いやすく」「より分かりやすく」「より安全に」プログラム
できていないことが問題だろ


374 :デフォルトの名無しさん:2010/03/28(日) 22:53:45
>>369
参照に代入されたnullを「ない」の意味で使うか、Null Objectを定義すればよし。

375 :デフォルトの名無しさん:2010/03/28(日) 22:53:59
ちんこの遊び場はここですか

376 :デフォルトの名無しさん:2010/03/28(日) 22:56:39
>>373
もちろんオブジェクト指向は万能な「銀の弾丸」じゃない。
そこを補うのが、例えば>>367みたいな実践。

377 :デフォルトの名無しさん:2010/03/28(日) 22:57:15
>371
オブジェクト指向の利点を活かすには、それを含めてってことだけどな。
草創期からOODに取り組んでいたウェブスターが言ったのは、人材だの会社の
政治的な側面も考えて「環境を整えてからやれ」ってこと。

378 :デフォルトの名無しさん:2010/03/28(日) 23:04:29
>>374
nullを使ったらnullチェックが必要になるのでisNoneを呼び忘れる危険と変わらないのでは?
Null Objectってどうやって使うの?まさかtypeid?それこそ場合分けの構造じゃんか

こういう小手先の芸じゃなくて、言語使用として場合分けの構造をサポートした方がいいという判断で、
Scalaとかはcase classを導入したんだと思うんだけどなー

379 :デフォルトの名無しさん:2010/03/28(日) 23:05:03
オブジェクト指向じゃない言語は本当に迷宮入りする事があると思う
ある意味怖い

380 :デフォルトの名無しさん:2010/03/28(日) 23:08:19
>>378
http://www.hyuki.com/dp/dpinfo.html#NullObject

381 :デフォルトの名無しさん:2010/03/28(日) 23:14:16
>>379
200人規模のプロジェクトだとオブジェクト指向でも平気で迷宮入りするのは気のせい?


382 :デフォルトの名無しさん:2010/03/28(日) 23:15:10
>>380
ありがとう
読んでみたけど、Null Objectでどうやってgetを実装するの?
戻り値がないので無理でしょ

やっぱりメソッドの集合で物事を抽象化するには限界があるのだと思うよ
限界があるというか、もっといい方法がある場合があるので、そちらも使うべき

383 :デフォルトの名無しさん:2010/03/28(日) 23:15:40
200人いれば200のオブジェクト指向があるってのが事実。
大統一理論があると思ってはいけないw

384 :デフォルトの名無しさん:2010/03/28(日) 23:17:18
>>382
べつにnullを使っちゃいけないということはないと思うけどなぁ。
いい方法があれば併用すべきというのは同意。

385 :デフォルトの名無しさん:2010/03/28(日) 23:22:27
>>382
ていうかべつに代数データ型でなくてswitch caseでいいわけでしょ。
基本的にパターンマッチは記述を簡潔にするのが目的だと思うけど。
OOがやる抽象化は拡張できるようにするためでしょ。

386 :デフォルトの名無しさん:2010/03/28(日) 23:26:08
>>381
そんなレベルじゃない
自分で自分が作った物が分からなくなる
オブジェクト指向だとプログラム自体がある程度設計書だがそれがない

387 :デフォルトの名無しさん:2010/03/28(日) 23:28:02
>>384
同位THX
ついでだからさらに続けると、
一旦場合分けの構造の有用性を受け入れると、意外とその適用範囲が広いことが分かると思うのよ
Scalaではかなり使われているし、関数型言語ではいわずもがな
とすると、これはもう、
"メソッドの集合で全てを表現しようとしたオブジェクト指向はやりすぎでした、間違いでした"
という結論にならざるを得ないのだけど、どうよ?

388 :デフォルトの名無しさん:2010/03/28(日) 23:34:30
メソッドどころか「データの抽象化がオブジェクト指向ではない」ってのは、
高名なクック船長がおっしゃってますw

389 :デフォルトの名無しさん:2010/03/28(日) 23:35:58
>>385
>ていうかべつに代数データ型でなくてswitch caseでいいわけでしょ。
あれ?
オブジェクト指向ってsiwtch caseを使わずにオブジェクトのメソッドで抽象化するというのが原則じゃなかったっけ?
switch caseを使うって事は、場合分けの構造がやっぱり必要って事になるよ

390 :デフォルトの名無しさん:2010/03/28(日) 23:36:21
>>386
それはどうしてそういえるの?

391 :385:2010/03/28(日) 23:44:14
>>389
極端に言えば、パターンマッチはswitch caseがあれば、場合わけの構造とやらがあるので、いらんでしょ?
OOでわざわざ抽象化してデザインすると、それを外部から拡張できるようになる。
それとも場合わけの構造ってなにか具体的な定義があるの?

392 :デフォルトの名無しさん:2010/03/28(日) 23:46:23
>>391
ぶっちゃけそんな細かいとこどーでもいいよ
実装方法なんてどーだっていいし
オブジェクト指向となんも関係ないのに
それがオブジェクト指向だと思ってる可愛そうな脳みそしてる奴多いな
オブジェクト指向はあくまでも仕様をオブジェクトに落とすだけだ

そんな細部の話が出てくる時点でもうおかしいだろ

393 :デフォルトの名無しさん:2010/03/28(日) 23:55:48
>>392
個人的な意見だけど、オブジェクト指向って言葉は、
「オブジェクトという概念を中心に据えたテクニックや分析手法の集合」なんじゃないのかな。
その具体的なテクニックの代表例が、例えばデザインパターン。

だから、人によって見解に相違が出てくるのは当然だし、
「○○という定義に沿ってなければオブジェクト指向じゃない」みたいな話はあんまり意味がないんじゃないかな。

394 :デフォルトの名無しさん:2010/03/28(日) 23:55:58
>>391
>極端に言えば、パターンマッチはswitch caseがあれば、場合わけの構造とやらがあるので、いらんでしょ?
確かにswitch caseがあれば、パターンマッチはそれの強力版みたいなものなので、原理的にはいらない
それは同位
うん?でも議論がかみ合ってないな
別にパターンマッチが必要と言っているのでは無く、
switch caseという便利なものを否定しようとするオブジェクト指向はいまいちじゃない?と言っている

395 :374:2010/03/29(月) 00:01:47
>>394
そりゃ、goto禁止すると例外処理がきれいにかけないから構造化プログラミングはいまいち、
って言ってるようなもんだよ。

あくまで「原則」は「原則」なわけで、どういう書き方が最適かは状況による。
将来拡張する可能性が高いなら、switch caseはハードコーディングされてあまり良くない。
そうでなければ以下略。

396 :デフォルトの名無しさん:2010/03/29(月) 00:06:14
>>393
違うよ
はじめはシミュレーション用の言語だったんだから
オブジェクト=物体と仕様をわかりやすく落とし込むために作られた
たしか気体分子同士の関係をみるためだったかな?

仕様をそのままコードに落とせるのが目的なんだから
デザパタなんて入る隙間なんてない
よってデザパタがオブジェクト指向だという奴はオブジェクト指向を理解してない

大事なのは仕様

397 :385:2010/03/29(月) 00:06:39
>>394
否定してないと思うけど?
だって大抵のOOには場合わけが書ける言語構造があるし、分岐のコードみたんな書くよね。
否定されるのは拡張が必要になるのに、それをやりにくくするコードを書く場合。

場合わけのコードをばらまくことを推奨する言語が、メンテナンスとか拡張とか頭にないってことなんじゃないの?
便利だといって後のことなんも考えてませんみたいな。

398 :デフォルトの名無しさん:2010/03/29(月) 00:07:06
>>388
クック船長がどう言っていようが、
Stroustrup(発音しらん)艦長がなにを言っていようが、
ケイ番長がなにを言っていようが、
このさい関係ない
そんな定義論に興味ない
Abstract Data Typeは使いにくい場面が多いし、偏りすぎ
ただそれだけ

399 :デフォルトの名無しさん:2010/03/29(月) 00:11:11
>>395
>そりゃ、goto禁止すると例外処理がきれいにかけないから構造化プログラミングはいまいち、
>って言ってるようなもんだよ。
なるほど
合点がいった
ありがとう

400 :デフォルトの名無しさん:2010/03/29(月) 00:13:19
>>390
どこに何に対する処理か分からないルーチンがばら撒かれるから
オブジェクト指向だとオブジェクト自体に処理が書かれるからどこにあるか分かる

401 :デフォルトの名無しさん:2010/03/29(月) 00:15:42
>>397
>場合わけのコードをばらまくことを推奨する言語が、メンテナンスとか拡張とか頭にないってことなんじゃないの?
>便利だといって後のことなんも考えてませんみたいな。
でもここは同意できないな
場合分けのコードってメンテナンス性も拡張性も落とさない
ただし静的型付けがあれば、かな

402 :385:2010/03/29(月) 00:25:46
>>401
型でチェックできればいいってもんではない。
コードに手を入れるのは大変だし、取り除くのも大変。

パターンマッチにも拡張性が低いから拡張できるようにって取り組みがあった気がするが。

403 :デフォルトの名無しさん:2010/03/29(月) 00:27:50
>>398
その通りだけどw
表記色々あるが、ストラブストラップ艦長が成功したのは抽象化そのものに
こだわるより、Cとの親和性を重視した結果。
そもそもJavaにおける「プリミティブな型」を考えりゃわかるけど、同じメソッドを
持ってるオブジェクトであるはずでもコピーではまったく同一に扱えないわけで…

メッセージ志向がオブジェクト指向なのかどうかも誰も確定できない状態で、
OODが正しいなんて言うのが間違い。OOD的考え方の導入に利があるかどうかの
話でしかないんだけどな。

404 :デフォルトの名無しさん:2010/03/29(月) 00:31:49
同じコードを10箇所とかにコピペするのを止めて欲しい
仕様変更でコードを変更するだけで死んでしまう

405 :デフォルトの名無しさん:2010/03/29(月) 00:32:55
>>402
つOCamlの多相バリアント
元のコードには手を入れずに拡張できる

406 :デフォルトの名無しさん:2010/03/29(月) 00:37:29
>>396
いわゆるGoF本の正式なタイトルは、
「オブジェクト指向における再利用のためのデザインパターン(Design Patterns Elements of Reusable Object-Oriented Software)」
なんだけどな。。

407 :デフォルトの名無しさん:2010/03/29(月) 00:39:59
>>406
だからといって本人達が理解しているかどうかは全く別
少なくとも俺には製作者のオナニーにしか見えない

408 :デフォルトの名無しさん:2010/03/29(月) 00:41:43
>>407
本人ってのは誰? GoFのおっちゃん?

409 :デフォルトの名無しさん:2010/03/29(月) 00:42:52
それとデザパタははじめの設計思想のシミュのための〜って部分の原型すらないじゃない
仕様をそのままコードに落としこめるメリットをまるごと削り取って
パターンどおりに作ると安全性、汎用性の名のもとに余計な仕様は入れるは、
オナニークラスはいれるは仕様からコードを説明はできないわであまりにも酷い

やってることが給料泥棒と変わらないよ
だいたい、だれが汎用性なんていれてくれって頼んだよ?

410 :デフォルトの名無しさん:2010/03/29(月) 00:44:04
>>402
「開放-閉鎖原則(The Open-Closed Principle)」の考えに基づくなら、
「変更に対して閉じており、拡張に対して開いている」方が良い、という結論にはなるね。

411 :デフォルトの名無しさん:2010/03/29(月) 00:45:18
>>405
拡張できるといってもレコードの拡張とはサブタイピング関係が逆になるので要注意な

412 :デフォルトの名無しさん:2010/03/29(月) 00:46:33
>>409
> だいたい、だれが汎用性なんていれてくれって頼んだよ?

君以外のコーダーと一週間後の自分。
メンテナンス性の向上に役立たない汎用性が不必要であることは言うまでもないが。

413 :デフォルトの名無しさん:2010/03/29(月) 00:47:36
ぶっちゃけデザパタは「馬鹿は何も考えるな!この通りに作れ!」っていうリアリズムだろw

414 :デフォルトの名無しさん:2010/03/29(月) 00:52:24
さっきから
>オブジェクト指向は仕様をそのままコードに落とせる
と叫んでいるイタい上司がいるのですが、なんとかなりませんか?

415 :デフォルトの名無しさん:2010/03/29(月) 00:56:22
>>414
何ともなりません。自分でやってみて実証してくださいとお願いするしかないですw

416 :デフォルトの名無しさん:2010/03/29(月) 00:56:39
A.アセンブラかマシン語
B.超高級言語(ネイティブな母語のようなもの)のインタープリタ

概念というより、言語の問題だろうな…

417 :デフォルトの名無しさん:2010/03/29(月) 01:13:27
ずっと粘着してる奴コテつけろ
だれだかわからない

418 :デフォルトの名無しさん:2010/03/29(月) 01:23:39
>>414
成り立ちから考えてデザパタはどうやってもやってることが違う

419 :デフォルトの名無しさん:2010/03/29(月) 01:27:01
まあ、ちゃんとプログラムやってたら
ほとんどのデザパタはいつのまにかやってるもんだと思う

420 :デフォルトの名無しさん:2010/03/29(月) 01:30:23
>>419
俺とお前の作り方は違うんだな
俺はあくまでも仕様書に書いた構造をコードに落とす
そこにデザパタが介在する隙間はない
パターンなんてねぇから

421 :デフォルトの名無しさん:2010/03/29(月) 01:41:35
>>420
仕様書があるならそれでいいと思う
リファレンスとして仕様書があるから早いしわかりやすい

デザパタはある意味共通化された設計だから分かりやすいってとこもあるが
無理にデザパタにあてはめるのは意味ない
ちゃんと設計してたらデザパタとだいたい同じ設計が出来上がるもんだと思ってるかしな

422 :デフォルトの名無しさん:2010/03/29(月) 01:43:10
だって元々デザパタは経験則で生まれたもんだろ。
マトモなPGが組めば同じようなパターンになるのは当然。
それを「知識」として受け取るような奴がいるから困ることになる。

たとえば誰が使っても単一の生成しかしないようなオブジェクトにおいて、
[factory methodだから〜]とか言ってnewしてからCreateってなのを、あたかも
理想的な実装であるかのように強要する奴はいらない。それだけだろw


423 :デフォルトの名無しさん:2010/03/29(月) 01:48:46
>>422
そうだな

デザパタに限ったことではないがこれが唯一解みたいなのはいて欲しくない
わかってデザパタ使ってほしい

424 :デフォルトの名無しさん:2010/03/29(月) 01:53:33
オブジェクト指向の意味は
privateによるカプセル化と、
ポリシークラスによる構造定義が真の意味だと思ってる
工期がどうってのはあくまで副次的な産物

425 :デフォルトの名無しさん:2010/03/29(月) 09:19:47
オブジェクト指向で用意されたライブラリがクソ使いやすいんだが。
String, Array, Hashとか基本的な奴ほど特に。
Cでやろうとするとすごく煩雑にならないか?

426 :デフォルトの名無しさん:2010/03/29(月) 09:24:22
だよねー
その3つがあればなんでもつくれるよねー

427 :デフォルトの名無しさん:2010/03/29(月) 21:23:31
>>425
Cでの実装も、継承、多態を考えなければ、そう難しくはないと思うよ。

たとえば文字列の場合、

公開用の型として
typedef struct {int class_id;} t_string;
実装用の型として、
typedef struct {int class_id; char* str; } t_string_impl;
を用意しておき、
インスタンス生成の関数が呼ばれたら、t_string_implを生成し、キャストして、ライブラリの外へはt_stringを返す(正確にはポインタを返す)。

その他、文字列操作に関する関数は、返されたt_stringを渡して、ライブラリの中で、キャストしてt_string_implを取り出し、操作する。

使う側としては、インスタンスのポインタと関数のセットで扱うので、そう違いはないかと。

継承、多態を実現しようとすると>>425のいうとおり、煩雑になると思う。
ってゆうか、C++つかいやがれってことです。

428 :デフォルトの名無しさん:2010/03/29(月) 22:39:04
>>425
>オブジェクト指向で用意されたライブラリがクソ使いやすいんだが。
>String, Array, Hashとか基本的な奴ほど特に。
それは別にオブジェクト指向である必要はないよね
MLならモジュール、Haskellなら型クラスというやり方もある
オブジェクト指向しか知らない人は世界が狭いよ

429 :デフォルトの名無しさん:2010/03/29(月) 22:46:13
プログラミングにおける「良い習慣」を全部オブジェクト指向の手柄にしちゃうのが初心者

430 :デフォルトの名無しさん:2010/03/30(火) 21:26:39
昔は、cは関数が豊富でよい、と言われていたものだが。

431 :デフォルトの名無しさん:2010/03/30(火) 22:04:56
オブジェクト指向設計と絡めてC++の利点を説明できない人ってなんなの?
サブルーチンに対してばっかり話してるけどそんなのC言語の標準関数と変わらないじゃん
全然オブジェクト指向出てこないんだけど?w

432 :デフォルトの名無しさん:2010/03/30(火) 22:20:05
>>431
何が変わらないの?

433 :デフォルトの名無しさん:2010/03/30(火) 22:23:06
newしたらオブジェクト指向

434 :デフォルトの名無しさん:2010/03/30(火) 22:25:02
>>432
設計じゃないという意味
設計の話でstrcpyとか出てこないでしょ?
だけどこの板に巣くってる馬鹿な人は
いつもオブジェクト指向の話するのに文字列クラスなんて馬鹿なもん出して説明しようとしてる

いい加減、オブジェクト指向理解できてないって気づけよw

435 :デフォルトの名無しさん:2010/03/30(火) 22:42:27
ここは別にOODと言ってないんだから設計の話じゃなくてもいいだろ。OOPでもw

436 :デフォルトの名無しさん:2010/03/30(火) 22:52:18
だったら別スレ建てろよ
邪魔だな邪魔
オブジェクト指向理解してねぇしw

437 :デフォルトの名無しさん:2010/03/30(火) 22:54:43
別スレはお前だろ。元々オブジェクト指向ってのは実装が先だぞ。
設計なんてのはその考え方を推し進める上で、後から出てきた話だ。

438 :デフォルトの名無しさん:2010/03/30(火) 23:26:18
>>437
はぁ?
馬鹿は糞して寝ろよw

439 :デフォルトの名無しさん:2010/03/30(火) 23:52:52
ちんこさんチンコンパイラはまだですか?

440 :デフォルトの名無しさん:2010/03/31(水) 00:19:45
>>431
オブジェクト指向言語としてのC++はあまり評価が高くないように思うが。

441 :デフォルトの名無しさん:2010/03/31(水) 00:48:00
オブジェクト指向言語としてのC++、なんて話じゃないな。1人が勘違いしてるだけ

442 :デフォルトの名無しさん:2010/03/31(水) 04:38:57
情報隠蔽に、コーディングレベルでの意味を見出せない。
言語レベルでのコントロール規制…うーむ。


443 :デフォルトの名無しさん:2010/03/31(水) 04:51:32
データを勝手に変更させないってことじゃないのか
例えばマイナス入れちゃ駄目な変数に勝手にマイナス入れられないようにするとか

444 :デフォルトの名無しさん:2010/03/31(水) 05:07:58
>一行目
private指定で、getterだけで使用…? 他の思いつかない俺はダメだな。
ハードコーディングしたデータを使うだけなら、別段規制する必要性を感じない。
人間は間違うもんだ…という前提にたっての規制なら…意味あるか

>二行目
setterで入力データのチェックを行う。というのが思いついた。
関数言語でも入力内容のチェックを通すのは容易い。
わざわざそれを隠蔽と称して、setterで行う意味合いはなんだろう。

考えなければ…


そもそも、前面に出やすい「再利用性」も疑問が残る。
関数とオブジェクト指向の再利用性の違い、とはなんだろう?
恐らく、考える階層が違うのだろうが…。

445 :デフォルトの名無しさん:2010/03/31(水) 07:57:02
>>442
静的型検証と同じこと。
特に、自分以外の人間と一緒にコーディングする時のことを考えてみるとよろし。
「昨日の自分と今日の自分は別人」とか言ったりもするし。

cf. 契約ベースプログラミング

446 :デフォルトの名無しさん:2010/03/31(水) 08:01:48
>>444
継承できるかできないかの差かと思う
これができないとコピペが乱立する

447 :デフォルトの名無しさん:2010/03/31(水) 08:06:59
>>444
言うまでも無いが、なんでもかんでもgetter/setterを実装するならあんまり意味がない。
そのオブジェクトが他のオブジェクトに対して、本当に提供すべき「サービス」は何か、ということを考える。
オブジェクトは、責任分散協調系の中の主体の一つ。

再利用性については、何を意識しているかによるけど、
一時期盛んに言われていた「継承は再利用のためにある」みたいな説明は、
最近は批判されていることが多いね。
個人的には、メンテナンス性が向上すれば自ずと再利用性も向上する、程度に考えているが。

あと、「人間は間違うもの」という認識は、君が考えている以上に超重要。

448 :デフォルトの名無しさん:2010/03/31(水) 08:18:54
参考になりそうなキーワード:
単一責任原則
"Tell, Don't Ask."

449 :デフォルトの名無しさん:2010/03/31(水) 09:04:11
あまり専門用語使ってると説得力ない希ガス
よく分かんねで終わってしまいそう

450 :デフォルトの名無しさん:2010/03/31(水) 09:05:42
言ってる方は気持ちいいだろうけど

451 :デフォルトの名無しさん:2010/03/31(水) 10:19:39
>>446
> これができないとコピペが乱立する
出来なくても, unix の kernel にはコピペないよ


452 :デフォルトの名無しさん:2010/03/31(水) 10:28:50
>>451は何を根拠にそう発言したのだろうかw

453 :デフォルトの名無しさん:2010/03/31(水) 10:59:32
>>451
少なくとも, v6 のソースには見受けられなかったし, 4.2BSD もそうだった
*BSD や Open Solaris でもみかけないな.
Linux のドライバにはあるかも知れない.


454 :デフォルトの名無しさん:2010/03/31(水) 11:15:37
オブジェクト恥垢

455 :デフォルトの名無しさん:2010/03/31(水) 12:23:31
OOPのポイントは2つ。
1.クラスのインスタンス化
2.メッセージング

「なぜクラスをインスタンス化する必要があるのか」、
「メソッド呼び出しとメッセージ送信の違いは何か」、
を明解に答えることができれば、
OOPを理解している、とみていいんじゃないの。

456 :デフォルトの名無しさん:2010/03/31(水) 13:08:56
そのふたつはObjective-Cをマスターすることによって理解できるな

457 :デフォルトの名無しさん:2010/03/31(水) 13:30:35
「変数と、それを操作するメソッドを1つにまとめる」(クラス)
「ユニークな変数にはユニークなメソッドを用いる」(クラスのインスタンス化)

Javaで、Stringクラスを100個インスタンス化したとする。文字列の長さを得るには、

オブジェクトa.length();
オブジェクトb.length();
オブジェクトc.length();


とするわけだが、ここで、オブジェクトaのlength()が対応しているのは、
オブジェクトa内部に隠蔽された変数であって、オブジェクトbやcの変数ではない。
このように変数とメソッドが1対1で対応していることの利点は、
片方を知っていればもう片方を知る必要がなくなるということ。
要するに、メソッドを知っていればそれに対応する変数を知る必要がなくなる(隠蔽可能になる)ということ。
変数とメソッドを分離した場合は、変数の隠蔽ができなくなるので、
変数とメソッドの両方を知る必要がでてくる。

変数を隠蔽するという観点からすれば、変数の入力はsetter、出力はgetterで行うのが望ましい、
ということになるね。

458 :デフォルトの名無しさん:2010/03/31(水) 14:07:54
メッセージングについては、
ttp://www.geocities.jp/objectbrain/messagebrain.html
を読めば分かるんじゃね。

OOPってのは、要するに、
可能な限りオブジェクトを他から切り離して単独で動かそうとするプログラミングのことでしょ。
その仕組みがインスタンス化だったりメッセージングだったりするわけで。
非OOPでもOOPのようなことはできるじゃん、ってな意見だかネタだかをよく聞くけど、
そんなこと当たり前のことだよねぇ。できるかできないかの話じゃなくて、簡単か難しいかの話。

非OOPでも、「ローカル変数なんていらん!全部グローバル変数でいいだろ!」
ってなことを言われても、まあ、間違いではないんだけど、普通はやらないからねぇ。

459 :デフォルトの名無しさん:2010/03/31(水) 19:24:23
> このように変数とメソッドが1対1で対応していることの利点は、
> 片方を知っていればもう片方を知る必要がなくなるということ。

???
片方を知っていれば、もう片方を知る必要が無い?何言ってんの?
おまえ、自分の書いたOOPのサンプルコードで、

> オブジェクトa.length();

このように、"オブジェクトa" と length() の両方を指定しているよな。
"オブジェクトa" だけでも、"length()" だけでも、思ったようには動いてくれないよな?
両方知ってる必要があるんだよな?片方だけを知ってれば良いってのはどんな寝言?

まったく、OOP信者はマジキチだな。


460 :デフォルトの名無しさん:2010/03/31(水) 19:39:49
>>457が言ってる「変数」って、オブジェクトaの内部状態のことでしょ。

461 :デフォルトの名無しさん:2010/03/31(水) 19:50:24
Cの関数でも、
構造体aを指定しているのに、
なぜか構造体bのメンバが変更される、
とかありえないから。

struct hoge a, b;
func( &a ); //なぜかbのメンバが変更される。

その発想が怖い。

462 :デフォルトの名無しさん:2010/03/31(水) 20:01:12
>>461
func(hoge)が、内部でbを変更するコードになっていればありうる。

463 :デフォルトの名無しさん:2010/03/31(水) 20:11:08
そしてそれはOOPの欠点だ。
Cなら有りえない。

464 :デフォルトの名無しさん:2010/03/31(水) 20:15:27
単に関数付き構造体ってことじゃないのか
構造体みたく好き勝手に値変えられない構造体みたいな

465 :デフォルトの名無しさん:2010/03/31(水) 20:28:16
>>464
言語仕様レベルではね。特に後段が重要なのではあるが。

466 :デフォルトの名無しさん:2010/03/31(水) 21:46:10
>>459
Javaで、Stringクラスを〜、って言ってんだから、
メソッドa.length()に対応する変数は、
オブジェクト内部に隠蔽された変数(文字列の長さを表す数値)のことでしょ。

ていうか、Javaすら知らないんだったら黙っとけよ。

467 :デフォルトの名無しさん:2010/03/31(水) 21:53:08
しかし、>>459の発言は痛過ぎるね。
まさに、Javaを知りません、OOPLを知りません、ってな文章だなw


468 :デフォルトの名無しさん:2010/03/31(水) 22:11:06
まあ重要なのはそういう隠蔽化ではないけどな。
誰かがStringを継承して、ある特殊なエンコードに対応したクラスを作ってくれたとしても、
その中身をあまり知らずに安易にStringと同様の使い方をすることはできないしね。

469 :デフォルトの名無しさん:2010/03/31(水) 22:14:30
涙ふけって、OOP信者よ。
変数とメソッドが一対一で対応って意味不明だろ。
クラスとメソッドが一対一で対応しているわけで。

470 :デフォルトの名無しさん:2010/03/31(水) 22:18:00
常に対応してるんだったらメソッドなんかいらんわな
単純な関係が崩れたときのためにアクセサを通すわけで

471 :デフォルトの名無しさん:2010/03/31(水) 22:24:04
あーまた変な事言い出した。
メソッドがクラスと対応しているのは当たり前だろ。

472 :デフォルトの名無しさん:2010/03/31(水) 22:27:58
オブジェクト指向なんてもはや基礎教養だろ。
踏まえた上でどう実践していくかというフェーズで、
信じるとか信じないとかいう段階はとうに通り過ぎてる。

まぁ、理解したつもり、のレベルのやつがとても多いのは事実だけどなー。

473 :デフォルトの名無しさん:2010/03/31(水) 22:30:26
>>471
まず、クラスとは何か、メソッドとは何か、という言葉の定義の確認から始めた方が
いい気がするな。

474 :デフォルトの名無しさん:2010/03/31(水) 22:36:23
SmalltalkやCLOSも学んだ方がいい
といってもちんこは人の話を聞かないのであった

475 :デフォルトの名無しさん:2010/03/31(水) 22:36:46
隔離されたグローバル変数(というか環境)みたいなもん

476 :デフォルトの名無しさん:2010/03/31(水) 22:44:18
>>472
Javaの話をしていたんだよね。JavaってクラスベースのOOP言語だよね。
クラスとメソッドが対応するのは当たり前だよね。
メソッドのアドレスが格納されている、いわゆるvtableはクラスごとに用意されるのは知ってるよね。
そしたら、クラスとメソッドが関連付けられるのは自明だよね。

>オブジェクト指向を踏まえた上でどう実践していくかというフェーズで、
そのOOP前提みたいな論調はなんなんですかね。
まーOOPで出来る事はデータの整合をとる事ぐらいだってのが、
大衆にも大体ばれてきてて、
「だったらデータの整合性の管理だけをOOPに任せよう」、
って意味での「踏まえる」ならわかるが。

477 :デフォルトの名無しさん:2010/03/31(水) 23:08:32
>>476
たぶん前半は俺宛じゃないと思うが、
それはどちらかというと「クラスインスタンス」じゃないか?

あと、データの整合性を取る云々は、「責務の分担を保障できる」と考えてみてはどうかな。

もちろん、慎重にコーディングすれば非OOPLでもできる話だが、
OOPLを使ったほうが当然効率が良い。

478 :デフォルトの名無しさん:2010/03/31(水) 23:23:41
>>477
メソッドがクラスにくっついてるのがクラスベースのOOP。
メソッドがインスタンスにくっついてるのがプロトタイプベースのOOP。
こんなの常識過ぎるだろ。
そこの区別の問題があるから、JavaのようなクラスベースのOOPを説明するなら、
「メソッドはクラスと関連付けられる」って表現が適切なんだよ。
メソッドはインスタンスと関連付けられる、と書くと、プロトタイプベースなのかと勘違いされる。

479 :デフォルトの名無しさん:2010/03/31(水) 23:30:00
>>478
クラスの中のメソッドと対応してる時はなんなのよ

480 :デフォルトの名無しさん:2010/03/31(水) 23:32:06
えらく無知を晒してるやついるけど
オブジェクト指向は魔法みたいなものと勘違いしてんじゃねーの?
ほとんど似たようなものだろ

481 :デフォルトの名無しさん:2010/03/31(水) 23:42:53
>>478
だからクラスインスタンスと書いたわけだが。
クラスに紐付く、という説明だとインスタンスを生成することの意味が分からなくなるし、
それにポリモーフィズムの説明ができない。

482 :デフォルトの名無しさん:2010/03/31(水) 23:47:32
>>478
CLOS みたく、どっちにも付いてないのは何て言うんだ


483 :デフォルトの名無しさん:2010/04/01(木) 00:03:47
>>481
Javaのポリモーフィズムはインスタンスのクラスに基づいて行われる。
わかる?
インスタンスのクラスのメソッドが呼ばれる。
もう一度言うよ。
インスタンスのクラスのメソッドが呼ばれる。
インスタンスがメソッドを持っているわけではない。クラスがメソッドを持ってる。
メソッドの呼び出しは、インスタンス→動的クラス判定→メソッドと、クラス経由で呼び出される。
「クラスのメソッド〜」って表現、日常的に使うでしょ。
一方、インスタンスがメソッドを持ってるのは、プロトタイプベースと言う。

でもちょっと考えれば分かりそうなもの。
Javaでは同じクラスのインスタンスであれば、
ポリモーフィズム時に呼び出されるメソッドは同じものになるよね。
これはメソッドがクラスに結びついているから。

484 :デフォルトの名無しさん:2010/04/01(木) 00:06:36
てか本当に初心者が多いな。
こんなんがOOP万歳してるんだろうな。
せいぜい今のうちにいい夢みてればいいよ。
すぐに 大人たちは嘘つきだ って言い出すから。

485 :デフォルトの名無しさん:2010/04/01(木) 00:25:32
>>483
いや、内部的にはその通りだよ。
というか、俺と同じことを言ってるようにしか見えんのだが。

後段については、インスタンスを外部から呼び出す側は、
そのインスタンスの実装クラスが何か、ということは意識しないよね、という話。
あるインタフェースを実装したインスタンスのメソッドを呼ぶと、
実装クラスに合わせて処理が動的にディスパッチされる、
という話を認めると、何か都合が悪いのかもしれないけどさ。
(もちろん、これはOOの要素技術の一つであって、定義でも本質でもない)

486 :デフォルトの名無しさん:2010/04/01(木) 00:28:13
OOPをやってると、どんどん恥垢が溜まっていくのだろうか…

487 :デフォルトの名無しさん:2010/04/01(木) 00:39:53
>>486
反論ないなら寝るけど、他人を自分と同レベルに引きずり落とすことに熱心になるくらいなら、
自分の世界を広げる努力をした方がいいと思うよ。

488 :486:2010/04/01(木) 00:48:27
すみません特別誰の発言に向けた言葉でもありません…
コーディングしてると垢のようなものが溜まっていくような感覚がしまして…
思考が固まっていくような…独り言でした…紛らわしくてすみません…

489 :デフォルトの名無しさん:2010/04/01(木) 00:52:39
コーディングが煮詰まると恥垢が溜まるとは珍しい人ですね。

490 :デフォルトの名無しさん:2010/04/01(木) 00:55:19
削れば恥垢は落ちます…
僕と一緒に綺麗になりましょうよ…ウホッ

491 :デフォルトの名無しさん:2010/04/01(木) 01:02:42
OOPがもし発明されなかったら、
入力支援の方向が左になってたんだろうか。
構造体の変数書くと、その構造体を使う関数が左にずらりと並ぶ・・・

492 :デフォルトの名無しさん:2010/04/01(木) 01:10:57
>後段については、インスタンスを外部から呼び出す側は、
>そのインスタンスの実装クラスが何か、ということは意識しないよね、という話。

その、何か気にしないで済む「実装クラス」とメソッド群は対応しているだよね。
実装クラスが判明すれば、メソッドは一意に決定するんだよね。
クラスが分かればメソッドは決定するんだよね。
クラスがメソッドを決めるんだよね。
だったら、メソッドはクラスにぶら下ってるよね。

てかもう本当にいやになってきた。
JavaなんかのクラスベースのOOPでメソッドがクラスに関連づいてるってことを否定する人って何なのよ。
クラス作らなきゃポリモーフィズム出来ないって時点で気づけよ。
メソッドがクラスにくくりついてるから、
多態したいだけクラス作らなきゃ多態できないんだ。
同じクラスのインスタンスで多態できるか?出来ないよな。
ちなみに、プロトタイプベースだとこれが出来る。
その差はなんだ?メソッドがクラスにぶら下っているか、インスタンスにぶら下っているかの差だよな。

493 :デフォルトの名無しさん:2010/04/01(木) 01:21:02
>>491
俺も昔それを考えた事がある。
俺の結論はこう。
「関数名を書くと、引数にとりうる型の参照可能な変数が列挙される」
要は引数を補完する。何気に便利そうだ。

ところで、OOPで使われる object.method() って並びは英語的に変じゃない?
俺たちはコンピュータに命令を下しているわけだから、命令文的に、
command( object ) の方が自然に思えるのだが。
やっぱOOPって何から何までキモいと思う。

494 :デフォルトの名無しさん:2010/04/01(木) 01:24:42
アドレス空間上、コード領域に置かれるのが判ってるなら〜ベースなんてどうでもよくね?w

495 :デフォルトの名無しさん:2010/04/01(木) 01:31:03
>>492
インスタンスの利用者から見れば、クラスベースであれプロトタイプベースであれ、
メソッドのコードが実際にはどこにぶら下がっていようが、処理系がその詳細を
隠蔽する以上、「インスタンスのメソッドを呼び出す」という風に見えるのだから、
多態性を説明する時に、メソッドがクラスに紐付いていることを過度に強調してなんか意味あるの?

っていう話じゃないの。

496 :デフォルトの名無しさん:2010/04/01(木) 01:36:45
>>493
Objectが主語だからでしょ。

497 :デフォルトの名無しさん:2010/04/01(木) 01:49:33
>>495
インスタンスの設計者はどうなるんだよ。
使う側が気にしなくても良いってのはいつでも真理だよ。

それに俺は何も強調して無いぞ。
俺「メソッドはクラスに関連付いてる」
彼「どちらかというとメソッドはクラスインスタンスに関連付いてるんじゃね」
俺「どちらかというとクラスでしょ」

498 :デフォルトの名無しさん:2010/04/01(木) 01:51:57
>>493
>「関数名を書くと、引数にとりうる型の参照可能な変数が列挙される」
おぉ、いいね。
これはOOPであっても実装してほしいぞ。
変数マークアップ機能の次はこれだ。

>object.method() って並びは英語的に変じゃない?
英語的にも日本語的にも変だな。
command( object ) という書き方がゼロになっていないということも、
戸惑わされる。中には、どちらの表現もできたりする。
object.method() は廃止の方向でいいかもな。

499 :デフォルトの名無しさん:2010/04/01(木) 01:58:39
>>496
> Objectが主語

object.getValue();
オブジェクトが値を得るわけじゃないのに主語?
操作の対象なんだから、オブジェクトのその名のとおり、目的語が適当だと思うんだがな。
オブジェクト指向って名前止めて、主観指向に改名すりゃいいのに。
この破綻したパラダイムにはそっちのがお似合いだろーよ。

500 :デフォルトの名無しさん:2010/04/01(木) 02:09:24
>>496
objectは目的語ですよ。辞書的にみて。。。。。という冗談は置いといて、

objectにmethodというメッセージを送って処理を行わせる。
英語的には、Let object methodという感じなのかな?

こじつけだけど。


501 :デフォルトの名無しさん:2010/04/01(木) 02:25:46
もっとバトルしてくんねぇかなあ
OOPer vs アンチOOPer

ま、アンチOOPerはOOPを理解できないって点で既に劣ってるわけだがw
理解してたら争う意味もねぇな

502 :デフォルトの名無しさん:2010/04/01(木) 02:26:56
現実にはやっぱりオブジェクトは目的語だとおもうよ。
コンピュータに処理をさせる対象として「オブジェクト」なんだから。

でも、OOPの世界ではオブジェクトは、まるで主語であるかのような語順だし、
考え方も、オブジェクトを中心に考えるってんだから、
主語にしようと試みてるのだろうね、現実がどうであろうと。
壮大なウソを突き通そうとするのは大変なものだね。頑張れ北朝鮮、まけるな左翼団体。

object1.hoge();
object2.piyo();

とかさー。
個性豊かなオブジェクト達が、
めいめいに、「僕は〜する」、「僕は〜する」、と、ぶつくさ独り言を唱えてて、
一向にまとまらない様は、オブジェクト指向の本質ですらあると思う。

command( object1, object2 );

と命令してやりたくなる。

503 :デフォルトの名無しさん:2010/04/01(木) 02:44:06
そんでオブジェクト同士が生命維持装置のごとくメッセージを飛ばしあいこしてさー。
プログラマはそれのご機嫌取りに終始させられて。
んで、オブジェクト当人たちはウジウジしててなかなか他のオブジェクトと関わろうとしないしさ、
誰が音頭取るんだよ、とか思ってたら、コンポーネント!とか叫びながら、
親分クラスが登場してきてさー、
そしたら変な木構造が出来上がって、
こんどは、それにそぐわないような処理は出来ませんとか言い出して、
だったら、単一の木構造は止めようとか言うから、ガベコレだね、って
どーすんのこれ。

504 :デフォルトの名無しさん:2010/04/01(木) 07:43:23
>>497
ポリモーで動的に管理したら、実際に動いてるクラスが何かを知る方法って簡単には無いよね
インスタンス単位でみないと、アップキャストされた基底クラスなのか
基底クラスのままのインスタンスなのかで違うやろ

いくらクラスで設計しても、インスタンス管理の設計もしなくちゃならんわけだし
貴方の言いたい方向がよくわからん

505 :デフォルトの名無しさん:2010/04/01(木) 08:06:04
>>504
多態性をC言語で表現するのは無理ではないけど明らかにしんどいし、
「それOOPじゃなくてもできるじゃんwww」の彼としては目を背けたい部分なんじゃないか。

506 :デフォルトの名無しさん:2010/04/01(木) 08:19:39
>>502
> 現実にはやっぱりオブジェクトは目的語だとおもうよ。

語順的にはそういうケースは多いな。

ただ、オブジェクトを主体として考える概念であることには違いない。
各主体に責務を割り当てて、(君曰くウジウジしてる)オブジェクト同士に適切な関係を設定してやると。
「関数に書かれた手続きをプログラマが仕切ってグワっと並べるのがプログラミングだろ!」
というのは確かに漢らしいかもしれないけど、それで物事が片付くのはかなり小さなシステムに限定される
ということに気づかないと、確かにオブジェクト指向はプログラマの主導権をスポイルする軟弱な概念に見えるのかもな。

507 :デフォルトの名無しさん:2010/04/01(木) 09:22:32
thread.run()とか、object.toString()とか、すごく自然だ。

508 :デフォルトの名無しさん:2010/04/01(木) 09:57:31
おまいら実際、どんだけの物を書いたの?
俺はJavaで5万行。Rmi+JDBC+Appletなシステムを一人で書いた。
C++で一万行。PlatformSDK+Win32API使ってエディタ書いた。

一方、Cでは宿題スレの宿題を書いた。
上記エディタは最初BCCのCを使って書いていたが、
なんだが息苦しくなってC++で書き直す羽目になった。
AbstractWindowを作って、色々派生させて画一的に扱いたかったから。

509 :デフォルトの名無しさん:2010/04/01(木) 10:56:38
批判ではなく、純粋な質問なのだが

何行書いた、というのは具体的にどんな意味があるの?

510 :デフォルトの名無しさん:2010/04/01(木) 11:13:41
規模の目安。

なるべく簡潔に書く派と、そうでもない派があれど、
百行と一万行は規模が違うし、一万行と十万行も規模が違う。

(そうでもない派ってのは、可読性のため一時変数を導入したり、
コメントもたっぷりつけたり、改行を間に入れがちなスタイルだったり)

おまいらがどんな規模のものを想定して発言してるのか聞いてみたかっただけ。
規模が大きくなればなるほど、カプセル化やポリモーフィズムが恋しくなるから。

511 :デフォルトの名無しさん:2010/04/01(木) 11:14:00
OOPだと例えばシューティングゲームでの敵を処理する場合
移動する場合 enemy.move() とか書けて
さらに同じ敵でも敵クラス継承すれば enemyTypeA.move() とか enemyTypeB.move() とか
違う敵の種類でも .move() と同じ書き方しても使用するインスタンスにより違う動きをさせることができるから直感的に記述することができる
さらに敵クラスがオブジェクトクラスを継承したものだとすると
それを自機クラスに継承させると myShip.move() と同じように書ける
同じことCでやろうとするとどうなるか
関数名をいくつも用意させなければならない羽目になる
例えば move_EnemyTypeA(EnemyTypeA *enemyTypeA), move_EnemyTypeB(EnemyTypeB *enemyTypeB), move_MyShip(MyShip, *myShip)
とか用意しなくいけなくなり、面倒になる
これがC++なら move() だけで済み、これだけで「動く」という処理を直感的に記述することができる
取りあえずの1例としてOOPの便利さを示した

512 :デフォルトの名無しさん:2010/04/01(木) 11:52:56
OOPは利点が多々あるが、そんな直感的な記述はすべきではない

513 :デフォルトの名無しさん:2010/04/01(木) 11:57:25
>>512
なぜだね?

514 :デフォルトの名無しさん:2010/04/01(木) 13:07:52
根本的に、コンピュータはマシン語でしか動かない
その為、結局どんな手法でも、複雑さは変らないが
手法によって複雑さを、人間に表現させる方法に差が出る(手法や言語は、人間が理解し易くする為の物)

・POA(機能中心アプローチ):”アルゴリズム”を中心に、複雑な処理を表現する
・DOA(データ中心アプローチ):”データ構造”を中心に、複雑な処理を表現する
・OOA(オブジェクト指向):アルゴリズム+データ構造(クラス)の”構造(オブジェクトの連係)”を中心に、複雑な処理を表現する


515 :デフォルトの名無しさん:2010/04/01(木) 13:41:25
>>493

「彼女を守る」「法律を守る」で「守る」の意味は全然違う。「彼女を守る」ことは「彼女に
従う」ことではない。

英語だと、「I drew a veil」は「私はヴェールを描いた」だが、「I drew a veil over my face」だと、
「私は顔にヴェールをかぶった」となる。

英語のようにメソッドを先に記述すると、解釈が文末までなかなか確定しなくて不便だ。
「Join(Thread)」だと、どうも心が落ち着かない。オブジェクトを先に記述する「Thread.Join()」ほうが
好まれた。

516 :デフォルトの名無しさん:2010/04/01(木) 14:46:56
メッセージングのアイデアはアラン・ケイの発案だが、彼はこんなふうに説明している。参考まで。

このような柔軟な機能はどれだけ複雑である必要があるだろうか?
文法上は決して複雑で無くてもよい。なじみ深い英語の語順である主語、
動詞、目的語(よく前置詞や、たまに暗黙の主語を伴う)があれば全く十分だ。
オブジェクト指向の言い方で言うと、主語はメッセージのレシーバであり、
文の残りはメッセージだ。《略》という事で、オブジェクトはただ
ネットワーク上のピア・ピア・サーバのように考えられ、使われると考える。
(これは偶然ではなく、六十年代後期におけるARPAnet から Internet にかけての
開発にさかのぼるアイデアを起源とする)。

http://metatoys.org/oxymoron/oxymoron.html

517 :デフォルトの名無しさん:2010/04/01(木) 15:01:35
アラン・ケイには敬意を表するが、
彼の言ってることをあまり理解したいとは…思わないw

518 :デフォルトの名無しさん:2010/04/01(木) 15:18:36
class S
{
 void V()
 {
  o.C();
 }
};
こんな感じだと思っていたのに

519 :デフォルトの名無しさん:2010/04/01(木) 18:21:29
>>515
Thread.Join()の方がキモいと思うがなぁ。
だって、実際にJoin処理を行うのはコンピュータであって、Threadじゃないから。
computer.join(thread)ってイメージ。
今思いついたが、please.join(thread)って書き方が洒落てて面白いかもしれない。
pleaseってクラス作って、グローバルな関数を全部ぶち込んどく(笑

でもさー、
アセンブリでもadd a, bと書くし、Unixのシェルでもcat fileとか書くんだから、
やっぱコマンドが前に来るのが自然な発想なんじゃないの?
不自然なことすると、ウソが雪ダルマ式に膨らんで、どっかで詰むよ。

520 :デフォルトの名無しさん:2010/04/01(木) 18:32:04
でさー、
目的語を前に置くのは、そう言う方言だから仕方が無い、ということで了承したとしても、
目的語が二つ以上あった場合はどうするんだという問題が残るよね。
(object1, object2).method;
こうは書けないんだろ?
だったら素直に、func(object1, object2);で良いと思うのだが。


521 :デフォルトの名無しさん:2010/04/01(木) 18:44:25
引数が二個以上あるとややこしい。
strcpyに渡す二つの変数、どっちがsrcかdstか分からなくなる。

str.copyTo(str2)のほうが見やすいのでは? どうかね?

522 :デフォルトの名無しさん:2010/04/01(木) 20:09:33
>>519
それを言い出すと、そもそも「コンピュータに処理を命令(コマンド)する」という概念自体が
「ウソ」なわけだが。

物理的には電気信号の微細な変化に過ぎないし、理論的にもチューリングマシンの
定義に「命令」とか「コマンド」なんて単語は出てこない。計算機に算譜を入力する行為が
「命令」のアナロジーと相性が良いから、という程度の話。

極端に言えば、コンピュータ技術ってのは、ただの電気信号の変化に過ぎないものを、
いかにうまく「ウソ」をついて、それに何か意味を持っているかのごとく人間に誤解させるか、
そういうものだと言ってもいい。
それを「人間から計算機への命令」という形で見せるか、「計算機の中にある仮想的な
ノード間でのメッセージのやり取り」という形で見せるかは、単に流儀の問題に過ぎない。

そして、>>520-521のやり取りで如実に現れているが、特に二者関係を扱うときに、
「ただ一つの計算機に人間が命令して仕事をさせる」というモデルでは、うまく扱えないことが多い。
そこをうまく概念化して整理できるのが、オブジェクト指向の利点の一つだ。


とりあえず、君がオブジェクト指向の何に躓いてるのかは何となく見えたけど、まぁ、あれだ、
もっと広い物の見方を身につけろ、としか言えんな。
計算機の世界の広さは、人間の発想力の広さと同じなんだよ。それを自分で狭めるこたない。

523 :デフォルトの名無しさん:2010/04/01(木) 21:10:12
>>518
クラスを作ることはオブジェクト指向言語では必須ではないはず。
クラスをつくらない言語というのもあるから(何かは忘れた)。

あと、インスタンス化のオブジェクト指向言語では必須ではないはず。

C++やJavaはピュアオブジェクト指向言語ではなく、マルチパラダイム言語なんだよね。

>>520
目的語2つというのはおかしいよね。
その場合だと、意味的にはobject1, object2の2つをもつセットにmethodを行わせるという形になるんじゃない。




524 :デフォルトの名無しさん:2010/04/01(木) 21:12:57
うわ、でたよ。得意技の詭弁。
池沼じみた発言をしてすぐ煙に巻こうとする。
なんでもそうだけど、コマンド的なものが前に来るのが一般的で、
それを否定しようが無いから、電気信号が〜とかわけわからんこと言い出す。
if文が {}(x)if だったら嫌だろ?
for文が {}(;;)for だったら嫌だろ?

>特に二者関係を扱うときに、
>「ただ一つの計算機に人間が命令して仕事をさせる」というモデルでは、うまく扱えないことが多い。

簡単だよ。command( object1, object2 ) ほらよ、object1とobject2の2者間の関係をうまく扱えたよ。
「ただ一つの計算機に人間が命令して仕事をさせる」ってモデルは現実を良くあらわしているし、
なにもウソは無いし、それでみんなうまくやってきているわけだから、
それを「うまく扱えない事が多い」って言うのは現実を否定している罠。
だって、一台のコンピュータに命令を下して皆仕事してるんだろ。

それに、2者間の関係を表すのは一般的にはOOPのほうが苦手だ。
object1.relation(object2);
object2.relation(object1);
メソッドをどっちのクラスに実装すべきか迷うし、どっちに実装したとしても不自然で不細工だな。

525 :デフォルトの名無しさん:2010/04/01(木) 21:18:57
>>523
>目的語2つというのはおかしいよね。
なんでおかしいんだよ。
複数のオブジェクトに対して処理をしたいことだってあるだろ。
目的語は常に一つってのはOOP脳か何かか?

526 :デフォルトの名無しさん:2010/04/01(木) 21:27:38
前、別のスレであった奴
(map (lambda (x y) (+ x y)) '(1 2 3) '(4 5 6))
map(lambda x,y:x+y,[1,2,3],[4,5,6])

[[1,2,3],[4,5,6]].transpose.map{|x,y| x+y}
rubyの方はあまり直感的じゃないと思う

527 :デフォルトの名無しさん:2010/04/01(木) 21:37:21
>>524
> if文が {}(x)if だったら嫌だろ?
> for文が {}(;;)for だったら嫌だろ?

逆ポーランド記法、でググってみるといいと思うよ。
ていうか、関数型言語だとそういう感じの記法ってよく見かけないっけ(制御文であるかは知らんけど)。

本題の話をすると、>>522は別に詭弁でもなんでもなくて、むしろコンピュータの本質だよ。
プログラミングというのは、人間の物の見方、すなわち価値観を計算機に入力することだ、と言ってもいい。
オブジェクト指向的な価値観は絶対ではないが、一方で、命令的なパラダイムもある時期に支配的だった
価値観の反映に過ぎない。どちらも、対象をモデル化するためのもので、表現の仕方が違うだけ。

だからこそ、君がやってるように、OOPLでの表現を非OOPLで表現することができるわけだ。
その上で、わざわざ分かりにくく、効率の悪い方法で表現する必要もなかろ、という話。

528 :デフォルトの名無しさん:2010/04/01(木) 21:55:41
>>520
それよくある。
二つのクラスに密接に関わる関数を、
どっちのクラスにメソッドとして装備させようか、
判断がつかないのな。

結局、Utl とか、Ability とかの名前の静的クラスを用意して、
static な関数を集めることで便利に使えている。
そこに関連する定数も集めておく。

静的クラスは案外使える。
何でも new できればいいわけじゃないって。

>>521
str2 = str1
が一番見やすいと思うw
演算子への適用もOOPの利点だよな。
vector + vector
ができるのがいいんだけどな。

529 :デフォルトの名無しさん:2010/04/01(木) 22:06:17
逆ポーランド記法ぐらいしってるって。
「嫌だろ」という話をしてるんだ。事実、あんま使われねーだろ、読みにくいから。

ざっくり言うと、今、「後置記法は読みずらいだろ」みたいな話をしているわけでしょ?
なんで、電気信号がどうとかって話になるんだ?詭弁だろ。
それに、コンピュータが「何か」するのは事実だろ。
実際お前の目の前で「何か」しているだろ。
オブジェクト指向みたいに、そう言う風に見せかけているだけじゃなくて、
ハードウェアレベルで「何か」しているよね。
それに指示出すこと考えているんだから、そのハードウェア構成を端的にモデル化した
言語で指示出したいよね?何がある?ただの電卓と違う点は何処?
まずメモリ空間があるよね。次にプログラムカウンタがあるよね。
だったら、プログラミングってのはメモリ空間をどう分割するかという「データ構造」と、
プログラムカウンタをどう制御するかという「制御構造」に終始することになるよね。
OOPなにそれ。オブジェクトがメッセージ投げ合ってどうのこうの?好きにやってよ。
どっかでハードウェア構成とのギャップが出てきて苦しむんだ。
実際のハードウェア構成と合っていない、それが「ウソ」だということだ。
お前の言うわけのわからん「ウソ」の定義と違って明確だな。

530 :デフォルトの名無しさん:2010/04/01(木) 22:07:09
ベクターの足し算が+で出来るとか、どうでもよすぎる

531 :デフォルトの名無しさん:2010/04/01(木) 22:18:51
>>529
おまえ、OOPの良さが理解できないんだろ?
OOPすら理解できない能無しは発言しないでくれるかな。

532 :デフォルトの名無しさん:2010/04/01(木) 22:21:31
俺の知る限り、物事を深く理解する者は、その暗部も認めるものだ。

533 :デフォルトの名無しさん:2010/04/01(木) 22:26:02
良い部分を知らない奴と、良し悪しの両方を理解している奴じゃ次元が違うっしょ。

534 :デフォルトの名無しさん:2010/04/01(木) 22:30:48
>>529
これほど歪んだアセンブラへの愛の吐露は初めて見た。

> まずメモリ空間があるよね。次にプログラムカウンタがあるよね。
> だったら、プログラミングってのはメモリ空間をどう分割するかという「データ構造」と、
> プログラムカウンタをどう制御するかという「制御構造」に終始することになるよね。

1. OSや低レベル言語処理系がハードウェアをそういう風に見せているだけ、だけどな。
2. そういう道具立てを使って、異なる価値観に基づいたモデル化をするという方法もあるのだよ。
  仮想化って知ってる?

> それに指示出すこと考えているんだから、そのハードウェア構成を端的にモデル化した
> 言語で指示出したいよね?

実現したいユーザ体験を、簡潔かつ変更に強い形でモデル化できる言語で指示を出したいです。

> OOPなにそれ。オブジェクトがメッセージ投げ合ってどうのこうの?好きにやってよ。
> どっかでハードウェア構成とのギャップが出てきて苦しむんだ。

多少の処理負荷の増大よりも、モデル化のしやすさを追求して人間に楽をさせてくれるのがオブジェクト指向。
ギャップなんてものは、ハードウェア性能の向上で既に吸収されている。

> 実際のハードウェア構成と合っていない、それが「ウソ」だということだ。

単体ハードウェアを前提にするのが好きみたいだけど、
分散コンピューティングとか並行プログラミングって知ってるかな?

535 :デフォルトの名無しさん:2010/04/01(木) 22:33:05
なんで悪い部分だけをピンポイントで知りえると思うのか。
せっかくなので、OOPの良い部分を語ってもらいましょうかね。
カプセル化?多態?オーバーロード?何が挙がるかな。
でも、多くの人たちが挙げる利点の中には、
OOPとコンピュータの相性が悪い部分を吸収するために
仕方なく追加したような妥協的機能を、何故かありがたがっている変なケースもあるよ。
物は言いようという奴。

536 :デフォルトの名無しさん:2010/04/01(木) 22:47:34
ほらまたOOP信者の詭弁ごっごが始まった。五万とみてきた。
こういう風になればいいなぁ〜ああいう風になればいいなぁ〜そんなばっか。
何が出来て何が出来ないかまるで区別が付いていない。
お前に限って言えば、「〜って用語知ってる?」
こんなばっか。しかも提灯記事に使われるようなキャッチーな技術用語ばっか。
お前にそれらの用語のバックグラウンドに潜む技術が必要になることは
永遠に無いだろうになー、ご苦労な請った。

> 実現したいユーザ体験を、簡潔かつ変更に強い形でモデル化できる言語で指示を出したいです。
何これ(笑 政治家みたいな言い回しだな。出来るといいね。被れてる間は無理だと思うが。

> 多少の処理負荷の増大よりも、モデル化のしやすさを追求して人間に楽をさせてくれるのがオブジェクト指向。
「追求して」だってさ。いつからOOPはそんな言語になったんだ。
どうやったらそんな無責任で適当な事ばっかいえるのか。お前やっぱおかしいよ。

> ギャップなんてものは、ハードウェア性能の向上で既に吸収されている。
はぁ?実行時のオーバーヘッドのはなしなんかしてたっけ?
ゆわば設計時のオーバーヘッドの話をしていたんじゃないの?大丈夫?

537 :デフォルトの名無しさん:2010/04/01(木) 22:52:42
>>536
技術的な反論をしてくれないかな。
あと、君の言う「プログラム」というのはどの程度の規模と複雑さを想定している?

538 :デフォルトの名無しさん:2010/04/01(木) 22:56:14
ちなみに、非スタンドアロン環境(並行コンピューティングとか)に対する反論もまだだね。
ぜひ合理的にお願いしたいところだけど。

539 :デフォルトの名無しさん:2010/04/01(木) 23:02:01
オブジェクト指向の出発点には些細なウソが含まれてて、
そのウソを突き通すために、OOPで書かれたプログラムやOOP自体が、
雪ダルマ式にファットになってる。
そのウソがあったからこそ、あることに目を瞑ったからこそ、
夢が広がったんだけれど、でも、もともとがウソから始まってるから、
物語は悲しい幕引きになる。現実逃避の産物といえるな。
OOPにあるのは生産性ではなくてエンターテイメント性だったってわけさ。

540 :デフォルトの名無しさん:2010/04/01(木) 23:02:40
メモリ空間やプログラムカウンタっていうハードウェアがある、とか思ってる件についても聞こうか。

541 :デフォルトの名無しさん:2010/04/01(木) 23:09:23
オブジェクト指向ってようするにモジュールを分割する手法のひとつでしょ

542 :デフォルトの名無しさん:2010/04/01(木) 23:12:46
>>519

そう書くと、Computer.Join(Char, String)か、Computer.Join(Thread)とかになる。

文字列結合のJoin()とスレッド同期のJoin()が全く違うことをやるので、気持ち悪い。

あと、String.Replace("a", "b").Replace("c","d")を、Replace(Replace(String, "a", "b"), "c", "d")
みたいに書かなければならなくなる。

>>520

オブケクト配列を対象とするメソッドは、(Object1, Object2).Method()で問題ないだろう。

543 :デフォルトの名無しさん:2010/04/01(木) 23:15:25
>あと、君の言う「プログラム」というのはどの程度の規模と複雑さを想定している?
これは難しいな。OOPを使わないで、機能ごとにモジュール化していくかぎりは、
モジュールごとで完全なカプセル化が行えるから、それほど複雑にならないし、
規模と複雑さは「なんでも」って事になるだろうな。
OOP使わない方がカプセル化は硬くなるし、オーバーライドやオーバーロードなどの
あいまいさも減るから、安全になる、とは言っとく。
反例挙げるなら再利用性について言及すべきだったな。

>ちなみに、非スタンドアロン環境(並行コンピューティングとか)に対する反論もまだだね。
>ぜひ合理的にお願いしたいところだけど。

ノイマン型コンピュータである限り構造は同じだ。
メモリ空間があって、プログラムカウンタがある。ただ、それらが複数あるってだけだ。
データ構造と制御構造は複雑に成るだろうが、それは、ハードウェア構成が複雑なのだから仕方が無い。
何もウソは無い。

544 :デフォルトの名無しさん:2010/04/01(木) 23:17:03
>>539
君が言ってる「命令」や「ハードウェア」は、それもまた「ウソ」の産物だというのは既に指摘したよね。

べつに、「ウソ」だから悪いわけじゃない。
人間に対してより素晴らしい「ウソ」をつける計算機環境こそ、我らの目指すべきものだからね。

そして、「ウソ」のつき方も一通りじゃない。
例えば、「ウソ」の上に「ウソ」を塗り固めた環境を用意して、その上でコーディングするというのもアリだ。
早い話が、スクリプトのランタイムとか、Javaや.NETの仮想マシンとかだな。
そういう環境で処理性能も同時に追求したいなら、JITに任せればいいわけだし。

545 :デフォルトの名無しさん:2010/04/01(木) 23:24:30
>>543
っ【マルチプルインスタンス】

> メモリ空間があって、プログラムカウンタがある。ただ、それらが複数あるってだけだ。

複数あって協調させなきゃいけない時点で、
単純な「人間 vs. 計算機」の命令モデルは破綻するわけですが。

546 :デフォルトの名無しさん:2010/04/01(木) 23:27:24
>>542
> 文字列結合のJoin()とスレッド同期のJoin()が全く違うことをやるので、気持ち悪い。
そりゃお前普通にコンパイルエラーだろ。オーバーロードなぞ俺も嫌いだ。

>あと、String.Replace("a", "b").Replace("c","d")を、Replace(Replace(String, "a", "b"), "c", "d")
>みたいに書かなければならなくなる。

あーどうしよう、
String.Replace("a", "b").Replace("c","d")
が汚く見えてしまう。

547 :デフォルトの名無しさん:2010/04/01(木) 23:34:47
>>539
言いたいこと、なんとなくはわかるけど。
関数を構造体と合体させたのは確かに問題が多いかもしれない。

それで、グローバルオンリーの関数群のカプセル化機能が
付加できなかったわけではないし、
構造体だけ継承を付ければ、よかったかもしれない。
とにかく、もっとシンプルな言語の進化であったほうがよかったのは、認める。

僕は、OOPがもっと理想的な状態でコンパイルされれば、
それほど遅くなるはずがないと思っている。
ベースのよりマシン語レベルへの変換が行われにくさがあるから、
コンパイラが完全になりにくいだけなんだよ。
それでも、マシン語レベルまで落とすことは不可能だと思わないし、
現に最近のコンパイラはより速いコードをはくようになった。

上の議論で目的語が二つ以上のとき苦手というのがあったが、
逆に、一つに集中しているときは得意というのもある。
jQueryのメソッドチェーンとかさ。
大規模ならOOPという意見があるが、
クラス設計ミスると、とてつもないことにならんの?
小規模なスクリプト系で、他人が念入りに設計したものを使うのにOOPは便利じゃん。

548 :デフォルトの名無しさん:2010/04/01(木) 23:41:31
>>544
> 君が言ってる「命令」や「ハードウェア」は、それもまた「ウソ」の産物だというのは既に指摘したよね。
またなんか言い出した。こいつ本当にどうしようもないな。
それじゃあれですかね、数学の数字の「1」もウソの産物なんですかね。
まぁそんなことはどうでも良いんですけどね、だってそれは、お前の言ってる
中学生のいいわけみたいな意味で「ウソ」という言葉を使っているわけじゃないからな。
俺は明確に、ハードウェアとのミスマッチ、実態とのミスマッチが俺の言う「ウソ」の定義だと
宣言しているわけで。お前の勝手な定義で話し進められても困る。

>>545
メモリ空間をどう分断するか、それは、マルチプルインスタンスそのものだ。
データをどう配置するかって話だからな。

> 複数あって協調させなきゃいけない時点で、
> 単純な「人間 vs. 計算機」の命令モデルは破綻するわけですが。

「人間 vs. 複数の計算機」になるだけだろ。
こんどは複数の計算機に対して命令を出すわけだ。
どういった状態でネットワーク化されているかによって書き方が変わってくるだろうが、
そこにウソは無いよ。

549 :デフォルトの名無しさん:2010/04/01(木) 23:44:52
>>547
> クラス設計ミスると、とてつもないことにならんの?

クラス設計をミスって大被害を負うような規模で、非OOで組むとか想像もしたくないな。

その辺のリスクを軽減できる、オブジェクト指向より良い抽象化手法が出てくる可能性は否定しない。
どちらにせよ、ハードウェア大好きな彼が望む方向とは真逆だろう。

550 :デフォルトの名無しさん:2010/04/01(木) 23:45:29
また、文字列クラス(=サブルーチン)でオブジェクト指向語るアフォがでたのか?
だからそんなサブルーチンじゃ
オブジェクト指向の話なんかできねっつのw
なんでいつまでたっても設計レベルの話ができないんだこいつはw

551 :デフォルトの名無しさん:2010/04/01(木) 23:47:55
>>547
おー分かてるねー。
もともとオブジェクトってのはデータ構造寄りの発想なのに、
そんなところに、制御構造をぶら下げた罪は大きい。
おかげで制御構造はズタズタ。
パゲッティーって何の事だったっけ、人類は過去から学ばないものだね。

後半の実行速度云々は俺はあんま気にしないけどな。

552 :デフォルトの名無しさん:2010/04/01(木) 23:49:43
>クラス設計をミスって大被害を負うような規模で、非OOで組むとか想像もしたくないな。

非OOPでモジュール単位で完璧なカプセル化を行った方が
はるかに安全なんだよ。柔軟性は損なわれるがな。
やっぱりわからない人なんだね。

553 :デフォルトの名無しさん:2010/04/01(木) 23:51:53
>>548
例えばだが、いまどきのOSで、君の大好きな「メモリ空間」が
物理アドレスと一対一対応じゃないことくらいは当然知ってるよね・・・?
それに、まさか仮想メモリを指して「ハードウェアとミスマッチだからてめーは駄目だ」とか言わないとは思うが。

> メモリ空間をどう分断するか、それは、マルチプルインスタンスそのものだ。
> データをどう配置するかって話だからな。

それ、全部処理系に任せようよ。

> 「人間 vs. 複数の計算機」になるだけだろ。
> こんどは複数の計算機に対して命令を出すわけだ。

君も、既に計算機が自律分散協調であることの恩恵を受けてるはずなんだがなぁ。
そんなに命令モデルでないと許せないなら、今日からGoogleを使うのはやめた方がいい。

554 :デフォルトの名無しさん:2010/04/01(木) 23:54:00
>>552
> 柔軟性は損なわれるがな。

OOが支持される理由、その答えを自分で言ってるわけだが。

555 :デフォルトの名無しさん:2010/04/02(金) 00:09:23
>>553
???
仮想メモリはハードウェアとマッチしてるだろ?何言ってんだ?

> それ、全部処理系に任せようよ。
データの配置を処理系が面倒見てくれるのは悪くないと思うよ。
でもそんな話してたっけ。

> 自律分散協調
で、でたー。まさに人権屋的発想。こういうやつらこそOOPを駄目にしているのだろうな。
いちおう教えといてあげるけど、お前、多分いわゆる中2病状態だよ。
あとでわかるよ。

556 :デフォルトの名無しさん:2010/04/02(金) 00:16:44
あれだよ、柔軟性は必要になってから書き足しても問題ないし、
再利用性は、初めから期待するだけ無駄というもの。
どうせ使いまわせるのは、使いまわす必要が無いほど単純なものか、
もしくは、完璧にカプセル化された製品レベルの巨大なモジュールかのどっちかだ。

557 :デフォルトの名無しさん:2010/04/02(金) 00:51:02
>>555
> 仮想メモリはハードウェアとマッチしてるだろ?何言ってんだ?
逆だ、ソフトに合わせるようにハードが作ってあるだけだ
誰かがもっと効率のいい仮想メモリ管理アルゴリズムを思いつけばハードもかわる


558 :デフォルトの名無しさん:2010/04/02(金) 01:28:06
またサブルーチン馬鹿が現れたか

559 :デフォルトの名無しさん:2010/04/02(金) 01:53:24
なんでサブルーチンでオブジェクト指向の話をするのかわからないな
んで結局、メモリがどーだとか実行速度がどーだとか関係ない話に行っちゃう
馬鹿だろ?
頭悪いだろ?
設計とかやったことないだろ?
なんでそんなに頭悪いの?

560 :デフォルトの名無しさん:2010/04/02(金) 02:31:39
俺はOOPLが当たり前の世代なので、非OOPな人にマジで聞きたい
複数のクラスのインスタンスがごちゃ混ぜに入れられたコレクションの
各要素を文字列化し、出力する…という処理は
OOPLだと各要素に対してtoString()とかそれに準ずるメソッド呼べば良いんだが
非OOPLではどう書けば良いんだ?

561 :デフォルトの名無しさん:2010/04/02(金) 03:01:10
>>560
なんでそんなサブルーチンの話をするの?

562 :デフォルトの名無しさん:2010/04/02(金) 03:02:50
>561
何故って、どうやって書くのか疑問に思ったから

563 :デフォルトの名無しさん:2010/04/02(金) 03:09:11
>>562
じゃ、スレ違いだから別スレでやってね

564 :デフォルトの名無しさん:2010/04/02(金) 03:10:46
このスレで話していいよ。
OOPvs非OOP

565 :デフォルトの名無しさん:2010/04/02(金) 03:26:34
構造体にタグ入れといてclass1_toString(),class2_toString()・・にswitchって感じじゃない?
関数ポインタ使う仕組みとかでもいける

566 :デフォルトの名無しさん:2010/04/02(金) 03:26:44
聞きかじりオブジェクト指向ばっかw

567 :デフォルトの名無しさん:2010/04/02(金) 03:28:57
何か色んな階層の話に飛び火して
意味が分からない。



568 :デフォルトの名無しさん:2010/04/02(金) 03:29:11
サブルーチン馬鹿よりかはマシだな

569 :デフォルトの名無しさん:2010/04/02(金) 03:31:37
まあさ・・・
オブジェクト指向が有用でも別にお前が偉いわけじゃないって種類の反感があるんだよ

570 :デフォルトの名無しさん:2010/04/02(金) 03:32:51
オブジェクト指向にstatic変数があるのがおかしいと思う。
これさえなければたとえCであってもOOPになると思う。(スタックがすごいことになるが)

571 :デフォルトの名無しさん:2010/04/02(金) 03:35:17
singletonにはstaticが…

572 :デフォルトの名無しさん:2010/04/02(金) 03:44:57
>>565
for内にswitchでcase型:みたいな感じになるワケね
なるほど、言われてみれば単純な答えだった
しかし頭がOOPLなのでその単純な答えが出てこなかった

下段はむしろ書く前に思いついたんだけど
それじゃ、まんまOOPだから非OOP的には無いんだよなぁ…と思って

573 :デフォルトの名無しさん:2010/04/02(金) 03:51:16
>>572
>非OOP的には無いんだよなぁ
いやCでも普通にありな手法じゃない?lisp系だったらクロージャでほいほいだし

574 :デフォルトの名無しさん:2010/04/02(金) 04:54:11
まあCは関数ポインタ使えば、構造体がメソッドも含むオブジェクトに早変わりするからなw
そんな手法は大昔から使われてるし、そういう真似ができるからObjective-CはCで書かれてるわけで。

575 :デフォルトの名無しさん:2010/04/02(金) 05:03:48
>>572
言われてみればじゃねぇだろ
馬鹿だから知らなかったんだろw

576 :デフォルトの名無しさん:2010/04/02(金) 07:50:01
>>555
> 仮想メモリはハードウェアとマッチしてるだろ?何言ってんだ?

Amazon EC2が、どういう方法でサービスをホストしてるか知ったら発狂しそうだな。

> > 自律分散協調
> で、でたー。まさに人権屋的発想。こういうやつらこそOOPを駄目にしているのだろうな。
> いちおう教えといてあげるけど、お前、多分いわゆる中2病状態だよ。
> あとでわかるよ。

えー、実用技術としてGoogleのバックエンドでバリバリ動いてて、最近超注目されてるのに。
興味があるなら、BigTableとかMapReduceとかで検索してみるといい。
それに、何が人権なのかよく分からんが、むしろ単細胞生物のメタファの方が適切じゃね。

577 :デフォルトの名無しさん:2010/04/02(金) 08:05:22
>>569
まー、そういうのもあるかもしれないがねぇ。
今や、別にそんなに肩肘張るような新味のあるものでもないとも思うけど。

>>574
非オブジェクト指向「言語」でも、オブジェクト指向「言語」と同等の表現はできるって奴だね。
まぁ、OOPL処理系を作る以外で本当にやる奴ぁいないと思うけどさ。

ただ、本当は、「言語」の話と、「指向」の話と、「分析」の話は分けたほうが良いのだろう。
でないと、特定の言語(「C言語」とか)に対する好き嫌いの話と混ざる。
言語は、彼流に言うところの、プログラマにうまい「ウソ」を見せるインタフェースにあたるところだから、
どうしても混同されやすいところがあるのは仕方ないけど。

578 :デフォルトの名無しさん:2010/04/02(金) 08:21:39
ああそうだ。

>>548
> それじゃあれですかね、数学の数字の「1」もウソの産物なんですかね。

イエス。正確には、その「ウソ」は公理系と呼ぶがね。
(「なぜ0で割ってはいけないのか?」という動画が面白いので、一度見てみるといい)
ついでに言えば、文字の'1'も、ASCIIコードなら0x31に割り当てられたものでしかない。

電圧の高低にどういう意味を割り当てるか、というのは使う側の価値観に依存するんだよ。
こんなのは、中二病でもなんでもなくて基礎教養だ。

579 :デフォルトの名無しさん:2010/04/02(金) 09:10:28
嘘でも本当でも、世の中プラグマティストが
多いんだよねー


580 :デフォルトの名無しさん:2010/04/02(金) 09:31:56
>>560

各オブジェクトに対応した大量のif文を含むグローバルな関数ToString()を用意して、

foreach(Object o in objects){
 names += ToString(o);
}

とかやることになるだろう。ToString()の実装が悩ましくなりそうだ。

581 :デフォルトの名無しさん:2010/04/02(金) 09:37:38
>>565
> 構造体にタグ入れといてclass1_toString(),class2_toString()・・にswitchって感じ

メソッドの数だけswitchが発生し、
新たなtoStringを必要とする新たなクラス(?)が発生したら、
対応するswitchに追記をしなければいけなくなる。

一方、ポリモーフィズムを用いれば、
新クラスをいくら作成しても、
toString呼び出し部分の既存のコードに変更はない。

> 関数ポインタ使う仕組みとかでもいける

俺なら素直に、OOPLを使う。

>>552
> 柔軟性は損なわれるがな。

柔軟な方がボクは好きです。
カプセル化も、OOPLのもので不自由したことなどありません。

582 :デフォルトの名無しさん:2010/04/02(金) 09:40:08
>>581
>メソッドの数だけswitchが発生し、
>新たなtoStringを必要とする新たなクラス(?)が発生したら、
>対応するswitchに追記をしなければいけなくなる。
これはデメリットなの?
追加されたら追加されたとわかる記述はどこかにほしいんだけど

583 :デフォルトの名無しさん:2010/04/02(金) 09:42:27
構造体に同じ型もたせて呼び出すだけと違うんか?

584 :デフォルトの名無しさん:2010/04/02(金) 09:48:09
少なくとも、俺なら変更箇所が散らばるのは嫌だよ。
toStringだけじゃなくても、よく使うメソッドは沢山あって、
rubyで言うと、to_i, to_f, to_a, inspect, hashといろいろあるとする。
>>580が言ってるように頑張ったとすると、各グローバル変数、
ToI, ToF, ToA, Inspect, Hashの内部のスイッチに、
新たな構造体について追記をしなきゃいけなくなるのでは?

> 追加されたら追加されたとわかる記述はどこかにほしいんだけど

あなたが何を欲しがるかにまで、ケチをつけるつもりはないよ。

585 :デフォルトの名無しさん:2010/04/02(金) 09:49:41
>>586訂正:
×各グローバル変数
○各グローバルな関数

586 :デフォルトの名無しさん:2010/04/02(金) 09:50:31
いかん、脳が弱っとるw >>585のリンク先は>>584…。

587 :デフォルトの名無しさん:2010/04/02(金) 09:52:58
>>584
変更箇所が散らばるのが嫌?
俺はしかるべきところにしかるべき処理があったほうがいいと思うんだけど
WindowsのプログラムならOnXXXXのところにその処理があったほうがよくねーか?
したらたとえ処理対象が同一のものでもメッセージを処理する場所で当然バラバラになると思うんだけど
これを強引にまとめちゃうこともできるっちゃできるけど
知らない人がみたら混乱するだけでなんにもメリットないんじゃないの?

588 :デフォルトの名無しさん:2010/04/02(金) 09:56:55
>>584
それとさっきっから勘違いしてるみたいだけど
この話題はオブジェクト指向言語にたまたまついている
オブジェクト指向とはあまり関係がない機能の一部の話であって
オブジェクト指向とはあまり関係がないんだけど
こんなところさぐってオブジェクト指向わかった気になるのって間違ってると思うんだけどどうよ?

589 :デフォルトの名無しさん:2010/04/02(金) 09:58:58
>>582
どうとるかは人によると思うけど
まともに動いているメソッドに、直接触れなくてもいいのは安心できる。
switchくらいなら、まぁ…いいんだろうけど。複雑な処理の追記や、ロ
ジックの変更は、問題が波及する。

なので、クラスへ個別に記述した方が安心。
クラス増加 = メソッド増加と考えることもできる。
追加されたかどうかの確認なら、運用で対処とか、grepとか、IDEの機能
で補完できる気もする。


590 :デフォルトの名無しさん:2010/04/02(金) 10:00:06
へ?この話題はれっきとしたポリモフィズムの話だよな?

591 :デフォルトの名無しさん:2010/04/02(金) 10:03:50
>>589
>まともに動いているメソッドに、直接触れなくてもいいのは安心できる。
実際は挙動が変わってるんだからそれはただのまやかしだろう

>>590
じゃ、設計段階でそうなってるの?
違うでしょ?
それにこの手にことやろうと思ったら圧倒的にC言語のがやりやすいよ
超でかいメモリプール作ってそこに構造体全部いれるようにしてアドレステーブル作れば
現在使用中のメモリ量まで一括して出せる

592 :デフォルトの名無しさん:2010/04/02(金) 10:05:09
>>587
> 変更箇所が散らばるのが嫌?

これはあれだよ、
新しいtoStringの実装を必要とする新しいクラス(?)ができたときに、
>>580方式でのグローバルなToString関数の中に、
newclass_toString関数を呼ぶ記述を追記する必要がある、という意味で、
newclass_toStringだけじゃなくToStringも触らなきゃいけない、
変更箇所が一箇所じゃないという意味。

一方、ポリモーフィズムを用いれば、
上の例だとnewclass_toString関数だけ変更すればい。

> WindowsのプログラムならOnXXXXのところにその処理があったほうがよくねーか?

その処理、とは? newclass_toStringに相当する処理のこと?

593 :デフォルトの名無しさん:2010/04/02(金) 10:16:10
>>588
> こんなところさぐってオブジェクト指向わかった気になるのって間違ってると思うんだけどどうよ?

朝からずいぶんな言い草だなw
オブジェクト指向分かった気になんかなってないし、
オブジェクト指向が何なのかにさえあまり興味は無い。

今はカプセル化とかポリモーフィズムとか、
そういう個別の恩恵についてコメントしてるだけ。
オブジェクト指向がどうの、という結論は求めてない。

594 :デフォルトの名無しさん:2010/04/02(金) 10:35:27
>>591
まやかしか…確かに。

だが、前提として責任が明確に分かれているのは、利点ではないか?

595 :デフォルトの名無しさん:2010/04/02(金) 10:39:36
>>594
は?見た目が変わってないのに挙動が変わってる状態のどの辺が明確なの?

596 :デフォルトの名無しさん:2010/04/02(金) 10:45:52
見た目って、どこの見た目?

597 :デフォルトの名無しさん:2010/04/02(金) 10:49:23
>>596
ポリモった部分
ちなみに言っておくけど俺の立場はC++反対派な

598 :デフォルトの名無しさん:2010/04/02(金) 10:50:58
C++っつーかオブジェクト指向反対派だな
特にポリモなんて完全に後付けでしかもこれ入れた奴ってオブジェクト指向理解できてないだろ
そういうわけわからん経過も含めてこの機能は嫌いだな

599 :デフォルトの名無しさん:2010/04/02(金) 10:54:30
Cの構造体でできることは、インスタンス変数とクラスメソッド(staticメソッド)の組み合わせでしょ?
インスタンス変数とインスタンスメソッドの組み合わせはどうやって作んの?

600 :デフォルトの名無しさん:2010/04/02(金) 10:55:46
前に上がってる例でいけば
switch文に、増加した分岐処理が記述されている事。
また、増加した処理関数が別名で追記される事。

が、明確だ。という意味かな。

601 :デフォルトの名無しさん:2010/04/02(金) 11:00:51
>>598
確かに

オブジェクト指向って、具体的なオブジェクトだけでなくて
人それぞれで考えが異なるような抽象化されたオブジェクトも含んでる
ポリモーフィズムはそう言った分かりにくさを助長してるかもしれん
それなのに、型名による動的な分岐は簡単に出来ない

でも俺はC++好きだけどね

602 :デフォルトの名無しさん:2010/04/02(金) 11:04:03
ポリモーフィズムが嫌いなら、関数ポインタでループさせるのも嫌いなんだよな

603 :デフォルトの名無しさん:2010/04/02(金) 11:11:13
>>591
簡易的なメモリ管理クラスを継承したクラスを使用すれば
固まったプール作らなくても実現できる
管理方法の切り替えも楽にできる

もちろんオブジェクト指向じゃなくても可能
ただ切り替えが分かりやすいってだけだがね

604 :デフォルトの名無しさん:2010/04/02(金) 11:12:34
カプセル化やポリモーフィズムは好きだが、
C++は好きじゃない。C#も好きじゃない。それらに比べりゃCが好き。
ただCでOOPLの真似事をしようと思うくらいなら、素直にC++を使う。

605 :デフォルトの名無しさん:2010/04/02(金) 11:13:43
>>601

「型名による動的な分岐は簡単に出来ない」かどうかは、継承元となっているクラスの
設計次第だろう。オブジェクト指向そのものの問題ではない。

object.GetType().Nameみたいなので型名が取得できれば、分岐は簡単だ。

606 :デフォルトの名無しさん:2010/04/02(金) 11:15:09
C++のtemplateはどうよ
ポリシークラスこそオブジェクト指向

607 :デフォルトの名無しさん:2010/04/02(金) 11:18:13
>>605
可能かどうかの話だったら可能だよ
言語仕様の話かもしれないが、リソースとして名前を持つんじゃなくて
型名で分岐させる方法があるべきだと思ってる

608 :デフォルトの名無しさん:2010/04/02(金) 11:18:54
ポリモー(ryこそがOOPの肝じゃなかったのか

609 :デフォルトの名無しさん:2010/04/02(金) 11:25:31
>>599
非OOPerどもは、そもそもクラスメソッドとインスタンスメソッドの区別がつかないし、
インスタンスメソッドを使う理由もわからない。
変数と関数ポインタのまとまりをオブジェクトと勘違いしてやがる。

610 :デフォルトの名無しさん:2010/04/02(金) 11:25:41
>>606
俺(>>581,584,592,593,604)ね、それ大嫌い。
あんなもんで静的にポコポコ複製させて、
肝心のOOP機能については消極的でさ。virtualつけろとかなんとかw
Javaみたいに基本virtualで例外finalにしてほしかった。ケチくさいんよw
ハゲ(すとらうすとらっぷ)は自分の本のなかでテンプレートをひたすら自賛してたけど。

611 :デフォルトの名無しさん:2010/04/02(金) 11:47:05
>>610
静的な「構造」のみを提供するのがtemplateだからね
複製は仕方ねえよw

部品と構造(設計)、具体的なオブジェクトを分けて考えるならtemplateは強力
言われてる通りまだまだ発展途上だけどね
これが使いこなせてこそオブジェクト指向が語れると思う

612 :デフォルトの名無しさん:2010/04/02(金) 11:49:24
>>608
俺はそう思わない
あくまでも副産物的なもの
ポリシークラスによる部品と、構造を提供するtemplate
クラスのカプセル化こそが本質

613 :デフォルトの名無しさん:2010/04/02(金) 11:55:54
そんな難しい話はわかりませんが、同じ引数の同名関数を大量に生産するのはやめてくださいw

614 :デフォルトの名無しさん:2010/04/02(金) 11:56:28
>>609

ああ、俺にもクラスメソッドとインスタンスメソッドの区別 ― というか、その区別の存在意義 ― は
良くわからない。

「インスタンスメソッド」とはいっても、そいつはクラス設計で定義されているんだから、
「インスタンスメソッド」を、インスタンスごとにオーバーライドできなければ、それは、結局、クラスの
メソッドなのだ。

真にあるインスタンス固有のメソッドがある言語は、Io言語みたいなやつ。というか、この言語では、
クラスとインスタンスの区別がない。

615 :デフォルトの名無しさん:2010/04/02(金) 11:58:26
>>613
コンパイル後だから別にいいじゃん
exeファイルのサイズが制限されてるんならわかるが

616 :デフォルトの名無しさん:2010/04/02(金) 12:00:05
>>614
ポリモーがあるから分けてるだけじゃね?
便利だけど俺もあんまし好きじゃない

617 :デフォルトの名無しさん:2010/04/02(金) 12:47:55
interfaceに対してプログラミングせよ、ってまだメジャーじゃないんだな。
多態性のメリットって結局そこだと思うんだが。

618 :デフォルトの名無しさん:2010/04/02(金) 12:53:32
>>611
テンプレートなんてはじめC++に入ってなかっただろ
完全に後付けかつオブジェクト指向と関係無い
お前、なんか違う方向行ってるぜw
ちなみに継承も後付け

後付け機能はホント使えないのばっかだな

619 :デフォルトの名無しさん:2010/04/02(金) 13:15:10
てかクラスメソッドとインスタンスメソッドなんて全く別モンじゃねえかw
クラスメソッドなんて非OOPと変わらんw

620 :デフォルトの名無しさん:2010/04/02(金) 13:37:22
>>618
後付けだから関係ないとかわけわからんこと言うなよ
よりオブジェクト指向の方向に進化してる

template使ったことないだろお前

621 :デフォルトの名無しさん:2010/04/02(金) 15:04:39
>>620
バーカ、無くてもオブジェクト指向言語って主張してた時期があるのに
明らかにいらねーだろそんな機能
だいたい言語の機能一つとって設計と関係ない内容重視してんじゃねーよ低脳
だからお前みたいなのは役に立たないっていうんだよ

622 :デフォルトの名無しさん:2010/04/02(金) 15:13:42
エージェント指向はどうなった?

というか、これからはCPUのマルチプロセッサ化が急速に進むだろう
から並列処理を簡単にできる言語、しかもオブジェクト指向と矛盾
しない言語が望まれるのでは?

623 :デフォルトの名無しさん:2010/04/02(金) 15:14:42
>>621
わからないなら無理にレス返さなくていいよ

624 :デフォルトの名無しさん:2010/04/02(金) 15:24:49
>>622
コンパイラの最適化では使われそうだけど、どうなんだろうな
ユーザに指定できたとしてもCPU命令を直接扱うのって面倒だしね

625 :デフォルトの名無しさん:2010/04/02(金) 15:35:18
>>623
アレアレ?もしかして得意になってテンプレート勉強したんだけど
実はまったくオブジェクト指向と関係なかったってオチついちゃって意気消沈?ニヤニヤw

626 :デフォルトの名無しさん:2010/04/02(金) 15:36:33
>>625
>>620
わからないなら無理にレスしなくていいって

627 :デフォルトの名無しさん:2010/04/02(金) 15:51:54
>>626
アレアレ?
ageちゃうの?
もしかして図星?ニヤニヤw
全然関係ないことに時間費やしちゃった?w
ざーんねんwテンプレートをどんなに一生懸命勉強してもオブジェクト指向理解できないからw

628 :デフォルトの名無しさん:2010/04/02(金) 15:54:34
templateってあくまでC++の特徴的な機能であってOOPとは無関係だろ

629 :デフォルトの名無しさん:2010/04/02(金) 15:57:43
>>628
はぁ?特徴なんて表してねーだろ
寝ぼけんなよw
オブジェクト指向を全く理解してないアフォの入れたオナニーだ

630 :デフォルトの名無しさん:2010/04/02(金) 16:00:13
だって別にtemplateってオブジェクト指向関係なしに使えるよねえ

631 :デフォルトの名無しさん:2010/04/02(金) 16:03:40
>>628
メソッドのポリシークラス化によって型にとらわれない部品を作成できる
そのポリシークラスを利用する構造をまたtemplateによって記述できる
使う側はすでに用意された構造のみを利用して新しいオブジェクトを作成できる
だから、具体的に記述箇所がほとんどなくなる

新しいプロジェクトごとに細かいメソッドを用意することがない
プラモデル作るような感じで、部品を取り寄せるだけでよくなる

632 :デフォルトの名無しさん:2010/04/02(金) 16:13:15
それって、フレームワークや組み込み関数と
同じレベルで使ってるってこと?

業務に特化した基礎クラス作ればいいとは思うが…

633 :デフォルトの名無しさん:2010/04/02(金) 16:18:21
>>632
同じレベルというか、型レベルで最初からアダプタになってる
同じレベルで扱うこともできるし、自ら作成した特化したポリシーを使ってもいい

業務に特化したクラスを一度作ったとしても
次のプロジェクトでそのまま流用できるほど汎用的に作ってあっても
無理な仕様変更には対応できない
やっぱり新しいクラスを作らなければならない

これは、プログラミングするということ自体が動的動作を目的にしてるから
コンパイル時点で切り替えるということをtemplateは実現できる

634 :デフォルトの名無しさん:2010/04/02(金) 16:21:26
>コンパイル時点で切り替えるということをtemplateは実現できる
コンパイル時点で切り替えるということはできない
templateはそれを実現できる

です

635 :デフォルトの名無しさん:2010/04/02(金) 16:45:36
何でもできるみたいな言い方になってるけど、事実なんでもできる
プログラミングが継承とコンポジションの構造、テンプレート指定子だけで終わる

636 :デフォルトの名無しさん:2010/04/02(金) 17:53:36
質問、JavaやC#のジェネリクスとはどう違うの?

637 :デフォルトの名無しさん:2010/04/02(金) 18:04:36
とは言え動的に切り替えたいことだってありますから

638 :デフォルトの名無しさん:2010/04/02(金) 18:04:50
>>624
クロックが頭打ちとなった今、並列処理にマッチしたパラダイムが必要なのでしょうね。
そういうものとして今までに候補にあがったものはどのようなものでしょうか?

639 :デフォルトの名無しさん:2010/04/03(土) 00:26:53
>>622
> 並列処理を簡単にできる言語、しかもオブジェクト指向と矛盾しない
すくなくとも、オブジェクト指向なんかいらん!
オブジェクト、オブジェクト言う奴に限って並列化のこととか、どこ吹く風だしな


640 :デフォルトの名無しさん:2010/04/03(土) 00:40:49
>>639
っ【Scala】

641 :デフォルトの名無しさん:2010/04/03(土) 00:45:07
>>638
すまん、あまり詳しくないんだ
GPGPUもまだわからない状況だし、マルチコアCPUの命令仕様も扱ったことない

ただ言えることは、
まだif分岐が起こるとそこで先読みが打ち止めになる
最適化で分岐を減らしたり、本当に単純な分岐を別のCPU命令に置き換えると爆速になるのは今も変わらない
CISK RISKレベルのシフトが起こるかもしれないけど、まだまだ先の話

642 :デフォルトの名無しさん:2010/04/03(土) 01:56:54
並列化は制御に対して行われるものだから、
オブジェクト中心で考えるオブジェクト指向とは相性が悪いよ。
制御構造をないがしろにしてきた罰だな。
オブジェクトの振る舞いを記述することで、プログラムを表現しようという発想が、
本当に正しかったのかどうか今一度見直しましょう。
そもそも、プログラムって何でしたっけ?
「運動会のプログラム」のプログラムってどういう意味?
プログラムの本質は何?
プログラムの提供する機能は、何によってもたらされる?
何を中心に考えるべき?
何を「指向」すべき?
本当に大切なものが、ないがしろにされて無い?
わかりやすい「物」よりも、
見えにくい「何か」が大切だったりするものなんじゃないの?

643 :デフォルトの名無しさん:2010/04/03(土) 02:08:08
並列化と言ったら関数型だな

644 :デフォルトの名無しさん:2010/04/03(土) 02:15:15
関数、いい言葉だ。
関数は英語でfunctionと書くが、機能もfunctionと訳される。
これはとても重要な事。

645 :デフォルトの名無しさん:2010/04/03(土) 02:38:23
>>642
知ったかぶりもここまで来ると感動的だな。

>>644
オブジェクト指向と違って、君の大好きな手続き型の対極に位置する概念なんだがな。。

646 :デフォルトの名無しさん:2010/04/03(土) 12:13:11
人間の使いやすさと、機能性、性能とか
ぜんぶ手に入るものなの?

処理系やコンパイラが頭よけりゃいいのかな

647 :デフォルトの名無しさん:2010/04/03(土) 14:05:59
>>646
> 人間の使いやすさと、機能性、性能とか
それを 「どこに向かって言ってるか?」 だな


648 :デフォルトの名無しさん:2010/04/05(月) 01:59:37
写像としての関数なんて、数学と文字列処理で、
演算子と一緒の場合に使う時くらい。
他にはほとんど使えない。
何かに使えないかという工夫なのか、
エラー発生を通知するboolを返す関数が常態化しているが、
try出現で古典的手法になったじゃん。

関数なんてほとんど形骸化しているんだよ。
実際、戻り値なんてほとんどの場合いらないんだよね。
void関数が大活躍なのに、return必須とか鬱陶しいくらい。

OOPで、methodという名前に変更されたのもうなずける。
methodは、functionというよりBASICの命令文なんだよ。
object.method()というのは、
「objectさんは、methodして」という命令文。

649 :デフォルトの名無しさん:2010/04/05(月) 08:42:07
>>648
on error goto

650 :デフォルトの名無しさん:2010/04/05(月) 18:36:38
例外なんぞ劣化したgoto

651 :デフォルトの名無しさん:2010/04/05(月) 19:27:13
危険性を取り除いたgotoと言い給え

652 :デフォルトの名無しさん:2010/04/05(月) 20:04:29
いずれにせよ所詮 goto

653 :デフォルトの名無しさん:2010/04/05(月) 20:36:58
GO★TO

654 :デフォルトの名無しさん:2010/04/05(月) 22:44:12
関数という超エレガントな発想を否定してしまうとは。
OOP脳は怖いね。

> object.method()というのは、
> 「objectさんは、methodして」という命令文。

object1 さんと object2 さんに method してほしい場合はどうするんですかね。
method( object1, object2 )とは書けないですよね。
object1.method( object2 ) と書きますか?それとも、
object2.method( object1 ) と書きますか?
こんな簡単なことにすら頭を悩ます必要がある、それがOOP。

655 :デフォルトの名無しさん:2010/04/05(月) 22:52:03
http://ja.wikipedia.org/wiki/サブルーチン
> 関数 (function) が返す値は戻り値(もどりち)または返り値(かえりち)と呼ばれる。function が関数と
> 訳されるのは、単に機能の実装を行うだけでなく、引数としてとりうる値の集合から、戻り値としてとりうる
> 値の集合への写像のように捉えることができるためである。したがって、ほとんどの命令型プログラミング
> 言語では次の点において数学の関数とは異なる。
>
> * 引数が同じでも状況に応じて戻り値が異なる(状態を持つ)
> * 関数の処理の実行によってシステムに変化が発生する(副作用を持つ)
> * 戻り値が存在しない場合がある
>
> ただし、純粋な関数型言語における関数は、状態や副作用などをもたず、数学の関数に近い性質を持つ。

656 :デフォルトの名無しさん:2010/04/05(月) 22:53:38
> object.method()というのは、
> 「objectさんは、methodして」という命令文。

あー気持ち悪い。日本語的には
「objectをmethodしてください」、でいいだろ。
それが英語風だとmethod( object )になるってだけで。
なんだよ、objectさんって。
オブジェクトには処理手順がくっついてるってだけで、
実際に処理を実行するのはCPUなりスレッドなりだろ。
すくなくとも、オブジェクトが実行するわけじゃねーだろ。

657 :デフォルトの名無しさん:2010/04/05(月) 22:59:53
>>654
object1とobject2が相互に入れ替え可能な処理ならその通りだけど、
それはmethod(object1, object2)でも同じことだよね。

入れ替え可能でないなら、どちらを先に書くか悩まなければいけないのは
どちらの記法でも同じだし、むしろ非対称なobject1.method(object2)の方が
意味が確定しやすいとすら言える。

658 :デフォルトの名無しさん:2010/04/05(月) 23:07:33
>>656
「methodの処理を実行する。それはobjectの責務である」って考えてみたらどうか。

659 :デフォルトの名無しさん:2010/04/05(月) 23:21:01
あーまた何か言い出した。
どちらを先に書くか悩む?なにいってんだ。
そんなもんは好きにすればよい。
関数作るやつが勝手にきめりゃいいんだよ。
単に処理の対象としてobj1とobj2を指定するってだけなんだからな。
OOPの場合、まずもって、いずれかのオブジェクトに処理をぶら下げるのが美徳なわけだが、
その処理が複数のオブジェクト間に作用するものである場合、
どのオブジェクトにぶら下げるのか迷うし、どこにぶら下げても「汚い」。

すべての処理が、必ずなんらかのオブジェクトに関連づくとは限らない。
これは、制御構造とデータ構造が本質的に別物だから。
なのに、処理をオブジェクトに紐付けるのは愚行だ。

データは単体では何もできない。複数のデータが相互作用しあって初めて機能が提供される。
その、データとデータをコミュニケートさせるのが「制御」。
制御はデータとデータの間を取り持ち、機能を提供する。
つまり、制御はデータとデータの「間」にあるもの。
それをデータにぶら下げるなんて、アホだね。

660 :デフォルトの名無しさん:2010/04/05(月) 23:26:17
>>658
なんで処理の実行が、「処理の対象物」の責務になるんだよ。
rm file もしくは file . rm 。
これ、削除処理はファイルの責務か?
しかもなんでそこまで複雑に考えなきゃならん。
普通に、
 命令 対象物1 対象物2 対象物3
の並びでいいだろ。超シンプル、超わかりやすい。

661 :デフォルトの名無しさん:2010/04/05(月) 23:33:22
object.method() を後付けで超飛躍的解釈を施すこと自体が不思議なんですが。
普通に method のかくれた第一引数が object のポインタ、として今までこまったことがないのですが、それは単に私が c++ から入ってしまったせいかなあ?

662 :デフォルトの名無しさん:2010/04/05(月) 23:36:24
> すべての処理が、必ずなんらかのオブジェクトに関連づくとは限らない。
そりゃそうだ。

> これは、制御構造とデータ構造が本質的に別物だから。
そもそも何を「本質的」と言ってるのか説明が欲しいところだけど、それはともかくとして、
もしかして「データ=主体」とか思ってるのかな。

それぞれが責務を持ち、外部に役務(サービス)を提供するのがオブジェクトだとすれば、
外部に対してそう見えていれば良いのであって、別に「データ=主体」である必要はない。
そうであってもいいけどさ。

とりあえず、オブジェクト指向をちゃんと理解してから批判しようや。
君のやってるのはただの藁人形叩き。

663 :デフォルトの名無しさん:2010/04/05(月) 23:43:31
>>660
ファイルシステムはどこ行ったの?


あと、「分かりやすい」という言葉を安易に連発するのはやめないか。
せめて「命令型パラダイムと親和性が高い」とかにしとこうぜ。
純粋関数型や制約プログラミングだってあるわけだし。

664 :デフォルトの名無しさん:2010/04/05(月) 23:46:35
>もしかして「データ=主体」とか思ってるのかな。

なんじゃこれ、なにいってるのかわかんね。
プログラムの主体は機能で、
機能は制御によってもたらされるから、
プログラムの主体は制御だ。
データなんてものは、なが〜い目で見れば一時変数に過ぎん。

665 :デフォルトの名無しさん:2010/04/05(月) 23:47:04
専門用語使ってりゃあ自分は気持ちいいかもしれないけど他人に対する説得力は欠けるぞw

666 :デフォルトの名無しさん:2010/04/05(月) 23:50:49
>ファイルシステムはどこ行ったの?

ファイルシステムは対象物として指定しているか、
グローバル変数として渡るかのどっちかだ。
どちらにしても、何らかの手法で 命令rm はファイルシステムを知り、
対象のファイルを削除する。当たり前のことだろ。

667 :デフォルトの名無しさん:2010/04/05(月) 23:57:11
>>664
なら、個々に状態を持った機能=オブジェクトでいいじゃない。
「責務と役務」というのは、それを外部にどう見せるかという話。

>>666
なら、「ファイルの削除を実行する。それはファイルシステムの責務である。」という
分析も成り立つよね。
ていうか、ファイルシステムなんて「役務(サービス)を提供する責務を持つ機能」そのものだし。

668 :デフォルトの名無しさん:2010/04/06(火) 00:12:19
>>667
前半:
クラスがデータを持たない、ただのインターフェイスだってんなら、いいとおもうよ。
要はただの関数のテーブルを外部に公開しているだけっていう。
でもどうせ、内部的なindexやハンドルなんか持っちゃうんだろ。なら却下だ。

後半:
話し合ってる「層」がずれてる。
ファイルをどう削除するかの責任を持つのは rmコマンド だ。
rmコマンドはいくつかのオプション引数をとるかもしれないだろ?
それらのrmコマンドが提供する「機能」についての責任の話をしてなんじゃないのか?
rmコマンドが責任を持つほか仕方ないだろ。

669 :デフォルトの名無しさん:2010/04/06(火) 00:50:43
まーいろいろいいたいことはあるが、
まず、処理そのものが状態を持つべきではないんだ。
引数で指定すべし。そんなに手間か?

それから、ここからが本番なんだが、
責務やら役務やら役割やらサービスやら、変な言葉使いやがってよー。
そんなに色々な言葉使ってまで「それっぽく」して煙に巻きたいかよ。
一言「機能」でいいだろ。複雑な言い回ししたって現実は何にもかわんねーんだよ。
「それっぽく」聞こえる、ただそれだけ。

670 :デフォルトの名無しさん:2010/04/06(火) 01:27:42
お前らこんなスレにいるぐらいだから、
ぶっちゃけ本当はOOPに嫌気がさしてるんだろ?
マジでマジで。

671 :デフォルトの名無しさん:2010/04/06(火) 01:46:00
プログラム書くために、思考の形態を、そのまま記述できる手法は良いと思う。

自分の場合は、いかにフローに落とすか、ってイメージが強いなぁ。
木構造でしか考えられないな…。


672 :デフォルトの名無しさん:2010/04/06(火) 08:02:48
>>668
> でもどうせ、内部的なindexやハンドルなんか持っちゃうんだろ。なら却下だ。

え? なんで? 世の中、自分の「状態」を持たないサービスの方がむしろ少数派だよ?
例えばだけど、ファイルシステムとかGoogleとか2chを、役務(サービス)を提供する
オブジェクトと考えてみたらどうよ。

> ファイルをどう削除するかの責任を持つのは rmコマンド だ。
> rmコマンドはいくつかのオプション引数をとるかもしれないだろ?
> それらのrmコマンドが提供する「機能」についての責任の話をしてなんじゃないのか?

っ【Commandパターン】

「コマンド」だって、自分の役務(サービス)を提供するオブジェクトの一つと看做すことも
できるわけでね。それと同様に、Fileオブジェクト(≠ファイル)とかファイルシステムを、
固有の責務を持ったオブジェクトと看做す、という分析も同じくらいアリだというだけの話。

673 :デフォルトの名無しさん:2010/04/06(火) 08:20:01
>>669
> まず、処理そのものが状態を持つべきではないんだ。

そうだよ。状態を持つのは「オブジェクト」だ。
とりあえず、そのオブジェクトがどう実装されているか、という部分はブラックボックスとして
考えてみるのが良いと思うよ。んで、Javaでいうinterfaceだけでコーディングする世界を考える。
(オブジェクトはマイクロコンピュータである、ってのはアラン・ケイの台詞だったか?)

> 引数で指定すべし。そんなに手間か?

小規模なコードなら、君の言うとおり、あまりご利益はないかもね。
状態が複雑に絡み合った大規模なコードでこそメリットがある考え方、というのは前提。

> 責務やら役務やら役割やらサービスやら、変な言葉使いやがってよー。

一般的な用語だと思うけどなぁ。
一つ言えるのは、「機能」をどういう形でどの責任範囲で外部に提供するか、
という側面を強調している点で一貫してるよね。

674 :デフォルトの名無しさん:2010/04/06(火) 11:33:32
>>642

意味不明だ。オブジェクト指向は制御を阻害しないぞ。多数のスレッドを扱うならば、むしろ
クラスのインスタンスで非同期メソッドを呼び、個別結果をインスタンス変数に格納し、全体状況を
スタティック変数に放り込むほうが楽だろう。

>>643

並列化までは、オブジェクト指向だろうが関数型だろうが、あまり変わららないかもしれない。
超並列化時代に突入するまでは、関数型が主役になりそうにはない。

675 :デフォルトの名無しさん:2010/04/06(火) 20:10:08
長文ご苦労としか。OOP脳では所詮この程度か。
知ってて当たり前のことしか書かれてない。あー言えばこう言うの世界。
それでも、OOPが優勢になることはないんだよ。
これはもう時代の流れで決まってること。
共産主義と同じですたれるのだ。
なぜそんなことがいえるか、この辺の感覚的な部分は、
なかなかわかってもらえないようだけど、
なるべく簡潔に説明すると、
プログラムの機能は、
「制御でデータの関係を定義する」
ことで成り立つから。
オブジェクトに制御をぶら下げた時点で、構造的におわっとる。

676 :デフォルトの名無しさん:2010/04/06(火) 20:12:53
変な言語を使い、変な思考で構築しているうちに、
変な頭になっちゃうのさ。あーおそろしー。
右も左もわからないやつが使うのがOOP。

677 :デフォルトの名無しさん:2010/04/06(火) 20:14:14
開発環境のベンダーなんかは、わざとやってるのかもしれないがな。
檻に閉じ込めておくために。洗脳おそろしや。

678 :デフォルトの名無しさん:2010/04/06(火) 20:27:39
>>654
OOPをサポートする言語のほとんどにはstatic関数があります。


679 :デフォルトの名無しさん:2010/04/06(火) 20:29:17
なぜ、static関数のような非OOP的機能が用意されたかを考えなさい。

680 :デフォルトの名無しさん:2010/04/06(火) 20:29:51
大体struct使う奴にOOPうんたらとか言われると微妙に気分が悪い。

681 :デフォルトの名無しさん:2010/04/06(火) 20:42:44
C++最強説浮上

682 :デフォルトの名無しさん:2010/04/06(火) 20:54:02
>>675
> プログラムの機能は、「制御でデータの関係を定義する」ことで成り立つから。

だから、それは数ある分析手法の一つでしかないと何度(ry
大雑把に言えば、「ユーザがどんなサービスを受けたいか」とか、
「写像と制約によって何を定義したいか」とかでコード化する対象を分析し、
コードを記述する手法が数多くある。
命令型パラダイムはそのうちの一つに過ぎない、それだけのことだ。

んで、要求が複雑になり変化が早くなったことで、「どんなサービスを受けたいか」で
定義する手法の需要が上がっているのが現在。
はっきり言えば、君のそれは、手続きベースでプログラムを書く人間の都合を押し付けてるだけなんだよ、
そんなもんは「本質」でもなんでもない。

683 :デフォルトの名無しさん:2010/04/06(火) 22:16:27
車1.ワイパー()

は納得いくが、

車1.洗車()

は確かに気持ち悪い。
洗車機能は、洗車機にあるのであって、車にあるわけではない。
そいういうときはstaticで

洗車機::洗車(車1)

とすれば無問題なのかもしれない。

だが、多数の自動車インスタンスを一括して洗車()したい場合、どうするか?
という問題がある。
もちろん、いろいろなタイプの自動車が入り混じっているし、
続々と新車が発表されている。
で、解決に、

foreach (車配列){ ((洗車可能)車).洗車(); }

のような一括処理のために、やっぱり、車クラスに洗車メソッドを付けてしまう。
一見エレガントでも、こういうのは気持ち悪いと言われればそうかもしれない。
でもこれはOOPの問題というより、クラス設計の問題だが・・・

684 :デフォルトの名無しさん:2010/04/06(火) 22:19:16
ああ言えばこう言う。
>「どんなサービスを受けたいか」
言い回しがすでにきめぇ。何で変に受身なんだよ。
普通に、
「必要な機能は何か」
でいいだろ。そういうところが頭おかしいっていってんだよ、受身野郎がよ。

685 :デフォルトの名無しさん:2010/04/06(火) 22:28:14
車に基づいて洗車の処理が決定するようだけど、
他の要因でも洗車の処理が変わりうる場合はどうするんだ?

686 :デフォルトの名無しさん:2010/04/06(火) 22:28:53
俺はずっと手続き型で来た人間だけど。

>>684
UPの開始工程が要求分析だからじゃないの?
客先がプログラム知らんから頭悪そうな言い方になる。

687 :デフォルトの名無しさん:2010/04/06(火) 22:33:34
普段から自分たちを奴隷に見立ててるから、
「オブジェクト様が〜なさる」、みたいな発想になるんだよ。
プログラムは指示書なんだから、
「これとこれとこれ、あれしといて」
でいいんだよ。

688 :デフォルトの名無しさん:2010/04/06(火) 23:20:06
>>683
車≠Carオブジェクト。
責務を適切に分割できるほうを選ぶよろし。

>>685
1. 車からその要因を参照するなり処理を委譲するなりする
2. 洗車機を導入する

どちらが最適かは、もちろん状況による。

689 :デフォルトの名無しさん:2010/04/06(火) 23:27:23
>>684
1. プログラムは、ユーザ(自分含む)が利用「する」ためのもの。プログラムは利用「される」もの。
2. 複数人開発において、他人の書いたコードは利用「する」ためのもの。自分の書いたコードは利用「される」もの。

受身じゃないプログラムの存在意義がどこにあるのか、逆に知りたいな。
合理的に教えてくれ。

690 :デフォルトの名無しさん:2010/04/06(火) 23:38:03
> 1. 車からその要因を参照するなり処理を委譲するなりする
結局車だけで処理を決定できないから、要因を参照して分岐したり、
たらいまわしにしたりするってんだろ。
だったら、はじめから車に洗車メソッドなんぞ付けるべきではないよな。
セッターとゲッター程度にしとけという話。

> 2. 洗車機を導入する
中でswitchするんですね、わかります。

691 :デフォルトの名無しさん:2010/04/06(火) 23:45:15
>>690
そこは視点による。

1. 「車」の外部から見た時に、「車」が提供するサービスとして一貫性があるなら、
  内部実装がたらい回しでも無問題、の場合もありうる
2. オブジェクト単体で処理を決定できる場面の方が少ない。
  オブジェクトが、他のオブジェクトのサービスを利用して処理を組み立てるのはむしろ自然。
3. 「洗車機」は巨視的視点 or 仲介者の話であって、必ずしもswitchの話ではないお

692 :デフォルトの名無しさん:2010/04/06(火) 23:49:04
合理的合理的うるっせーな。
合理的ってアホの使う言葉だぞ。知っとけ。

「する」とか「される」とか、お前の価値基準はそれしかないのか?
お前は幾何学的思考能力がねーんだよ。
だから、あっちから見るとこう見えるし、こっちから見るとこう見えるし〜
って考えがふらふらしてんだよ。
レス読み返してみろ。「それは一つの考え方にすぎない、他の解釈もある、逆の考えもある」
とかそんなばっかだろ。いちいち自分の立場を変えるな。上から見下ろせ。
見えたものがすべてだ。

 プログラムの機能は、
 「制御でデータの関係を定義する」
 ことで成り立つ。

 プログラムは指示書。

西洋的な考え方も少しは学べ。じゃないと人生損するぞ。

693 :デフォルトの名無しさん:2010/04/06(火) 23:52:38
また、「視点による」とか言ってるし。
そうやって、視点を変えて、同じところをぐるぐる回ってればいいよ。
ただ、どっから見ても、たとえ見え方が違っていたとしても、
「現実、事実、真実」が変わったわけではない、ってことは知っとけ。

694 :デフォルトの名無しさん:2010/04/06(火) 23:57:29
あと、俺からの忠告。
どうしてもOOPしたいんなら、データを持つオブジェクトのメソッドは、
セッターとゲッターだけにしとけ。
そんなのOOPじゃねーっつーんなら、もうOOPやめとけ。

695 :デフォルトの名無しさん:2010/04/06(火) 23:59:21
>>692
合理性を軽視するプログラマとか、本気で意味が分からないんだが。。


ていうか、「見えたものが全てだ」ってのは俺がずっと言ってることなんだけどね。
コードを使う側(ユーザ、他のコーダ)から見た時の一貫性を基準に分析する一手法が
オブジェクト指向、というのが俺の解釈。

696 :デフォルトの名無しさん:2010/04/07(水) 00:03:28
>>693
西洋から学べとか言ってる割には、哲学に疎そうな台詞が。。
まぁ、君と哲学論争をしたいわけではないのでやめておこう。

697 :デフォルトの名無しさん:2010/04/07(水) 00:10:25
いつ「西洋=西洋哲学」になったんだ?

合理性合理性いってるやつに限って合理性がねーんだよ。
本当の合理性を知らない。言ってる意味わからないだろ?そーだろうな。

>コードを使う側(ユーザ、他のコーダ)から見た時の一貫性を基準に分析する一手法が
>オブジェクト指向、というのが俺の解釈。

それはお前がアホだということ。
遣うか遣われるかの価値基準しか持ち合わせていないということ。
それにしがみ付いて、おかしな病気になっている、ということ。
「機能」と「役割」の区別がついていないということ。

698 :デフォルトの名無しさん:2010/04/07(水) 00:16:01
>>697
> 遣うか遣われるかの価値基準しか持ち合わせていないということ。
> 「機能」と「役割」の区別がついていないということ。

そこをもうちょっと理路立てて順番に説明しておくれ。

699 :デフォルトの名無しさん:2010/04/07(水) 00:20:09
>>687
むしろその「あれしといて」がOOPだと思うのだが。
その例えだと、非OOPは…そうだな、大手製造業の社長が
部品1つ1つの取り付け方の指示書書いてることにならないか?

700 :デフォルトの名無しさん:2010/04/07(水) 00:22:48
オブジェクト指向は、オブジェクトがメッセージをやり取りして、ってのが定義だったはずなのに、
それすら自分の解釈で勝手に捻じ曲げる。
というか、かってに捻じ曲がるのだろうな、
人より次元の少ない物差しですべて測るわけだからな。
そして、変な形で再構築されるわけか。
使い手視点からのコーディングがOOP?笑わせるな。

701 :デフォルトの名無しさん:2010/04/07(水) 00:31:18
>>698
機能は関係が主体。かつ能動的。
役割はパーツが主体。かつ受動的。

>>699
「これを、あれしといて」がOOP。
「これとこれとこれを、あれしといて」は非OOP。
OOPでかくとこんなことになる。
これ.あれ(これ, これ, これ)
どの「これ」に「あれ」を紐付けましょうかねぇ。

702 :デフォルトの名無しさん:2010/04/07(水) 00:38:51
> オブジェクト指向は、オブジェクトがメッセージをやり取りして、ってのが定義だったはずなのに、
全然ちがってるし
アランケイのオブジェクトとハゲのオブジェクトがちがってることくらい当たり前だろ


703 :デフォルトの名無しさん:2010/04/07(水) 00:46:10
>>700
> オブジェクト指向は、オブジェクトがメッセージをやり取りして、ってのが定義だったはずなのに、

人によってわりと定義が違うのは指摘の通りで確かに悩ましいけど、俺の解釈であるところの
> 使い手視点からのコーディングがOOP
ってのは、その説明を別の角度から言ってるだけだよ。
各オブジェクトが主体であると同時に客体であり、メッセージによって他のオブジェクトと相互作用する。
つまり、使う側にとって、使われる側のオブジェクトは自身の責務とサービスが明確でなければならない。

世界に自分ひとりしか居なくて、それで世界が完結してるなら、相互作用だのサービスだの考えなくても良いだろうけどね。

>>701
それ、俺と全く同じことを言ってない?

704 :デフォルトの名無しさん:2010/04/07(水) 00:48:43
役割はパーツが主体だから、聞こえがいいんだよ。
「〜さんは〜の役割を担ってる」とかな。
その、甘い響きに魅了されてアホが引っかかる。
ウソも方便ってやつ。でもウソはウソ。
機能は人々で成り立つ(人々ってのが重要)、そういう冷たさも必要だし、
エンジニアならそうじゃなきゃやってけない。システムとはそういうもの。
〜が〜の役割を担う、じゃなくて、
機能は〜や、〜や、〜で成り立つ。(複数なのがポイント)

705 :デフォルトの名無しさん:2010/04/07(水) 00:52:30
相互作用はOOPの苦手分野だろうがよ。
object1.communicate( object2 );
変だろ?
communicate( object1, object2 );
だよな。

706 :デフォルトの名無しさん:2010/04/07(水) 00:58:47
>>701
あれ(これ,これ,これ)って命令は、特殊な状況でしか出来ないんだけどね。
ついでにOOPは非OOPの考え方を含むので、その書き方を排除する理由はない。
OOPであろうがそう書けば良いだけの話だ。

707 :デフォルトの名無しさん:2010/04/07(水) 01:00:27
>>705
private Foo foo;

public void method() {
  foo.bar();
}

708 :デフォルトの名無しさん:2010/04/07(水) 01:03:51
>>704
その話とオブジェクト指向の関係が見えないんだけども。

709 :デフォルトの名無しさん:2010/04/07(水) 01:05:53
こんな感じのやつらに、それぞれいつものやっといて
みたいなことができるのが便利

710 :デフォルトの名無しさん:2010/04/07(水) 01:09:30
>ついでにOOPは非OOPの考え方を含むので
なにそれ

711 :デフォルトの名無しさん:2010/04/07(水) 01:11:23
>>710
え?

712 :デフォルトの名無しさん:2010/04/07(水) 01:15:20
>>708
OOPは複数の対象物間の関係を記述するのが苦手だろ。
staticなメソッド作れとか言ってるやつも居るが、
それは非OOP的発想だわな。
しかもオブジェクト同士がコミュニケートしている箇所が「重要」な処理なのに、
その「重要」な箇所を非OOP的に書くとか。だったらOOPってなんなんだ。
肝心なところで機能不全ですか?

713 :デフォルトの名無しさん:2010/04/07(水) 01:25:08
>>710 >>712
OOPは手続き型や関数型などと組み合わせて初めて威力を発揮するもの。
ハナっから単体で存在しようなどとはしてないんだよ。
手続き型のOOPLなら、手続き的にやるべきところは手続き的にやれば良い。
あれ(これ,これ,これ)としたいならそうすれば良いだけ。

変わるとすればその先の、あれ()の内部の書き方だろうな。
渡された「あれ()」は各引数に対して何かをする処理を書くだろうが
その各「これ」に対する具体的な処理は、OOP的には「これ」のメソッドとして書くことになるだろう。
仮に「これ.それ()」だとすれば、それ()内部はやはり手続き的に書くだろう。

714 :デフォルトの名無しさん:2010/04/07(水) 01:32:28
つまり、メソッドはセッターとゲッターだけになるってことだろ?
もっとも安全なOOPの使い方で、俺も推薦するけど、
それ、機能不全だろ。

715 :デフォルトの名無しさん:2010/04/07(水) 01:39:15
セッターは慣れるほどに微妙な存在になるけどな。
てかカプセル化だけなら安全なだけで便利さはあんまりないよ。
ポリモが使えるようになった時、OOPの真骨頂が見えると思う。

そして機能不全は別に否定しない。OOPだけで何かが出来るというモノではないからね。

716 :デフォルトの名無しさん:2010/04/07(水) 01:43:48
ポリモでたー。
ゲッターとセッターだけのクラスでポリモが役に立ちますかね。
俺なら素直にタイプ値でswitchだな。
switch嫌う人も居るけど、制御構造が明確というメリットがある。

717 :デフォルトの名無しさん:2010/04/07(水) 01:50:18
そして、セッターとゲッターもアホらしいので、もう構造体だ。
まーOOPはデータの管理に使えばうまく機能すると思うよ。
コンテナはうまく機能している。

718 :デフォルトの名無しさん:2010/04/07(水) 01:51:38
何使う場合でも結局大事なのはバランス感覚だよな。

719 :デフォルトの名無しさん:2010/04/07(水) 01:54:00
対象になりうる型の種類が少なければ型switchでも良いんだけどな。
対象が増えてくると辛いと思うぞ。
それこそ何が入っているか不明なリストとかも存在するし。
標準ライブラリと添付ライブラリと各マが作った自作クラス全部そこに書くのか?
んで各自は新しい型を作る度に「要修正関数リスト」みたいなのとにらめっこするのか?

720 :デフォルトの名無しさん:2010/04/07(水) 02:03:32
ポリモが必要な新しい型をポンポン作る機会なんてねーよ。
それ、設計ミスってる。

721 :デフォルトの名無しさん:2010/04/07(水) 02:20:53
ん?新クラス作っておおよそのフィールドが出たら、とりあえず文字列化メソッドぐらいは実装しない?

722 :デフォルトの名無しさん:2010/04/07(水) 02:25:09
「何が入ってるか不明なリスト」とかいう前提だとOOPだって無力じゃねえか
ルートobjectのリストとするしかないわけだろ
ルートobjectに全機能をぶち込むか

723 :デフォルトの名無しさん:2010/04/07(水) 02:49:20
いつもそんなリストと戦ってるんですか。大変そうですね。
僕は楽な仕事ばっかりでよかった!

724 :デフォルトの名無しさん:2010/04/07(水) 07:02:28
>>675

プログラムの機能が「制御でデータ関係を定義する」ことで成り立つとしても、「オブジェクトに
制御をぶら下げた時点で、構造的におわっとる」が即座に正しくはならないよ。構造的に
終わるかどうかは、使う側の選好の問題だからだ。

HaskellにO'Haskellが出てきたり、MLにOCamlが出てきたりと、実際にはオブジェクトに制御を
ぶら下げたほうが人間にとって分かりやすい。新生児からの成長の過程での学習が、
オブジェクト指向的だからだ。

725 :デフォルトの名無しさん:2010/04/07(水) 07:11:45
>>683

洗車機のインスタンスで車のインスタンスを洗車するのだから、洗車機::洗車(車配列)を
インスタンスメソッドとして実装するべきだろう。

複数の車を洗車するということがよほど特殊なことでない限り、foreachなことは、
洗車機::洗車(車配列)本体に収めてしまえばいい。

726 :デフォルトの名無しさん:2010/04/07(水) 07:18:38
>>712
>>707をもっと丁寧に書いてみたお。

public class Hoge {
  private Foo foo = null;

  public Hoge(Foo foo) {
    this.foo = foo;
  }

  public void method() {
    ・・・
    foo.bar(); // HogeからFooに必要な処理を委譲
  }
}

  ・・・
  Hoge hoge = new Hoge(foo); // 「Hoge -> Foo」の関係を定義
  hoge.method();


これで、Hoge -> Fooの関係を極めて明瞭にモデル化できるわな。
(getterとかどこにも書いていないことに注意)

こういう手法のメリットは、一度Hogeを作ってしまえば、後は「HogeはFooを使っている」ということを
オブジェクトを使う側は全く意識する必要がないこと。もちろん、Fooの実装はポリモで扱える。
単体オブジェクトの単純な一対一なら記述量が増えるだけで大してメリットはないが、
こういう関係が幾重にも重なったり、一つのクラスに属するオブジェクトが多数登場するような状況で威力を発揮する。

一方で、そもそもobject1.method(object2)と記述するとしても、別に問題はないけどな。
それをもって「OOPは複数の対象物間の関係を記述するのが苦手」とか言われても意味が分からん。

727 :デフォルトの名無しさん:2010/04/07(水) 08:16:24
>>722
分割統治という言葉を知らないのか。そんなんでよくプログラマやってるな。

728 :デフォルトの名無しさん:2010/04/07(水) 18:08:24
>>726
で、foo.bar()の処理の決定に、hogeが要因になる場合はどうするんだ?

729 :デフォルトの名無しさん:2010/04/07(水) 18:18:55
>こういう関係が幾重にも重なったり、一つのクラスに属するオブジェクトが
>多数登場するような状況で威力を発揮する。

想像してみよう。
1.各オブジェクトは自分に関係のあるオブジェクトへの参照を持つ。
2.各オブジェクトは自分自身に対する処理しかしない。

プログラムの機能をオブジェクト同士の化学反応に頼って成り立たせるわけか。
あほだ。

730 :デフォルトの名無しさん:2010/04/07(水) 18:23:16
>>728
生成時 or 実行時にHogeをFooに渡せばいいんじゃね。
本当にHogeごと渡さなければいけないか(=状態を別クラスに分離できないか)は要検討だけど。

731 :デフォルトの名無しさん:2010/04/07(水) 18:27:14
まずいのは、各オブジェクトの性質で、最終的なプログラムの機能を決めようとしていること。

732 :デフォルトの名無しさん:2010/04/07(水) 18:30:15
>>729
>>731
具体的にどういう弊害があるのか論証しておくれ。

733 :デフォルトの名無しさん:2010/04/07(水) 18:35:53
>>730
で、foo.bar()の扱いはどうなるの?
hoge.method()の中で呼ばれるfoo.bar()の中で、さらにhogeのメソッドを呼び返すの?
hogeは今hoge.method()の実行中で、状態が不完全であるにも関わらず?
カプセル化ってなんだったっけと、考えさせられるな。
処理が完了していないまま、互いのメソッドを呼び出しあうと、
カプセル化は崩れるわな。何のためのOOPやら。

734 :デフォルトの名無しさん:2010/04/07(水) 18:44:23
>>733
> hogeは今hoge.method()の実行中で、状態が不完全であるにも関わらず?

それがクリティカルになるケースなら、そもそも2オブジェクト間の委譲ではなく、
仲介者を用意するなりなんなりするべき。

735 :デフォルトの名無しさん:2010/04/07(水) 18:46:21
>>733
オブジェクト同士が、お互いのメソッドを呼び合うとかはやるな。
同じメソッドを呼び合うようなことのないように>>734とかやり方は色々あるけど
ただそれ以前に、カプセル化の意味を何か勘違いしていないか?
カプセル化は外部が直接状態を書き換えられないようにする、ってのが本質で
その際の信頼性については言及しないと思うぞ。

736 :デフォルトの名無しさん:2010/04/07(水) 18:51:29
そもそも、オブジェクト同士が互いに強く依存しているコードは、
機能がきちんと疎結合になっていないわけで、設計レベルでの失敗も疑うべきだな。

>>735
なるべくアトミックになる単位で操作を提供するのが望ましくはあると思うけどね。

737 :デフォルトの名無しさん:2010/04/07(水) 18:55:23
>>734
>>726
> (getterとかどこにも書いていないことに注意)
は破綻したわけだ。
それがOOPの限界。

>>735
>カプセル化は外部が直接状態を書き換えられないようにする、ってのが本質で
>その際の信頼性については言及しないと思うぞ。
マジで?俺の中でカプセル化の地位が下がった。

738 :デフォルトの名無しさん:2010/04/07(水) 19:00:31
>>737
1. 呼び出し順序が問題になるような双方向関連、みたいな特殊なケースを一般化して何がしたいのか分からん
2. なぜ仲介者が存在するとgetter使わなきゃいけないと思ったのか説明を

739 :デフォルトの名無しさん:2010/04/07(水) 19:40:43
あと、>>732への返答がまだだね。

740 :デフォルトの名無しさん:2010/04/07(水) 21:21:03
ちょっとまって、これは返答に付き合う義理はないよね、レベル的に。

741 :デフォルトの名無しさん:2010/04/07(水) 21:45:47
>>724
>HaskellにO'Haskellが出てきたり、MLにOCamlが出てきたりと、実際にはオブジェクトに制御を
いやいやいやいや
O'Haskellの最終更新日見た?論文書く人以外に誰か使ったと思う?
OCamlでオブジェクトが嫌われ者だってのは割と常識だよ?

742 :デフォルトの名無しさん:2010/04/07(水) 21:57:03
関数型の世界はよく知らんけど
手続き型の世界じゃもう一般教養

743 :デフォルトの名無しさん:2010/04/07(水) 22:11:49
>>740
レベル^^;

744 :デフォルトの名無しさん:2010/04/08(木) 15:25:44
template厨はどこへ

745 :デフォルトの名無しさん:2010/04/08(木) 23:54:04
アンチOO君は何処行った

746 :デフォルトの名無しさん:2010/04/09(金) 00:52:14
アンチOOじゃねぇけど, OO意味ねぇ!!!
アホが書くと object に隠蔽したグローバル変数の大群じゃねぇかw


747 :デフォルトの名無しさん:2010/04/09(金) 01:10:49
そりゃ、OOPLを使えばOOになるわけじゃないし。

748 :デフォルトの名無しさん:2010/04/09(金) 04:50:32
OO自体は意味あるが、OO信者はいらない。
そういう奴は実行フローが見えてないから、バグ出ても自分の責任だという認識がない。
本来設計はそのためにあるのに、デバッグ段階の症状を見ても原因を特定できないのは
勘弁してほしい。何の関係もない別プロジェクトの人間が何で口出さなきゃならんのだw

749 :デフォルトの名無しさん:2010/04/09(金) 08:03:46
そういう奴は、「OOとは何ぞや」と説くよりもデザパタ暗記させた方がマシになりそう。
デザパタは暗記して意味のあるもんでもないけど。

750 :デフォルトの名無しさん:2010/04/09(金) 12:14:16
世間でよく聞くオブジェクト指向ってさ、その文脈をよくよく吟味してみると、
オブジェクト指向のある一種類だけを取り上げて、それで全てみたいな感じで
語られるから、かなり誤解されている部分が多いような気がする。
っていうようなこと言うと「じゃあ、その他の種類ってのを挙げてみろよ」と
喧嘩腰で食って掛かってくるひとが必ず出てくるから、話が進まないんだけどね。

751 :デフォルトの名無しさん:2010/04/09(金) 12:41:17
>>750
それでしたら、その他の種類のものを一例挙げて頂けないでしょうか。
その上で何か興味深い議論をさせて頂けたなら幸いです。

よろしくお願いします。

752 :デフォルトの名無しさん:2010/04/09(金) 22:07:20
>>726
ポインタの保持なんてしてるじゃん
fooにいれたもんは生きてるか死んでるかわからないじゃん
これでカプセル化を理解してるとか最低最悪だな
fooがぶっこみ料理だったらなんでもできちゃうじゃねーかよ

こんな素人が金もらってプログラム組んでるから世も末だなって思う

753 :デフォルトの名無しさん:2010/04/09(金) 22:12:13
xxx yyy = new xxx();

754 :デフォルトの名無しさん:2010/04/09(金) 23:03:44
>>752
君は、ガソリン車に灯油を入れてエンジンぶっ壊して逆ギレするタイプ?

マジレスすると、普通にvalidationして例外投げればいいだけの話。

755 :デフォルトの名無しさん:2010/04/10(土) 01:35:12
>>754
全然違うこと言ってない?
いつの間にかにHogeでfooの内容が変更されている恐怖を
他のクラスはどうやって知ったらいいの?

その実装ってグローバル変数の恐怖とまったく変わらないじゃん
仮にfooがグローバルインスタンスホルダー的超巨大クラスだったときとか
もうカプセル化なんてまったく気にする必要がないウンコ設計じゃん

756 :デフォルトの名無しさん:2010/04/10(土) 01:43:25
>>755
グローバル変数だと直代入されたらどうしようもないが
カプセル化してるなら「変更されたら他のクラスに知らせる」って実装も漏れなくできます。

757 :デフォルトの名無しさん:2010/04/10(土) 01:49:14
もしくは「変更されたかどうか確認する」メソッドを持つことも出来るし。

758 :デフォルトの名無しさん:2010/04/10(土) 02:00:42
>>756
俺のレス復唱してくれるかな?

759 :デフォルトの名無しさん:2010/04/10(土) 02:05:00
まあ、とりあえずクラスのメンバ変数にfooはあかんよ
こんなのもった時点でカプセル化なんてまったく意味ないわ
他どんなにいいわけしたってこれじゃなんの制限も活きてないじゃない
まったくやってること無駄だわ

こんなの基準にして設計勉強しちゃってる時間がそもそも無駄だわ
意味ないじゃない
なんのためにカプセル化してるの?
勝手に変えられちゃうの嫌だからじゃないの?
こんな初っ端のアクセスでクラスに毒物しこむような真似しておいてカプセル化できてますはない

760 :デフォルトの名無しさん:2010/04/10(土) 02:13:34
>>755
好きなのを選んでくれ。
1. Fooのインタフェースを適切に設計してカプセル化し、不適切な操作を防ぐ
2. Fooを最初からImmutableオブジェクトとして設計する
3. Hoge#method()の挙動をきちんとドキュメント化する

そもそも、影響範囲は最大でもfooインスタンスに限定されるのだから、
グローバル変数と比較するのはおかしい。

> 仮にfooがグローバルインスタンスホルダー的超巨大クラスだったときとか

それを書いたコーダーをクビにしてからリファクタリング汁

761 :デフォルトの名無しさん:2010/04/10(土) 02:19:08
>>758
復唱しても解りにくいぞw
「fooの変更」でなく「fooが参照してるオブジェクトの内部の変更」のことが言いたいの?

762 :デフォルトの名無しさん:2010/04/10(土) 02:24:29
>>759
何が言いたいのかよく分からないのだが、
オブジェクト内に他のオブジェクトへの参照を持っておいて、それを呼び出すと、
具体的にどのオブジェクトのどの部分が汚染されて、その結果どのような悪影響があると主張したいの?

763 :デフォルトの名無しさん:2010/04/10(土) 02:25:46
あと、>>732への回答もよろしくね。

764 :デフォルトの名無しさん:2010/04/10(土) 02:34:17
参照もたせるとJavaだとリークの可能性、C++だと解放済領域への不正参照の可能性があるけど
ここらへんってどうやって回避してる?

765 :デフォルトの名無しさん:2010/04/10(土) 02:36:46
>>764
Java: 不必要な双方向参照を避ける
C++: スマートポインタを使う

766 :デフォルトの名無しさん:2010/04/10(土) 02:51:03
しょぼw

767 :デフォルトの名無しさん:2010/04/10(土) 02:55:26
循環参照でもリークするし、
スマートポインタだって同じ理由でリークする

基本的にリークの可能性は回避できない。どうしても防ぎたいなら
適当なタイミングでプロセスごと終了(再起動)するよう設計するぐらいだね

768 :デフォルトの名無しさん:2010/04/10(土) 03:04:47
0にならないから10も100も同じ!

769 :デフォルトの名無しさん:2010/04/10(土) 03:09:11
いまどき循環参照が問題になるGCなんてあるの?

770 :デフォルトの名無しさん:2010/04/10(土) 03:54:59
まずはBertrand MeyerのDesign by Contractを勉強しろ。

771 :デフォルトの名無しさん:2010/04/10(土) 11:40:07
「interfaceはcontractである」みたいな考え方を表すキーワードって何だっけ。

772 :デフォルトの名無しさん:2010/04/10(土) 13:42:53
>>760
それしか解決策ない?
もっとよく考えてよ

773 :デフォルトの名無しさん:2010/04/10(土) 13:48:05
>>772
他にもあるかもしれんが、なんか良い方法を知ってるなら教えてくれ。

774 :デフォルトの名無しさん:2010/04/10(土) 13:49:52
>>761
fooの変更であってるよ
ただ、もっとわかりやすくいうと
Hoge内でのfooの変更
これがダメ
Hogeのとあるメソッドでfooが使われてるかどうかが外部から見えないのが一番ダメ

これがダメだからのカプセル化なんだし
結果としてカプセルになってないじゃん
Hogeがfooを介してなんでもできるようになってしまっている
fooがグローバルインスタンスホルダー的な仕様のものならこれは最低最悪の実装といっていい
設計なんもわかってないわ

775 :デフォルトの名無しさん:2010/04/10(土) 13:56:30
>>774
> Hogeのとあるメソッドでfooが使われてるかどうかが外部から見えないのが一番ダメ

見えない(見えなくてもいい)のが最大のメリットじゃないか。何を言ってらっしゃるのか。
カプセル化は、オブジェクトを無菌室に叩き込んでスタンドアロンにすることじゃないぞ。

776 :デフォルトの名無しさん:2010/04/10(土) 14:03:43
Fooは、自分の責務をドキュメント化し、それを確認する単体テストを書く。

Hogeをコーディングする側は、Fooがどんな責務を持っているかだけ知っていればいい。
Fooの実装が、自分の責務をきちんと実装できていないなら、それは単なるバグだ。

777 :デフォルトの名無しさん:2010/04/10(土) 14:04:13
fooがきっちりアクセス制御されてりゃいいんじゃないの
そこまで変な設計とは思わない

778 :デフォルトの名無しさん:2010/04/10(土) 14:06:29
最強のオブジェクト指向な言語はC++
Javaとかウンコ

779 :デフォルトの名無しさん:2010/04/10(土) 14:26:16
>>777
コンポジション知らないプログラマが許されるのは小学生までだよねー(ry

780 :デフォルトの名無しさん:2010/04/10(土) 15:11:04
>>722
それは静的型付けの問題であってOOPの問題じゃないだろ

781 :デフォルトの名無しさん:2010/04/10(土) 15:54:52
>>775
ばっかじゃねぇの
アフォか
Hoge呼び出すたびにfooの内容変わってんじゃねーかよ
どこにそんなこと書いてあるんだよ
しかもfooに別のもんが登録されてたら芋づる式にそれまで変わっちまうじゃねーか
もうこの時点でfooの可能性が無限大なだけにHogeの設計は死んでるも同然
使ってる側はHoge動かすたびに何が影響してるのかHogeの中身みてまず
fooが確保されてることを知るしか手はないね
そしたら次にfooの中まで知らなきゃいけないときてる
もう完全に姿勢が「わからなかったらソースを見てください」的な極めて無責任
かつまったくセンスの死んだ設計だね

単純にさHogeのメソッドで必要なときに引数からfooの必要なもんだけ渡したんじゃダメなのかよ
なんで確保しちゃうんだよ
仮にHogeをブラックボックスにしたときに使ってる側はHogeがfooをガメ続けていることを
どこまで認識しなきゃいけないんだよ
ソース見なきゃわからないのかよ
ぶっちゃけ使い難いだろ

782 :デフォルトの名無しさん:2010/04/10(土) 16:04:44
>>781
>>776

783 :デフォルトの名無しさん:2010/04/10(土) 16:07:16
>>781
> そしたら次にfooの中まで知らなきゃいけないときてる
> もう完全に姿勢が「わからなかったらソースを見てください」的な極めて無責任



> 単純にさHogeのメソッドで必要なときに引数からfooの必要なもんだけ渡したんじゃダメなのかよ

^^;;;

784 :デフォルトの名無しさん:2010/04/10(土) 16:14:55
Hoge「何かおきたら勝手に呼びますけど、動作の保障はありまん」
foo「何がいつ呼ばれるのかこわいお。仕様変わったらどうすんだお」
ユーザー「仕様書よこせ」
マ「ソース嫁」

785 :デフォルトの名無しさん:2010/04/10(土) 17:39:00
>>782
それHogeを使う側のことまったく考えてないよね?
HogeをつかうにはFooの事情にも詳しくないといけないっておかしくない?

786 :デフォルトの名無しさん:2010/04/10(土) 17:41:19
仕様を把握せずに使えばどんな設計も糞になるわ

787 :デフォルトの名無しさん:2010/04/10(土) 18:54:01
>>784
HogeとFooの両方のJavadocに仕様を書いて、単体テストで保証しとけ。
呼び出し順が重要なら、FooのJavadocにそう書いておけ。
んで、Fooのライフサイクルを整理して、公開するAPIを最小限に汁。

繰り返しになるが、Fooをいきなり#dispose()から呼び始めるコードは単なるバグだ。

788 :デフォルトの名無しさん:2010/04/10(土) 18:58:32
>>785
Hogeも同じこと。自分の責務をドキュメント化し、それを確認する単体テストを書く。
Hogeを使う側は、コンストラクタを見れば「Hogeを使うにはFooが必要」ということが分かる。

では、Hogeに与えるFooをどうやって作るのか、というのは問題になるが、必要なら、
HogeとFooを提供する側がそれらを一度に生成するFactoryを用意するなり、
DIコンテナを使うなりすればいい。

789 :デフォルトの名無しさん:2010/04/11(日) 01:03:00
循環参照って
ある意味再帰?w

790 :デフォルトの名無しさん:2010/04/11(日) 01:04:24
末尾が付く方な

791 :デフォルトの名無しさん:2010/04/11(日) 01:21:53
fooの仕様変更がないとすれば
ビルダーとかねてcreate関数でfooを作成してアダプタ作る
仕様変更するならアダプタとインターフェース分ける

単純にfooの機能をラッピングしたいだけならグローバル関数を作る
もちろんnamespaceで分ける
javaならメソッド関数だけで引数のfooをやりたいように呼ぶ

ラッピングした処理自体を拡張したり
fooが状態を保持するようなクラスなら
これもアダプタクラスとインターフェースクラスで分ける

コンストラクタで他クラスを勝手に保持するようなクラスはありえない

792 :デフォルトの名無しさん:2010/04/11(日) 01:25:18
コンストラクタで通信が必要なオブジェクトを渡すっていつもやるけどなんでだめなの?

793 :デフォルトの名無しさん:2010/04/11(日) 01:27:19
>>792
渡すクラスがおかしかったらどうすんの?
例外処理とか入るならinit関数なりにした方が面倒なくね

794 :デフォルトの名無しさん:2010/04/11(日) 01:28:28
もっと具体的に

795 :デフォルトの名無しさん:2010/04/11(日) 01:30:49
>>794
何が知りたいの
コンストラクタで例外投げるつもり?
勝手に継承されたりキャストされたらバグ直行じゃん

796 :デフォルトの名無しさん:2010/04/11(日) 01:33:21
勝手に継承って動的に継承?
勝手にキャストってそのクラス作るの自分でしょ?
コンストラクタで例外って誰が例外を発生するの?

797 :デフォルトの名無しさん:2010/04/11(日) 01:35:57
>>795
まともなコーダーなら、継承クラスのコンストラクタの最初でsuper(Foo)呼ぶけどな。
もちろん、そこを警戒してFactoryメソッドにするのも当然アリだが。

798 :デフォルトの名無しさん:2010/04/11(日) 01:39:14
>>796
コンストラクタがいつよばれるか分かってんの?
コンストラクタは初期化だけにしとけよ
つか勉強不足すぎ

まあ、使う側は生成するだけで一行だからすっきり書けるってのはわかる

799 :デフォルトの名無しさん:2010/04/11(日) 01:40:07
>>798
いやお前の言ってることが全然分からないんだけどまじで

800 :デフォルトの名無しさん:2010/04/11(日) 01:42:06
コミュニケーション不全スレ

801 :デフォルトの名無しさん:2010/04/11(日) 01:44:22
>>799
説明する気はない
起こり得る最低限の問題は書いた
わからないなら考えてくれ
反論が正当なら俺も改める

802 :デフォルトの名無しさん:2010/04/11(日) 01:45:35
言ってることが分からないから反論もないわw

803 :デフォルトの名無しさん:2010/04/11(日) 01:47:53
まあコードも書かずにプログラミング語ってもな

804 :デフォルトの名無しさん:2010/04/11(日) 01:49:25
一口にコンストラクタといっても、言語は何を想定しているのか。

805 :デフォルトの名無しさん:2010/04/11(日) 01:50:51
説明する気はないw

806 :デフォルトの名無しさん:2010/04/11(日) 01:53:01
なんという典型的なFUD

807 :デフォルトの名無しさん:2010/04/11(日) 01:56:11
>>806
連投必死ですか

808 :デフォルトの名無しさん:2010/04/11(日) 01:57:43
自分が理解できない人間はキチガイの一人だけと

809 :デフォルトの名無しさん:2010/04/11(日) 02:16:18
>>807
俺は>>797>>804だけだが。

810 :デフォルトの名無しさん:2010/04/11(日) 02:24:42
オブジェクトの状態が変更されるのは、当たり前で
その影響が想定範囲外に波及するのを気にしてるなら
作り方自体が問題なんじゃないの?

811 :デフォルトの名無しさん:2010/04/11(日) 02:32:37
>>788
ていうか俺の言ってること理解してる?

Hogeがfooに依存してる割にはfooが自由ってのが絶対にバグおこすよ
こんな仕組みにしてちゃダメでしょ
単純にfooを開放したくなったときにHogeにはどう取り繕えばいいの?
こいつは消滅するときにfooが必要だったりするの?
とかいらない心配までしないといけないじゃない
そりゃドキュメントにそう書いてあるとかいういいわけもできるけど
ぶっちゃけそんな必要ないのにそんな仕組みにするのは三流だと思わない

もう一度いうけどfooを保持する必要ってないじゃない?

812 :デフォルトの名無しさん:2010/04/11(日) 02:54:15
GC系ならHogeが解放するまではfooは解放されないね。
C++は解放されないように消滅タイミングを管理する必要がある。
そういう言語仕様なんだからそりゃそうでしょう。
Javaならfooがいつ解放されるかコード見るか仕様を確認するかしかないし
C++だとしたら引数で渡したものはどのように扱われるかはコード見るか仕様を確認するかしかないでしょう。
関係性があるクラスが相手の都合を知らなきゃいけないのは当然でしょ。
保持しないことによりそれが常に改善されるわけではないと思うが。
関係性がある場合ほとんどのメソッドにオブジェクト渡すことになる。
ケースバイケースだと思うが。
コンストラクタで関係性を明示しておくのは普通に一手法だろ。

813 :デフォルトの名無しさん:2010/04/11(日) 03:03:38
>>811
1. そもそも何故Hogeに渡したFooインスタンスを、Hoge以外の場所で使いまわすのが前提なのか
2. 仮にFooを色々な場所で使いまわすのが前提なら、最初からimmutableなオブジェクトとして設計するなり、
 Fooインスタンス自身のライフサイクルを確認できる手段を提供して、そのことをドキュメントに明記すべき。

どちらにせよ、あらかじめ保持しようが呼び出しのパラメータとして渡そうが、2の場合なら
Hoge側でチェックが必要なのは変わらん。
FooがHogeの機能の一部であるなら、コンポジションとして委譲する方法がある、というだけの話。

>>810の言う通りで、自分でわざわざバグを作りこんでおいて「コンポジションを使うのは三流」とか
意味が分からん。

814 :デフォルトの名無しさん:2010/04/11(日) 03:19:49
>>813
はぁ?
1はなんで他で使っちゃいけないんだよ?
Hogeでしか使わないならHoge内で生成しろよ
2は解決策の心算なの?それ
プログラム組むの下手糞なんじゃない?
単純にHogeで使うメソッドの引数からfooの内容で必要なもんぶち込んでやればいいだけの話だろ?
なんでそれをやたら避けようとするんだ?

815 :デフォルトの名無しさん:2010/04/11(日) 03:24:49
おまえがそれで大規模なプログラムをオープンソースで発表すれば多少はみんな言うこと聞いてくれると思うよ。
そのルールが実際に開発で有効かね。

816 :デフォルトの名無しさん:2010/04/11(日) 03:25:18
>>814
> 1はなんで他で使っちゃいけないんだよ?

使ってもいいよ。他で使うことが前提なら2の対策をするべきというだけ。

> Hogeでしか使わないならHoge内で生成しろよ

もちろんそれでもいいよ。外から与えた方が便利な場合も多いけどな。

> 単純にHogeで使うメソッドの引数からfooの内容で必要なもんぶち込んでやればいいだけの話だろ?

なぜHogeが、直接関係のないFooのサービスを提供できると思ったのか具体的に説明を。

817 :デフォルトの名無しさん:2010/04/11(日) 03:27:14
>>815
君は、オープンソースのソースコードとか読んだことないの?
大小問わず、あらゆるプロジェクトで利用されてる基本中の基本テクニックなんだが。

818 :デフォルトの名無しさん:2010/04/11(日) 03:27:56
>>817
具体的にどのオープンソースかね。
そんなルールが徹底されているコード見たことないから教えてくれ。

819 :デフォルトの名無しさん:2010/04/11(日) 03:32:13
>>818
http://www.apache.org/

820 :デフォルトの名無しさん:2010/04/11(日) 03:36:15
アパッチて・・・
お前読んでないだろ

821 :デフォルトの名無しさん:2010/04/11(日) 03:51:50
>>820
使ってて仕様に疑問があったら、コードを取ってきて調べるとか普通やるだろ?

CommonsでもXercesでもStructsでもCouchDBでも、好きなのを調べるといい。
Javadocを見てAPIを調べるだけでも勉強になると思うよ

822 :デフォルトの名無しさん:2010/04/11(日) 03:53:49
で何が徹底されてるって?

823 :デフォルトの名無しさん:2010/04/11(日) 04:30:48
そろそろ現実と向き合おうよ。

824 :デフォルトの名無しさん:2010/04/11(日) 05:20:41
>>817
だからなんなの?
どんなにえらい奴やすごい奴が使ってようとダメなもんはダメなんだよ
それとも議論にサジなげて権威で自分の主張を正しいって言い張るつもりで
いった発言なのそれ?
ダサくない?

825 :デフォルトの名無しさん:2010/04/11(日) 05:32:22
>>821
Structsって何ね?

826 :デフォルトの名無しさん:2010/04/11(日) 05:38:38
>>816
>なぜHogeが、直接関係のないFooのサービスを提供できると思ったのか具体的に説明を。
意味不明
単純にfooはHogeのなんらかの処理で必要だから初っ端に確保してんだろ?
それを必要になるごとに引数で渡せって言っただけだよ?
何を何と勘違いしたの?

827 :デフォルトの名無しさん:2010/04/11(日) 05:46:44
>関係性がある場合ほとんどのメソッドにオブジェクト渡すことになる。
無意味な潔癖症は生産性を下げます

828 :デフォルトの名無しさん:2010/04/11(日) 06:17:31
>>824
君が「実績を作って証明しろ」って言ったから、
既に実績は山ほどあるよって教えてあげたのに、これ以上どうしろとw

>>826
> fooの内容で必要なもんぶち込んでやればいいだけ

って書いてあったから、Fooインスタンスから内部状態を取り出してHoge内で
処理しろって意味かなっと思ったのさ。すまなかったね。

委譲を使う理由は>>726で既に書いてるよね。

では、改めて>>813が解決策になっていない理由を具体的に論じてもらえるかな。

829 :デフォルトの名無しさん:2010/04/11(日) 06:42:50
>>828
>>813の2のこと?
だって無駄じゃん
引数で渡せばそれで終りだし
これ以外の解決策ってほぼないでしょ?
仮にやったとしてもHogeの中のfooの挙動を把握することはできないっしょ?
んでfooをだよHogeを知らない人間も使ってたとしたらHogeまで知らなきゃいけないのはなんかおかしくない?

830 :デフォルトの名無しさん:2010/04/11(日) 06:50:13
まあ、コードで書くと

//ケース1
//fooの処理も実行されるがHogeのソースかドキュメントを読まないとわからない
hoge.unko();

//ケース2
//fooが使用されていることが見た目に明らか
hoge.unko(foo);

これのどっちがソース的にいいかっていったら間違いなくケース2だろ?
ケース1はやってはいけないことだ
これはC言語の時代から同じな

グローバル変数・関数がダメな理由といっしょだ
っていうかこのグローバル変数がダメな理由っていうのはちゃんと覚えておいたほうがいい
同じ害が出るものもちゃんとわかるようになるし
もちろんシングルトンとかも同様に駄目

831 :デフォルトの名無しさん:2010/04/11(日) 10:05:27
fooが使われているか否かを知らなくていいのは1。

GoFのCommandパターンは要求をオブジェクト化し、
内部の関数や変数を隠したままクライアントをパラメータ化する。
Command#executeを呼び出すだけ。

変数や関数の実装を隠すことはカプセル化であり、
インタフェースだけ見えているという抽象化である。

832 :デフォルトの名無しさん:2010/04/11(日) 10:13:30
クラスは内部状態を持っていてそれが変化する。
これはクラスの基本的な仕様。
で渡したオブジェクトは内部状態と一員として保持されても文句が言えない。
これもほとんどのオブジェクト指向言語の仕様。
引数でオブジェクトを渡したとしてそれを参照するだけなのか、
変更するメソッドを呼び出すのか、参照先を記録するのか分からない。
結局クラスの実装仕様を理解せざるを得ない。
なおかつ関連性が深いクラスになるとほぼすべてのメソッドでオブジェクトが参照されるようになる。
だったらコンストラクタで参照を保持したほうが可読性高いんじゃないの?

833 :デフォルトの名無しさん:2010/04/11(日) 12:07:45
>>829-830
つまり、FooをHogeの内部に保持すべきでない理由は:
1. Fooに対して操作が行われることが、Hogeを利用する側から不可視になるから
2. Hogeに渡されたFooが、他の場所で破壊的に操作される恐れがあるから
ということでいいのかな(次からは論点を箇条書きでまとめてほしいな)。

まず、2については、new Hoge(foo)でもhoge.method(foo)でも問題は変わらないよね。
Fooの設計、もしくはFooインスタンスを生成して利用する側のインスタンス管理の問題であって、
コンポジションに限った話ではない。

1については、ファイル出力でよく使う以下のパターンを見れば十分なんじゃないかな。

 OutputStream out =
   new BufferedOutputStream(new FileOutputStream(new File("hoge.txt")));
 ・・・
 out.write(data); // データを出力したい。具体的な出力先と出力方法は知らなくとも良い

典型的なDecoratorパターンだけど、実際にoutを使う側からすれば、
ここで重要なのは「データを出力すること」であって、具体的な出力先(File)や、
出力方法(FileOutputStream/BufferedOutputStream)や、現在の書き込み位置ではないわけだ。
つまり、委譲を使う方法の方が、「データを出力する」という操作をより簡潔かつ明瞭に記述できる。

また、具体的な出力方法を知る必要があるなら、outを初期化している部分を調べればいい。
これは、FILE *fp = fopen("hoge.txt", "wb");と何ら変わらない。

834 :デフォルトの名無しさん:2010/04/11(日) 12:14:43
あと、副次的な話だけど、
例えばHogeが、FooとBarとBazとQuxとQuuxとFoobarの機能を使って実装されている場合に、

 Hoge hoge = new Hoge(foo, bar, baz, qux, quux, foobar);
 hoge.method(i, j);
 hoge.method(i, k);
 hoge.method(j, k);

と書くのと、

 hoge.method(foo, bar, baz, qux, quux, foobar, i, j);
 hoge.method(foo, bar, baz, qux, quux, foobar, i, k);
 hoge.method(foo, bar, baz, qux, quux, foobar, j, k);

と書くのとどっちが楽か、という話もあるね。
こういうのが非現実的な例だと思うなら、WIN32APIの関数を見てみるといい。

835 :デフォルトの名無しさん:2010/04/11(日) 12:15:38
ソース的にいい悪いの問題じゃなく用途の違いだと思う

836 :デフォルトの名無しさん:2010/04/11(日) 12:37:40
829ではないが
>Hogeを利用する側から不可視になるから
が問題だといってるのなら、「典型的なDecoratorパターン」も問題なのだろうから
>委譲を使う方法の方が、「データを出力する」という操作をより簡潔かつ明瞭に記述できる。
は説得として弱いと思う。
(おれはケースバイケースの立場だが)

837 :デフォルトの名無しさん:2010/04/11(日) 12:50:17
>>836
うん。もちろんケースバイケースだと思うよ。
とはいえ>>813にも書いた通り、Fooをきちんと設計しておけば、大抵は問題にならないはず。

OutputStreamは、あくまで「常にFooの使われ方を把握しなければならない」という主張に対する反例。
まさか、彼も「他人の書いたコードは信用できない」なんて時代錯誤な事は言ってないと思うし。

838 :デフォルトの名無しさん:2010/04/11(日) 14:26:19
> 1. Fooに対して操作が行われることが、Hogeを利用する側から不可視になるから

ってさ、ちょっと待って欲しい。
fooのインスタンスに対してどんな操作が行われようと、
Hogeを利用する側には無関係では?
Hogeがそれを「把握して無いといけない」設計がおかしいのでは?

SwingのJTableはTableModelのインスタンスを公開してるから、
そちらに対して操作はできるし、通常のGUIからのイベントも、
TableModelに当然操作を加えてる。
互いに、どこで操作が行われたかなど気にする必要もない。

839 :デフォルトの名無しさん:2010/04/11(日) 14:28:31
さすがにお前は議論が見えてない

840 :デフォルトの名無しさん:2010/04/11(日) 15:55:47
>>838
ちゃんと読めよwwww

841 :デフォルトの名無しさん:2010/04/11(日) 16:01:39
>>837
なるだろ
だいたいfooは問題なくてもHogeの呼び出し方でfooの状況がどうなってるかわかんねーじゃねーかよ
なんで「大抵問題にならないはず」とかわけのわからないこと言ってるの?

俺が指摘したこと(>>830)わかってる?
本当にカプセル化とかわかってるんだろうか?
なんかもう会話が成立しないね(笑)w

842 :デフォルトの名無しさん:2010/04/11(日) 16:04:49
人の指摘は無視していいたいことだけ言うタイプ

843 :デフォルトの名無しさん:2010/04/11(日) 16:12:18
>>841
問題になるなら、具体的な状況。
カプセル化、グローバル変数の弊害もあげてるので、
その点について説明する必要があるのではないか?

議論ではなくて、見下したいだけなら、どうでもいいですが

844 :デフォルトの名無しさん:2010/04/11(日) 16:13:10
>>841
>>830には、君がそう主張する「理由」が何も書いてないけどね。
アホとかバカとか書く前に、少しは自分の主張をロジカルに書いてくれ。

それはともかく、Hogeに渡したFooインスタンスを、
1. そもそも他で使おうとすべきでない
2. 使おうとするなら、Fooはきちんとそれを想定して設計すべき
のどちらか、ってこれ三度目なんだけどな。

2は、例えばFooをimmutable、つまり一度生成したら二度と状態が変わらないものとして
設計する方法がある(Fooの状態を変更したい場合は、新たなFooインスタンスを生成する)。
これなら、君の心配する問題は起きない。

つうか、そもそもhoge.method(foo)でも同じ問題が起きると思うのだが、
なぜコンポジションの場合でのみ問題があると考えるの?

845 :デフォルトの名無しさん:2010/04/11(日) 16:31:30
もうあれだ、次からはレスの最初に、

・主張したいこと
・その具体的かつ論理的な根拠

をそれぞれ箇条書きで書いてくれ。それ以外はもう返答しないのでよろしく。

846 :デフォルトの名無しさん:2010/04/11(日) 16:39:34
つまり破壊的代入が出来ない言語が最強という事でよろしいですか

847 :デフォルトの名無しさん:2010/04/11(日) 16:50:25
人に要求するけどおれはやらないよ!

848 :デフォルトの名無しさん:2010/04/11(日) 16:53:15
徹底的に代入を排除するとオブジェクト指向でかけないのではないか?

849 :デフォルトの名無しさん:2010/04/11(日) 17:15:38
>>844
はぁ?
だから引数から渡せば問題ないのになんでその2つなの?
頭大丈夫?おk?

850 :デフォルトの名無しさん:2010/04/11(日) 17:16:31
人の指摘は無視していいたいことだけ言うタイプ

851 :デフォルトの名無しさん:2010/04/11(日) 17:18:42
>>849
つ マルチスレッドw

852 :デフォルトの名無しさん:2010/04/11(日) 17:32:40
>>849
「引数から渡せば問題ないのに」??

hoge.method(foo)

他の場所で…

foo.setBaz(ababa)

されてたら一緒では?


853 :デフォルトの名無しさん:2010/04/11(日) 17:36:05
他人の指摘は誤読して反論か無視
決して論点は明確にせず自説を復唱
キチガイは相手できないな

854 :デフォルトの名無しさん:2010/04/11(日) 19:05:39
>>849
>>845

> だから引数から渡せば問題ないのになんでその2つなの?

>>852さんの指摘も含めて、「問題ない」の部分の論拠を箇条書きにしてね。

855 :デフォルトの名無しさん:2010/04/11(日) 20:42:14
>>831
> GoFのCommandパターンは要求をオブジェクト化し、
いっちゃん役に立たない例のあれねw


856 :デフォルトの名無しさん:2010/04/11(日) 21:21:18
具体的に指摘できず煽るだけであった

857 :デフォルトの名無しさん:2010/04/11(日) 22:28:41
>>852
全然俺の言ってること理解してねーのはわかった

858 :デフォルトの名無しさん:2010/04/11(日) 22:34:45
もう一度いうけど俺は>>830の問題について言ってるんだよ
なのに>>852のレスは何を言ったの?
後、お前はなか割って入って>>852は全然言ってることが狂ってるってわからないの?
なんでわからないの?

指摘にもなってないじゃん
>>852こそ俺のレス(>>830)何を指摘してるのか聞いてみたいよ

意味わかんねーよ
馬鹿すぎて会話が成立しねーんだよ(笑)

859 :デフォルトの名無しさん:2010/04/11(日) 22:45:29
都合のいい解釈しかしないし答えないw

860 :デフォルトの名無しさん:2010/04/11(日) 22:52:30
じゃあ、あんまり馬鹿な君に俺の考えてることを丁寧に教えてあげよう
まさか、わざと話を曲解してるんじゃなくてマジで馬鹿の場合とか困るからな
俺は>>830

//ケース1
//fooの処理も実行されるがHogeのソースかドキュメントを読まないとわからない
hoge.unko();

//ケース2
//fooが使用されていることが見た目に明らか
hoge.unko(foo);

書いたよね?
んでケース1の問題も説明付きだしなんの問題もないよね?
ここまではおk?

それに対して>>852のレスがきた

続く

861 :デフォルトの名無しさん:2010/04/11(日) 22:55:42
続き

んで>>852
>「引数から渡せば問題ないのに」??
>hoge.method(foo)
>他の場所で…
>foo.setBaz(ababa)
>されてたら一緒では?
という

はぁ?
意味がわからない?

method(foo)の中でfooが使われていることが明示的にわかったら
それでいいだろ
俺の話はそこで終りだろ
なんだよfoo.setBaz(ababa)って?何が主張したいの?

終り

862 :デフォルトの名無しさん:2010/04/11(日) 22:57:31
>>860
まず、そこから間違ってるよな。

//ケース1(訂正版)
//fooが使用されていることが見た目に明らか、かつ操作を簡潔に利用できる
//fooが他の場所で変更されると、Hogeの動作に影響する可能性がある
Hoge hoge = new Hoge(foo);
hoge.unko();

//ケース2
//fooが使用されていることが見た目に明らかだが、毎回インスタンスを渡さなければならない
//fooが他の場所で変更されると、Hogeの動作に影響する可能性がある
hoge.unko(foo);

863 :デフォルトの名無しさん:2010/04/11(日) 23:05:05
>>862
え?俺が指摘してる問題になんで修正かけてるの?
俺の意見に対して君が修正できる意味がわからないんだけど?
そういうのは自分の主張として改めて出してくれない?

人の意見パクるなよ

864 :デフォルトの名無しさん:2010/04/11(日) 23:05:49
>>861
>>833はこう言ってるな。
> つまり、FooをHogeの内部に保持すべきでない理由は:
> 1. Fooに対して操作が行われることが、Hogeを利用する側から不可視になるから
> 2. Hogeに渡されたFooが、他の場所で破壊的に操作される恐れがあるから
> ということでいいのかな(次からは論点を箇条書きでまとめてほしいな)。

これに対する反論はないから、この論点整理に異存はないと判断していいんだよな?

で、>>852は2について言ってるんだろ。それに対して、
> method(foo)の中でfooが使われていることが明示的にわかったらそれでいいだろ
と答えたということは、つまり2については撤回するってことでいいんだよな?

865 :デフォルトの名無しさん:2010/04/11(日) 23:09:24
>>863
問題の前提自体が間違ってるから修正しただけ。
誤った前提を元に議論をしたいなんて思う暇人はいないからな。

866 :デフォルトの名無しさん:2010/04/11(日) 23:11:00
修正部分は反論なんだろ。
パクリ云々で論点ずらして逃げようとしてるように見えるだけだよ。

867 :デフォルトの名無しさん:2010/04/11(日) 23:11:03
>>864
>と答えたということは、つまり2については撤回するってことでいいんだよな?
正直、意味がわからない

クラスのメンバで保持する場合は

hoge.unko();

これになっちゃってunkoメソッドの中でfooが使われているかどうかわからないよね?

hoge.unko(foo);

とした場合はunkoメソッドの中でfooが使われていることが明らかだよね?

これしか俺は言ってないんだけど?
つまり2はunkoメソッドの中でfooが使われていることをHogeソースをみないとわからない
ことが問題であることを指摘した例なんだけど?おk?

868 :デフォルトの名無しさん:2010/04/11(日) 23:14:25
>>865
そしたら話は早い
お前はここで俺と議論しあっている人間とはちょっと違って
カプセル化を律儀に守ることにそもそも反対な立場なんだろ?
そしたら今の話題とは関係ないからちょっと黙っててくれない?

>>867の内容だけど2って分かりにくいな
俺のレス(>>830)でいうとケース1のことな

869 :デフォルトの名無しさん:2010/04/11(日) 23:22:35
横からだが
関連性が深いクラスはすべてのメソッドにオブジェクト渡す形になることになるけどそうしろって主張なの?
実際のOOPLでは参照を保持するのは普通に許されるわけだが
コンストラクタで渡したオブジェクトはすべてのメソッドで変更されると考えることに比べて
それはメリットがあることなの?
俺はケースバイケースでコンストラクタで関連性を明示するほうが可読性高い場合も多いと思うが。
とこれまでも何度もレスしてるけどw。

870 :デフォルトの名無しさん:2010/04/11(日) 23:24:31
>>869
そういうレスの仕方は駄目
何を主張してるのかわけわからなくなる
っていうかすでになってる
ちゃんとアンカーとレスしたい引用文つけて

871 :デフォルトの名無しさん:2010/04/11(日) 23:26:50
>>867-868
期待させないうちに言っておくが、俺は別にお前の味方でも何でもないぞ。
Hoge hoge = new Hoge(foo)を無視して、hoge.unko()だけで云々しても意味ないだろ、
と言いたかっただけ。

872 :デフォルトの名無しさん:2010/04/11(日) 23:28:53
>>870
え?どれにアンカーつければいいの?
一貫して>>830を反復してるだけじゃん。
hoge.unko(foo);しかゆるさないならhogeがつねにhogeと関係性もつなら
hoge.aaa(foo);
hoge.bbb(foo);
hoge.ccc(foo);
となるけど
それより
new Hoge(foo);で関連性明示したほうがシンプルなんじゃないの?

これでもまだ分からないかな?

873 :デフォルトの名無しさん:2010/04/11(日) 23:30:11
>hogeがつねにhoge

>hogeがつねにfoo


874 :デフォルトの名無しさん:2010/04/11(日) 23:36:49
>>869でFAだな。
「コンストラクタで関連性を明示して、中で処理を委譲すると良い場合が多い。」

これに反論したいんだったら、「委譲はあらゆる場合で、メソッドに毎回渡すよりデメリットが大きい」
ということを証明する必要があるが、それも>>833で反論済みで、アンチ君もまともに再反論できてない、と。

875 :デフォルトの名無しさん:2010/04/11(日) 23:59:08
>>872
いやだからそれだと

hoge.unko();

こう書かれているときにunko()メソッドの中でfooが使われているかどうかHogeのソースみないとわからないじゃない?
どうやってfooが使われていることを知るの?

>new Hoge(foo);
これだと初期化に一旦fooが必要なだけでガメ続けているかどうかまでは
Hogeのソースや仕様書(書いてあるかどうか知らんけどw)みないとわからないよね?

ちなみにまだ理解してない人がいそうだからいっておくけど
fooのポインタをHogeの内部で抱えてfooを色々いじくり倒してる状態はカプセル化
ぶっ壊れてるからね
別にその状態に対してなんとも思わないなら別に俺のレスに対する反論はいらないんだぜ

876 :デフォルトの名無しさん:2010/04/12(月) 00:08:58
>>875
>これだと初期化に一旦fooが必要なだけでガメ続けているかどうかまでは
>Hogeのソースや仕様書(書いてあるかどうか知らんけどw)みないとわからないよね?
すべてに使われると仮定すればいいんじゃないの?>>833もその例なんだろ。
実際>>872はすべてのメソッドで使われているとの前提。
OOPLは参照の保持を許してるよ。

ということは「参照保持は禁止」というコーディングルールが徹底されていることが
前提だから結局コードの確認は必要なんじゃないの?
だったら
「コンストラクタで渡すオブジェクトは渡されたオブジェクトから常に利用されると考える」
というコーディングルールもありじゃないの?
君のカプセル化は狭義に定義されているが
その現実度・遵守可能性・可読性・簡便性を考えて妥当なの?ってことなんだよ。

君の言い方をまねすれば
この点に対してなんとも思わないなら別に俺のレスに対する反論はいらないんだぜ

877 :デフォルトの名無しさん:2010/04/12(月) 00:12:09
>>874
横だけど、
バグの責任をできるだけfooに押し付けたいとこだな
前に書いたけど、fooが基本的に不変なら、hogeはファクトリを兼用した方がいい
fooを内包することが分かりやすくなる

fooが多数あり、またポリモーされるなら、hogeはただの関数群クラスとして
毎回引数でfooを指定して処理させた方がいい

さまざまなfooに対して、便利だからと勝手にポインタなり保持されたら
回避策はあるにしろ、そうでないといけない設計には問題がある
fooとの関係を持つhoge自体にfooのバグを内包させることは良くない

878 :デフォルトの名無しさん:2010/04/12(月) 00:13:30
>>876
あ、だから結局、カプセル化をぶち壊してもなんとも思わないんでしょ?

879 :デフォルトの名無しさん:2010/04/12(月) 00:14:57
>>875
> >new Hoge(foo);
> これだと初期化に一旦fooが必要なだけでガメ続けているかどうかまでは
> Hogeのソースや仕様書(書いてあるかどうか知らんけどw)みないとわからないよね?

逆に、「new Hoge(foo)」を見て、fooを初期化以外では使ってないと思う方が不思議だ。
少なくとも、それ以降のHogeのメソッドがFooインスタンスを要求していなければ、
つまりFooへの委譲を利用して実装していると容易に推論できるわな。

> fooのポインタをHogeの内部で抱えてfooを色々いじくり倒してる状態はカプセル化ぶっ壊れてるからね

君の思うカプセル化の「具体的な」定義を「箇条書きで」「厳密に」述べてくれ。話はそれからだ。

880 :デフォルトの名無しさん:2010/04/12(月) 00:16:47
>>879
>逆に、「new Hoge(foo)」を見て、fooを初期化以外では使ってないと思う方が不思議だ。
そんなのわかんねーだろぶっちゃけw

881 :デフォルトの名無しさん:2010/04/12(月) 00:17:30
>>876
常に関係し、fooの状態を保持したいなら継承するべき

882 :デフォルトの名無しさん:2010/04/12(月) 00:19:30
>>877
FooとHogeの単体テストをきちんと実施していれば、ある程度は問題ないんじゃない?
懸念は分かるけどね。
あと、HogeとFooの関係が1..nなら、パラメータとして渡すのもアリだというのはもちろんそう。

883 :デフォルトの名無しさん:2010/04/12(月) 00:19:57
便利だからとコンストラクタで初期化以外のことやるなよ
initなり用意しろよ
そんなに手間かかんねえよ

884 :デフォルトの名無しさん:2010/04/12(月) 00:20:45
>>880
忘れ物。
> 君の思うカプセル化の「具体的な」定義を「箇条書きで」「厳密に」述べてくれ。話はそれからだ。

885 :デフォルトの名無しさん:2010/04/12(月) 00:22:22
>>878
残念通じなかったね。
まあ別に俺が困ることはないんだけど。
ちなみに俺はhoge.aaa(foo);はよくやってたし今もやってる。
しかし明らかにすべてのメソッドで関連性があるときに
いちいちすべてに引数渡しにするのはかえって可読性や記述性が落ちると思って辞めた。
他人からみれば宣言しない限り参照保持してないことを示せてないし
宣言するなら
「コンストラクタで渡すオブジェクトは渡されたオブジェクトから常に利用する」
と宣言しても変わらないし。
ただ、引数にすればそのメソッド呼び出しに必要なんだとだと
言語仕様から推測できるのは間違いないから場所によっては当然使ってる。
実装仕様やコーディングルールがない状態なら
利用者はaaa(foo)で参照保持してる可能性すら疑うからメリットはない場合も多いと考えてる。

886 :デフォルトの名無しさん:2010/04/12(月) 00:22:58
>>881
HogeとFooの関係がis-aでないなら、基本的には委譲を使うべきじゃないの。
少なくとも最近の考え方はそうだよね。

887 :デフォルトの名無しさん:2010/04/12(月) 00:23:31
>>885
ごちゃごちゃ長いけど結局カプセル化どーでもいいって話だろ

888 :デフォルトの名無しさん:2010/04/12(月) 00:23:51
OOPの問題点を挙げてるように見えて
実はどんなパラダイムでも共通の問題点を挙げてないか?

889 :デフォルトの名無しさん:2010/04/12(月) 00:23:52
>>882
問題はないね
でも、今からhogeクラスを作成するとしたらやらん
それでバグ起こしたことがあるし、デバッグでどこがおかしいのか本当に分からなかったからね
あれはもう嫌だ

890 :デフォルトの名無しさん:2010/04/12(月) 00:25:04
>>881
常に関係しているオブジェクトが他のオブジェクトとも連携がある場合はどうするの?

891 :デフォルトの名無しさん:2010/04/12(月) 00:25:52
>>887
「お前のカプセル化」は他人には通用しないからどうでもいいって言われてるんだよw

892 :デフォルトの名無しさん:2010/04/12(月) 00:26:27
>>890
全部1つのクラスに内包する

893 :デフォルトの名無しさん:2010/04/12(月) 00:26:46
オレオレカプセル化

894 :デフォルトの名無しさん:2010/04/12(月) 00:27:03
>>885
「俺のコードは問題ない」の典型な

895 :デフォルトの名無しさん:2010/04/12(月) 00:27:28
>>892
そのなかで連携してる場合は?

896 :デフォルトの名無しさん:2010/04/12(月) 00:27:39
>>891
なんで?
自分のやってること図に書いてみろよ
どの辺がカプセルになってんだよw
仕様するメソッドとか出入り口無視してカプセルなんてぶち破ってるじゃん

897 :デフォルトの名無しさん:2010/04/12(月) 00:28:27
>>890
管理するクラスを間にはさむ
もちろん一方通行じゃなければ話は変わる

898 :デフォルトの名無しさん:2010/04/12(月) 00:28:49
>>896
> 君の思うカプセル化の「具体的な」定義を「箇条書きで」「厳密に」述べてくれ。話はそれからだ。

899 :デフォルトの名無しさん:2010/04/12(月) 00:32:33
カプセル化は壊してないだろ
よくわからん言い方やめろ
コンストラクタで渡そうが保持しようが
fooのprivateにはアクセスできん

あと、コンストラクタで保持するのが良くない理由は
コピーしてんのか、継承してんのかわからん
コード嫁ってのはなしな

混在してたら可読性下がる

900 :デフォルトの名無しさん:2010/04/12(月) 00:33:20
>>898
まあ、たくさんあるんだけど
とりあえず今浮かぶのは

少なくともシングルトンはNG
引数でポインタ渡してそれを保持するのもNG
グローバル関数呼んじゃうのもNG

まあ、後はその都度みつけ次第指摘

901 :デフォルトの名無しさん:2010/04/12(月) 00:34:34
>>899
バッカで
そしたらシングルトン使ったらなんでもできんじゃねーかよ
お前こそカプセル化の定義してみろよ

902 :デフォルトの名無しさん:2010/04/12(月) 00:36:28
ちょっと待て
シングルトンはOOPらしさを「敢えて」壊すために使うパターンだと思ってたのだが

903 :デフォルトの名無しさん:2010/04/12(月) 00:37:59
>>902
エピソードはどうでもいいけど駄目だ
使ったらあかん
これは問答無用だ
他にどんな使い方があろうと言葉出した時点で即NG
(俺の常識だとね)

904 :デフォルトの名無しさん:2010/04/12(月) 00:38:41
>>901
なんでもできない
シングルトンのライフタイムを制限する必要がある場合は特に

カプセル化はprivateだけ
継承時にprivateしようが、そこ書き換えるだけで崩壊するクラスが堅固とは言えん

905 :デフォルトの名無しさん:2010/04/12(月) 00:39:29
オブジェクト指向といえば継承(is-a)だと言われていたのが委譲(has-a)中心になってきたのは、
基本的には拡張性と柔軟性を確保するため。単一責任原則が教えるところでもある。

わりと分かりやすいところで言えばBridgeパターン。
継承を使って関連を定義すると、関連性の軸が2つ以上ある場合に、
新たな種類を増やすたびにクラス数がべき乗のオーダーで増えて爆発を起こしてしまう。
委譲を用いることで、こういったことをなくすことができる。

906 :デフォルトの名無しさん:2010/04/12(月) 00:41:01
>>900
>引数でポインタ渡してそれを保持するのもNG
これをコーディングルールにしてやってるんだったら
冗長でまわりくどいコードになると思うけどな。>>872がまわりくどいと思わないんだな。
シングルトンはほとんどの場合同意。
グローバル関数はグローバル変数・シングルトンがなければおれはokだね。

907 :デフォルトの名無しさん:2010/04/12(月) 00:42:30
>>906
まわりくどくないのと可読性はイコールじゃないだろ…
あくまでもお前の中だけじゃね?

908 :デフォルトの名無しさん:2010/04/12(月) 00:43:08
>>900
例ではなくちゃんと定義で言ってくれ。
君が思いついた例かどうかで、カプセル化かどうか判断されては全く議論にならん。

909 :デフォルトの名無しさん:2010/04/12(月) 00:43:54
>>906
>冗長でまわりくどいコードになると思うけどな。>>872がまわりくどいと思わないんだな。
ならないよ
だってfooは確実にあるもの
newしたところではあったのに他では滅多におめにかかれないって状況がそもそもない

まあ、記述がうざってぇってのならそうかもしれないけど
大きい問題じゃないな
むしろ、俺は「fooを使っているよ」っていう表現を重視したい
ちゃんとアクセス状況がわかるようにすることは大事だろ?

910 :デフォルトの名無しさん:2010/04/12(月) 00:44:42
俺オブジェクト指向を押し付けるリーダーの下の開発がまともに動くとは思えない。
俺カプセル化って誰に話しが通じるんだよ。

911 :デフォルトの名無しさん:2010/04/12(月) 00:45:27
>>908
お前以外はどうやらわかっているようなので別に答える義務はないかな?
なんのレスを返すのに俺からの情報がたりないの?

議論の本筋とはずれてないなら協力するけどあんまりくだらないことなら
遠慮したいね

912 :デフォルトの名無しさん:2010/04/12(月) 00:46:09
引数に明示するのも、しないのも、状況しだいじゃね?
知る必要がなければ、明示する必要もない。

つーかさ、「知る」っつー主体がどこなのか、誰なのか
かみ合って無い気がするんだがな。


913 :デフォルトの名無しさん:2010/04/12(月) 00:46:38
ここで分かれたな
回りくどいのが嫌いだから保持
明示したいから常に指定

俺は後者

914 :デフォルトの名無しさん:2010/04/12(月) 00:46:42
>>899
> あと、コンストラクタで保持するのが良くない理由は
> コピーしてんのか、継承してんのかわからん

それはおk。どちらにせよ、初期化の引数に出てくるオブジェクトは関連付けを意味する、
というのは一般的なコーディングルールと言って差し支えない。アンチ君が知らないだけで。

915 :デフォルトの名無しさん:2010/04/12(月) 00:48:19
>>911
俺を含めた、君以外の人間数人にはさっぱりのように見えるが。
というわけでよろしくな。まさか言えないわけじゃないだろ?

916 :デフォルトの名無しさん:2010/04/12(月) 00:48:30
>>912
>>877

917 :デフォルトの名無しさん:2010/04/12(月) 00:49:14
>>909
うんそれが自己満足なんだよ。
unko(foo)をすべてのコードに書いてかつ参照保持しないとコーディングルールにするのと
コンストラクタで渡したオブジェクトは保持されますってのをコーデングルールにするのとで
どっちがいいかで他人を押し切れるほど説得力がないんだよ。

918 :デフォルトの名無しさん:2010/04/12(月) 00:51:37
>>914
概念はそうだけど、「関係してる」の意味が複数あるからいってる
具体的に何やってんのか区別できないから分けた方が可読性は上がる
少ない行数ですっきり書きたいのは、あくまでもお前の好み

919 :デフォルトの名無しさん:2010/04/12(月) 00:52:41
>>913
new Hoge(Foo)(あるいはHoge.init(Foo)とかHoge.newInstance(Foo)でもいいが)は、
関連性の明示に入るかどうかってのもあるだろう。

これがOKかは、Hogeを初期化する場所と、Fooを初期化する場所があまりにも遠い、
かつFooがHogeまで旅してくる間に、どこかのコードが参照を保持して勝手に変更する
恐れがある、かどうかだろうな。

んで、そういう場合に当てはまるかは状況による。
例えば、DIコンテナを使ってるなら要らない心配だし。

920 :デフォルトの名無しさん:2010/04/12(月) 00:53:34
>>917
>コンストラクタで渡したオブジェクトは保持されますってのをコーデングルールにするのとで
これって微妙じゃね?
ドキュメントに色々書かなきゃいけなくなるよ
使うほうもドキュメントをたくさん眺めなきゃいけないし

Hogeにnewで渡して以降のfooの内容を変更しちゃってもいいの?
って疑問が残るし
多分、駄目なもんといいもんと混在してるっしょ?
俺はこういう疑問をもたせるようなプログラムをいいと思わないんだよね
また、fooの内容がどんなに変更されてもいいようにHogeをこさえること自体結構苦痛じゃね?w
引数で渡したほうがいいぜ〜
一応PG10年選手な俺の意見w

921 :デフォルトの名無しさん:2010/04/12(月) 00:54:12
>>913
>>833のOutputStreamはルール違反で取り締まるってこと?
それを説得する理由が
「参照保持しない」というコーディングルール上でfooのメソッド呼び出しが限定されるってことだよね。
そりゃ仕事での指示なら従うけど
「コンストラクタで渡したオブジェクトは保持されます」って
ルールのほうがシンプルなのに頭かたくね?めんどくさ。って思われると思うぞ。

922 :デフォルトの名無しさん:2010/04/12(月) 00:54:51
俺は900とは違うひとだが、彼の書き込みから予測するに
副作用の範囲を局所化し(俺カプセル化)、
副作用を伴うならそれを明示化しろ(引数で渡す)
ってところじゃないかな。

まあ、いわんとするところはわかるっていうか、かなり同意するが
彼の主張するカプセル化は通常のより意味が強すぎるような気がする。

って、想像で書いてるので全然ちがうかもしれんが。

923 :デフォルトの名無しさん:2010/04/12(月) 00:57:15
>>920
君が思い込んでるだけで
「コンストラクタで渡したオブジェクトは保持されます」
「あらゆる局面で参照保持は禁止します」
は大差ないぞ。少なくともデザパタのようなものが出回ってるこの世の中。
凝り固まった頭が下しか考えてないだけで。

924 :デフォルトの名無しさん:2010/04/12(月) 00:58:06
>>921
だからさ、処理が限定できないのよ
何でもコンストラクタは読みにくいじゃん

hoge.retain(new foo);

hoge(new foo);

で明らかに前者の方が分かりやすいだろ
何いってんの

925 :デフォルトの名無しさん:2010/04/12(月) 00:59:12
>>924
お前はなんで
「あらゆる局面で参照保持は禁止します」
の前提を隠すの?

926 :デフォルトの名無しさん:2010/04/12(月) 00:59:26
>>923
あらゆる局面じゃないよ
コンストラクタでだよ

927 :デフォルトの名無しさん:2010/04/12(月) 01:00:01
>>918
俺のイメージは、UMLクラス図で言うところの集約/コンポジションかな。
もちろん、関連付けの意図をドキュメントとして明示するのは大事。
一方で、初期化のパラメータを関連付けとして扱うことで、
呼び出し関係を調べることで機能の抱合関係を分析できるメリットもある。

928 :デフォルトの名無しさん:2010/04/12(月) 01:01:15
>>926
それじゃもっとひどいんだがw

929 :830:2010/04/12(月) 01:01:19
なんか色んな奴が混じってるけど
あらゆる局面でポインタ保持は>>830の俺だけな
いまからつけるけど(もう大体議論終わってるかw)w

930 :デフォルトの名無しさん:2010/04/12(月) 01:01:29
>>925
ああすまん
違う話だった

931 :830:2010/04/12(月) 01:04:03
間違えた

あらゆる局面でポインタ保持禁止

なw

932 :デフォルトの名無しさん:2010/04/12(月) 01:05:05
>>920
Fooのサービス、つまりそれぞれのメソッドがどんな動作をしてどんな結果を返すのか、
きちんと定義できていれば、大きな問題にならないと思うよ。
それを定義し確認するためのツールの一つとして、Javadocや単体テストを考える。

933 :デフォルトの名無しさん:2010/04/12(月) 01:06:21
>>924 は何でもコンストラクタの人に言った
すまん

934 :デフォルトの名無しさん:2010/04/12(月) 01:07:14
とりあえず設計がしっかりしてれば、知らんところで使用されることはないだろう。
後の突き詰めた部分は好み?

935 :デフォルトの名無しさん:2010/04/12(月) 01:08:14
俺ルールは守られるからドキュメント要らず!
俺ルールじゃないものは認めないからドキュメントすべてかけよ!
読まないからやっぱり文句言うけど。

936 :デフォルトの名無しさん:2010/04/12(月) 01:11:31
>>935
それこそ昨日のアンチOO君に紹介したapacheプロジェクトじゃないけど、
ある程度デファクトなベストプラクティスはあるし、それは取り入れていった方が良いと思うぞ。

もちろん、現場ごとにきちんと明文化するのは大事。

937 :デフォルトの名無しさん:2010/04/12(月) 01:13:22
ドキュメントは書いて欲しいね。

ベストプラクティスってさ、どういう意味でのベストプラクティス?

938 :デフォルトの名無しさん:2010/04/12(月) 01:14:47
すべて引数渡し君は>>833のOutputStreamも禁止なの?
そうとうな人たちの説得が必要そうだけど。

939 :デフォルトの名無しさん:2010/04/12(月) 01:14:49
>>931
ファクトリ関係や、明示された保持は?

940 :936:2010/04/12(月) 01:15:51
余談だが、ベストプラクティスを学問的に体系化した知として共有する意味では、
ソフトウェア工学は今のところあまり成功してないな。
人によってオブジェクト指向の何を強調するかが違う、なんてのも同根だろう。

こないだ、ソフトウェア工学を見直す、みたいな記事も出てたけど、もうちょっと何とかならないものか。

941 :デフォルトの名無しさん:2010/04/12(月) 01:17:00
>>937
それこそ、デザインパターンみたいなのとか。

942 :デフォルトの名無しさん:2010/04/12(月) 01:18:38
コンストラクタで保持するのは無しだろ
すごいテクニックがあるなら別だが

943 :デフォルトの名無しさん:2010/04/12(月) 01:18:55
おれはいまだXP信者なのでドキュメントはコードで伝わらないものだけにしたい。
でも何でも引数じゃないよ。

944 :デフォルトの名無しさん:2010/04/12(月) 01:19:14
>>941
デファクトスタンダードな認識の上で成り立つ
ベストプラクティスって事か

職業プログラマとしては、ある意味楽だろうなー

945 :デフォルトの名無しさん:2010/04/12(月) 01:20:00
>>944
共通認識できるのは強みだよね

946 :デフォルトの名無しさん:2010/04/12(月) 01:20:05
>>942
ダメなサンプルコードプリーズ
>>833のBufferedOutputStreamはなし?

947 :デフォルトの名無しさん:2010/04/12(月) 01:24:15
>>946
デコレータは便利だな確かに
でもコンストラクタじゃなくてもできる

ダメソースは昔、上司が勝手に継承拡張して
その拡張したクラスで、俺のクラスのコンストラクタ引数をマジックナンバー化したときのコード

948 :デフォルトの名無しさん:2010/04/12(月) 01:25:05
>>947
うんその議論はここ数日となんら関係ないなw

949 :デフォルトの名無しさん:2010/04/12(月) 01:25:17
>>945
作れる様な気もするけど…
プログラマー個々人が納得できるよう、
様々な状況下で、多面的に見た結果を示さなければ…

それに個人のポテンシャルも上げないとダメか。
精進します…

950 :デフォルトの名無しさん:2010/04/12(月) 01:27:48
>>948
関係ないな

前も言ったけど、コンストラクタで例外発生したらどうしてるの?
保持してるなら、fooの初期化(代入)もしてるんだよな

951 :デフォルトの名無しさん:2010/04/12(月) 01:29:38
ちなみに、ここ数日で来た人へ、「何でも引数」君の主張の変遷。

OOとか言ってる奴は糞!
⇒ OOは手続きで命令すべきハードウェアの論理に反してる!ウソでコードを書くOOは滅びるのが必然!
⇒ 「じゃあ仮想マシンって何。並列コンピューティングって何。」
⇒ OOの表現は、全て関数のみの手続きで書ける!obj1.method(obj2)とか何それキモい
⇒ 「それ、委譲で書けるよ。」
⇒ 委譲はカプセル化に反してる!関連性は毎回引数で渡せ! ← いまココ!

952 :デフォルトの名無しさん:2010/04/12(月) 01:29:44
>>950
参照って言ってるんだから初期化は外でやってるでしょ・・・
参照を保持するという初期化をしてるだけ

953 :デフォルトの名無しさん:2010/04/12(月) 01:31:16
>>952
hoge(new foo);
されたら死ねるんじゃ?

954 :デフォルトの名無しさん:2010/04/12(月) 01:32:22
>>953
それはHogeのコンストラクタを呼ぶ前に例外投げない?

955 :デフォルトの名無しさん:2010/04/12(月) 01:33:12
>>953
それ関係ない。
例外が発生するのは
hoge(new foo);とかかれているところであって
Hogeのコンストラクタ内部ではない。

956 :デフォルトの名無しさん:2010/04/12(月) 01:34:54
ん、それって構文エラーってこと?

957 :デフォルトの名無しさん:2010/04/12(月) 01:35:48
おまえもう黙って入門書読み返せって

958 :デフォルトの名無しさん:2010/04/12(月) 01:40:10
>>954
言い方が悪かった

無効な値の入ったfooを保持してしまった場合のこと
hogeを利用する全てに問題が波及しない?

959 :デフォルトの名無しさん:2010/04/12(月) 01:41:04
それは渡す側の責任でしょ

960 :デフォルトの名無しさん:2010/04/12(月) 01:43:47
>>959
確かにそうだけど、保持してるから問題責任がhogeに無いのに
エラー動作するっていやじゃない?

961 :デフォルトの名無しさん:2010/04/12(月) 01:44:29
>>959
それか、Hogeの初期化時にチェックしてIllegalArgumentExceptionを投げるかだな。

962 :デフォルトの名無しさん:2010/04/12(月) 01:45:53
>>961
コンストラクタで例外投げるか
好みの問題になるのか

963 :デフォルトの名無しさん:2010/04/12(月) 01:46:03
そもそも作れなかった時点でHogeに渡すのがおかしいし
Fooが必要なHogeが動作するはずがない。

964 :デフォルトの名無しさん:2010/04/12(月) 01:47:21
コードの大半がエラーチェックな気がする

965 :デフォルトの名無しさん:2010/04/12(月) 01:50:30
>>963
そもそもおかしい処理がかけちゃうのがさも正しいように書けるのがいやだって言ってる

966 :デフォルトの名無しさん:2010/04/12(月) 01:51:35
かけちゃうのが

消し忘れ
抜いて読んでください

967 :デフォルトの名無しさん:2010/04/12(月) 01:51:47
>>965
だからそれはHogeの外側の書き方の問題なんだよ。

968 :デフォルトの名無しさん:2010/04/12(月) 01:52:40
>>967
馬鹿がかけないようにするのも俺らの仕事じゃないか?

969 :デフォルトの名無しさん:2010/04/12(月) 01:53:44
>>965
findbugsとかの静的解析ツールを併用すれば、nullチェックしてないのとかは機械的に検出してくれるよ。

970 :デフォルトの名無しさん:2010/04/12(月) 01:53:53
>>968
この件に関してそんなことが可能なの?
一例を挙げてみてくれ

971 :デフォルトの名無しさん:2010/04/12(月) 01:56:41
>>969
なるほど

templateとマクロ使ったらコンパイルエラーに出来るよ
javaはゴメンなさいしとく

972 :デフォルトの名無しさん:2010/04/12(月) 02:04:43
簡単に書くなら

hoge::hoge(foo& a)
{ foo_ = check<foo>(a); }

みたいな感じで

973 :デフォルトの名無しさん:2010/04/12(月) 08:08:02
静的なチェックにこだわりすぎるのはどうかと思うけどな
オブジェクト指向は基本動的が有利な世界だし

974 :デフォルトの名無しさん:2010/04/12(月) 13:52:37
メソッド呼出し毎にFooのインスタンスを渡すんじゃ、
呼び出し側でFooのインスタンスを管理しなければならないじゃないか。

それに、メソッド呼出し毎に別のインスタンスを渡すことも出来てしまう。


975 :デフォルトの名無しさん:2010/04/12(月) 14:07:03
だな。
FooだけでなくBar, Bazのインスタンスも引数で渡すなどというのなら、
使う側は
hoge, foo, bar, bazのインスタンス群をまとめて管理しないといけない。

976 :デフォルトの名無しさん:2010/04/12(月) 14:30:10
そもそもhogeにfooを管理させるつもりなら、hoge内で生成したらよくね

静的チェックもオブジェクト指向なんだがね

977 :デフォルトの名無しさん:2010/04/12(月) 19:16:17
>>976
拡張性を犠牲にするならそれも一つの選択肢。

978 :デフォルトの名無しさん:2010/04/12(月) 19:39:44
>>977
拡張性って云うけど、堅牢さを犠牲にするものなの?
トレードオフ?

979 :デフォルトの名無しさん:2010/04/12(月) 19:59:52
>>978
堅牢さを追求するのは良いけど、変化に対する柔軟性が犠牲になるならよく考えるべき。
また、Fooのインタフェースをきちんと設計すれば、問題は軽減できる。

980 :デフォルトの名無しさん:2010/04/12(月) 20:16:44
>>979
バグを広げるようなクラスを作っておいて
拡張性と言われても納得できないもの

981 :デフォルトの名無しさん:2010/04/12(月) 20:19:40
極端な話便利だからグローバル変数しましたと言ってるようなもんだな。

982 :デフォルトの名無しさん:2010/04/12(月) 20:25:10
>>980
で、具体的に、どこにバグがあるわけ?
夢の世界で見えないコードをデバッグしちゃう人?

983 :デフォルトの名無しさん:2010/04/12(月) 20:38:42
>>976
そうやって拡大解釈するのはやめろよ
どんどんオブジェクト指向がバズワード化していく

984 :デフォルトの名無しさん:2010/04/12(月) 21:06:05
>>980
その理屈だと、動的結合は全てバグの源だから許されない、ということになるんだが。

それに、バグを広げるというが、各オブジェクトの責務を最小限に留める設計とすれば、
単体テストを行いやすくなり、結果的に品質は向上する。

985 :デフォルトの名無しさん:2010/04/12(月) 21:24:11
インターフェースから得る値(引数、返り値)は、
エラーチェックにかけるもんじゃないの?

986 :デフォルトの名無しさん:2010/04/12(月) 22:57:01
プログラマーの99%は無能

987 :デフォルトの名無しさん:2010/04/13(火) 00:48:42
>>984
結合が悪とは言ってない
fooを利用するなら保持しなくてもいいし
何故(使い方によっては)バグをわざわざ出やすくする書き方を推奨してるのかが理解できないだけ
皆が使ってるから、なんて理屈はやめてくれよ

回避策なんてたくさんあるだろうけど
そもそもこのような設計にしなければ、簡単に責任をfooに押し付けることが出来る
何で遠回りなことしてるのよ

988 :デフォルトの名無しさん:2010/04/13(火) 00:51:52
>>982
それもプログラマの仕事でしょ
経験豊かなプログラム設計者は、
このやり方はこの場合破綻する、という結末をたくさん知っているもの

989 :デフォルトの名無しさん:2010/04/13(火) 02:31:30
秒1000個データをとばす外部装置があって, こいつが 1000 個ぶら下がってるとする
で, このデータを秒単位でまとめたものを a, 分単位でまとめたものを b
ちゃんと1日単位とか週単位とかでもまとめる, c とか d とか ...

まとめるためには一つ下の単位の計算結果をを使って, 計数は異なるけどほぼ同様の計算を行う

おまえらだったら, この処理どう扱う?


990 :デフォルトの名無しさん:2010/04/13(火) 04:48:40
>>988
いいから、具体的なバグを示せっての。バグがもう既に入っているんだろ?

991 :デフォルトの名無しさん:2010/04/13(火) 08:05:30
経験豊かなプログラム設計者(キリリッ

992 :デフォルトの名無しさん:2010/04/13(火) 08:19:42
>>987
何度も何度も指摘されてるが、Fooインスタンスを毎回メソッド引数として渡しても、
fooが不正なら問題は全く変わらない。
むしろ、初期化の段階でHogeに閉じ込めておけば、Hogeを利用してコードを書くプログラマが
Fooに触るチャンスを無くすことができて、むしろ安全性は大きく向上するぞ?

また、グローバル変数と同じだからダメとも言っていたが、クラスのフィールドの場合は、
影響範囲が一つのインスタンス内に完全に限定できるという点は無視?

993 :デフォルトの名無しさん:2010/04/13(火) 11:40:53
>>992
そうだよ、問題は変わらない
そこを言ってるのではなくて
問題をhogeに波及させてること

いや、fooへのポインタが他所にあるかなんてhogeは知らないわけで
fooを閉じ込めたかどうかなんてわからないだろ
チャンスは(ほんの少し)減るだけであって
なんで無くなるのよ
無くしたいなら生成からhogeに閉じ込めておけばいいだろ

あとポインタ保持だとインスタンスに限定できない
newがオーバーロードされてたりすれば複数になる

994 :デフォルトの名無しさん:2010/04/13(火) 11:52:24
すまん、解釈間違った

hogeだけを利用したい場合は確かに安全だ
でも、hoge内で生成しても効果は変わらない

fooを利用するだけでなく、fooの状態の操作をhoge内で行っているなら
隠してしまうと、fooしか扱ってない箇所で困ると思うのだが

995 :デフォルトの名無しさん:2010/04/13(火) 12:00:35
そうだな、値の取得のみのインターフェースクラスへfooをキャストして保持するなら賛成

996 :デフォルトの名無しさん:2010/04/13(火) 12:12:02
>>995
内部構造の話になったからお前の負けな

997 :デフォルトの名無しさん:2010/04/13(火) 22:41:45
えーと、俺は一週間ぐらい前にOOPを否定していた子だけど、
一週間ぐらい仕事が忙しくて2chどころじゃなかった。
で、久しぶりにスレ開いてみたら、255スレも伸びてるのな。
こんなくだらない話題で何故か盛り上がっちゃうのがOOPなのな。
傍らか見てると、どちらがより上手くウソをつけるか競い合ってるように見える。
難しく考える必要は無いと思うよ。
俺が散々言ってる、
「プログラムの機能は『制御でデータ間の関係を定義する』ことで成り立つ」
ってのを念頭に置いとけば、OOPも上手く使えるだろうし、
テキトーなこと言う奴に翻弄されることもなくなるだろうよ。

998 :デフォルトの名無しさん:2010/04/13(火) 23:07:42
問題は実際の大規模開発でどれだけ有効か。
思い込みも含めて。

999 :デフォルトの名無しさん:2010/04/13(火) 23:08:48
もう一度書いとくけど、
OOP使うなら、データの整合性を取ることのみに使う、
つまり、メソッドはセッターとゲッターのみ、
つまり、構造体++な使い方、
が望ましいと思うよ。救われたいならな。
事実、コンテナとか文字列クラスとか、やたら上手く機能しているだろ?
そこが使いどころ。

1000 :デフォルトの名無しさん:2010/04/13(火) 23:37:24
我を信じる者は救われる、偽救世主に惑わされるな、ってか。

まぁ、誰が真の救世主かは、ログを読んだ人が自分で判断すると良い。
正解を引けるかは、それも自分の実力のうちだ。

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

302 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)