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

何が見えてるんですか？

アイちゃんはそんな難しいこと気にしなくていいんだよ

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

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

また新しいオブジェクト指向が広がるだけだよ。

未来

オブイェクト指向

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

>6
46サンチか88かそれが問題だ

Javaの先には何も見えない

>Javaの先には何も見えない
節穴じゃなかろうか？

空っぽのスパゲッティ

マジレスすると、Ｃ＋＋のようなマルチパラダイム言語
すべてをオブジェクト指向でやろうとするＪａｖａは気持ち悪すぎ

>>11
なんでもじゃないだろ
プリミティブな変数が残ってる時点でうんこ

じゃあ、Rubyがいいの？

このあたりでSmalltalk原理主義者とLisp原理主義者登場

細胞指向が登場します。

棟方志功

２１００年頃には人間指向プログラミング言語（NOPL）が台頭しはじめる。
これは当時普及していたC↑が仕様を拡大しすぎたため、
プログラミング言語にヒトへの優しさを取り戻すことを謳って提唱された。

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

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

"hello, world.";

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

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

TextEditApp app;

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

オブジェクト指向でも不足で、もっと、というとこれかな

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

オブジェクト爪向

且つ分散型

至高のオブジェクト

JAVAはC++が使いにくすぎだから
使いやすいように整理しただけの言語
JAVAが凄いなら、C++はその2倍

ウェルベール指向(←多分だれもわからない)

>>17
ただのシェルスクリプトやん

オブジェクト指向なんて所詮一時的な暇つぶしに過ぎない。
小学生でも綺麗なコードを書ける指向が次の志向。

>>23
知ってるベル
とでも反応すればいいのか?

>>25
自分に解らないものは全部「汚い」で済ませるのか。

初恋指向

玄人指向

VBだったり

シコシコウ

あらゆる現場で開発本題そっちのけでオブジェクト指向にはまって
文明終了

オブジェクト指向

はい、ここまでエージェント指向無しｗ

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

うんこー

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

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

例外を出してくれるならいいが得体の知れてる外国籍の
特定団体にdelegateしかねないから実装は計画的に

Smalltalkの生みの親であるアラン・ケイの予測：

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

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

今何年だよ

オブジェクト指向より棟方志功のほうが好き

劇団ひとり乙

憧れのアーキテクトに会いに行こうぜ
待ってる。
http://www.microsoft.com/japan/msdn/vstudio/events/agileseminar.aspx

経済危機を脱する処方箋はすでに解っている。量的緩和だ。
なのに日銀はかたくなにその実行を拒否している何故か？

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

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

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

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

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

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

>>43
>不況を脱出する政策もすでに解っている。給付金だ。
>（ただし額が足りない。今の100倍は必要。それを毎年やることだ）

荒唐無稽にもほどがある

あぼーん

