10/04/05 23:57:11
>>664
なら、個々に状態を持った機能＝オブジェクトでいいじゃない。
「責務と役務」というのは、それを外部にどう見せるかという話。
>>666
なら、「ファイルの削除を実行する。それはファイルシステムの責務である。」という
分析も成り立つよね。
ていうか、ファイルシステムなんて「役務（サービス）を提供する責務を持つ機能」そのものだし。
668:デフォルトの名無しさん
10/04/06 00:12:19
>>667
前半：
クラスがデータを持たない、ただのインターフェイスだってんなら、いいとおもうよ。
要はただの関数のテーブルを外部に公開しているだけっていう。
でもどうせ、内部的なindexやハンドルなんか持っちゃうんだろ。なら却下だ。
後半：
話し合ってる「層」がずれてる。
ファイルをどう削除するかの責任を持つのは rmコマンド だ。
rmコマンドはいくつかのオプション引数をとるかもしれないだろ？
それらのrmコマンドが提供する「機能」についての責任の話をしてなんじゃないのか？
rmコマンドが責任を持つほか仕方ないだろ。
669:デフォルトの名無しさん
10/04/06 00:50:43
まーいろいろいいたいことはあるが、
まず、処理そのものが状態を持つべきではないんだ。
引数で指定すべし。そんなに手間か？
それから、ここからが本番なんだが、
責務やら役務やら役割やらサービスやら、変な言葉使いやがってよー。
そんなに色々な言葉使ってまで「それっぽく」して煙に巻きたいかよ。
一言「機能」でいいだろ。複雑な言い回ししたって現実は何にもかわんねーんだよ。
「それっぽく」聞こえる、ただそれだけ。
670:デフォルトの名無しさん
10/04/06 01:27:42
お前らこんなスレにいるぐらいだから、
ぶっちゃけ本当はOOPに嫌気がさしてるんだろ？
マジでマジで。
671:デフォルトの名無しさん
10/04/06 01:46:00
プログラム書くために、思考の形態を、そのまま記述できる手法は良いと思う。
自分の場合は、いかにフローに落とすか、ってイメージが強いなぁ。
木構造でしか考えられないな…。
672:デフォルトの名無しさん
10/04/06 08:02:48
>>668
> でもどうせ、内部的なindexやハンドルなんか持っちゃうんだろ。なら却下だ。
え？ なんで？ 世の中、自分の「状態」を持たないサービスの方がむしろ少数派だよ？
例えばだけど、ファイルシステムとかGoogleとか2chを、役務（サービス）を提供する
オブジェクトと考えてみたらどうよ。
> ファイルをどう削除するかの責任を持つのは rmコマンド だ。
> rmコマンドはいくつかのオプション引数をとるかもしれないだろ？
> それらのrmコマンドが提供する「機能」についての責任の話をしてなんじゃないのか？
っ【Commandパターン】
「コマンド」だって、自分の役務（サービス）を提供するオブジェクトの一つと看做すことも
できるわけでね。それと同様に、Fileオブジェクト（≠ファイル）とかファイルシステムを、
固有の責務を持ったオブジェクトと看做す、という分析も同じくらいアリだというだけの話。
673:デフォルトの名無しさん
10/04/06 08:20:01
>>669
> まず、処理そのものが状態を持つべきではないんだ。
そうだよ。状態を持つのは「オブジェクト」だ。
とりあえず、そのオブジェクトがどう実装されているか、という部分はブラックボックスとして
考えてみるのが良いと思うよ。んで、Javaでいうinterfaceだけでコーディングする世界を考える。
（オブジェクトはマイクロコンピュータである、ってのはアラン・ケイの台詞だったか？）
> 引数で指定すべし。そんなに手間か？
小規模なコードなら、君の言うとおり、あまりご利益はないかもね。
状態が複雑に絡み合った大規模なコードでこそメリットがある考え方、というのは前提。
> 責務やら役務やら役割やらサービスやら、変な言葉使いやがってよー。
一般的な用語だと思うけどなぁ。
一つ言えるのは、「機能」をどういう形でどの責任範囲で外部に提供するか、
という側面を強調している点で一貫してるよね。
674:デフォルトの名無しさん
10/04/06 11:33:32
>>642
意味不明だ。オブジェクト指向は制御を阻害しないぞ。多数のスレッドを扱うならば、むしろ
クラスのインスタンスで非同期メソッドを呼び、個別結果をインスタンス変数に格納し、全体状況を
スタティック変数に放り込むほうが楽だろう。
>>643
並列化までは、オブジェクト指向だろうが関数型だろうが、あまり変わららないかもしれない。
超並列化時代に突入するまでは、関数型が主役になりそうにはない。
675:デフォルトの名無しさん
10/04/06 20:10:08
長文ご苦労としか。OOP脳では所詮この程度か。
知ってて当たり前のことしか書かれてない。あー言えばこう言うの世界。
それでも、OOPが優勢になることはないんだよ。
これはもう時代の流れで決まってること。
共産主義と同じですたれるのだ。
なぜそんなことがいえるか、この辺の感覚的な部分は、
なかなかわかってもらえないようだけど、
なるべく簡潔に説明すると、
プログラムの機能は、
「制御でデータの関係を定義する」
ことで成り立つから。
オブジェクトに制御をぶら下げた時点で、構造的におわっとる。
676:デフォルトの名無しさん
10/04/06 20:12:53
変な言語を使い、変な思考で構築しているうちに、
変な頭になっちゃうのさ。あーおそろしー。
右も左もわからないやつが使うのがOOP。
677:デフォルトの名無しさん
10/04/06 20:14:14
開発環境のベンダーなんかは、わざとやってるのかもしれないがな。
檻に閉じ込めておくために。洗脳おそろしや。
678:デフォルトの名無しさん
10/04/06 20:27:39
>>654
OOPをサポートする言語のほとんどにはstatic関数があります。
679:デフォルトの名無しさん
10/04/06 20:29:17
なぜ、static関数のような非OOP的機能が用意されたかを考えなさい。
680:デフォルトの名無しさん
10/04/06 20:29:51
大体struct使う奴にOOPうんたらとか言われると微妙に気分が悪い。
681:デフォルトの名無しさん
10/04/06 20:42:44
C++最強説浮上
682:デフォルトの名無しさん
10/04/06 20:54:02
>>675
> プログラムの機能は、「制御でデータの関係を定義する」ことで成り立つから。
だから、それは数ある分析手法の一つでしかないと何度（ｒｙ
大雑把に言えば、「ユーザがどんなサービスを受けたいか」とか、
「写像と制約によって何を定義したいか」とかでコード化する対象を分析し、
コードを記述する手法が数多くある。
命令型パラダイムはそのうちの一つに過ぎない、それだけのことだ。
んで、要求が複雑になり変化が早くなったことで、「どんなサービスを受けたいか」で
定義する手法の需要が上がっているのが現在。
はっきり言えば、君のそれは、手続きベースでプログラムを書く人間の都合を押し付けてるだけなんだよ、
そんなもんは「本質」でもなんでもない。
683:デフォルトの名無しさん
10/04/06 22:16:27
車1.ワイパー()
は納得いくが、
車1.洗車()
は確かに気持ち悪い。
洗車機能は、洗車機にあるのであって、車にあるわけではない。
そいういうときはstaticで
洗車機::洗車(車1)
とすれば無問題なのかもしれない。
だが、多数の自動車インスタンスを一括して洗車()したい場合、どうするか？
という問題がある。
もちろん、いろいろなタイプの自動車が入り混じっているし、
続々と新車が発表されている。
で、解決に、
foreach (車配列){ ((洗車可能)車).洗車(); }
のような一括処理のために、やっぱり、車クラスに洗車メソッドを付けてしまう。
一見エレガントでも、こういうのは気持ち悪いと言われればそうかもしれない。
でもこれはOOPの問題というより、クラス設計の問題だが・・・
684:デフォルトの名無しさん
10/04/06 22:19:16
ああ言えばこう言う。
>「どんなサービスを受けたいか」
言い回しがすでにきめぇ。何で変に受身なんだよ。
普通に、
「必要な機能は何か」
でいいだろ。そういうところが頭おかしいっていってんだよ、受身野郎がよ。
685:デフォルトの名無しさん
10/04/06 22:28:14
車に基づいて洗車の処理が決定するようだけど、
他の要因でも洗車の処理が変わりうる場合はどうするんだ？
686:デフォルトの名無しさん
10/04/06 22:28:53
俺はずっと手続き型で来た人間だけど。
>>684
UPの開始工程が要求分析だからじゃないの？
客先がプログラム知らんから頭悪そうな言い方になる。
687:デフォルトの名無しさん
10/04/06 22:33:34
普段から自分たちを奴隷に見立ててるから、
「オブジェクト様が～なさる」、みたいな発想になるんだよ。
プログラムは指示書なんだから、
「これとこれとこれ、あれしといて」
でいいんだよ。