　　　　　　　　　　　 ＿＿ 　‐ ''"￣￣ ｀ﾞ' ..、
.　　　　　　　　　　　|　.　／　: : : : : : : : : : : : :.' ,
　　　　　　　　　　≠　／ : : : : : : : : : : : : : : : : : ∨ﾞ＼
　　　　　　　　　　| _ｲ. ／: : : :/ ﾊ: :、: ､: : ､: : r‐┴| く
　　　　　　　　　イ:/: /: /:/:Χ./ .}: 八:.|::!:.:.|: : !　　:| .ﾉ
　　　　　　　　　{:::{: /:|/ﾚ|ｨ心≧ |/ .ィﾅ什ﾉ: : Ｌ...ノｲ.､
.　　　　　　　　／／|',::::（,| .ﾋ::ﾘﾞ. ′　匕:::ﾘﾚ∨: : |＼冫
　 　　　　　　/／::ﾊ: : : : :', :::::::　　 　 ｀'-'ﾞ　:: ﾊ:.: レｲ S（そんな）O（オカルト）A（ありえません）！
　　　　　　 ／　: ﾉ ∨: : : ﾍ　　　__ 　 ::::::　,≠ヽ',: : ::ﾄ、
　　　　　,./: : : :/._,.-∨: ::＿丶　 _　.　　イ 　　　∨: :.!: ＼
.　　　 , '＞.-‐''二＞''.´＼　,.二つ￣￣￣二＞. 　',: :',: : : :＼
　　　く 　　　く//__.ﾊ .i＼.ヾ{_:_: : :＿ : : :＿_ミ､__ 　ﾏ: :ヾ､: : ::ゝ
.　　,'　.＼　　.{|::|─､U　（/ﾞ .二⊃|ヽ＼　 {:::::::|:|.､ 　ﾏ:..'., ヽ: : : : :＞ー　- ､
　 　　　{ .＼_.＞‐ "　￣￣ﾞ´!.: :: :.∨＼＼|:::::::|:}. ',.　 ',: :..'., 　 × : : : : : : : : :ヾ
　　　　 ∨: : ├──.!　 ／ 　 　　　マ::::::┐::://::k.}　 ﾏ: :...'.,　　　　 　￣　ヾ´
.　　　　　∨: : ＼.　　|.Ｙ. 　　　　　　　ヾ.__{_/彡Χ　　　',: : : .'.,
.　　　　　　マ: : : :ー┤| ,'　　　　　　　 　∨ﾞ|　　　＼　　∨: : : :＼　
　　　　　　 　＼＿ イ! | :　　　　　　　　 　∨､　 　 　＼ 　' ,: : : : .:＼
　　　　　　　　　　　　∨.',　　　　　　　　　　}::::ヽ　 　 　 ∨ .＼: : : : ヾ
.　　　　　　　　　　　　 ∨.' ,　　　　　/　,'　ﾉ.::::::::.＼ 　　:ﾉ 　 　＼: : :::

>>44
いや案外荒唐無稽とも言えない

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

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

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

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

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

派遣切り

Lispは良い言語だ。

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

アスペクトって限られたヤツだけ使うべきだよな
あるメソッド呼んだ時に副作用ある処理が勝手に呼ばれたとか
ヘボが組むと結構悲惨な事態になる予感。

アスペクトって言うと難しく聞こえるけど、要はアスベストのこと

アスベスト渦がオブジェクトの世界にまで
広がっていたとは…

アスペクト指向でうまくいった例って、
セミナー屋のインチキ講師以外にあるのか？

アスペクト指向の元が腐ってると

えらいめにあうがアスペクト指向をありがたがるです

高度なツールほど、馬鹿には使いこなせない。

馬鹿が使うと

高度なツールほど、馬鹿でも使えるようになっている。

高度なツールほど、賢い奴には使いづらい

オブジェクト指向の先？今のトレンドだと、関数型じゃない？

ここ数年で関数型界隈で何か画期的な進展があったかというと、何もない。
単にヤマ師が「次は関数型の時代」とわめいているだけで、
中の人達は、みんなさめてるよ。

C#は関数型になりつつあるけど

それって何てF#？

何もないといえば何もないが
そもそもC言語のようなものがなぜ広まったかというと

なぜ広まったかというと

OSを記述するための…ってのが、なんかあれだったんじゃないの
Web用言語として売り出したphpとかも
あれだけどあれじゃないか

つまり共通項は何かに特化してるってこと
特定の分野をこなす最適解だと
半端な言語はいらねえってことだ

http://pc12.2ch.net/test/read.cgi/tech/1248205502/

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

そこでメタ言語だろ。

マクロとかテンプレートとか

うちの会社に使用書からCOBOLを吐き出すツールがあるけど、
そのうち他の言語でも当たり前になるんだろうな。
(モックレベルじゃなくて即本番稼働できるレベル)

UMLからC++のクラス定義を吐き出すレベルじゃなくて
もっとすごいの？

だからモックじゃねなくて即本番稼動って書いてるだろ

>>72
てことはプログラマいらないってことだよね。
仕事で、作りたくもないプログラム組まされる苦労がなくなるのはいいことかも。
言語のことで悩まなくてもいいし,仕様変わってもすぐ対応できる。
つまりオブジェクト指向の次に来るのは「仕様書→ソースジェネレータ」てことか？

それ、なんて４ＧＬ？

>>75
既にそうなってるフレームワークはいくつかあるぞ

クラウドに決まってるだろ
そんなことも分からないから、日本のITプログラマは馬鹿にされるんだろ

sage も分からん馬鹿は黙ってろ

http://www.jma-net.go.jp/sat/data/web/suneclipse_img/mtsat2_20090722_0900-1400_enhanced.gif

コピペ君って馬鹿だな、まで読んだ。

クラウド（笑）

ITプログラマってｗ

     　/　　　　/　　/　　　/　　/　　　/　　　　　/
    　　　　　　　 ＿_,____
    　　　/.　　／// |ヽヽ＼ 　　　/　　/　　/
    　　　　　　^^^^^.|^^^^^^
    .　/　　/ 　 ∧__∧
    　　　　　　( ´・ω・)∧∧
    　/　　　　 /⌒ ,つ⌒ヽ) 　 //　　/　　/
    　　　 　 　(___　 (　　__)
    "''"" "'゛''` '゛ ゛゜'　'''　''　'''　゜`　゛　゜ ゛''`
    もし、またメール送っても嫌いにならないでね。

ITプログラマってすげーぞおいｗ

よし、明日からは「俺はITプログラマだ」って言うよｗ

オブジェクト指向を理解するのならば、
下記が良書だな
↓
http://www.amazon.co.jp/exec/obidos/ASIN/4798104183/randokubunkok-22

エクセルのマクロみたいに、やりたいことを行動で教えるプログラミングが好き。
ソースが見えるから修正も楽だし。

>>88
そんなあなたにwsh

>>87
今さらオブジェクト指向を学ぶなんて歴史的価値しかないけどな
はじめからλ計算をベースにしておけばよかったものを、
人類は無知のために横道にそれた時期がありました、という歴史

ITプログラマ吹いた
なんでこんなのがム板に紛れ込んでるんだろ

>>90
それじゃあまるでOOPとλ計算が同じ用途で、排他的な関係みたいじゃない
両者は全く別物であって、排他的でも何でもないんだが

>>90
まったくもってその通りだな。

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

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

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

>>93
そうなったらきっと、モダンな構文のCLOSが誕生したんだろうな。それだけ。

Dylanはなかったことですかそうですか。

オブジェクト指向の言語なんて所詮、
　なんかこうしたらうまくいくかも
っていうフィーリングで作られてる
しかも未だにオブジェクト指向とは何かみたいな馬鹿げた議論をしている

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

この差は歴然www

Ｃ言語が最高傑作だな
Ｃ＋＋はただの改悪で終わった希ガス
導入したもんがすべて〜かもしれない〜っぽくね？の域を出られないとか
ホント落ちたもんだよな＞言語開発者

C言語→NULLあり、破壊的代入のみ、キャストあり、ガベコレ無し
どこがどう最高傑作？

そうだ、忘れてた、多相型すらないわ＞C言語

オブジェクト指向は構造化されたスパゲッティ

>>96
>しかも未だにオブジェクト指向とは何かみたいな馬鹿げた議論をしている
馬鹿げた、っつーか、未だに理解できてない馬鹿だからこそ
議論 (の余地なんかないが) してるだけ。

という議論が繰り返されるわりには誰もメリットいえないよね？
メリットっぽいのだしてもそれが本当にメリットかどうか判断できない内容ばっかり

君自身が判断できないってだけじゃないのか？

OOみたいな古典をいまだに最先端だと思いこんでる奴も少なくないのが現実

>>98
はガベコレ環境であるがゆえの悩みを持ったことがないんだろう。
GCを働かせたくないから、ヒープを使わないように書き換えていくような作業を。

オブジェクト指向プログラミングを理解できてる奴なんていないよ

誰も彼もがオブジェクト指向とは何か、という事を適当に書き散らしてるからか
最近ゲシュタルト崩壊気味になってきた

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

>>98
C言語は高級言語とアセンブリの中間の言語としてはかなりのものだと思う
アセンブリや高級言語として見ると非力な感じはするけどな

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

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

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

>>105
どんな状況になったら、そんな苦行をしなきゃいけなくなるの？
単純に興味深いわ

オブジェクト指向よりか関数型だとか言ってる奴がいるが、
そのトレンドの変化は単純にここ数年の計算機の適用領域が変わってるだけなんだよ。

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

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

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

いまだにオブジェクト指向とか言ってるやつが化石に見えるのは俺だけだろうか・・・ｗ
これからは関数型言語だ！とか言ってるやつが原始人に見えるのは俺だけだろうか・・・ｗ

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

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

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

>>109
DylanはＳ式抜きのCLOSだよ。

>>114
> あんな破壊的状態変化を管理しろってのが無理難題
> functional styleでGUI作る利点に早く気づくといいよ

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

しかしFRPはまだ発展途上

>>110
C#で60FPSのゲーム。
GCが動くと性能がガタ落ちするので、
スタックオブジェクトを効率的に使っていく必要がある。

>>113
だって、オブジェクト指向のオブジェクトってぜんぜんオブジェクト的じゃないじゃん。
あるオブジェクトを見ているとき、別のオブジェクトは時間が止まったみたいになってるし。

>>118
60FPSのゲームをC#で！
逆にGCを必死で抑えると60FPSが実現できるんだ
そっちの方が驚き
お疲れさまです

>>116
>ただ、管理する方法が変わるだけ。
そう、ただ管理する方法が変わるだけ
その方法が変わることによって、
人間がかけなければならない手間と注意の量はずいぶん変わるけどね

>>121
そのうえで、オブジェクト指向より関数型を推す理由ある？
俺はGUIはオブジェクト指向で考えたほうがわかりやすいと思ってるんだが。
関数型はGUIに向かん。

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

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

RxはC#で使えるでしょ
関数型ならではというのはおかしいんじゃない

どうでもいいけど、なんで「指向」と「型」を比較してんの？

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

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

たぶん誤解している人もいるかもしれないので補足しておくと
関数型の言語
ではなくて
関数と型理論の言語
という意味なんでよろしく

>>122
変わらないだろ
クラスは構造体と違ってインスタンスのコピーが気軽にできないだけ不便になったってのならあるけどな

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

>>126
>一応、何かそんな話はどっかのページかスレで見たけど、GUIでイベント合成すると何がうれしいのか俺の脳では分からなかった。
なんとも残念な感じ
例えばこれのイントロとか読むと分かり易いんだが
www.cs.brown.edu/~greg/thesis.pdf

ああ・・・一般人＋αレベルの2chのム板の「オブジェクト指向の先には一体何があるんですか？」
なんていうタイトルのスレに英語の論文晒してもまじめに読む奴がいるわけないのは
常識的にわかるだろうに・・・
英語なんて生活の一部だぜかっこいいだろ、とか
英語の論文晒しとけば反論できないだろ、とか
晒し主の心情がわかる今日この頃ですが・・・
ここは日本語でおｋと返すのが2ch流ですかね

>>131
日本語だとあんまり無いのよね
ttp://igeta.cocolog-nifty.com/blog/2009/01/reactive.html

イベントキューの上のレイヤーにリアクティブな高階関数のセットを提供
イベントキューを遅延評価のリストに見立てるとリスト処理のボキャブラリがそのまま使えて便利です
宣言的な記述がやっぱいいです
という話なのかな
結構いいかも

仮に関数型言語でGUIを扱うのがオブジェクト指向より便利だとするなら、
なぜ関数型言語界隈でオブジェクト指向ＧＵＩライブラリラッパーがまかり通っているんだ。

流行だろ

オブジェクト指向の代替として今注目されているのがプロセス指向だろ。

今？注目されてるの？どこで？

>>130
んー、英語の方も日本語の方も読んでみた。
便利＆考えることが減る気もするけど、そうでもない気もする。

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

手続き型言語でジェネリックプログラミングしてるなら非純粋関数型言語は
単にジェネリックな実装を簡潔に記述できるという程度の認識でいい気がする
C++でbindとか使いまくってるなら大差ない。

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

だから両方同時に使えば良いじゃない

イベント合成できるのは関数型だけと思ってる能天気…

そもそもイベント駆動とGUIは本来別々だっての。
イベント処理の記述や合成が簡単にできるということと、
GUIを容易に構成できるということは全然別問題だろ。

>>138
>ボタン押したら無意味に派手なアニメーションをさせるようなGUI(Appleみたいな)と相性が悪い気がする。
functional reactive animationでぐぐってみるといいよ

SmalltalkやXのイベント駆動がアタリすぎて、
今だにGUI＝イベント処理という妄想がまかり通ってるらしい。

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

>>144
誰がそんな主張をしてるの？何番のレス？

ゴネたところで、
GUIに一番向いているのは関数型だという根拠として
イベント処理しか出てきていないということは、
イベント処理さえできればGUIは全てＯＫという前提だろ。

>>131
自分の言葉で説明できない奴はどの世界にいても絶対に認められることはないよね
それがどんなに正しい主張をしていようとも絶対だ

上っ面でしか説明できないならマ板でやればいいと思うんだ。

関数型言語は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

GUIで一番大切なのはペタペタがやりやすいかどうかだろｗｗｗｗ

関数型言語でも線分や四角形が簡単に書けるから、
GUIに最適な言語は関数型だと？

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

つうか画面表示自体が、関数型の考え方でいくと副作用だろ。
その時点で副作用ガンガン使うGUIみたいなアプリを関数型の方が扱いやすいって主張は受け入れがたいんだよ。

は？意味わかんね
結局落ちてきたメッセージをどう処理するかでしかないのに
わざわざクラスにしておく必要を感じない
微妙なことやると確実にメッセージ飛ばしたりガメたりもう画面単位でどうせ完結できないのに
無理やりクラスにしたところで意味が感じられない

結局、関数型でGUIをつくるのが簡単だと言ってる人は、
自分ではGUI部品やCGライブラリをつくらずに、
ただ単にイベント処理をつなげるだけでGUIをつくったつもり
になっている人でしかないということ。
HaskellにもGUI toolkitあるけど、ライブラリのソースは
関数型として美しいとは到底言えないシロモノ。

現実、win32apiをはじめとしてほとんどメッセージの受け渡しで動いてる限りそんなもんじゃね？

土方にとっては、そんなもんだろうな。

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

すごいすごい
よくまとまった記事がアップされてる
ttp://d.hatena.ne.jp/maoe/20100109/1263059731
これを読むといいと思う

>>157
自分の言葉で説明する気がねーならわざわざレスするなよクズ

>>159
俺は157ではないが、自分の言葉で説明したら1000レス楽勝で埋まると思うが。

俺らが知りたいのは名無しの誰かさんの有能さを証明することじゃなくて、
新しい技術への知識だろ。
履き違えるな。

勝手に俺らって括るなよ
俺は名無しの誰かさんの有能さを証明することなんだよ

>>162
だったらスレ違いだ。
マ板に池。

関数型は型にはまった事以外をやるとしんどい
まるで書き方を強制されてる気分になる
オ略向は酒飲んでても組める

>>160
許可する
1000レス埋めてくれ

結局マルチパラダイム言語Lisp最強という結論に・・・

>>159
自分の言葉かぁ
私が2chに書きちらすより、リンク先を読む方が100倍分かり易くてためになるとおもうけど？
万一参考になるなら読んでくだされ

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

>>167
まず何を言いたいのか結論からかけよ
それで詳細をたずねられたらはじめて詳細を答えるように練習しろ
そんなに長い文章になること事態おかしいんだよ

人と話さないでひきこもって独りよがりなプログラムばっかり組んでるから
掲示板のレスもそうやって聞き手を意識できない

この下手糞が

>>167
判りやすいから続けてくれ。
168-9みたいな中身スカスカは無視してよし。

>>159で
>自分の言葉で説明する気がねーならわざわざレスするなよクズ
自分の言葉による説明を求めているのに
>>168で
説明は要らん。結論だけ言え
とかどうすりゃいいのｗ

結論から言うと、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!といった破壊的代入を利用せずとも
常にクリックされた回数が入り込みます
（続く?）

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

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

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

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

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

よく判ってないけど、副作用が起きるのは諦めて、
入力を入れ替え続けると解釈することで矛盾の無い形で
実現してみましたって感じ？
CPSで関数が戻らないことを利用して関数の引数を更新し続けるような。

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

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

>>172
>結論から言うと、FRPの仕組みを使えば、関数型言語でもGUIは綺麗にかけますし、
>今まで以上に簡単になります
はい、しゃべりすぎはじめの２行から君の話って意味ないんです
聞いておくけどFRPとかいうのを使わなかったら関数型言語だとGUIは綺麗にかけないっていってるのね？

俺からみるとあんまりGUI関係ないんだよね。FRPの仕組みの利点も。

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

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

オブジェクト指向の先には関数型言語があるでFA?

どうしてそれがFAになるんだ。

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

先の先の先は自然言語だけどね。その手前に論理型が来るのかな。

>>1
マイクで、ハローコンピュータとか言うと
勝手にプログラムしてくれるようになるんじゃなかったのか？

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

んなもん少なくとも俺らが生きているうちは無理だろ
次元が違いすぎる

最近のグーグルとか見ていると
結構、言葉の解釈はしているじゃん。

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

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

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

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

脳波キーボードは早期に実現して貰いたい

>>186
> 意味と意図は別でしょ。

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

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

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

人間の発言にはたいてい膨大な前提条件や考え自体の矛盾があるから、
結局コンピューターからものすごい量の質問される事になって実用化は難しそうだと思う。

>>189
そこはライフログで自動的に属性を判断しましょうって事でしょ。
あとは力技で、

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

>>188
それが「プログラミング」なんだけどね
ビットの並びに意味付けするというのが本質

そうそう、意味をビットに落とす。
それを簡単にしたい->プログラミング言語とかで。

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

機械が人類を抹殺する時代が早くやってきてほしい

>>191
うーん、そういう風に言ったら、いつまででもプログラミングしている
という事になっちゃうので、ここでの議論とは合致しないと思う。

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

>>195
んー？
どういう立場で喋ってる？そりゃオムレツのレシピがプログラム済であるということでしかないのはプログラム経験あればわかるよね

セマンティックウェブってあれは８０年代のlispでやってたようなAI技術そのまんまでびっくりしたわ

温故知新

>>196
卵など個々の材料の意味づけと
オムライスのレシピから
セマンティックウェブで
コンピュータが推測して
オムレツを作っちゃうようなイメージ。

>>199
卵など個々の材料の意味づけ＝プロパティ設定
オムライスのレシピ＝焼き方メソッド
オムライスとオムレツは継承関係、みたいなことを指示すると言ってんじゃないのそれは

>>199
レシピのコーパスがライブラリ
「オムレツつくって」がmain関数

何も新しいことはない。

また、たとえ話か
そのたとえ話が適切かどうか誰が証明してくれんだろな

オムライスとかオムレツとか、たとえが混乱して悪いんだけど

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

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

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

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

>>203
> 考えて部品を増減したり

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

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

どういう立場で？と聞いたのは、意味を理解できるコンピュータがあったなら、というとこで喋るのか、
「意味を理解させる」というのは突き詰めれば条件分岐であるというとこまで踏み込んで喋るのかということなんだけど
前者みたいね
それだとなんとも言いようがない

「卵のふわふわしたフライパンで作るおいしいやつ！」って
”俺”が言えばオムレツが出てきて
”オムライス嫌い”の奴が言えば卵焼きが出てくる
ってのは、やっぱり難しいと思うな。

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

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

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

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

オブイェークト指向

>>205
> 条件分岐であるというとこまで

それはおかしいよ。

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

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

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

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

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

しらけてるというか、陳腐だなあということなんだけど

陳腐とか言われちゃったよｗ

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

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

そりゃあんた意味を理解するコンピュータがあって
会社名入れたらプログラム出てくるといいねと言われたってそれ以外どう言いようがあるんだよｗ
さようならｗ

ただの妄想の話でそこまで熱くならんでも

少し上の方で自然言語でプログラミングの話あったでしょ。
あれって自然言語の文法を借りて、語彙も制限して使う話で、
コンピュータがなんでも理解できるという意味ではない。

少し上の方で自然言語でプログラミングの話あったでしょ。
あれって自然言語の文法を借りて、語彙も制限して使う話で、
コンピュータがなんでも理解できるという意味ではない。

ちょっと気の利いたDSLレベルのものしか作れなさそうだ。
自然言語は複雑な問題を簡潔に記述するのに向いた文法とは思えない。

>>215
25年以上も後の話でDSLはないだろ。

その時代には、プログラミングの対象はコンピュータというより
ロボットだと思うけど、それでも自然言語でいけるようになるのかな？

漫画みたいな人工知能は実現不可能だって結論出ただろ

ロボットがどうして漫画みたいな人工知能ということになるんだい
動き回るコンピュータ = ロボット ではないのかな？

>>219
適切な時機にアームを制御できるだけでロボットだね。

>>219
それが俺たちの望んでいるロボット像かってことだよ。
今ロボット関係の研究しているやつらなんてほとんどが
漫画みたいなロボットに憧れてロボット作ってるわけで。

ガンダムは作れるけどバルキリーはさすがに無理

俺はガンダムより最終形態の天元突破グレンラガンがほしい

デカイだけでダサイメカは嫌い
モスピーダなんてホンダがホントに作りそうじゃないか

>>217
自然言語は非オブジェクト指向的体系の代表だから、
オブジェクト指向的なロボティクスの動作記述に適していないんじゃないのと
いう疑問と解釈していいのかな。

>>225
25年とかそれ以上の先のことでしょ。現在だって、
情報家電のユーザインターフェイスにオブジェクト指向なんて
持ってきたらそれだけでアウトですよ。

てか家電の場合は全体が１つのオブジェクト

利用者が打ち込むコマンドレベルの話だろ。

利用者のコマンドとしてのOOねぇ…右クリックメニューみたいな感じ？

Googleが開発したGoっていう言語のオブジェクト指向が凄いらしい。
オブジェクト指向の良い部分だけを取り入れたハイブリッドな思考
は今後の主流になるかな？

よく分からんのだが、オブジェクト指向の良くない部分てなに

>>231
意味がないところ
別にオブジェクト単位にしたところで工数など１ｈたりとも減らすことはできない

>>230
対象物をすべてオブジェクトって概念で抽象化しようとするのに無理があるところｗ

とりあえず、仕様を記述するための規格化された優秀な言語が欲しいな。
実装は後回しでもいいから、人間の意図の表現とプログラミング言語の間を埋める、
表現の手段が欲しい。

Prologじゃだめなの？

>>232-233が何か重大な勘違いをしている気がする件。

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

>>236
じゃあ、なんのためにやるの？
成果を数字で表してくんない？

>>237
なかなかきちんとまとまった説明はないけど、例えばこれとか参考になるんじゃないかな。
http://itpro.nikkeibp.co.jp/article/COLUMN/20060921/248617/

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

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

>>237
まぁ、グローバル変数をオブジェクトに押し込んでみました、ってだけの技術やからね…
成果なんて出ないと思うよ

>>239が何を言っているのか分からない

わかんないんです（＞＜）

>>238
結局、何が言いたいのかまったくわからない
自分の言葉で単刀直入に結論から言ってよ

>>242
俺の理解では、

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

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

>>243
つまり数字ではでてこないのね
気がするだけレベルなのがな

>>244
どういう種類の数字？

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

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

>>245
>仕様変更に伴う工数も大幅に短縮できるはずだが。
だったら数字をだせよ

>>245
逆に考えよう
それが自分のただの思い込みだったら？
ぶっちゃけＣ＋＋とＣ言語とで比べてまったく同じ処理をするソースを書いたことないでしょ？

>>246
そりゃ、書いてるコードや仕様変更の内容による。

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

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

>>248
>保守性にかなり差が出てくると思う。
「思う」以上のこと言えないよね？

>>249
実体験と書いてあるわけだが。

>>250
だったら「思う」じゃなくて事実を書けばいいじゃん

>>251
揚げ足取りがやりたいならよそでやってくれ。

>>252
どこが上げ足とってんだよｗ

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

>>253
実体験に基づいて、実際にオブジェクト指向を採用することによる効果が出てくるコード規模について、
推測を交えて話したら、君の中では俺が全てについて憶測で話していることになるの？

>>254
だから知らないなら無理してレスしなくていいって
別に俺の問題に対する答えをもってるわけじゃないんでしょ？

>>255
えーっと、君の問題って何だっけ？

>>255
一人でコード書くなら差はあまり感じられないかもしれない

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

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

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

>>257
だから具体的な答えをもってないのになんでレスするの？
無理しなくていいよ

>>258
可読性の向上や、想定していない使用方法からくるバグとデバッグ時間
コードの修正による再コンパイル時間
諸々の理由からくる余計な時間が省けるだけ

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

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

>>259
>可読性の向上や、想定していない使用方法からくるバグとデバッグ時間
向上してるかどうかなんてわかんないんでしょ？

>>258
お前の言っている数値ってなんだ？
基準は相対基準か絶対基準か？

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

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

>>261
あー、わからないならレスしなくていいって
そこからいってなにをすれば証明にいたるのかわからない奴相手にしたくないから

>>260
可読性がってこと？
まあそうだね
数値化はできないな

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

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

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

>>263
ごちゃごちゃ無駄なこと書いてるけど結局可読性が上がってる云々とは関係ないじゃないか
だからわからないのに無理してレスするなよ

>>264
ひとつひとつのメソッドを全て読むのと、名前だけの確認で終わるのどっちが早いのかはわからない？

>>265
なんで全然関係ない話をするの？

>>266
可読性の話の続きなんだが

もしかして、プログラミングしたことないのか？
理屈だけで覚えようとしてるなら用語もわからないかもしれないな

>>267
それがＣ言語からＣ＋＋に変わって（オブジェクト指向という意味で）のメリットなの？
君、自分がまったく関係ない話してるの気がついてる？

人には具体的な答えを求めて
自分は片言の日本語でやりとり
一つでもおかしな点があると思い込んだら全否定
質問して知識の物乞いしてんのに殿様気取り
普通ならぶん殴られてもおかしくないから直せよ

>>270
だから別に知らないならレスしなくていいって言ってるじゃん

>>269
外部にみせていいメソッドだけ公開できるのはC++からだろ
カプセル化ができないと全てのメソッドを公開しないといけない
だから全部読むはめになる
どこもずれていない

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

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

>>257
代わりに答えてくれてありがとう。
どうも、彼は単に自分の知らない概念を全否定したいだけの人だったみたいだね。
時間を無駄にしてしまった。

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

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

>>272-273
なんでさっきから知らないのに無理やりレスするの？
いいって言ってるのに押し付けるのやめてよ

>>273
はっきり言えば、あなたの言い方が
多分オブジェクト指向を理解していると言いづらかったから横槍いれたんです
もっと勉強してください

>>276
そんなこといって結局メリットに関してなんも具体的な説明できないじゃん
だから知らないならレスしなくていいって言ってたのにやけにつっかかるなぁ

>>277
再コンパイル時間については？
可読性の向上については？
反論ないようだね

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

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

>>278
あれが具体的？
頭おかしいんじゃないか？
工数はいくつ減らせるの？
普段仕事してて１ｈだって根拠を求められるのに
なんで言語に対してはそういい加減なの？

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

それと何度もいうけど
知らないなら無理やりレスするのやめてもらえます？
まったく同じ仕様のものをＣ言語とＣ＋＋とで比較した経験すらおそらくあなたないですよね？

>>280
知らないならレスしなくていいよ

>>279
工数？
1/2以下

一つの単位で機能を管理・提供できる点がoopじゃないのん。
cのstructじゃ処理(関数)を外側で指定(関数ポインタへの代入)しなくちゃならないんだし。

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

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

>>279
まぁ、貴方のように、既にデスマってしまった人を救済する銀の弾丸ではないかもね。
そもそも、そういう事態に陥らないための方法論がオブジェクト指向。

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

>>283
てか「処理」と「データ」をオブジェクトの名の下に一元管理できるのは大きな要素だと思う

>>285
処理とデータを関連づけるのはいいが
一緒にするのはダメなオブジェクト指向の典型だ

>>286
おまえ、手続き抽象ぐらいは理解した上で書いているのか？

>>287
否定してるわけじゃない
インターフェースとデータは分けて管理するのは当然だろ

>>288
それって細かい実装技術でしょ？
それが設計にまで影響しちゃうのってないじゃん
なんかこのスレに相応しくない話してない？
インターフェースクラスが本質の設計に影響を与えるのってないでしょ？

インターフェースクラス？？

>>290
どっちでもいっしょでしょ？

>>291
え？ｗ　何と何が？ｗ

>>292
上げ足取りたくてレスしたの？
死ねよ

>>293
どうせ二行費やすなら>>292答えろよｗ

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

>>294
まあ、インターフェースが設計に影響与えるのはおかしいでそ？
なのでこの話はここでおしまい

>>295
なんか誤解していたら申し訳ないので伝えておく。
俺がここまでにレスしたのは>>290 >>292 >> 294だけ。
「インターフェースクラス」っていう謎の用語に怯えただけ。

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

>>295
だいたいの設計には必要無いかもな

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

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

>>297
ないよ
ないから君の話にはこれ以外のレスしない
おわり

そんなに実例みたくばboost読んでみろよ

boostのインターフェース設計がまさか設計無しに作られてるとか低能な言い訳しないでね

ごめん
Cがどうとか言ってた基地外か
boost読めないから無理だったね

あたかもboostがいいようにいうけどまったくいいことないと思うよ

いい悪いの話ではない
話題をそらすなよ

>>297
javaだとインターフェースクラスを直接作れるね
C++だと、メンバ変数のない純粋仮想関数だけのクラスだと思えばよし

マルチエージェント指向

>>303
なら、boostはどんな説明をするために話題に出したの？
こんなのオブジェクト設計なんてしてねーただのオナニーライブラリじゃん

>>306
論派したいんだろうけど、話題反らしたり無知披露したりで屑認定されてるよ

>>306
頭悪いんですね…

オブジェクト指向？なにそれ、おいしいの？
オブジェクトなんて構造体でしょ？なんでそんなに有り難がる必要があるだろう
ましてや構造体でシステム設計とか意味不明

>>309
勉強して批判しようね屑

熟練のプログラマって意外とオブジェクト指向で作らないんだよね。
考えが古いのかな？
実はあまり必要ないとか？

>>311
意味ねーし
オブジェクト指向になって具体的にいいことって出せる奴いねーもん

>>312
Stringクラスも不要？

>>313
仮に似たような機能Ｃ言語で作ったらいらないな

>>314
文字列の長さ順にソートするような場合どうする？
strlenを毎回呼ぶつもり？

>>315
それはＣ＋＋でないと作れない機能ですか？
ってことだな
同じ労力だと思うぜ

>>316
ってことだな？　思うぜ？

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

>>317
は？
それって何か問題あるの？
っていうか話の主旨をどこにしたいの？
俺は別にライブラリの出来不出来の話をしたいわけじゃないんだけど？

>>318
ライブラリの出来不出来の話などするつもりはない。

>>319
じゃ、何が言いたいんだよ
さっきから

>>320
「文字列の長さ順にソートするような場合どうする？
strlenを毎回呼ぶつもり？」

stringクラスと、そのsize()メソッドがあるから、
そのインスタンスsに対しs.size()とサイズを取得できる。

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

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

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

>>322
っていうＣ言語の関数を用意したら？
でお仕舞いな話を出されてもねｗ

>>323
そんな手間をかけるくらいなら、
俺はstring#sizeを使って単に、
bool sizegreater(const std::string &a, const std::string &b) {
return a.size() > b.size();
}
こう書いて、sort(v.begin(), v.end(), sizegreater);に渡す。

> っていうＣ言語の関

ご苦労様ですｗ

>>324
だから君が言ってるのはライブラリの有無の話でしょ？
最近、こんな馬鹿が金もらってプログラム組んでるからな

#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で同等のことをするのは大変。
大変じゃないというのならサクッと示してほしいところ。

>>326
>毎回strlenを呼ばずにCで同等のことをするのは大変
大変（笑）

>>325
すでに>>322で書いたように、stringに対してs.size()が呼べるからこそ、
>>315の問題の部分は、return a.size() > b.size(); と書ける。

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

>>328
バーカｗ
しゃべるたびに頭になにも入ってないのがバレバレだなｗ

オブジェクト指向不要論みたいなのを掲げて煽ってるヤツって釣りじゃねーの？
本当に不要とか思ってるのなら単なる馬鹿で相手にするだけ時間の無駄だと思うんだが。

文字列の長さでソートする時、strlenを毎回呼び出さないですむ方法が、
Cでスマートに表現できるのなら俺は>>329をバカと呼んだりはしないよ。

指摘するほうもオブジェクト指向と全然関係ないところをあげて
サブルーチン単位の細かいことしか挙げないのはどうしてなの？
はじめのオブジェクト指向にテンプレートなんて入ってなかったでしょ？

>>331
は？意味がわからない
仮に構造体をもって

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

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

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

同意　
http://d47.decoo.jp/diary/hasseee/?guid=on

>>333
ほら、そうなる。

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

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

>>335
はぁ？
だからＣ＋＋の場合ライブラリとしてStringが用意されてるのは認めて
Ｃ言語ではライブラリの類を認めないってのはどういう理論なの？
Stringはライブラリでしょ？
Ｃ言語で俺が書いたMYSTRがそれに当たるんでしょ？

それとこの辺ってオブジェクト指向関係ないじゃん
なんでこんなサブルーチン出してオブジェクト指向云々の説明をしようとするの？
できっこないじゃない

データ抽象がオブジェクト指向だっていうならCだって
オブジェクト指向プログラミングできるだろう

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

これはさすがに会話続行不能なレベルだよね
ライブラリと言語仕様と設計の区別もついてない

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

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

>>336
> また、キャッシュのための変数の中身は、
> strlenの結果と同一であるように注意を払う必要も出てしまう。

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

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

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

>>340
なんでそうやって小手先の技にこだわるの？
オブジェクト指向設計の話をしてよ

>>342
オブジェクト指向設計？？
その話をするのはまだ早いとおもう。
今はまだCと比較できる部分のほうがいいかと。

>>341
なんで仕様書がないサブルーチンなんかでオブジェクト指向の話ができるの？
理解してないのは君のほうなんじゃないの？
だから文字列クラスでオブジェクト指向の話ができるなんていっちゃうんじゃないの？
できないよ

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

>>345
彼らはカプセル化すら分かってないから…。
内部表現丸出しでも平気らしいし。

初心者ｗ

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

>>345
それオブジェクト指向のメリットなのー？（爆笑）

追い詰められたカスの特徴ｗ　理屈で返事しないｗ

はぁ？文字列クラスなんて意味のねーものいじってねぇで
オブジェクト指向設計の説明してみせろよ
なんで文字列クラスなんだよバッカじゃねーのｗ

追い詰められたカスの特徴ｗ　理屈で返事しないｗ

ソースが読みやすくて綺麗になる

知識レベルが近ければオブジェクト志向もチームでやるには有効なケースはあるが、
揃ってないなら捨てた方が吉。中途半端な知識の奴とか覚えたてのニワカがいる場合も
クラス設計そのものがスパゲティになるから排除した方が良いｗ

知識レベルが低い奴が書いたコードは
オブジェクト指向であろうがなかろうが
スパゲッティーだっつーの

あと、オブジェクト指向じゃないとデバッグやりにくい
バグが起きないと保障されている場所もチェックして行かないといけない

>>355
高い低いの問題じゃない。ぶっちゃけ一人だけ知識深い奴がいても、そいつのコードは周りから見れば
さっぱり、なんてことは良くある。

だいたい自分のコードが見やすいかどうかなんて誰か１人にでも聞いたことあるのか？ｗ

複数開発なら普通にあるだろ。「見やすい？」とかじゃなくて「わかる？」とかだと思うがｗ

オブジェクト指向的な考え方は、メンテしやすいソフトウェアを書く上では
今や教養として必須だと思うけどな。是非を問う段階はとうに通り過ぎてる。

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

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

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

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

>>356
それちがうとおもう
経験的に、関数的にまとまってる設計(副作用のない設計)の方がデバッグは楽

>>360
たしかにそうなんだけど, 現場ではオブジェクトの名の元に
クラスに隠蔽されたグローバル変数が飛び交ってるんだが

>>360
>一番重要なのは、データと処理を統一的な方法でまとめることで、
>「より使いやすく」「より分かりやすく」「より安全に」プログラムできるようになることだろう。
脳みそにウジでもわいてるのか？
それのどこが金になるの？

>>361
副作用のない範囲で済むコードなら良いと思うけど、それは要求次第なわけだし。
副作用が影響を与える範囲を言語仕様的に限定できるのがオブジェクト指向言語の良いところ。
早い話が、自分や他人がアホなコードを書いた時のリスクを低減できる。

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

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

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

>>361
そもそもオブジェクト指向を取り入れてない言語のデバッガが低次元になってる

>>362
そこは継続的インテグレーションと静的解析ツールを使ってコーディングスタイルを強制、
でいいんじゃね。IDEや各種ツールを導入して自動化するのは重要。

>>364
> 副作用のない範囲で済むコードなら良いと思うけど、それは要求次第なわけだし
それもちゃうとおもう
うまくデザインすれば、副作用のある個所は物凄く減らせる

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

>>363
手戻りが減らせればコストを減らせて金になると思うけど。

>>365
ワークフローが中心になるタイプの業務システムとかだとそういう側面はあるかもしれないな。
そこは、オブジェクト指向というよりフレームワークのレベルでどうにかする問題だという気もするけど。

>>368
デザインによって副作用は減らせると思うけど、完全に取り除くことはできないわけだし。
それに、そういううまいデザインとオブジェクト指向の採用は矛盾しないんじゃない？

>>363 ではないんだけど
現実には >>362 の様な理由によって
>「より使いやすく」「より分かりやすく」「より安全に」プログラム
できていないことが問題だろ

>>369
参照に代入されたnullを「ない」の意味で使うか、Null Objectを定義すればよし。

ちんこの遊び場はここですか

>>373
もちろんオブジェクト指向は万能な「銀の弾丸」じゃない。
そこを補うのが、例えば>>367みたいな実践。

>371
オブジェクト指向の利点を活かすには、それを含めてってことだけどな。
草創期からOODに取り組んでいたウェブスターが言ったのは、人材だの会社の
政治的な側面も考えて「環境を整えてからやれ」ってこと。

>>374
nullを使ったらnullチェックが必要になるのでisNoneを呼び忘れる危険と変わらないのでは？
Null Objectってどうやって使うの？まさかtypeid？それこそ場合分けの構造じゃんか

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

オブジェクト指向じゃない言語は本当に迷宮入りする事があると思う
ある意味怖い

>>378
http://www.hyuki.com/dp/dpinfo.html#NullObject

>>379
200人規模のプロジェクトだとオブジェクト指向でも平気で迷宮入りするのは気のせい?

>>380
ありがとう
読んでみたけど、Null Objectでどうやってgetを実装するの？
戻り値がないので無理でしょ

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

200人いれば200のオブジェクト指向があるってのが事実。
大統一理論があると思ってはいけないｗ

>>382
べつにnullを使っちゃいけないということはないと思うけどなぁ。
いい方法があれば併用すべきというのは同意。

>>382
ていうかべつに代数データ型でなくてswitch caseでいいわけでしょ。
基本的にパターンマッチは記述を簡潔にするのが目的だと思うけど。
OOがやる抽象化は拡張できるようにするためでしょ。

>>381
そんなレベルじゃない
自分で自分が作った物が分からなくなる
オブジェクト指向だとプログラム自体がある程度設計書だがそれがない

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

メソッドどころか「データの抽象化がオブジェクト指向ではない」ってのは、
高名なクック船長がおっしゃってますｗ

>>385
>ていうかべつに代数データ型でなくてswitch caseでいいわけでしょ。
あれ？
オブジェクト指向ってsiwtch caseを使わずにオブジェクトのメソッドで抽象化するというのが原則じゃなかったっけ？
switch caseを使うって事は、場合分けの構造がやっぱり必要って事になるよ

>>386
それはどうしてそういえるの？

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

>>391
ぶっちゃけそんな細かいとこどーでもいいよ
実装方法なんてどーだっていいし
オブジェクト指向となんも関係ないのに
それがオブジェクト指向だと思ってる可愛そうな脳みそしてる奴多いな
オブジェクト指向はあくまでも仕様をオブジェクトに落とすだけだ

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

>>392
個人的な意見だけど、オブジェクト指向って言葉は、
「オブジェクトという概念を中心に据えたテクニックや分析手法の集合」なんじゃないのかな。
その具体的なテクニックの代表例が、例えばデザインパターン。

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

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

>>394
そりゃ、goto禁止すると例外処理がきれいにかけないから構造化プログラミングはいまいち、
って言ってるようなもんだよ。

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

>>393
違うよ
はじめはシミュレーション用の言語だったんだから
オブジェクト＝物体と仕様をわかりやすく落とし込むために作られた
たしか気体分子同士の関係をみるためだったかな？

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

大事なのは仕様

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

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

>>388
クック船長がどう言っていようが、
Stroustrup（発音しらん）艦長がなにを言っていようが、
ケイ番長がなにを言っていようが、
このさい関係ない
そんな定義論に興味ない
Abstract Data Typeは使いにくい場面が多いし、偏りすぎ
ただそれだけ

>>395
>そりゃ、goto禁止すると例外処理がきれいにかけないから構造化プログラミングはいまいち、
>って言ってるようなもんだよ。
なるほど
合点がいった
ありがとう

>>390
どこに何に対する処理か分からないルーチンがばら撒かれるから
オブジェクト指向だとオブジェクト自体に処理が書かれるからどこにあるか分かる

>>397
>場合わけのコードをばらまくことを推奨する言語が、メンテナンスとか拡張とか頭にないってことなんじゃないの?
>便利だといって後のことなんも考えてませんみたいな。
でもここは同意できないな
場合分けのコードってメンテナンス性も拡張性も落とさない
ただし静的型付けがあれば、かな

>>401
型でチェックできればいいってもんではない。
コードに手を入れるのは大変だし、取り除くのも大変。

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

>>398
その通りだけどｗ
表記色々あるが、ストラブストラップ艦長が成功したのは抽象化そのものに
こだわるより、Cとの親和性を重視した結果。
そもそもJavaにおける「プリミティブな型」を考えりゃわかるけど、同じメソッドを
持ってるオブジェクトであるはずでもコピーではまったく同一に扱えないわけで…

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

同じコードを１０箇所とかにコピペするのを止めて欲しい
仕様変更でコードを変更するだけで死んでしまう

>>402
つOCamlの多相バリアント
元のコードには手を入れずに拡張できる

>>396
いわゆるGoF本の正式なタイトルは、
「オブジェクト指向における再利用のためのデザインパターン(Design Patterns Elements of Reusable Object-Oriented Software)」
なんだけどな。。

>>406
だからといって本人達が理解しているかどうかは全く別
少なくとも俺には製作者のオナニーにしか見えない

>>407
本人ってのは誰？ GoFのおっちゃん？

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

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

>>402
「開放-閉鎖原則(The Open-Closed Principle)」の考えに基づくなら、
「変更に対して閉じており、拡張に対して開いている」方が良い、という結論にはなるね。

>>405
拡張できるといってもレコードの拡張とはサブタイピング関係が逆になるので要注意な

>>409
> だいたい、だれが汎用性なんていれてくれって頼んだよ？

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

ぶっちゃけデザパタは「馬鹿は何も考えるな！この通りに作れ！」っていうリアリズムだろｗ

さっきから
>オブジェクト指向は仕様をそのままコードに落とせる
と叫んでいるイタい上司がいるのですが、なんとかなりませんか？

>>414
何ともなりません。自分でやってみて実証してくださいとお願いするしかないですｗ

Ａ．アセンブラかマシン語
Ｂ．超高級言語（ネイティブな母語のようなもの）のインタープリタ

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

ずっと粘着してる奴コテつけろ
だれだかわからない

>>414
成り立ちから考えてデザパタはどうやってもやってることが違う

まあ、ちゃんとプログラムやってたら
ほとんどのデザパタはいつのまにかやってるもんだと思う

>>419
俺とお前の作り方は違うんだな
俺はあくまでも仕様書に書いた構造をコードに落とす
そこにデザパタが介在する隙間はない
パターンなんてねぇから

>>420
仕様書があるならそれでいいと思う
リファレンスとして仕様書があるから早いしわかりやすい

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

だって元々デザパタは経験則で生まれたもんだろ。
マトモなPGが組めば同じようなパターンになるのは当然。
それを「知識」として受け取るような奴がいるから困ることになる。

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

>>422
そうだな

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

オブジェクト指向の意味は
privateによるカプセル化と、
ポリシークラスによる構造定義が真の意味だと思ってる
工期がどうってのはあくまで副次的な産物

オブジェクト指向で用意されたライブラリがクソ使いやすいんだが。
String, Array, Hashとか基本的な奴ほど特に。
Cでやろうとするとすごく煩雑にならないか？

だよねー
その３つがあればなんでもつくれるよねー

>>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++つかいやがれってことです。

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

プログラミングにおける「良い習慣」を全部オブジェクト指向の手柄にしちゃうのが初心者

昔は、cは関数が豊富でよい、と言われていたものだが。

オブジェクト指向設計と絡めてＣ＋＋の利点を説明できない人ってなんなの？
サブルーチンに対してばっかり話してるけどそんなのＣ言語の標準関数と変わらないじゃん
全然オブジェクト指向出てこないんだけど？ｗ

>>431
何が変わらないの？

newしたらオブジェクト指向

>>432
設計じゃないという意味
設計の話でstrcpyとか出てこないでしょ？
だけどこの板に巣くってる馬鹿な人は
いつもオブジェクト指向の話するのに文字列クラスなんて馬鹿なもん出して説明しようとしてる

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

ここは別にOODと言ってないんだから設計の話じゃなくてもいいだろ。OOPでもｗ

だったら別スレ建てろよ
邪魔だな邪魔
オブジェクト指向理解してねぇしｗ

別スレはお前だろ。元々オブジェクト指向ってのは実装が先だぞ。
設計なんてのはその考え方を推し進める上で、後から出てきた話だ。

>>437
はぁ？
馬鹿は糞して寝ろよｗ

ちんこさんチンコンパイラはまだですか？

>>431
オブジェクト指向言語としてのC++はあまり評価が高くないように思うが。

オブジェクト指向言語としてのC++、なんて話じゃないな。１人が勘違いしてるだけ

情報隠蔽に、コーディングレベルでの意味を見出せない。
言語レベルでのコントロール規制…うーむ。

データを勝手に変更させないってことじゃないのか
例えばマイナス入れちゃ駄目な変数に勝手にマイナス入れられないようにするとか

＞一行目
private指定で、getterだけで使用…？　他の思いつかない俺はダメだな。
ハードコーディングしたデータを使うだけなら、別段規制する必要性を感じない。
人間は間違うもんだ…という前提にたっての規制なら…意味あるか

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

考えなければ…


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

>>442
静的型検証と同じこと。
特に、自分以外の人間と一緒にコーディングする時のことを考えてみるとよろし。
「昨日の自分と今日の自分は別人」とか言ったりもするし。

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

>>444
継承できるかできないかの差かと思う
これができないとコピペが乱立する

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

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

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

参考になりそうなキーワード：
単一責任原則
"Tell, Don't Ask."

あまり専門用語使ってると説得力ない希ガス
よく分かんねで終わってしまいそう

言ってる方は気持ちいいだろうけど

>>446
> これができないとコピペが乱立する
出来なくても, unix の kernel にはコピペないよ

>>451は何を根拠にそう発言したのだろうかｗ

>>451
少なくとも, v6 のソースには見受けられなかったし, 4.2BSD もそうだった
*BSD や Open Solaris でもみかけないな.
Linux のドライバにはあるかも知れない.

オブジェクト恥垢

OOPのポイントは2つ。
１．クラスのインスタンス化
２．メッセージング

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

そのふたつはObjective-Cをマスターすることによって理解できるな

「変数と、それを操作するメソッドを1つにまとめる」（クラス）
「ユニークな変数にはユニークなメソッドを用いる」（クラスのインスタンス化）

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

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

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

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

メッセージングについては、
ttp://www.geocities.jp/objectbrain/messagebrain.html
を読めば分かるんじゃね。

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

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

>　このように変数とメソッドが1対1で対応していることの利点は、
>　片方を知っていればもう片方を知る必要がなくなるということ。

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

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

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

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

>>457が言ってる「変数」って、オブジェクトaの内部状態のことでしょ。

Cの関数でも、
構造体aを指定しているのに、
なぜか構造体bのメンバが変更される、
とかありえないから。

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

その発想が怖い。

>>461
func(hoge)が、内部でbを変更するコードになっていればありうる。

そしてそれはOOPの欠点だ。
Cなら有りえない。

単に関数付き構造体ってことじゃないのか
構造体みたく好き勝手に値変えられない構造体みたいな

>>464
言語仕様レベルではね。特に後段が重要なのではあるが。

>>459
Javaで、Stringクラスを〜、って言ってんだから、
メソッドa.length()に対応する変数は、
オブジェクト内部に隠蔽された変数（文字列の長さを表す数値）のことでしょ。

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

しかし、>>459の発言は痛過ぎるね。
まさに、Javaを知りません、OOPLを知りません、ってな文章だなｗ

まあ重要なのはそういう隠蔽化ではないけどな。
誰かがStringを継承して、ある特殊なエンコードに対応したクラスを作ってくれたとしても、
その中身をあまり知らずに安易にStringと同様の使い方をすることはできないしね。

涙ふけって、OOP信者よ。
変数とメソッドが一対一で対応って意味不明だろ。
クラスとメソッドが一対一で対応しているわけで。

常に対応してるんだったらメソッドなんかいらんわな
単純な関係が崩れたときのためにアクセサを通すわけで

あーまた変な事言い出した。
メソッドがクラスと対応しているのは当たり前だろ。

オブジェクト指向なんてもはや基礎教養だろ。
踏まえた上でどう実践していくかというフェーズで、
信じるとか信じないとかいう段階はとうに通り過ぎてる。

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

>>471
まず、クラスとは何か、メソッドとは何か、という言葉の定義の確認から始めた方が
いい気がするな。

SmalltalkやCLOSも学んだ方がいい
といってもちんこは人の話を聞かないのであった

隔離されたグローバル変数(というか環境)みたいなもん

>>472
Javaの話をしていたんだよね。JavaってクラスベースのOOP言語だよね。
クラスとメソッドが対応するのは当たり前だよね。
メソッドのアドレスが格納されている、いわゆるvtableはクラスごとに用意されるのは知ってるよね。
そしたら、クラスとメソッドが関連付けられるのは自明だよね。

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

>>476
たぶん前半は俺宛じゃないと思うが、
それはどちらかというと「クラスインスタンス」じゃないか？

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

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

>>477
メソッドがクラスにくっついてるのがクラスベースのOOP。
メソッドがインスタンスにくっついてるのがプロトタイプベースのOOP。
こんなの常識過ぎるだろ。
そこの区別の問題があるから、JavaのようなクラスベースのOOPを説明するなら、
「メソッドはクラスと関連付けられる」って表現が適切なんだよ。
メソッドはインスタンスと関連付けられる、と書くと、プロトタイプベースなのかと勘違いされる。

>>478
クラスの中のメソッドと対応してる時はなんなのよ

えらく無知を晒してるやついるけど
オブジェクト指向は魔法みたいなものと勘違いしてんじゃねーの？
ほとんど似たようなものだろ

>>478
だからクラスインスタンスと書いたわけだが。
クラスに紐付く、という説明だとインスタンスを生成することの意味が分からなくなるし、
それにポリモーフィズムの説明ができない。

>>478
CLOS みたく、どっちにも付いてないのは何て言うんだ

>>481
Javaのポリモーフィズムはインスタンスのクラスに基づいて行われる。
わかる？
インスタンスのクラスのメソッドが呼ばれる。
もう一度言うよ。
インスタンスのクラスのメソッドが呼ばれる。
インスタンスがメソッドを持っているわけではない。クラスがメソッドを持ってる。
メソッドの呼び出しは、インスタンス→動的クラス判定→メソッドと、クラス経由で呼び出される。
「クラスのメソッド〜」って表現、日常的に使うでしょ。
一方、インスタンスがメソッドを持ってるのは、プロトタイプベースと言う。

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

てか本当に初心者が多いな。
こんなんがOOP万歳してるんだろうな。
せいぜい今のうちにいい夢みてればいいよ。
すぐに　大人たちは嘘つきだ　って言い出すから。

>>483
いや、内部的にはその通りだよ。
というか、俺と同じことを言ってるようにしか見えんのだが。

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

OOPをやってると、どんどん恥垢が溜まっていくのだろうか…

>>486
反論ないなら寝るけど、他人を自分と同レベルに引きずり落とすことに熱心になるくらいなら、
自分の世界を広げる努力をした方がいいと思うよ。

すみません特別誰の発言に向けた言葉でもありません…
コーディングしてると垢のようなものが溜まっていくような感覚がしまして…
思考が固まっていくような…独り言でした…紛らわしくてすみません…

コーディングが煮詰まると恥垢が溜まるとは珍しい人ですね。

削れば恥垢は落ちます…
僕と一緒に綺麗になりましょうよ…ウホッ

OOPがもし発明されなかったら、
入力支援の方向が左になってたんだろうか。
構造体の変数書くと、その構造体を使う関数が左にずらりと並ぶ・・・

>後段については、インスタンスを外部から呼び出す側は、
>そのインスタンスの実装クラスが何か、ということは意識しないよね、という話。

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

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

>>491
俺も昔それを考えた事がある。
俺の結論はこう。
「関数名を書くと、引数にとりうる型の参照可能な変数が列挙される」
要は引数を補完する。何気に便利そうだ。

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

アドレス空間上、コード領域に置かれるのが判ってるなら〜ベースなんてどうでもよくね？ｗ

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

っていう話じゃないの。

>>493
Objectが主語だからでしょ。

>>495
インスタンスの設計者はどうなるんだよ。
使う側が気にしなくても良いってのはいつでも真理だよ。

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

>>493
＞「関数名を書くと、引数にとりうる型の参照可能な変数が列挙される」
おぉ、いいね。
これはOOPであっても実装してほしいぞ。
変数マークアップ機能の次はこれだ。

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

>>496
>　Objectが主語

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

>>496
objectは目的語ですよ。辞書的にみて。。。。。という冗談は置いといて、

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

こじつけだけど。

もっとバトルしてくんねぇかなあ
OOPer vs アンチOOPer

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

現実にはやっぱりオブジェクトは目的語だとおもうよ。
コンピュータに処理をさせる対象として「オブジェクト」なんだから。

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

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

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

command( object1, object2 );

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

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

>>497
ポリモーで動的に管理したら、実際に動いてるクラスが何かを知る方法って簡単には無いよね
インスタンス単位でみないと、アップキャストされた基底クラスなのか
基底クラスのままのインスタンスなのかで違うやろ

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

>>504
多態性をC言語で表現するのは無理ではないけど明らかにしんどいし、
「それOOPじゃなくてもできるじゃんｗｗｗ」の彼としては目を背けたい部分なんじゃないか。

>>502
> 現実にはやっぱりオブジェクトは目的語だとおもうよ。

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

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

thread.run()とか、object.toString()とか、すごく自然だ。

おまいら実際、どんだけの物を書いたの？
俺はJavaで5万行。Rmi+JDBC+Appletなシステムを一人で書いた。
C++で一万行。PlatformSDK+Win32API使ってエディタ書いた。

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

批判ではなく、純粋な質問なのだが

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

規模の目安。

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

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

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

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

OOPは利点が多々あるが、そんな直感的な記述はすべきではない

>>512
なぜだね？

根本的に、コンピュータはマシン語でしか動かない
その為、結局どんな手法でも、複雑さは変らないが
手法によって複雑さを、人間に表現させる方法に差が出る（手法や言語は、人間が理解し易くする為の物）

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

>>493

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

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

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

メッセージングのアイデアはアラン・ケイの発案だが、彼はこんなふうに説明している。参考まで。

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

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

アラン・ケイには敬意を表するが、
彼の言ってることをあまり理解したいとは…思わないｗ

class S
{
　void V()
　{
　　o.C();
　}
};
こんな感じだと思っていたのに

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

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

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

引数が二個以上あるとややこしい。
strcpyに渡す二つの変数、どっちがsrcかdstか分からなくなる。

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

>>519
それを言い出すと、そもそも「コンピュータに処理を命令（コマンド）する」という概念自体が
「ウソ」なわけだが。

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

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

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


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

>>518
クラスを作ることはオブジェクト指向言語では必須ではないはず。
クラスをつくらない言語というのもあるから（何かは忘れた）。

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

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

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

うわ、でたよ。得意技の詭弁。
池沼じみた発言をしてすぐ煙に巻こうとする。
なんでもそうだけど、コマンド的なものが前に来るのが一般的で、
それを否定しようが無いから、電気信号が〜とかわけわからんこと言い出す。
if文が {}(x)if だったら嫌だろ？
for文が {}(;;)for だったら嫌だろ？

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

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

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

>>523
>目的語２つというのはおかしいよね。
なんでおかしいんだよ。
複数のオブジェクトに対して処理をしたいことだってあるだろ。
目的語は常に一つってのはOOP脳か何かか？

前、別のスレであった奴
(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の方はあまり直感的じゃないと思う

>>524
> if文が {}(x)if だったら嫌だろ？
> for文が {}(;;)for だったら嫌だろ？

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

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

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

>>520
それよくある。
二つのクラスに密接に関わる関数を、
どっちのクラスにメソッドとして装備させようか、
判断がつかないのな。

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

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

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

逆ポーランド記法ぐらいしってるって。
「嫌だろ」という話をしてるんだ。事実、あんま使われねーだろ、読みにくいから。

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

ベクターの足し算が＋で出来るとか、どうでもよすぎる

>>529
おまえ、OOPの良さが理解できないんだろ？
OOPすら理解できない能無しは発言しないでくれるかな。

俺の知る限り、物事を深く理解する者は、その暗部も認めるものだ。

良い部分を知らない奴と、良し悪しの両方を理解している奴じゃ次元が違うっしょ。

>>529
これほど歪んだアセンブラへの愛の吐露は初めて見た。

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

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

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

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

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

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

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

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

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

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

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

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

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

>>536
技術的な反論をしてくれないかな。
あと、君の言う「プログラム」というのはどの程度の規模と複雑さを想定している？

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

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

メモリ空間やプログラムカウンタっていうハードウェアがある、とか思ってる件についても聞こうか。

オブジェクト指向ってようするにモジュールを分割する手法のひとつでしょ

>>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()で問題ないだろう。

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

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

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

>>539
君が言ってる「命令」や「ハードウェア」は、それもまた「ウソ」の産物だというのは既に指摘したよね。

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

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

>>543
っ【マルチプルインスタンス】

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

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

>>542
>　文字列結合のJoin()とスレッド同期のJoin()が全く違うことをやるので、気持ち悪い。
そりゃお前普通にコンパイルエラーだろ。オーバーロードなぞ俺も嫌いだ。

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

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

>>539
言いたいこと、なんとなくはわかるけど。
関数を構造体と合体させたのは確かに問題が多いかもしれない。

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

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

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

>>544
> 君が言ってる「命令」や「ハードウェア」は、それもまた「ウソ」の産物だというのは既に指摘したよね。
またなんか言い出した。こいつ本当にどうしようもないな。
それじゃあれですかね、数学の数字の「1」もウソの産物なんですかね。
まぁそんなことはどうでも良いんですけどね、だってそれは、お前の言ってる
中学生のいいわけみたいな意味で「ウソ」という言葉を使っているわけじゃないからな。
俺は明確に、ハードウェアとのミスマッチ、実態とのミスマッチが俺の言う「ウソ」の定義だと
宣言しているわけで。お前の勝手な定義で話し進められても困る。

>>545
メモリ空間をどう分断するか、それは、マルチプルインスタンスそのものだ。
データをどう配置するかって話だからな。

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

「人間 vs. 複数の計算機」になるだけだろ。
こんどは複数の計算機に対して命令を出すわけだ。
どういった状態でネットワーク化されているかによって書き方が変わってくるだろうが、
そこにウソは無いよ。

>>547
> クラス設計ミスると、とてつもないことにならんの？

クラス設計をミスって大被害を負うような規模で、非OOで組むとか想像もしたくないな。

その辺のリスクを軽減できる、オブジェクト指向より良い抽象化手法が出てくる可能性は否定しない。
どちらにせよ、ハードウェア大好きな彼が望む方向とは真逆だろう。

また、文字列クラス（＝サブルーチン）でオブジェクト指向語るアフォがでたのか？
だからそんなサブルーチンじゃ
オブジェクト指向の話なんかできねっつのｗ
なんでいつまでたっても設計レベルの話ができないんだこいつはｗ

>>547
おー分かてるねー。
もともとオブジェクトってのはデータ構造寄りの発想なのに、
そんなところに、制御構造をぶら下げた罪は大きい。
おかげで制御構造はズタズタ。
パゲッティーって何の事だったっけ、人類は過去から学ばないものだね。

後半の実行速度云々は俺はあんま気にしないけどな。

>クラス設計をミスって大被害を負うような規模で、非OOで組むとか想像もしたくないな。

非OOPでモジュール単位で完璧なカプセル化を行った方が
はるかに安全なんだよ。柔軟性は損なわれるがな。
やっぱりわからない人なんだね。

>>548
例えばだが、いまどきのOSで、君の大好きな「メモリ空間」が
物理アドレスと一対一対応じゃないことくらいは当然知ってるよね・・・？
それに、まさか仮想メモリを指して「ハードウェアとミスマッチだからてめーは駄目だ」とか言わないとは思うが。

> メモリ空間をどう分断するか、それは、マルチプルインスタンスそのものだ。
> データをどう配置するかって話だからな。

それ、全部処理系に任せようよ。

> 「人間 vs. 複数の計算機」になるだけだろ。
> こんどは複数の計算機に対して命令を出すわけだ。

君も、既に計算機が自律分散協調であることの恩恵を受けてるはずなんだがなぁ。
そんなに命令モデルでないと許せないなら、今日からGoogleを使うのはやめた方がいい。

>>552
> 柔軟性は損なわれるがな。

OOが支持される理由、その答えを自分で言ってるわけだが。

>>553
？？？
仮想メモリはハードウェアとマッチしてるだろ？何言ってんだ？

> それ、全部処理系に任せようよ。
データの配置を処理系が面倒見てくれるのは悪くないと思うよ。
でもそんな話してたっけ。

> 自律分散協調
で、でたー。まさに人権屋的発想。こういうやつらこそOOPを駄目にしているのだろうな。
いちおう教えといてあげるけど、お前、多分いわゆる中2病状態だよ。
あとでわかるよ。

あれだよ、柔軟性は必要になってから書き足しても問題ないし、
再利用性は、初めから期待するだけ無駄というもの。
どうせ使いまわせるのは、使いまわす必要が無いほど単純なものか、
もしくは、完璧にカプセル化された製品レベルの巨大なモジュールかのどっちかだ。

>>555
> 仮想メモリはハードウェアとマッチしてるだろ？何言ってんだ？
逆だ、ソフトに合わせるようにハードが作ってあるだけだ
誰かがもっと効率のいい仮想メモリ管理アルゴリズムを思いつけばハードもかわる

またサブルーチン馬鹿が現れたか

なんでサブルーチンでオブジェクト指向の話をするのかわからないな
んで結局、メモリがどーだとか実行速度がどーだとか関係ない話に行っちゃう
馬鹿だろ？
頭悪いだろ？
設計とかやったことないだろ？
なんでそんなに頭悪いの？

俺はOOPLが当たり前の世代なので、非OOPな人にマジで聞きたい
複数のクラスのインスタンスがごちゃ混ぜに入れられたコレクションの
各要素を文字列化し、出力する…という処理は
OOPLだと各要素に対してtoString()とかそれに準ずるメソッド呼べば良いんだが
非OOPLではどう書けば良いんだ？

>>560
なんでそんなサブルーチンの話をするの？

>561
何故って、どうやって書くのか疑問に思ったから

>>562
じゃ、スレ違いだから別スレでやってね

このスレで話していいよ。
OOPvs非OOP

構造体にタグ入れといてclass1_toString(),class2_toString()・・にswitchって感じじゃない？
関数ポインタ使う仕組みとかでもいける

聞きかじりオブジェクト指向ばっかｗ

何か色んな階層の話に飛び火して
意味が分からない。

サブルーチン馬鹿よりかはマシだな

まあさ・・・
オブジェクト指向が有用でも別にお前が偉いわけじゃないって種類の反感があるんだよ

オブジェクト指向にstatic変数があるのがおかしいと思う。
これさえなければたとえCであってもOOPになると思う。(スタックがすごいことになるが)

singletonにはstaticが…

>>565
for内にswitchでcase型:みたいな感じになるワケね
なるほど、言われてみれば単純な答えだった
しかし頭がOOPLなのでその単純な答えが出てこなかった

下段はむしろ書く前に思いついたんだけど
それじゃ、まんまOOPだから非OOP的には無いんだよなぁ…と思って

>>572
>非OOP的には無いんだよなぁ
いやCでも普通にありな手法じゃない？lisp系だったらクロージャでほいほいだし

まあCは関数ポインタ使えば、構造体がメソッドも含むオブジェクトに早変わりするからなｗ
そんな手法は大昔から使われてるし、そういう真似ができるからObjective-CはCで書かれてるわけで。

>>572
言われてみればじゃねぇだろ
馬鹿だから知らなかったんだろｗ

>>555
> 仮想メモリはハードウェアとマッチしてるだろ？何言ってんだ？

Amazon EC2が、どういう方法でサービスをホストしてるか知ったら発狂しそうだな。

> > 自律分散協調
> で、でたー。まさに人権屋的発想。こういうやつらこそOOPを駄目にしているのだろうな。
> いちおう教えといてあげるけど、お前、多分いわゆる中2病状態だよ。
> あとでわかるよ。

えー、実用技術としてGoogleのバックエンドでバリバリ動いてて、最近超注目されてるのに。
興味があるなら、BigTableとかMapReduceとかで検索してみるといい。
それに、何が人権なのかよく分からんが、むしろ単細胞生物のメタファの方が適切じゃね。

>>569
まー、そういうのもあるかもしれないがねぇ。
今や、別にそんなに肩肘張るような新味のあるものでもないとも思うけど。

>>574
非オブジェクト指向「言語」でも、オブジェクト指向「言語」と同等の表現はできるって奴だね。
まぁ、OOPL処理系を作る以外で本当にやる奴ぁいないと思うけどさ。

ただ、本当は、「言語」の話と、「指向」の話と、「分析」の話は分けたほうが良いのだろう。
でないと、特定の言語（「C言語」とか）に対する好き嫌いの話と混ざる。
言語は、彼流に言うところの、プログラマにうまい「ウソ」を見せるインタフェースにあたるところだから、
どうしても混同されやすいところがあるのは仕方ないけど。

ああそうだ。

>>548
> それじゃあれですかね、数学の数字の「1」もウソの産物なんですかね。

イエス。正確には、その「ウソ」は公理系と呼ぶがね。
（「なぜ0で割ってはいけないのか？」という動画が面白いので、一度見てみるといい）
ついでに言えば、文字の'1'も、ASCIIコードなら0x31に割り当てられたものでしかない。

電圧の高低にどういう意味を割り当てるか、というのは使う側の価値観に依存するんだよ。
こんなのは、中二病でもなんでもなくて基礎教養だ。

嘘でも本当でも、世の中プラグマティストが
多いんだよねー

>>560

各オブジェクトに対応した大量のif文を含むグローバルな関数ToString()を用意して、

foreach(Object o in objects){
　names += ToString(o);
}

とかやることになるだろう。ToString()の実装が悩ましくなりそうだ。

>>565
> 構造体にタグ入れといてclass1_toString(),class2_toString()・・にswitchって感じ

メソッドの数だけswitchが発生し、
新たなtoStringを必要とする新たなクラス（？）が発生したら、
対応するswitchに追記をしなければいけなくなる。

一方、ポリモーフィズムを用いれば、
新クラスをいくら作成しても、
toString呼び出し部分の既存のコードに変更はない。

> 関数ポインタ使う仕組みとかでもいける

俺なら素直に、OOPLを使う。

>>552
> 柔軟性は損なわれるがな。

柔軟な方がボクは好きです。
カプセル化も、OOPLのもので不自由したことなどありません。

>>581
>メソッドの数だけswitchが発生し、
>新たなtoStringを必要とする新たなクラス（？）が発生したら、
>対応するswitchに追記をしなければいけなくなる。
これはデメリットなの？
追加されたら追加されたとわかる記述はどこかにほしいんだけど

構造体に同じ型もたせて呼び出すだけと違うんか？

少なくとも、俺なら変更箇所が散らばるのは嫌だよ。
toStringだけじゃなくても、よく使うメソッドは沢山あって、
rubyで言うと、to_i, to_f, to_a, inspect, hashといろいろあるとする。
>>580が言ってるように頑張ったとすると、各グローバル変数、
ToI, ToF, ToA, Inspect, Hashの内部のスイッチに、
新たな構造体について追記をしなきゃいけなくなるのでは？

> 追加されたら追加されたとわかる記述はどこかにほしいんだけど

あなたが何を欲しがるかにまで、ケチをつけるつもりはないよ。

>>586訂正：
×各グローバル変数
○各グローバルな関数

いかん、脳が弱っとるｗ　>>585のリンク先は>>584…。

>>584
変更箇所が散らばるのが嫌？
俺はしかるべきところにしかるべき処理があったほうがいいと思うんだけど
WindowsのプログラムならOnXXXXのところにその処理があったほうがよくねーか？
したらたとえ処理対象が同一のものでもメッセージを処理する場所で当然バラバラになると思うんだけど
これを強引にまとめちゃうこともできるっちゃできるけど
知らない人がみたら混乱するだけでなんにもメリットないんじゃないの？

>>584
それとさっきっから勘違いしてるみたいだけど
この話題はオブジェクト指向言語にたまたまついている
オブジェクト指向とはあまり関係がない機能の一部の話であって
オブジェクト指向とはあまり関係がないんだけど
こんなところさぐってオブジェクト指向わかった気になるのって間違ってると思うんだけどどうよ？

>>582
どうとるかは人によると思うけど
まともに動いているメソッドに、直接触れなくてもいいのは安心できる。
switchくらいなら、まぁ…いいんだろうけど。複雑な処理の追記や、ロ
ジックの変更は、問題が波及する。

なので、クラスへ個別に記述した方が安心。
クラス増加 = メソッド増加と考えることもできる。
追加されたかどうかの確認なら、運用で対処とか、grepとか、IDEの機能
で補完できる気もする。

へ？この話題はれっきとしたポリモフィズムの話だよな？

>>589
>まともに動いているメソッドに、直接触れなくてもいいのは安心できる。
実際は挙動が変わってるんだからそれはただのまやかしだろう

>>590
じゃ、設計段階でそうなってるの？
違うでしょ？
それにこの手にことやろうと思ったら圧倒的にＣ言語のがやりやすいよ
超でかいメモリプール作ってそこに構造体全部いれるようにしてアドレステーブル作れば
現在使用中のメモリ量まで一括して出せる

>>587
> 変更箇所が散らばるのが嫌？

これはあれだよ、
新しいtoStringの実装を必要とする新しいクラス（？）ができたときに、
>>580方式でのグローバルなToString関数の中に、
newclass_toString関数を呼ぶ記述を追記する必要がある、という意味で、
newclass_toStringだけじゃなくToStringも触らなきゃいけない、
変更箇所が一箇所じゃないという意味。

一方、ポリモーフィズムを用いれば、
上の例だとnewclass_toString関数だけ変更すればい。

> WindowsのプログラムならOnXXXXのところにその処理があったほうがよくねーか？

その処理、とは？　newclass_toStringに相当する処理のこと？

>>588
> こんなところさぐってオブジェクト指向わかった気になるのって間違ってると思うんだけどどうよ？

朝からずいぶんな言い草だなｗ
オブジェクト指向分かった気になんかなってないし、
オブジェクト指向が何なのかにさえあまり興味は無い。

今はカプセル化とかポリモーフィズムとか、
そういう個別の恩恵についてコメントしてるだけ。
オブジェクト指向がどうの、という結論は求めてない。

>>591
まやかしか…確かに。

だが、前提として責任が明確に分かれているのは、利点ではないか？

>>594
は？見た目が変わってないのに挙動が変わってる状態のどの辺が明確なの？

見た目って、どこの見た目？

>>596
ポリモった部分
ちなみに言っておくけど俺の立場はＣ＋＋反対派な

Ｃ＋＋っつーかオブジェクト指向反対派だな
特にポリモなんて完全に後付けでしかもこれ入れた奴ってオブジェクト指向理解できてないだろ
そういうわけわからん経過も含めてこの機能は嫌いだな

Cの構造体でできることは、インスタンス変数とクラスメソッド（staticメソッド）の組み合わせでしょ？
インスタンス変数とインスタンスメソッドの組み合わせはどうやって作んの？

前に上がってる例でいけば
switch文に、増加した分岐処理が記述されている事。
また、増加した処理関数が別名で追記される事。

が、明確だ。という意味かな。

>>598
確かに

オブジェクト指向って、具体的なオブジェクトだけでなくて
人それぞれで考えが異なるような抽象化されたオブジェクトも含んでる
ポリモーフィズムはそう言った分かりにくさを助長してるかもしれん
それなのに、型名による動的な分岐は簡単に出来ない

でも俺はC++好きだけどね

ポリモーフィズムが嫌いなら、関数ポインタでループさせるのも嫌いなんだよな

>>591
簡易的なメモリ管理クラスを継承したクラスを使用すれば
固まったプール作らなくても実現できる
管理方法の切り替えも楽にできる

もちろんオブジェクト指向じゃなくても可能
ただ切り替えが分かりやすいってだけだがね

カプセル化やポリモーフィズムは好きだが、
C++は好きじゃない。C#も好きじゃない。それらに比べりゃCが好き。
ただCでOOPLの真似事をしようと思うくらいなら、素直にC++を使う。

>>601

「型名による動的な分岐は簡単に出来ない」かどうかは、継承元となっているクラスの
設計次第だろう。オブジェクト指向そのものの問題ではない。

object.GetType().Nameみたいなので型名が取得できれば、分岐は簡単だ。

C++のtemplateはどうよ
ポリシークラスこそオブジェクト指向

>>605
可能かどうかの話だったら可能だよ
言語仕様の話かもしれないが、リソースとして名前を持つんじゃなくて
型名で分岐させる方法があるべきだと思ってる

ポリモー（ｒｙこそがＯＯＰの肝じゃなかったのか

>>599
非OOPerどもは、そもそもクラスメソッドとインスタンスメソッドの区別がつかないし、
インスタンスメソッドを使う理由もわからない。
変数と関数ポインタのまとまりをオブジェクトと勘違いしてやがる。

>>606
俺（>>581,584,592,593,604）ね、それ大嫌い。
あんなもんで静的にポコポコ複製させて、
肝心のOOP機能については消極的でさ。virtualつけろとかなんとかｗ
Javaみたいに基本virtualで例外finalにしてほしかった。ケチくさいんよｗ
ハゲ（すとらうすとらっぷ）は自分の本のなかでテンプレートをひたすら自賛してたけど。

>>610
静的な「構造」のみを提供するのがtemplateだからね
複製は仕方ねえよｗ

部品と構造（設計）、具体的なオブジェクトを分けて考えるならtemplateは強力
言われてる通りまだまだ発展途上だけどね
これが使いこなせてこそオブジェクト指向が語れると思う

>>608
俺はそう思わない
あくまでも副産物的なもの
ポリシークラスによる部品と、構造を提供するtemplate
クラスのカプセル化こそが本質

そんな難しい話はわかりませんが、同じ引数の同名関数を大量に生産するのはやめてくださいｗ

>>609

ああ、俺にもクラスメソッドとインスタンスメソッドの区別 ― というか、その区別の存在意義 ― は
良くわからない。

「インスタンスメソッド」とはいっても、そいつはクラス設計で定義されているんだから、
「インスタンスメソッド」を、インスタンスごとにオーバーライドできなければ、それは、結局、クラスの
メソッドなのだ。

真にあるインスタンス固有のメソッドがある言語は、Io言語みたいなやつ。というか、この言語では、
クラスとインスタンスの区別がない。

>>613
コンパイル後だから別にいいじゃん
exeファイルのサイズが制限されてるんならわかるが

>>614
ポリモーがあるから分けてるだけじゃね？
便利だけど俺もあんまし好きじゃない

interfaceに対してプログラミングせよ、ってまだメジャーじゃないんだな。
多態性のメリットって結局そこだと思うんだが。

>>611
テンプレートなんてはじめＣ＋＋に入ってなかっただろ
完全に後付けかつオブジェクト指向と関係無い
お前、なんか違う方向行ってるぜｗ
ちなみに継承も後付け

後付け機能はホント使えないのばっかだな

てかクラスメソッドとインスタンスメソッドなんて全く別モンじゃねえかｗ
クラスメソッドなんて非ＯＯＰと変わらんｗ

>>618
後付けだから関係ないとかわけわからんこと言うなよ
よりオブジェクト指向の方向に進化してる

template使ったことないだろお前

>>620
バーカ、無くてもオブジェクト指向言語って主張してた時期があるのに
明らかにいらねーだろそんな機能
だいたい言語の機能一つとって設計と関係ない内容重視してんじゃねーよ低脳
だからお前みたいなのは役に立たないっていうんだよ

エージェント指向はどうなった？

というか、これからはCPUのマルチプロセッサ化が急速に進むだろう
から並列処理を簡単にできる言語、しかもオブジェクト指向と矛盾
しない言語が望まれるのでは？

>>621
わからないなら無理にレス返さなくていいよ

>>622
コンパイラの最適化では使われそうだけど、どうなんだろうな
ユーザに指定できたとしてもCPU命令を直接扱うのって面倒だしね

>>623
アレアレ？もしかして得意になってテンプレート勉強したんだけど
実はまったくオブジェクト指向と関係なかったってオチついちゃって意気消沈？ﾆﾔﾆﾔｗ

>>625
>>620
わからないなら無理にレスしなくていいって

>>626
アレアレ？
ageちゃうの？
もしかして図星？ﾆﾔﾆﾔｗ
全然関係ないことに時間費やしちゃった？ｗ
ざーんねんｗテンプレートをどんなに一生懸命勉強してもオブジェクト指向理解できないからｗ

templateってあくまでＣ＋＋の特徴的な機能であってＯＯＰとは無関係だろ

>>628
はぁ？特徴なんて表してねーだろ
寝ぼけんなよｗ
オブジェクト指向を全く理解してないアフォの入れたオナニーだ

だって別にtemplateってオブジェクト指向関係なしに使えるよねえ

>>628
メソッドのポリシークラス化によって型にとらわれない部品を作成できる
そのポリシークラスを利用する構造をまたtemplateによって記述できる
使う側はすでに用意された構造のみを利用して新しいオブジェクトを作成できる
だから、具体的に記述箇所がほとんどなくなる

新しいプロジェクトごとに細かいメソッドを用意することがない
プラモデル作るような感じで、部品を取り寄せるだけでよくなる

それって、フレームワークや組み込み関数と
同じレベルで使ってるってこと？

業務に特化した基礎クラス作ればいいとは思うが…

>>632
同じレベルというか、型レベルで最初からアダプタになってる
同じレベルで扱うこともできるし、自ら作成した特化したポリシーを使ってもいい

業務に特化したクラスを一度作ったとしても
次のプロジェクトでそのまま流用できるほど汎用的に作ってあっても
無理な仕様変更には対応できない
やっぱり新しいクラスを作らなければならない

これは、プログラミングするということ自体が動的動作を目的にしてるから
コンパイル時点で切り替えるということをtemplateは実現できる

＞コンパイル時点で切り替えるということをtemplateは実現できる
コンパイル時点で切り替えるということはできない
templateはそれを実現できる

です

何でもできるみたいな言い方になってるけど、事実なんでもできる
プログラミングが継承とコンポジションの構造、テンプレート指定子だけで終わる

質問、JavaやC#のジェネリクスとはどう違うの？

とは言え動的に切り替えたいことだってありますから

>>624
クロックが頭打ちとなった今、並列処理にマッチしたパラダイムが必要なのでしょうね。
そういうものとして今までに候補にあがったものはどのようなものでしょうか？

>>622
> 並列処理を簡単にできる言語、しかもオブジェクト指向と矛盾しない
すくなくとも、オブジェクト指向なんかいらん！
オブジェクト、オブジェクト言う奴に限って並列化のこととか、どこ吹く風だしな

>>639
っ【Scala】

>>638
すまん、あまり詳しくないんだ
GPGPUもまだわからない状況だし、マルチコアCPUの命令仕様も扱ったことない

ただ言えることは、
まだif分岐が起こるとそこで先読みが打ち止めになる
最適化で分岐を減らしたり、本当に単純な分岐を別のCPU命令に置き換えると爆速になるのは今も変わらない
CISK RISKレベルのシフトが起こるかもしれないけど、まだまだ先の話

並列化は制御に対して行われるものだから、
オブジェクト中心で考えるオブジェクト指向とは相性が悪いよ。
制御構造をないがしろにしてきた罰だな。
オブジェクトの振る舞いを記述することで、プログラムを表現しようという発想が、
本当に正しかったのかどうか今一度見直しましょう。
そもそも、プログラムって何でしたっけ？
「運動会のプログラム」のプログラムってどういう意味？
プログラムの本質は何？
プログラムの提供する機能は、何によってもたらされる？
何を中心に考えるべき？
何を「指向」すべき？
本当に大切なものが、ないがしろにされて無い？
わかりやすい「物」よりも、
見えにくい「何か」が大切だったりするものなんじゃないの？

並列化と言ったら関数型だな

関数、いい言葉だ。
関数は英語でfunctionと書くが、機能もfunctionと訳される。
これはとても重要な事。

>>642
知ったかぶりもここまで来ると感動的だな。

>>644
オブジェクト指向と違って、君の大好きな手続き型の対極に位置する概念なんだがな。。

人間の使いやすさと、機能性、性能とか
ぜんぶ手に入るものなの？

処理系やコンパイラが頭よけりゃいいのかな

>>646
> 人間の使いやすさと、機能性、性能とか
それを 「どこに向かって言ってるか?」 だな

写像としての関数なんて、数学と文字列処理で、
演算子と一緒の場合に使う時くらい。
他にはほとんど使えない。
何かに使えないかという工夫なのか、
エラー発生を通知するboolを返す関数が常態化しているが、
try出現で古典的手法になったじゃん。

関数なんてほとんど形骸化しているんだよ。
実際、戻り値なんてほとんどの場合いらないんだよね。
void関数が大活躍なのに、return必須とか鬱陶しいくらい。

OOPで、methodという名前に変更されたのもうなずける。
methodは、functionというよりBASICの命令文なんだよ。
object.method()というのは、
「objectさんは、methodして」という命令文。

>>648
on error goto

例外なんぞ劣化したgoto

危険性を取り除いたgotoと言い給え

いずれにせよ所詮 goto

GO★TO

関数という超エレガントな発想を否定してしまうとは。
OOP脳は怖いね。

> object.method()というのは、
> 「objectさんは、methodして」という命令文。

object1 さんと object2 さんに method してほしい場合はどうするんですかね。
method( object1, object2 )とは書けないですよね。
object1.method( object2 ) と書きますか？それとも、
object2.method( object1 ) と書きますか？
こんな簡単なことにすら頭を悩ます必要がある、それがOOP。

http://ja.wikipedia.org/wiki/サブルーチン
> 関数 (function) が返す値は戻り値（もどりち）または返り値（かえりち）と呼ばれる。function が関数と
> 訳されるのは、単に機能の実装を行うだけでなく、引数としてとりうる値の集合から、戻り値としてとりうる
> 値の集合への写像のように捉えることができるためである。したがって、ほとんどの命令型プログラミング
> 言語では次の点において数学の関数とは異なる。
>
> * 引数が同じでも状況に応じて戻り値が異なる（状態を持つ）
> * 関数の処理の実行によってシステムに変化が発生する（副作用を持つ）
> * 戻り値が存在しない場合がある
>
> ただし、純粋な関数型言語における関数は、状態や副作用などをもたず、数学の関数に近い性質を持つ。

> object.method()というのは、
> 「objectさんは、methodして」という命令文。

あー気持ち悪い。日本語的には
「objectをmethodしてください」、でいいだろ。
それが英語風だとmethod( object )になるってだけで。
なんだよ、objectさんって。
オブジェクトには処理手順がくっついてるってだけで、
実際に処理を実行するのはCPUなりスレッドなりだろ。
すくなくとも、オブジェクトが実行するわけじゃねーだろ。

>>654
object1とobject2が相互に入れ替え可能な処理ならその通りだけど、
それはmethod(object1, object2)でも同じことだよね。

入れ替え可能でないなら、どちらを先に書くか悩まなければいけないのは
どちらの記法でも同じだし、むしろ非対称なobject1.method(object2)の方が
意味が確定しやすいとすら言える。

>>656
「methodの処理を実行する。それはobjectの責務である」って考えてみたらどうか。

あーまた何か言い出した。
どちらを先に書くか悩む？なにいってんだ。
そんなもんは好きにすればよい。
関数作るやつが勝手にきめりゃいいんだよ。
単に処理の対象としてobj1とobj2を指定するってだけなんだからな。
OOPの場合、まずもって、いずれかのオブジェクトに処理をぶら下げるのが美徳なわけだが、
その処理が複数のオブジェクト間に作用するものである場合、
どのオブジェクトにぶら下げるのか迷うし、どこにぶら下げても「汚い」。

すべての処理が、必ずなんらかのオブジェクトに関連づくとは限らない。
これは、制御構造とデータ構造が本質的に別物だから。
なのに、処理をオブジェクトに紐付けるのは愚行だ。

データは単体では何もできない。複数のデータが相互作用しあって初めて機能が提供される。
その、データとデータをコミュニケートさせるのが「制御」。
制御はデータとデータの間を取り持ち、機能を提供する。
つまり、制御はデータとデータの「間」にあるもの。
それをデータにぶら下げるなんて、アホだね。

>>658
なんで処理の実行が、「処理の対象物」の責務になるんだよ。
rm file もしくは file . rm 。
これ、削除処理はファイルの責務か？
しかもなんでそこまで複雑に考えなきゃならん。
普通に、
　命令　対象物1　対象物2　対象物3
の並びでいいだろ。超シンプル、超わかりやすい。

object.method() を後付けで超飛躍的解釈を施すこと自体が不思議なんですが。
普通に method のかくれた第一引数が object のポインタ、として今までこまったことがないのですが、それは単に私が c++ から入ってしまったせいかなあ？

> すべての処理が、必ずなんらかのオブジェクトに関連づくとは限らない。
そりゃそうだ。

> これは、制御構造とデータ構造が本質的に別物だから。
そもそも何を「本質的」と言ってるのか説明が欲しいところだけど、それはともかくとして、
もしかして「データ＝主体」とか思ってるのかな。

それぞれが責務を持ち、外部に役務（サービス）を提供するのがオブジェクトだとすれば、
外部に対してそう見えていれば良いのであって、別に「データ＝主体」である必要はない。
そうであってもいいけどさ。

とりあえず、オブジェクト指向をちゃんと理解してから批判しようや。
君のやってるのはただの藁人形叩き。

>>660
ファイルシステムはどこ行ったの？


あと、「分かりやすい」という言葉を安易に連発するのはやめないか。
せめて「命令型パラダイムと親和性が高い」とかにしとこうぜ。
純粋関数型や制約プログラミングだってあるわけだし。

>もしかして「データ＝主体」とか思ってるのかな。

なんじゃこれ、なにいってるのかわかんね。
プログラムの主体は機能で、
機能は制御によってもたらされるから、
プログラムの主体は制御だ。
データなんてものは、なが〜い目で見れば一時変数に過ぎん。

専門用語使ってりゃあ自分は気持ちいいかもしれないけど他人に対する説得力は欠けるぞｗ

>ファイルシステムはどこ行ったの？

ファイルシステムは対象物として指定しているか、
グローバル変数として渡るかのどっちかだ。
どちらにしても、何らかの手法で 命令rm はファイルシステムを知り、
対象のファイルを削除する。当たり前のことだろ。

>>664
なら、個々に状態を持った機能＝オブジェクトでいいじゃない。
「責務と役務」というのは、それを外部にどう見せるかという話。

>>666
なら、「ファイルの削除を実行する。それはファイルシステムの責務である。」という
分析も成り立つよね。
ていうか、ファイルシステムなんて「役務（サービス）を提供する責務を持つ機能」そのものだし。

>>667
前半：
クラスがデータを持たない、ただのインターフェイスだってんなら、いいとおもうよ。
要はただの関数のテーブルを外部に公開しているだけっていう。
でもどうせ、内部的なindexやハンドルなんか持っちゃうんだろ。なら却下だ。

後半：
話し合ってる「層」がずれてる。
ファイルをどう削除するかの責任を持つのは rmコマンド だ。
rmコマンドはいくつかのオプション引数をとるかもしれないだろ？
それらのrmコマンドが提供する「機能」についての責任の話をしてなんじゃないのか？
rmコマンドが責任を持つほか仕方ないだろ。

まーいろいろいいたいことはあるが、
まず、処理そのものが状態を持つべきではないんだ。
引数で指定すべし。そんなに手間か？

それから、ここからが本番なんだが、
責務やら役務やら役割やらサービスやら、変な言葉使いやがってよー。
そんなに色々な言葉使ってまで「それっぽく」して煙に巻きたいかよ。
一言「機能」でいいだろ。複雑な言い回ししたって現実は何にもかわんねーんだよ。
「それっぽく」聞こえる、ただそれだけ。

お前らこんなスレにいるぐらいだから、
ぶっちゃけ本当はOOPに嫌気がさしてるんだろ？
マジでマジで。

プログラム書くために、思考の形態を、そのまま記述できる手法は良いと思う。

自分の場合は、いかにフローに落とすか、ってイメージが強いなぁ。
木構造でしか考えられないな…。

>>668
> でもどうせ、内部的なindexやハンドルなんか持っちゃうんだろ。なら却下だ。

え？ なんで？ 世の中、自分の「状態」を持たないサービスの方がむしろ少数派だよ？
例えばだけど、ファイルシステムとかGoogleとか2chを、役務（サービス）を提供する
オブジェクトと考えてみたらどうよ。

> ファイルをどう削除するかの責任を持つのは rmコマンド だ。
> rmコマンドはいくつかのオプション引数をとるかもしれないだろ？
> それらのrmコマンドが提供する「機能」についての責任の話をしてなんじゃないのか？

っ【Commandパターン】

「コマンド」だって、自分の役務（サービス）を提供するオブジェクトの一つと看做すことも
できるわけでね。それと同様に、Fileオブジェクト（≠ファイル）とかファイルシステムを、
固有の責務を持ったオブジェクトと看做す、という分析も同じくらいアリだというだけの話。

>>669
> まず、処理そのものが状態を持つべきではないんだ。

そうだよ。状態を持つのは「オブジェクト」だ。
とりあえず、そのオブジェクトがどう実装されているか、という部分はブラックボックスとして
考えてみるのが良いと思うよ。んで、Javaでいうinterfaceだけでコーディングする世界を考える。
（オブジェクトはマイクロコンピュータである、ってのはアラン・ケイの台詞だったか？）

> 引数で指定すべし。そんなに手間か？

小規模なコードなら、君の言うとおり、あまりご利益はないかもね。
状態が複雑に絡み合った大規模なコードでこそメリットがある考え方、というのは前提。

> 責務やら役務やら役割やらサービスやら、変な言葉使いやがってよー。

一般的な用語だと思うけどなぁ。
一つ言えるのは、「機能」をどういう形でどの責任範囲で外部に提供するか、
という側面を強調している点で一貫してるよね。

>>642

意味不明だ。オブジェクト指向は制御を阻害しないぞ。多数のスレッドを扱うならば、むしろ
クラスのインスタンスで非同期メソッドを呼び、個別結果をインスタンス変数に格納し、全体状況を
スタティック変数に放り込むほうが楽だろう。

>>643

並列化までは、オブジェクト指向だろうが関数型だろうが、あまり変わららないかもしれない。
超並列化時代に突入するまでは、関数型が主役になりそうにはない。

長文ご苦労としか。OOP脳では所詮この程度か。
知ってて当たり前のことしか書かれてない。あー言えばこう言うの世界。
それでも、OOPが優勢になることはないんだよ。
これはもう時代の流れで決まってること。
共産主義と同じですたれるのだ。
なぜそんなことがいえるか、この辺の感覚的な部分は、
なかなかわかってもらえないようだけど、
なるべく簡潔に説明すると、
プログラムの機能は、
「制御でデータの関係を定義する」
ことで成り立つから。
オブジェクトに制御をぶら下げた時点で、構造的におわっとる。

変な言語を使い、変な思考で構築しているうちに、
変な頭になっちゃうのさ。あーおそろしー。
右も左もわからないやつが使うのがOOP。

開発環境のベンダーなんかは、わざとやってるのかもしれないがな。
檻に閉じ込めておくために。洗脳おそろしや。

>>654
OOPをサポートする言語のほとんどにはstatic関数があります。

なぜ、static関数のような非OOP的機能が用意されたかを考えなさい。

大体struct使う奴にOOPうんたらとか言われると微妙に気分が悪い。

C++最強説浮上

>>675
> プログラムの機能は、「制御でデータの関係を定義する」ことで成り立つから。

だから、それは数ある分析手法の一つでしかないと何度（ｒｙ
大雑把に言えば、「ユーザがどんなサービスを受けたいか」とか、
「写像と制約によって何を定義したいか」とかでコード化する対象を分析し、
コードを記述する手法が数多くある。
命令型パラダイムはそのうちの一つに過ぎない、それだけのことだ。

んで、要求が複雑になり変化が早くなったことで、「どんなサービスを受けたいか」で
定義する手法の需要が上がっているのが現在。
はっきり言えば、君のそれは、手続きベースでプログラムを書く人間の都合を押し付けてるだけなんだよ、
そんなもんは「本質」でもなんでもない。

車1.ワイパー()

は納得いくが、

車1.洗車()

は確かに気持ち悪い。
洗車機能は、洗車機にあるのであって、車にあるわけではない。
そいういうときはstaticで

洗車機::洗車(車1)

とすれば無問題なのかもしれない。

だが、多数の自動車インスタンスを一括して洗車()したい場合、どうするか？
という問題がある。
もちろん、いろいろなタイプの自動車が入り混じっているし、
続々と新車が発表されている。
で、解決に、

foreach (車配列){ ((洗車可能)車).洗車(); }

のような一括処理のために、やっぱり、車クラスに洗車メソッドを付けてしまう。
一見エレガントでも、こういうのは気持ち悪いと言われればそうかもしれない。
でもこれはOOPの問題というより、クラス設計の問題だが・・・

ああ言えばこう言う。
>「どんなサービスを受けたいか」
言い回しがすでにきめぇ。何で変に受身なんだよ。
普通に、
「必要な機能は何か」
でいいだろ。そういうところが頭おかしいっていってんだよ、受身野郎がよ。

車に基づいて洗車の処理が決定するようだけど、
他の要因でも洗車の処理が変わりうる場合はどうするんだ？

俺はずっと手続き型で来た人間だけど。

>>684
UPの開始工程が要求分析だからじゃないの？
客先がプログラム知らんから頭悪そうな言い方になる。

普段から自分たちを奴隷に見立ててるから、
「オブジェクト様が〜なさる」、みたいな発想になるんだよ。
プログラムは指示書なんだから、
「これとこれとこれ、あれしといて」
でいいんだよ。

>>683
車≠Carオブジェクト。
責務を適切に分割できるほうを選ぶよろし。

>>685
1. 車からその要因を参照するなり処理を委譲するなりする
2. 洗車機を導入する

どちらが最適かは、もちろん状況による。

>>684
1. プログラムは、ユーザ（自分含む）が利用「する」ためのもの。プログラムは利用「される」もの。
2. 複数人開発において、他人の書いたコードは利用「する」ためのもの。自分の書いたコードは利用「される」もの。

受身じゃないプログラムの存在意義がどこにあるのか、逆に知りたいな。
合理的に教えてくれ。

> 1. 車からその要因を参照するなり処理を委譲するなりする
結局車だけで処理を決定できないから、要因を参照して分岐したり、
たらいまわしにしたりするってんだろ。
だったら、はじめから車に洗車メソッドなんぞ付けるべきではないよな。
セッターとゲッター程度にしとけという話。

> 2. 洗車機を導入する
中でswitchするんですね、わかります。

>>690
そこは視点による。

1. 「車」の外部から見た時に、「車」が提供するサービスとして一貫性があるなら、
　　内部実装がたらい回しでも無問題、の場合もありうる
2. オブジェクト単体で処理を決定できる場面の方が少ない。
　　オブジェクトが、他のオブジェクトのサービスを利用して処理を組み立てるのはむしろ自然。
3. 「洗車機」は巨視的視点 or 仲介者の話であって、必ずしもswitchの話ではないお

合理的合理的うるっせーな。
合理的ってアホの使う言葉だぞ。知っとけ。

「する」とか「される」とか、お前の価値基準はそれしかないのか？
お前は幾何学的思考能力がねーんだよ。
だから、あっちから見るとこう見えるし、こっちから見るとこう見えるし〜
って考えがふらふらしてんだよ。
レス読み返してみろ。「それは一つの考え方にすぎない、他の解釈もある、逆の考えもある」
とかそんなばっかだろ。いちいち自分の立場を変えるな。上から見下ろせ。
見えたものがすべてだ。

　プログラムの機能は、
　「制御でデータの関係を定義する」
　ことで成り立つ。

　プログラムは指示書。

西洋的な考え方も少しは学べ。じゃないと人生損するぞ。

また、「視点による」とか言ってるし。
そうやって、視点を変えて、同じところをぐるぐる回ってればいいよ。
ただ、どっから見ても、たとえ見え方が違っていたとしても、
「現実、事実、真実」が変わったわけではない、ってことは知っとけ。

あと、俺からの忠告。
どうしてもOOPしたいんなら、データを持つオブジェクトのメソッドは、
セッターとゲッターだけにしとけ。
そんなのOOPじゃねーっつーんなら、もうOOPやめとけ。

>>692
合理性を軽視するプログラマとか、本気で意味が分からないんだが。。


ていうか、「見えたものが全てだ」ってのは俺がずっと言ってることなんだけどね。
コードを使う側（ユーザ、他のコーダ）から見た時の一貫性を基準に分析する一手法が
オブジェクト指向、というのが俺の解釈。

>>693
西洋から学べとか言ってる割には、哲学に疎そうな台詞が。。
まぁ、君と哲学論争をしたいわけではないのでやめておこう。

いつ「西洋＝西洋哲学」になったんだ？

合理性合理性いってるやつに限って合理性がねーんだよ。
本当の合理性を知らない。言ってる意味わからないだろ？そーだろうな。

>コードを使う側（ユーザ、他のコーダ）から見た時の一貫性を基準に分析する一手法が
>オブジェクト指向、というのが俺の解釈。

それはお前がアホだということ。
遣うか遣われるかの価値基準しか持ち合わせていないということ。
それにしがみ付いて、おかしな病気になっている、ということ。
「機能」と「役割」の区別がついていないということ。

>>697
> 遣うか遣われるかの価値基準しか持ち合わせていないということ。
> 「機能」と「役割」の区別がついていないということ。

そこをもうちょっと理路立てて順番に説明しておくれ。

>>687
むしろその「あれしといて」がOOPだと思うのだが。
その例えだと、非OOPは…そうだな、大手製造業の社長が
部品1つ1つの取り付け方の指示書書いてることにならないか？

オブジェクト指向は、オブジェクトがメッセージをやり取りして、ってのが定義だったはずなのに、
それすら自分の解釈で勝手に捻じ曲げる。
というか、かってに捻じ曲がるのだろうな、
人より次元の少ない物差しですべて測るわけだからな。
そして、変な形で再構築されるわけか。
使い手視点からのコーディングがOOP？笑わせるな。

>>698
機能は関係が主体。かつ能動的。
役割はパーツが主体。かつ受動的。

>>699
「これを、あれしといて」がOOP。
「これとこれとこれを、あれしといて」は非OOP。
OOPでかくとこんなことになる。
これ.あれ(これ, これ, これ)
どの「これ」に「あれ」を紐付けましょうかねぇ。

> オブジェクト指向は、オブジェクトがメッセージをやり取りして、ってのが定義だったはずなのに、
全然ちがってるし
アランケイのオブジェクトとハゲのオブジェクトがちがってることくらい当たり前だろ

>>700
> オブジェクト指向は、オブジェクトがメッセージをやり取りして、ってのが定義だったはずなのに、

人によってわりと定義が違うのは指摘の通りで確かに悩ましいけど、俺の解釈であるところの
> 使い手視点からのコーディングがOOP
ってのは、その説明を別の角度から言ってるだけだよ。
各オブジェクトが主体であると同時に客体であり、メッセージによって他のオブジェクトと相互作用する。
つまり、使う側にとって、使われる側のオブジェクトは自身の責務とサービスが明確でなければならない。

世界に自分ひとりしか居なくて、それで世界が完結してるなら、相互作用だのサービスだの考えなくても良いだろうけどね。

>>701
それ、俺と全く同じことを言ってない？

役割はパーツが主体だから、聞こえがいいんだよ。
「〜さんは〜の役割を担ってる」とかな。
その、甘い響きに魅了されてアホが引っかかる。
ウソも方便ってやつ。でもウソはウソ。
機能は人々で成り立つ(人々ってのが重要)、そういう冷たさも必要だし、
エンジニアならそうじゃなきゃやってけない。システムとはそういうもの。
〜が〜の役割を担う、じゃなくて、
機能は〜や、〜や、〜で成り立つ。(複数なのがポイント)

相互作用はOOPの苦手分野だろうがよ。
object1.communicate( object2 );
変だろ？
communicate( object1, object2 );
だよな。

>>701
あれ(これ,これ,これ）って命令は、特殊な状況でしか出来ないんだけどね。
ついでにOOPは非OOPの考え方を含むので、その書き方を排除する理由はない。
OOPであろうがそう書けば良いだけの話だ。

>>705
private Foo foo;

public void method() {
　　foo.bar();
}

>>704
その話とオブジェクト指向の関係が見えないんだけども。

こんな感じのやつらに、それぞれいつものやっといて
みたいなことができるのが便利

>ついでにOOPは非OOPの考え方を含むので
なにそれ

>>710
え？

>>708
OOPは複数の対象物間の関係を記述するのが苦手だろ。
staticなメソッド作れとか言ってるやつも居るが、
それは非OOP的発想だわな。
しかもオブジェクト同士がコミュニケートしている箇所が「重要」な処理なのに、
その「重要」な箇所を非OOP的に書くとか。だったらOOPってなんなんだ。
肝心なところで機能不全ですか？

>>710 >>712
OOPは手続き型や関数型などと組み合わせて初めて威力を発揮するもの。
ハナっから単体で存在しようなどとはしてないんだよ。
手続き型のOOPLなら、手続き的にやるべきところは手続き的にやれば良い。
あれ(これ,これ,これ)としたいならそうすれば良いだけ。

変わるとすればその先の、あれ()の内部の書き方だろうな。
渡された「あれ()」は各引数に対して何かをする処理を書くだろうが
その各「これ」に対する具体的な処理は、OOP的には「これ」のメソッドとして書くことになるだろう。
仮に「これ.それ()」だとすれば、それ()内部はやはり手続き的に書くだろう。

つまり、メソッドはセッターとゲッターだけになるってことだろ？
もっとも安全なOOPの使い方で、俺も推薦するけど、
それ、機能不全だろ。

セッターは慣れるほどに微妙な存在になるけどな。
てかカプセル化だけなら安全なだけで便利さはあんまりないよ。
ポリモが使えるようになった時、OOPの真骨頂が見えると思う。

そして機能不全は別に否定しない。OOPだけで何かが出来るというモノではないからね。

ポリモでたー。
ゲッターとセッターだけのクラスでポリモが役に立ちますかね。
俺なら素直にタイプ値でswitchだな。
switch嫌う人も居るけど、制御構造が明確というメリットがある。

そして、セッターとゲッターもアホらしいので、もう構造体だ。
まーOOPはデータの管理に使えばうまく機能すると思うよ。
コンテナはうまく機能している。

何使う場合でも結局大事なのはバランス感覚だよな。

対象になりうる型の種類が少なければ型switchでも良いんだけどな。
対象が増えてくると辛いと思うぞ。
それこそ何が入っているか不明なリストとかも存在するし。
標準ライブラリと添付ライブラリと各マが作った自作クラス全部そこに書くのか？
んで各自は新しい型を作る度に「要修正関数リスト」みたいなのとにらめっこするのか？

ポリモが必要な新しい型をポンポン作る機会なんてねーよ。
それ、設計ミスってる。

ん？新クラス作っておおよそのフィールドが出たら、とりあえず文字列化メソッドぐらいは実装しない？

「何が入ってるか不明なリスト」とかいう前提だとOOPだって無力じゃねえか
ルートobjectのリストとするしかないわけだろ
ルートobjectに全機能をぶち込むか

いつもそんなリストと戦ってるんですか。大変そうですね。
僕は楽な仕事ばっかりでよかった！

>>675

プログラムの機能が「制御でデータ関係を定義する」ことで成り立つとしても、「オブジェクトに
制御をぶら下げた時点で、構造的におわっとる」が即座に正しくはならないよ。構造的に
終わるかどうかは、使う側の選好の問題だからだ。

HaskellにO'Haskellが出てきたり、MLにOCamlが出てきたりと、実際にはオブジェクトに制御を
ぶら下げたほうが人間にとって分かりやすい。新生児からの成長の過程での学習が、
オブジェクト指向的だからだ。

>>683

洗車機のインスタンスで車のインスタンスを洗車するのだから、洗車機::洗車(車配列)を
インスタンスメソッドとして実装するべきだろう。

複数の車を洗車するということがよほど特殊なことでない限り、foreachなことは、
洗車機::洗車(車配列)本体に収めてしまえばいい。

>>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は複数の対象物間の関係を記述するのが苦手」とか言われても意味が分からん。

>>722
分割統治という言葉を知らないのか。そんなんでよくプログラマやってるな。

>>726
で、foo.bar()の処理の決定に、hogeが要因になる場合はどうするんだ？

>こういう関係が幾重にも重なったり、一つのクラスに属するオブジェクトが
>多数登場するような状況で威力を発揮する。

想像してみよう。
1．各オブジェクトは自分に関係のあるオブジェクトへの参照を持つ。
2．各オブジェクトは自分自身に対する処理しかしない。

プログラムの機能をオブジェクト同士の化学反応に頼って成り立たせるわけか。
あほだ。

>>728
生成時 or 実行時にHogeをFooに渡せばいいんじゃね。
本当にHogeごと渡さなければいけないか（＝状態を別クラスに分離できないか）は要検討だけど。

まずいのは、各オブジェクトの性質で、最終的なプログラムの機能を決めようとしていること。

>>729
>>731
具体的にどういう弊害があるのか論証しておくれ。

>>730
で、foo.bar()の扱いはどうなるの？
hoge.method()の中で呼ばれるfoo.bar()の中で、さらにhogeのメソッドを呼び返すの？
hogeは今hoge.method()の実行中で、状態が不完全であるにも関わらず？
カプセル化ってなんだったっけと、考えさせられるな。
処理が完了していないまま、互いのメソッドを呼び出しあうと、
カプセル化は崩れるわな。何のためのOOPやら。

>>733
> hogeは今hoge.method()の実行中で、状態が不完全であるにも関わらず？

それがクリティカルになるケースなら、そもそも２オブジェクト間の委譲ではなく、
仲介者を用意するなりなんなりするべき。

>>733
オブジェクト同士が、お互いのメソッドを呼び合うとかはやるな。
同じメソッドを呼び合うようなことのないように>>734とかやり方は色々あるけど
ただそれ以前に、カプセル化の意味を何か勘違いしていないか？
カプセル化は外部が直接状態を書き換えられないようにする、ってのが本質で
その際の信頼性については言及しないと思うぞ。

そもそも、オブジェクト同士が互いに強く依存しているコードは、
機能がきちんと疎結合になっていないわけで、設計レベルでの失敗も疑うべきだな。

>>735
なるべくアトミックになる単位で操作を提供するのが望ましくはあると思うけどね。

>>734
>>726の
>　（getterとかどこにも書いていないことに注意）
は破綻したわけだ。
それがOOPの限界。

>>735
>カプセル化は外部が直接状態を書き換えられないようにする、ってのが本質で
>その際の信頼性については言及しないと思うぞ。
マジで？俺の中でカプセル化の地位が下がった。

>>737
1. 呼び出し順序が問題になるような双方向関連、みたいな特殊なケースを一般化して何がしたいのか分からん
2. なぜ仲介者が存在するとgetter使わなきゃいけないと思ったのか説明を

あと、>>732への返答がまだだね。

ちょっとまって、これは返答に付き合う義理はないよね、レベル的に。

>>724
>HaskellにO'Haskellが出てきたり、MLにOCamlが出てきたりと、実際にはオブジェクトに制御を
いやいやいやいや
O'Haskellの最終更新日見た？論文書く人以外に誰か使ったと思う？
OCamlでオブジェクトが嫌われ者だってのは割と常識だよ？

関数型の世界はよく知らんけど
手続き型の世界じゃもう一般教養

>>740
レベル＾＾；

template厨はどこへ

アンチOO君は何処行った

アンチOOじゃねぇけど, OO意味ねぇ!!!
アホが書くと object に隠蔽したグローバル変数の大群じゃねぇかw

そりゃ、OOPLを使えばOOになるわけじゃないし。

OO自体は意味あるが、OO信者はいらない。
そういう奴は実行フローが見えてないから、バグ出ても自分の責任だという認識がない。
本来設計はそのためにあるのに、デバッグ段階の症状を見ても原因を特定できないのは
勘弁してほしい。何の関係もない別プロジェクトの人間が何で口出さなきゃならんのだｗ

そういう奴は、「OOとは何ぞや」と説くよりもデザパタ暗記させた方がマシになりそう。
デザパタは暗記して意味のあるもんでもないけど。

世間でよく聞くオブジェクト指向ってさ、その文脈をよくよく吟味してみると、
オブジェクト指向のある一種類だけを取り上げて、それで全てみたいな感じで
語られるから、かなり誤解されている部分が多いような気がする。
っていうようなこと言うと「じゃあ、その他の種類ってのを挙げてみろよ」と
喧嘩腰で食って掛かってくるひとが必ず出てくるから、話が進まないんだけどね。

>>750
それでしたら、その他の種類のものを一例挙げて頂けないでしょうか。
その上で何か興味深い議論をさせて頂けたなら幸いです。

よろしくお願いします。

>>726
ポインタの保持なんてしてるじゃん
fooにいれたもんは生きてるか死んでるかわからないじゃん
これでカプセル化を理解してるとか最低最悪だな
fooがぶっこみ料理だったらなんでもできちゃうじゃねーかよ

こんな素人が金もらってプログラム組んでるから世も末だなって思う

xxx yyy = new xxx();

>>752
君は、ガソリン車に灯油を入れてエンジンぶっ壊して逆ギレするタイプ？

マジレスすると、普通にvalidationして例外投げればいいだけの話。

>>754
全然違うこと言ってない？
いつの間にかにHogeでfooの内容が変更されている恐怖を
他のクラスはどうやって知ったらいいの？

その実装ってグローバル変数の恐怖とまったく変わらないじゃん
仮にfooがグローバルインスタンスホルダー的超巨大クラスだったときとか
もうカプセル化なんてまったく気にする必要がないウンコ設計じゃん

>>755
グローバル変数だと直代入されたらどうしようもないが
カプセル化してるなら「変更されたら他のクラスに知らせる」って実装も漏れなくできます。

もしくは「変更されたかどうか確認する」メソッドを持つことも出来るし。

>>756
俺のレス復唱してくれるかな？

まあ、とりあえずクラスのメンバ変数にfooはあかんよ
こんなのもった時点でカプセル化なんてまったく意味ないわ
他どんなにいいわけしたってこれじゃなんの制限も活きてないじゃない
まったくやってること無駄だわ

こんなの基準にして設計勉強しちゃってる時間がそもそも無駄だわ
意味ないじゃない
なんのためにカプセル化してるの？
勝手に変えられちゃうの嫌だからじゃないの？
こんな初っ端のアクセスでクラスに毒物しこむような真似しておいてカプセル化できてますはない

>>755
好きなのを選んでくれ。
1. Fooのインタフェースを適切に設計してカプセル化し、不適切な操作を防ぐ
2. Fooを最初からImmutableオブジェクトとして設計する
3. Hoge#method()の挙動をきちんとドキュメント化する

そもそも、影響範囲は最大でもfooインスタンスに限定されるのだから、
グローバル変数と比較するのはおかしい。

> 仮にfooがグローバルインスタンスホルダー的超巨大クラスだったときとか

それを書いたコーダーをクビにしてからリファクタリング汁

>>758
復唱しても解りにくいぞw
「fooの変更」でなく「fooが参照してるオブジェクトの内部の変更」のことが言いたいの？

>>759
何が言いたいのかよく分からないのだが、
オブジェクト内に他のオブジェクトへの参照を持っておいて、それを呼び出すと、
具体的にどのオブジェクトのどの部分が汚染されて、その結果どのような悪影響があると主張したいの？

あと、>>732への回答もよろしくね。

参照もたせるとJavaだとリークの可能性、C++だと解放済領域への不正参照の可能性があるけど
ここらへんってどうやって回避してる？

>>764
Java: 不必要な双方向参照を避ける
C++: スマートポインタを使う

しょぼｗ

循環参照でもリークするし、
スマートポインタだって同じ理由でリークする

基本的にリークの可能性は回避できない。どうしても防ぎたいなら
適当なタイミングでプロセスごと終了（再起動）するよう設計するぐらいだね

０にならないから１０も１００も同じ！

いまどき循環参照が問題になるＧＣなんてあるの？

まずはBertrand MeyerのDesign by Contractを勉強しろ。

「interfaceはcontractである」みたいな考え方を表すキーワードって何だっけ。

>>760
それしか解決策ない？
もっとよく考えてよ

>>772
他にもあるかもしれんが、なんか良い方法を知ってるなら教えてくれ。

>>761
fooの変更であってるよ
ただ、もっとわかりやすくいうと
Hoge内でのfooの変更
これがダメ
Hogeのとあるメソッドでfooが使われてるかどうかが外部から見えないのが一番ダメ

これがダメだからのカプセル化なんだし
結果としてカプセルになってないじゃん
Hogeがfooを介してなんでもできるようになってしまっている
fooがグローバルインスタンスホルダー的な仕様のものならこれは最低最悪の実装といっていい
設計なんもわかってないわ

>>774
> Hogeのとあるメソッドでfooが使われてるかどうかが外部から見えないのが一番ダメ

見えない（見えなくてもいい）のが最大のメリットじゃないか。何を言ってらっしゃるのか。
カプセル化は、オブジェクトを無菌室に叩き込んでスタンドアロンにすることじゃないぞ。

Fooは、自分の責務をドキュメント化し、それを確認する単体テストを書く。

Hogeをコーディングする側は、Fooがどんな責務を持っているかだけ知っていればいい。
Fooの実装が、自分の責務をきちんと実装できていないなら、それは単なるバグだ。

fooがきっちりアクセス制御されてりゃいいんじゃないの
そこまで変な設計とは思わない

最強のオブジェクト指向な言語はC++
Javaとかウンコ

>>777
コンポジション知らないプログラマが許されるのは小学生までだよねー（ｒｙ

>>722
それは静的型付けの問題であってOOPの問題じゃないだろ

>>775
ばっかじゃねぇの
アフォか
Hoge呼び出すたびにfooの内容変わってんじゃねーかよ
どこにそんなこと書いてあるんだよ
しかもfooに別のもんが登録されてたら芋づる式にそれまで変わっちまうじゃねーか
もうこの時点でfooの可能性が無限大なだけにHogeの設計は死んでるも同然
使ってる側はHoge動かすたびに何が影響してるのかHogeの中身みてまず
fooが確保されてることを知るしか手はないね
そしたら次にfooの中まで知らなきゃいけないときてる
もう完全に姿勢が「わからなかったらソースを見てください」的な極めて無責任
かつまったくセンスの死んだ設計だね

単純にさHogeのメソッドで必要なときに引数からfooの必要なもんだけ渡したんじゃダメなのかよ
なんで確保しちゃうんだよ
仮にHogeをブラックボックスにしたときに使ってる側はHogeがfooをガメ続けていることを
どこまで認識しなきゃいけないんだよ
ソース見なきゃわからないのかよ
ぶっちゃけ使い難いだろ

>>781
>>776

>>781
> そしたら次にfooの中まで知らなきゃいけないときてる
> もう完全に姿勢が「わからなかったらソースを見てください」的な極めて無責任

↓

> 単純にさHogeのメソッドで必要なときに引数からfooの必要なもんだけ渡したんじゃダメなのかよ

＾＾；；；

Hoge「何かおきたら勝手に呼びますけど、動作の保障はありまん」
foo「何がいつ呼ばれるのかこわいお。仕様変わったらどうすんだお」
ユーザー「仕様書よこせ」
マ「ソース嫁」

>>782
それHogeを使う側のことまったく考えてないよね？
HogeをつかうにはFooの事情にも詳しくないといけないっておかしくない？

仕様を把握せずに使えばどんな設計も糞になるわ

>>784
HogeとFooの両方のJavadocに仕様を書いて、単体テストで保証しとけ。
呼び出し順が重要なら、FooのJavadocにそう書いておけ。
んで、Fooのライフサイクルを整理して、公開するAPIを最小限に汁。

繰り返しになるが、Fooをいきなり#dispose()から呼び始めるコードは単なるバグだ。

>>785
Hogeも同じこと。自分の責務をドキュメント化し、それを確認する単体テストを書く。
Hogeを使う側は、コンストラクタを見れば「Hogeを使うにはFooが必要」ということが分かる。

では、Hogeに与えるFooをどうやって作るのか、というのは問題になるが、必要なら、
HogeとFooを提供する側がそれらを一度に生成するFactoryを用意するなり、
DIコンテナを使うなりすればいい。

循環参照って
ある意味再帰？ｗ

末尾が付く方な

fooの仕様変更がないとすれば
ビルダーとかねてcreate関数でfooを作成してアダプタ作る
仕様変更するならアダプタとインターフェース分ける

単純にfooの機能をラッピングしたいだけならグローバル関数を作る
もちろんnamespaceで分ける
javaならメソッド関数だけで引数のfooをやりたいように呼ぶ

ラッピングした処理自体を拡張したり
fooが状態を保持するようなクラスなら
これもアダプタクラスとインターフェースクラスで分ける

コンストラクタで他クラスを勝手に保持するようなクラスはありえない

コンストラクタで通信が必要なオブジェクトを渡すっていつもやるけどなんでだめなの？

>>792
渡すクラスがおかしかったらどうすんの？
例外処理とか入るならinit関数なりにした方が面倒なくね

もっと具体的に

>>794
何が知りたいの
コンストラクタで例外投げるつもり？
勝手に継承されたりキャストされたらバグ直行じゃん

勝手に継承って動的に継承？
勝手にキャストってそのクラス作るの自分でしょ？
コンストラクタで例外って誰が例外を発生するの？

>>795
まともなコーダーなら、継承クラスのコンストラクタの最初でsuper(Foo)呼ぶけどな。
もちろん、そこを警戒してFactoryメソッドにするのも当然アリだが。

>>796
コンストラクタがいつよばれるか分かってんの？
コンストラクタは初期化だけにしとけよ
つか勉強不足すぎ

まあ、使う側は生成するだけで一行だからすっきり書けるってのはわかる

>>798
いやお前の言ってることが全然分からないんだけどまじで

コミュニケーション不全スレ

>>799
説明する気はない
起こり得る最低限の問題は書いた
わからないなら考えてくれ
反論が正当なら俺も改める

言ってることが分からないから反論もないわｗ

まあコードも書かずにプログラミング語ってもな

一口にコンストラクタといっても、言語は何を想定しているのか。

説明する気はないｗ

なんという典型的なFUD

>>806
連投必死ですか

自分が理解できない人間はキチガイの一人だけと

>>807
俺は>>797と>>804だけだが。

オブジェクトの状態が変更されるのは、当たり前で
その影響が想定範囲外に波及するのを気にしてるなら
作り方自体が問題なんじゃないの？

>>788
ていうか俺の言ってること理解してる？

Hogeがfooに依存してる割にはfooが自由ってのが絶対にバグおこすよ
こんな仕組みにしてちゃダメでしょ
単純にfooを開放したくなったときにHogeにはどう取り繕えばいいの？
こいつは消滅するときにfooが必要だったりするの？
とかいらない心配までしないといけないじゃない
そりゃドキュメントにそう書いてあるとかいういいわけもできるけど
ぶっちゃけそんな必要ないのにそんな仕組みにするのは三流だと思わない

もう一度いうけどfooを保持する必要ってないじゃない？

ＧＣ系ならHogeが解放するまではfooは解放されないね。
C++は解放されないように消滅タイミングを管理する必要がある。
そういう言語仕様なんだからそりゃそうでしょう。
Javaならfooがいつ解放されるかコード見るか仕様を確認するかしかないし
C++だとしたら引数で渡したものはどのように扱われるかはコード見るか仕様を確認するかしかないでしょう。
関係性があるクラスが相手の都合を知らなきゃいけないのは当然でしょ。
保持しないことによりそれが常に改善されるわけではないと思うが。
関係性がある場合ほとんどのメソッドにオブジェクト渡すことになる。
ケースバイケースだと思うが。
コンストラクタで関係性を明示しておくのは普通に一手法だろ。

>>811
1. そもそも何故Hogeに渡したFooインスタンスを、Hoge以外の場所で使いまわすのが前提なのか
2. 仮にFooを色々な場所で使いまわすのが前提なら、最初からimmutableなオブジェクトとして設計するなり、
　Fooインスタンス自身のライフサイクルを確認できる手段を提供して、そのことをドキュメントに明記すべき。

どちらにせよ、あらかじめ保持しようが呼び出しのパラメータとして渡そうが、2の場合なら
Hoge側でチェックが必要なのは変わらん。
FooがHogeの機能の一部であるなら、コンポジションとして委譲する方法がある、というだけの話。

>>810の言う通りで、自分でわざわざバグを作りこんでおいて「コンポジションを使うのは三流」とか
意味が分からん。

>>813
はぁ？
１はなんで他で使っちゃいけないんだよ？
Hogeでしか使わないならHoge内で生成しろよ
２は解決策の心算なの？それ
プログラム組むの下手糞なんじゃない？
単純にHogeで使うメソッドの引数からfooの内容で必要なもんぶち込んでやればいいだけの話だろ？
なんでそれをやたら避けようとするんだ？

おまえがそれで大規模なプログラムをオープンソースで発表すれば多少はみんな言うこと聞いてくれると思うよ。
そのルールが実際に開発で有効かね。

>>814
> １はなんで他で使っちゃいけないんだよ？

使ってもいいよ。他で使うことが前提なら2の対策をするべきというだけ。

> Hogeでしか使わないならHoge内で生成しろよ

もちろんそれでもいいよ。外から与えた方が便利な場合も多いけどな。

> 単純にHogeで使うメソッドの引数からfooの内容で必要なもんぶち込んでやればいいだけの話だろ？

なぜHogeが、直接関係のないFooのサービスを提供できると思ったのか具体的に説明を。

>>815
君は、オープンソースのソースコードとか読んだことないの？
大小問わず、あらゆるプロジェクトで利用されてる基本中の基本テクニックなんだが。

>>817
具体的にどのオープンソースかね。
そんなルールが徹底されているコード見たことないから教えてくれ。

>>818
http://www.apache.org/

アパッチて・・・
お前読んでないだろ

>>820
使ってて仕様に疑問があったら、コードを取ってきて調べるとか普通やるだろ？

CommonsでもXercesでもStructsでもCouchDBでも、好きなのを調べるといい。
Javadocを見てAPIを調べるだけでも勉強になると思うよ

で何が徹底されてるって？

そろそろ現実と向き合おうよ。

>>817
だからなんなの？
どんなにえらい奴やすごい奴が使ってようとダメなもんはダメなんだよ
それとも議論にサジなげて権威で自分の主張を正しいって言い張るつもりで
いった発言なのそれ？
ダサくない？

>>821
Structsって何ね？

>>816
>なぜHogeが、直接関係のないFooのサービスを提供できると思ったのか具体的に説明を。
意味不明
単純にfooはHogeのなんらかの処理で必要だから初っ端に確保してんだろ？
それを必要になるごとに引数で渡せって言っただけだよ？
何を何と勘違いしたの？

＞関係性がある場合ほとんどのメソッドにオブジェクト渡すことになる。
無意味な潔癖症は生産性を下げます

>>824
君が「実績を作って証明しろ」って言ったから、
既に実績は山ほどあるよって教えてあげたのに、これ以上どうしろとｗ

>>826
> fooの内容で必要なもんぶち込んでやればいいだけ

って書いてあったから、Fooインスタンスから内部状態を取り出してHoge内で
処理しろって意味かなっと思ったのさ。すまなかったね。

委譲を使う理由は>>726で既に書いてるよね。

では、改めて>>813が解決策になっていない理由を具体的に論じてもらえるかな。

>>828
>>813の２のこと？
だって無駄じゃん
引数で渡せばそれで終りだし
これ以外の解決策ってほぼないでしょ？
仮にやったとしてもHogeの中のfooの挙動を把握することはできないっしょ？
んでfooをだよHogeを知らない人間も使ってたとしたらHogeまで知らなきゃいけないのはなんかおかしくない？

まあ、コードで書くと

//ケース１
//fooの処理も実行されるがHogeのソースかドキュメントを読まないとわからない
hoge.unko();

//ケース２
//fooが使用されていることが見た目に明らか
hoge.unko(foo);

これのどっちがソース的にいいかっていったら間違いなくケース２だろ？
ケース１はやってはいけないことだ
これはＣ言語の時代から同じな

グローバル変数・関数がダメな理由といっしょだ
っていうかこのグローバル変数がダメな理由っていうのはちゃんと覚えておいたほうがいい
同じ害が出るものもちゃんとわかるようになるし
もちろんシングルトンとかも同様に駄目

fooが使われているか否かを知らなくていいのは1。

GoFのCommandパターンは要求をオブジェクト化し、
内部の関数や変数を隠したままクライアントをパラメータ化する。
Command#executeを呼び出すだけ。

変数や関数の実装を隠すことはカプセル化であり、
インタフェースだけ見えているという抽象化である。

クラスは内部状態を持っていてそれが変化する。
これはクラスの基本的な仕様。
で渡したオブジェクトは内部状態と一員として保持されても文句が言えない。
これもほとんどのオブジェクト指向言語の仕様。
引数でオブジェクトを渡したとしてそれを参照するだけなのか、
変更するメソッドを呼び出すのか、参照先を記録するのか分からない。
結局クラスの実装仕様を理解せざるを得ない。
なおかつ関連性が深いクラスになるとほぼすべてのメソッドでオブジェクトが参照されるようになる。
だったらコンストラクタで参照を保持したほうが可読性高いんじゃないの？

>>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");と何ら変わらない。

あと、副次的な話だけど、
例えば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の関数を見てみるといい。

ソース的にいい悪いの問題じゃなく用途の違いだと思う

829ではないが
＞Hogeを利用する側から不可視になるから
が問題だといってるのなら、「典型的なDecoratorパターン」も問題なのだろうから
＞委譲を使う方法の方が、「データを出力する」という操作をより簡潔かつ明瞭に記述できる。
は説得として弱いと思う。
(おれはケースバイケースの立場だが)

>>836
うん。もちろんケースバイケースだと思うよ。
とはいえ>>813にも書いた通り、Fooをきちんと設計しておけば、大抵は問題にならないはず。

OutputStreamは、あくまで「常にFooの使われ方を把握しなければならない」という主張に対する反例。
まさか、彼も「他人の書いたコードは信用できない」なんて時代錯誤な事は言ってないと思うし。

> 1. Fooに対して操作が行われることが、Hogeを利用する側から不可視になるから

ってさ、ちょっと待って欲しい。
fooのインスタンスに対してどんな操作が行われようと、
Hogeを利用する側には無関係では？
Hogeがそれを「把握して無いといけない」設計がおかしいのでは？

SwingのJTableはTableModelのインスタンスを公開してるから、
そちらに対して操作はできるし、通常のGUIからのイベントも、
TableModelに当然操作を加えてる。
互いに、どこで操作が行われたかなど気にする必要もない。

さすがにお前は議論が見えてない

>>838
ちゃんと読めよｗｗｗｗ

>>837
なるだろ
だいたいfooは問題なくてもHogeの呼び出し方でfooの状況がどうなってるかわかんねーじゃねーかよ
なんで「大抵問題にならないはず」とかわけのわからないこと言ってるの？

俺が指摘したこと（>>830）わかってる？
本当にカプセル化とかわかってるんだろうか？
なんかもう会話が成立しないね（笑）ｗ

人の指摘は無視していいたいことだけ言うタイプ

>>841
問題になるなら、具体的な状況。
カプセル化、グローバル変数の弊害もあげてるので、
その点について説明する必要があるのではないか？

議論ではなくて、見下したいだけなら、どうでもいいですが

>>841
>>830には、君がそう主張する「理由」が何も書いてないけどね。
アホとかバカとか書く前に、少しは自分の主張をロジカルに書いてくれ。

それはともかく、Hogeに渡したFooインスタンスを、
1. そもそも他で使おうとすべきでない
2. 使おうとするなら、Fooはきちんとそれを想定して設計すべき
のどちらか、ってこれ三度目なんだけどな。

2は、例えばFooをimmutable、つまり一度生成したら二度と状態が変わらないものとして
設計する方法がある（Fooの状態を変更したい場合は、新たなFooインスタンスを生成する）。
これなら、君の心配する問題は起きない。

つうか、そもそもhoge.method(foo)でも同じ問題が起きると思うのだが、
なぜコンポジションの場合でのみ問題があると考えるの？

もうあれだ、次からはレスの最初に、

・主張したいこと
・その具体的かつ論理的な根拠

をそれぞれ箇条書きで書いてくれ。それ以外はもう返答しないのでよろしく。

つまり破壊的代入が出来ない言語が最強という事でよろしいですか

人に要求するけどおれはやらないよ！

徹底的に代入を排除するとオブジェクト指向でかけないのではないか？

>>844
はぁ？
だから引数から渡せば問題ないのになんでその２つなの？
頭大丈夫？おｋ？

人の指摘は無視していいたいことだけ言うタイプ

>>849
つ　マルチスレッドｗ

>>849
「引数から渡せば問題ないのに」？？

hoge.method(foo)

他の場所で…

foo.setBaz(ababa)

されてたら一緒では？