オブジェクト指向の活用方法を教えて下さい

**デフォルトの名無しさん** · 2014/03/25(火) 21:44:07.66

お願いします。言語は問いません。
オブジェクト指向言語じゃなくても
オブジェクト指向の話であれば問題ありません。

**デフォルトの名無しさん** · 2014/03/27(木) 01:42:00.90

>>62
なんでそんなに追い詰められてんの？

**デフォルトの名無しさん** · 2014/03/27(木) 01:47:38.94

>>61
プログラムの実行順が気になる？
それは抽象化ができてないから。

長いコードがあって、その順番まで意識しないといけなくなってる。
つまりそのコードは細かい断片で考えることができないということだよ。

変数もスコープが広くなってるね。着目したい変数でgrepしてわかるということは
変数名は長くなっているはず。でないと他の変数名とかぶるはずだからね。で、関数は使われてないと。
（関数が適切に使われていれば同じ"ローカル"変数名が何度も出てくる。同じでいいから名前考える手間省けるよ？）

関数は引数と戻り値があるだけ。それはいつどのタイミングでも使っても良い。
このようになっていれば、全体のことは考えずにその関数という小さな部分で考えることが出来る。

大きなものを大きなまま作るのではなく小さな物にしていく。
そうすれば順番なんて気にすることはないよ。

順番なんて気にしていたら、ユニットテストで関数をテストするときどうするのさ？
ユニットテストではある関数を狙い撃ちでテストするのよ？

**デフォルトの名無しさん** · 2014/03/27(木) 01:48:13.52

>>63
なんでそう思ったの？
俺は新人に教育している気分なんだけどｗ

**デフォルトの名無しさん** · 2014/03/27(木) 01:48:36.67

LoCは何かと馬鹿にされがちだけど、
逆にCOCOMO2でとか言われても誰が答えられるってんだっていう。
つか変数や関数の数って何だよ。どうしてそれが気になる。コボラーか？
俺はどれも気にしないし、計測ツールもいれてねえよチクショウ。

**デフォルトの名無しさん** · 2014/03/27(木) 01:49:47.41

(オブジェクト指向から離れちゃうけど)関数を一画面に収まる規模にして、複数の関数から
構成するようにすると、関数呼び出しが発生することになってしまいます。それが必然性が
ないものだったら、ロジックを追いづらいし、メンテしずらくなってしまうような気がしま
す。大体、関数の名前を考えるのに苦労してしまって、変な名前をつけちゃいそうです。
個人の技術力の問題であれば、しばらくROMってます。

**デフォルトの名無しさん** · 2014/03/27(木) 01:53:16.02

LoCは「同じ仕様のアプリを作った時に短いほうが優れているだろう」という
判断には使えるがそれ以外の目的では使えないよ。

LoCが多くてもは生産性が高いことにはならない
（たとえばコピペをすれば簡単に水増しできるが、これは品質を下げる行為）

**デフォルトの名無しさん** · 2014/03/27(木) 01:55:37.34

Javaは現代のCOBOL

**デフォルトの名無しさん** · 2014/03/27(木) 02:05:57.47

>>67
> 関数呼び出しが発生することになってしまいます。それが必然性が
> ないものだったら、ロジックを追いづらいし

それも俺の中では答えが出てる。

それは関数呼び出しをした時、関数の中まで見ないとロジックが
わからないようなコード（関数）になっているから。

たとえば、printf()という関数、その関数の中まで追ってみないでしょう？
それは関数名さえ見れば、中を追わなくてわかるから。

追わなくてもわかるというのは、脳に記憶できているということ。
関数の仕様がわかりやすいものは記憶できるが
中で何やっているかさっぱりな関数は記憶できない。
そういう関数は複雑ということ。記憶できないような関数を作らない。

大きなアプリを作るとき、コードをいちいち読んでいたらいくら時間があっても足りない。
だから読む時間を記憶することで圧縮する。とはいっても複雑なものは記憶できないし、
数が多くても記憶できない。俺は記憶術の天才じゃないのでね。

だから、関数はできるだけ単純な機能にする。複雑で高機能なものをたくさん作るよりも
（たくさん作ると名前をつけるのに困るし）
単純なものを少数作って、それを組み合わせるほうが覚えることが少ない。
中を見ないとわからないような関数は作らない。そういうのはだめな関数。
（オブジェクト指向にする理由としてオブジェクトという単位でグループ分けしておけば、覚えやすいというのもある）

そうやって読むべき所を減らしていけばいいんだよ。関数の中を見なくて済むような
そんな関数にしていけば、関数呼び出しが発生してもロジックは追える。見なくて言い分早く追える。

**デフォルトの名無しさん** · 2014/03/27(木) 07:13:03.30

オブジェクト指向のこころは良い本だ

**デフォルトの名無しさん** · 2014/03/27(木) 07:26:53.08

「オブジェクト」が参照なのって割と不便だよね。

**デフォルトの名無しさん** · 2014/03/27(木) 10:03:27.48

関数型プログラミング的に言うと、
副作用（内部情報を持つ、外部デバイスにアクセスする等）のある関数は
プログラムを複雑にする悪玉菌扱いなんだけどね。
かといって純粋関数だけでプログラムかけるかっていう現実問題はあるけど。
しかし問題の切り分け方として、データと処理がセットになることが必ずしも礼賛されるかというとそうでもない。

**デフォルトの名無しさん** · 2014/03/27(木) 11:42:05.43

>>70
実際にはprintf()の中身は複雑なんですけどね。
https://www.sourceware.org/cgi-bin/cvsweb.cgi/libc/stdio/Attic/vfprintf.c?rev=1.30&;content-type=text/x-cvsweb-markup&cvsroot=glibc

**デフォルトの名無しさん** · 2014/03/27(木) 12:26:13.49

もっとも身近なオブジェクト指向の概念って、
ファイルやソケットのディスクリプタかな
説明もしやすいし理解も早い

**デフォルトの名無しさん** · 2014/03/27(木) 12:52:47.48

ファイラー上で見るファイルオブジェクト
あれのポップアップメニューが変化するのを見せるのがよさそう

**デフォルトの名無しさん** · 2014/03/27(木) 15:10:04.52

>>75
俺はStringクラスだと思うね。
この例を出すとどうも必ず叩かれるんだけどｗ

前提として長さをprivateで持ってる実装を考える（例えばjava.lang.Stringね）。
それを、連続したchar領域などと比較する。

strlenしないと長さが得られないのが後者で、
内部に既に長さを持ってるのが前者。

文字列データと、長さ、っていう非常に近い関係のものが、
内部に一緒に揃ってる。
一緒にあったほうがマシだから、一緒にある。
クラスの内側にそれを隠し持ってる。
そして、いろんなメソッドの内部でふんだんに参照してる。

**デフォルトの名無しさん** · 2014/03/27(木) 15:29:20.56

strlenしないと長さが得られないのか、最初から長さを持ってるのか、
中身がどういう仕掛けになってるのか気にしなくていいのがオブジェクト指向なんじゃないの？

**デフォルトの名無しさん** · 2014/03/27(木) 15:29:34.54

昔はそう思ったこともあるが実装とI/Fがあまりにも近すぎてよくない

**デフォルトの名無しさん** · 2014/03/27(木) 16:23:36.30

JavaのStringだと、lengthはフィールドじゃなくてメソッドでは？
内部で保持してるのかどうかは知らんが

**デフォルトの名無しさん** · 2014/03/27(木) 19:09:37.68

>ファイルやソケットのディスクリプタかな
ハンドル持ち回りはCによる実装レベルでも十分確立されてるし
OO言語じゃないと実装がとても大変って例はないもんかね

**デフォルトの名無しさん** · 2014/03/27(木) 20:16:21.85

>>77
オブジェクト指向の真髄はポリモーフィズムだと思ってるので
>>77の考え方に反逆するわ

**デフォルトの名無しさん** · 2014/03/27(木) 20:31:07.44

>>74
> 実際にはprintf()の中身は複雑なんですけどね。
いや、知ってるってｗ

複雑だけど、関数にすることで、
”中を見なくて良くなっている"

これがいい関数の例。

中を見ないと、どんなことやってるかわからないよ～。
となってるのが、悪い関数の例。

**デフォルトの名無しさん** · 2014/03/27(木) 21:26:09.20

C++のストリーム演算子らへんは何をやってるのかさっぱり判らない悪い例じゃないの

**デフォルトの名無しさん** · 2014/03/27(木) 21:34:12.95

>>84
何をやってるのかさっぱりわからないのは、
ストリーム演算子の中身の話であって、

そのストリーム演算子を使う人は
中身を見なくても、使えるでしょう？

関数の中身を見ないとロジックが追えないというのは
つまりこういうことだよ。（関数名は例ではない）

function process() {
　initialize();
　calc_price();
　save_data()
}

**デフォルトの名無しさん** · 2014/03/27(木) 21:55:08.72

>>85
お話が通じないことが良く判ったよ
俺流オペレータが何をやってるのかは中を見なと判らないでしょ
だからストリーム演算子の例を出したのに「使う人は使える」

>（関数名は例ではない）
ちゃんとした関数名にすれば中身見る必要無いだろ

**デフォルトの名無しさん** · 2014/03/27(木) 22:02:47.00

printfも可変引数の仕組みと書式の関係が判ってようやく
初めて使えるレベルになるものだと思うけどな
それって結局中身見ないとまともに使えないでござるよ…って事にならないかね？
まさかこんなスレでprintfの中身を一度も見たことない奴なんていないだろうから
きっと錯覚してるだけだよ

**デフォルトの名無しさん** · 2014/03/27(木) 22:06:56.92

そういう意味だと上のハンドル志向が一番解りやすい
中を見たいとも思わないし

**デフォルトの名無しさん** · 2014/03/27(木) 22:09:08.87

誰かJava8のStreamの話をしてくれ。

**デフォルトの名無しさん** · 2014/03/27(木) 22:12:33.90

かなりprintf族もハンドル取るのあるだろ
いやそういうことではなくて、関数名だけでちゃんと表現できてれば中身見る必要なんてないんだよ
結局いくら関数化しても中身見ないといけないようなケースは必ず存在するんだよ

**デフォルトの名無しさん** · 2014/03/27(木) 22:18:02.77

今言う中身は実装じゃね？
実装を知らなくても使い方が分かればいいと
例は良くわかんない

**デフォルトの名無しさん** · 2014/03/27(木) 22:26:01.90

実装を知らなくても使い方を想像できるってのは
裏返せば過去に自分が似たような物を作ったり設計書見たりとか
それなりの経験のある中の事じゃないの？
実装がさっぱり想像できないのをいくら眺めたところで
使い方が判るようになるとはとても思えないけど

**デフォルトの名無しさん** · 2014/03/27(木) 22:27:02.26

コメントとか仕様書とかに使い方が書いてあれば実装を見なくても済む
printfのすべての実装なんて見たことないけど、仕様書どうりの動作をするとわかっている

**デフォルトの名無しさん** · 2014/03/27(木) 22:36:29.59

想像して使うってのはよく分からないけどsleep()とかsystem()はそれに近いかも？
使い方を知って、かつそれが曖昧になっても関数名や引数で思い出せるってところが分かり易さじゃない？
逆に見ても分からないってのは設計として複雑な気が
std::coutでいえば<<なら直感的だけど>>だと途端に恐怖を覚える

**デフォルトの名無しさん** · 2014/03/27(木) 22:41:51.63

GoogleのC++スタイルガイドではストリームはやめろprintf使っとけって事になってるな。

**デフォルトの名無しさん** · 2014/03/27(木) 23:09:47.29

他の言語に全く採用されないところをみるに、たんに演算子いじれてすごいでしょアピールで実利はなかったんだったんだろう

**デフォルトの名無しさん** · 2014/03/27(木) 23:29:08.64

可変引数は呼び出し側自己申告以外にチェック機能が無いからバグの温床になりやすく
標準ライブラリからは除外したかったと昔どっかで読んだよ
正規表現みたいに書式と引数の型から判定するような仕組みは作れたはずだけど
それを言語仕様に含めてしまうと1関数でしかなかったprintfの書式文字列を
今更特別扱いするのは抵抗がとか紆余曲折あって全く別の方向に逃げた

**デフォルトの名無しさん** · 2014/03/27(木) 23:34:55.71

コンパイラが警告してくれるけどね

**デフォルトの名無しさん** · 2014/03/27(木) 23:55:40.61

>>86
> 俺流オペレータが何をやってるのかは中を見なと判らないでしょ
いつオペレータの話したの？

ストリーム演算子の話だったよね？

**デフォルトの名無しさん** · 2014/03/27(木) 23:59:54.87

俺流オペレータの代表格だわな

**デフォルトの名無しさん** · 2014/03/28(金) 00:09:53.54

代表格＝同じではないという意味。

**デフォルトの名無しさん** · 2014/03/28(金) 00:14:00.53

そのストリーム演算子を使う人は
中身を見なくても、使えるでしょう？

関数の中身を見ないとロジックが追えないというのは
つまりこういうことだよ。（関数名は例ではない）

function process() {
　initialize();
　calc_price();
　save_data()
}

定義済みのストリーム演算子は覚えればいいから、中を見ないでわかる。
俺俺オペレータで中を見ないとロジックを追えないようなものは
上に書いてあるのと同じ問題がある。

関数がダメなんじゃなくて使い方の問題。
オペレータもそれ自体がダメなんじゃなくて、使い方の問題。
中を見ないとロジック追えないような関数（オペレータも）はダメな関数。

話はこれと何も変わっとらん。反論にはなっていない。むしろ俺と同じことを言ってるだけ。

**デフォルトの名無しさん** · 2014/03/28(金) 00:37:59.39

例えばさ、AppleとかMicroSoftのAPIは実装非公開だし、実装知らなくても使ってますよみんな。

つか、中身はブラックボックスでいいって表現に語弊があるのかな。
全体の構造を見てるときは個々の中身は気にしなくてもいい、
個々の中身を検討してるときは他のオブジェクトは気にしなくてもいいって意味だよ。
スコープを小さくすればわかりやすいよねってこと。

**デフォルトの名無しさん** · 2014/03/28(金) 00:40:38.80

そういうこと。全体の構造を見ている時に
個々の中身を気にしなくちゃいけないコードを書いているから

>>67 みたいに
> 関数呼び出しが発生することになってしまいます。それが必然性が
> ないものだったら、ロジックを追いづらいし

関数呼び出しでロジックが追いづらくなっちゃうわけ。
それは関数の作り方が悪いせいであって関数のせいじゃないんだよ。

**デフォルトの名無しさん** · 2014/03/28(金) 00:53:28.66

本来シフト演算子なはずの << やら >> を入出力に使うっていうのが、
演算子オーバーロードの悪い使い方(=俺流オペレータ)の代表格だっていう話では。

**デフォルトの名無しさん** · 2014/03/28(金) 01:15:21.16

(構造化プログラミングのスレかな？)

**デフォルトの名無しさん** · 2014/03/28(金) 01:52:09.43

（ここまでオブジェクト指向の活用方法の具体例なし）

**デフォルトの名無しさん** · 2014/03/28(金) 01:54:17.33

>>105
話ずれてるなぁ。

良い関数と悪い関数の違いの話だよ？
自分で勝手に作った関数でその中を見ないと
呼び出し元が何やってるかわからないのがダメって話。

ストリーム演算子は普通に記憶してるじゃんか。
中見ないでしょ？

**デフォルトの名無しさん** · 2014/03/28(金) 02:34:08.23

具体例ならエロい人のソースを覗き見…
ぐへへ

**デフォルトの名無しさん** · 2014/03/28(金) 11:21:32.67

>>102
> function process() {
> 　initialize();
> 　calc_price();
> 　save_data()
> }

その三つの関数は、再利用もしないし、他からも呼ばれないんじゃないの？
だったら、中身を見る必要ないよね。
中身を見る必要があるとしたら、バグフィックスか仕様変更のときかでしょ。

**デフォルトの名無しさん** · 2014/03/28(金) 18:36:40.74

> 中身を見る必要があるとしたら、バグフィックスか仕様変更のときかでしょ。
ほら中見てるじゃんｗ

**デフォルトの名無しさん** · 2014/03/28(金) 18:44:51.50

中身を見なくていい　＝　機能もバグ取りもドキュメントも完成してるってことだから
今自分または開発チームが手がけてる関数は全て悪い関数ということになる。

**デフォルトの名無しさん** · 2014/03/28(金) 18:50:33.65

>>112そうとは言い切れないよ。

関数の仕様がシンプルで覚えやすければいい。
覚えるには何度も使うことが必須で
結果的に汎用性が高い（だから何度も使える）ものってことになる。

**デフォルトの名無しさん** · 2014/03/28(金) 18:58:13.19

>>111
> ほら中見てるじゃんｗ
見ないとロジック追えないだろ。

どんな関数でもメソッドでも同じ。
バグフィックスか仕様変更が必要なら、どんな場合でもそのコードを見る必要がある。

このことと、その関数の良し悪しは関係無い。

**デフォルトの名無しさん** · 2014/03/28(金) 19:03:06.04

>>114
> > ほら中見てるじゃんｗ
> 見ないとロジック追えないだろ。

君は少し勘違いしてるね。

上位関数のロジックを追う時に
下位関数のロジックを追わないとわからないって話だよ。

> function process() {
> 　initialize();
> 　calc_price();
> 　save_data()
> }

上位関数 = processのロジックを追う時に
下位関数 = initializeやcalc_priceやsave_data の
ロジックを追わないと上位関数が何をしているのかわからない。

function process(name) {
　　printf("hello " + name);
}

でもこの場合は上位関数（process）のロジックを追っている時に
下位関数（printf）のロジックは追わない。

**デフォルトの名無しさん** · 2014/03/28(金) 19:05:59.21

上位関数のロジックを追う時に
下位関数のロジックを追わないとわからないような
コードになってるから、

コードを解析するときに、関数があるたびに
下位関数の実装先にあっちこっちジャンプしていって大変なことになる。

**デフォルトの名無しさん** · 2014/03/28(金) 19:20:17.16

ここから発展して、
privateメソッドが、privateメソッドを読んでいて
そのprivateメソッドが、更にprivateメソッドを読んでいて
更にそのprivateメソッドが、privateメソッドを・・・みたいに
（再帰ではなく）文法上のコールスタックが深いものも
ダメな関数の一例だろうね。

なぜなら、privateメソッドは通常汎用的ではない。
汎用的なものに比べたら使われる回数が少ない。
こんなものは覚えられないし、覚える必要もない。

だから上位関数のロジックを追ってる時に
下位関数のロジックを追うことになる。

**デフォルトの名無しさん** · 2014/03/28(金) 20:50:21.98

>>116からの>>117は誤解を生むだろう。
関数への切り分けが適切であれば、利用している関数内で何してようが関係ない。
そうでないから、切り分けがまずいから結果としてサブのサブまで降りていかないといけないというのはわかるが、
構造としてサブのサブを呼び出すことが悪というのは真ではない。

**デフォルトの名無しさん** · 2014/03/29(土) 01:06:59.37

オブジェクト指向は1990年代の話題
当時は実装メモリも少なかったので、コンパイルサイズの上限に達しないように
コンパイル単位となるファイルや関数を小さくしなければならなかった。また
CPUの性能も低かったので、コンパイル単位を小さくすることで再makeにかかる
時間を節約していた。そうでなければとてもじゃないが、実務では使えなかった。
現代では分かりやすさを犠牲にしてまで、小さい関数を量産する必要はなくなっ
ている。
以上、教科書に載らないオブジェクト指向の歴史

**デフォルトの名無しさん** · 2014/03/29(土) 01:21:57.46

>>29
名付けを手間と思ってる時点で…
そういうやつに限ってコメントはダラダラズラズラ書く

そのコメントへの労力をまるごとメソッド名なり変数名なりの名付けに当てれば問題ない

**デフォルトの名無しさん** · 2014/03/29(土) 01:27:50.25

>>57
鳥肌立った

**デフォルトの名無しさん** · 2014/03/29(土) 01:30:44.27

>>67
ずっと読んでて思ったけど、もしかしてこの人がstaticおじさん？

**デフォルトの名無しさん** · 2014/03/29(土) 01:39:31.14

ようやくスレ全部読んだが、ポリモーフィズムとか委譲とかDIとかやってて、そういう話をしてるもんだと思って覗いたから
なんか逆に新鮮な気持ちになったぜ

俺が恵まれてるだけなんだろうが、50行を超える関数には出会ったことがない
自分でも書いたことがない

**デフォルトの名無しさん** · 2014/03/29(土) 01:45:14.49

50行を超える関数ぐらい出会うだろ？
オープンソースのコード読んだことある？

**デフォルトの名無しさん** · 2014/03/29(土) 08:53:28.56

オブジェクト指向で作られたライブラリを手続きの中で利用するのがベスト。
自身の構造をオブジェクトのネットワークで表現するのは問題を複雑にするだけ。
オブジェクト指向は基盤レイヤーで収まっていればいい。
より上のレイヤーは構造化プログラミングとモジュール化で対応すべきだ。

**デフォルトの名無しさん** · 2014/03/29(土) 10:41:15.74

>>125
>自身の構造をオブジェクトのネットワークで表現するのは問題を複雑にするだけ。

ならプログラマーなんかやめたほうがいい。適性なし。

**デフォルトの名無しさん** · 2014/03/29(土) 13:47:53.85

言いたい事はわかる。きれいに階層化されたツリー構造の方が処理を追いやすい。
しかし、どうしてもオブジェクトグラフがネットワーク状になる場合があるし、
ユーザーがオブジェクトどうしを自由に接続できるアプリだってある。

**デフォルトの名無しさん** · 2014/03/29(土) 14:12:25.86

プログラマ適性なしは言い過ぎ
最近は非オブジェクト指向の言語も注目されてきてるよね

**デフォルトの名無しさん** · 2014/03/29(土) 15:10:59.76

関数型の次はなんだ？

**デフォルトの名無しさん** · 2014/03/29(土) 17:53:31.03

OOだろうが非OOだろうが、
粒度の小さなデータ構造でネットワークを形成することを
「複雑にする」と思う時点でプログラミングに向いていない。

**デフォルトの名無しさん** · 2014/03/29(土) 18:15:38.16

メインルーチンでまとめて管理すればいいものを、
処理とデータをセットにすることに拘った挙句、
メディエータパターンなんてマヌケな再発明を強いられるOOPに哀愁を禁じえない。

**デフォルトの名無しさん** · 2014/03/29(土) 18:26:03.80

巨大なメインルーチンねえ。描画とかどうすんのかな。

**デフォルトの名無しさん** · 2014/03/29(土) 18:36:10.02

描画はイベントドリブンか、メインループの中で描画オブジェクトの配列を作るわ。

**デフォルトの名無しさん** · 2014/03/29(土) 19:00:43.30

>>131
あんたも適性ないね

**デフォルトの名無しさん** · 2014/03/29(土) 19:40:22.20

しかたない。SEにでも転職するか。

**デフォルトの名無しさん** · 2014/03/29(土) 20:02:51.62

適性とかそういう話じゃないなコレ、教育不足に経験不足だ

**デフォルトの名無しさん** · 2014/03/30(日) 02:19:44.18

数珠つなぎのメソッドチェーンを呼び出して何をするのかと思ったら、単に変数
に値を代入(または取得)して終わり、みたいのをよく見かけます。途中に現れる
メソッド名を見ても必然性を感じません。その階層で何をするでもないのです。
そういう場合はただの変数の代入に書き換えます。
(ついでなので)変数の名前はその目的が分かる名前に直します。

まるでオブジェクト指向の本質は多重のメソッド呼び出しだ、と言わんばかりな
のです。自分はそんなことより、単なる変数・関数であったとしても命名を重視
したいです。

規模の大きいソフトウェアの場合、名前をグルーピングして、階層を持たせて命
名することに異論はありません。でもそもそもそんなに大きいソフトウェアを
作っているわけではないんです。

世界にひとつだけの名前にして衝突を未然に防ぎたい、ということでしょうか？

**デフォルトの名無しさん** · 2014/03/30(日) 02:26:07.76

同じことがメソッド呼び出しにも言えます。チェーンしているメソッドがそれぞ
れ何を意味しているのか分かりづらい上、記述の順序と実行の順序が異なるので
す。

例えば文章において、姓名は「姓」と「名」を近くに記述することで「姓名」と
なって、ひとりの人を表わすことができます。日付の「年」「月」「日」も電話
番号の「市外局番」「市内局番」「加入者番号」も同様です。これらをばらばら
に離して記述すると読み解くのに苦労することでしょう。

記述の順序が実行の順序と一致しないというのは、そういう状況に似ています。
ソースプログラムがまるでなぞなぞのようになってしまうのです。

実行順序が隣り合っているものは隣り合わせて記述すると分かりやすいプログラ
ムになります。修正も簡単です。テキストエディタやgrepが強力なプログラミン
グツールになります。

**デフォルトの名無しさん** · 2014/03/30(日) 02:40:59.19

>>137,138
オブジェクト指向の必要性とは、規模とか複雑さとか再利用性の問題だから、
当てはまらなければ気にしなくてもいいんだよ。

**デフォルトの名無しさん** · 2014/03/30(日) 02:59:11.38

>>137-138
あなた、オブジェクト指向の話をしてないですよ。

**デフォルトの名無しさん** · 2014/03/30(日) 03:06:19.07

メソッドチェーンが何かを知らない人に説明しておくと、

value を foo関数で加工して、bar関数で加工して、baz関数で加工するという、
シェルスクリプトで言えば
cat var | foo | bar | baz というのを

baz(bar(foo(value))) という逆順で書くのではなく、
value.foo().bar().baz() という風に
処理の順番の通りにかけるようにした方法です。

ただそれだけのことです。
どちらがわかりやすいかは言うまでもありませんね。

**デフォルトの名無しさん** · 2014/03/30(日) 03:10:55.68

メソッドチェーンだと書いている順番に
処理が実行されるからわかりやすいんだよな。
オブジェクト指向だと、メソッド名短くても
かぶらないからその点でもメリットがある。

**デフォルトの名無しさん** · 2014/03/30(日) 03:11:55.59

なあんだ！どっちの目を使うかなんだね！

**デフォルトの名無しさん** · 2014/03/30(日) 03:28:36.95

> baz(bar(foo(value))) という逆順で書くのではなく、
これって引数無いからまだわかりやすいけど、
引数あると見にくいんだよね。

baz(bar(foo(value, 1, 2), true), "test");

呼び出しが深くなるにつれて、bazと"test"みたいに距離がどんどん離れちゃう。

これがメソッドチェーンだと
value.foo(1,2).bar(true).baz("test");
このように関数と引数が近くに集まる。

**デフォルトの名無しさん** · 2014/03/30(日) 03:30:32.83

これもオブジェクト指向の活用方法の一つだろうね。

**デフォルトの名無しさん** · 2014/03/30(日) 03:34:47.32

だらだら連ねて1文に詰め込むのはデバッガで追いにくくなるからあまり好きじゃない。

**デフォルトの名無しさん** · 2014/03/30(日) 11:13:41.29

>>139
>オブジェクト指向の必要性とは、規模とか複雑さとか再利用性の問題だから、

はずれ。

**デフォルトの名無しさん** · 2014/03/30(日) 11:13:50.33

返り値をチェックして独自のエラーログを出したいｗ

**デフォルトの名無しさん** · 2014/03/30(日) 11:14:24.92

>>146
どんなオンボロデバッガ使ってんだ？

**デフォルトの名無しさん** · 2014/03/30(日) 11:52:19.72

>>146
つまり、

baz(bar(foo(value, 1, 2), true), "test");

こういうのを

v = foo(value, 1, 2);
v = bar(v, true);
v = baz(v, "test");

って書くってこと？

おっと、メソッドチェーンとは関係ない話だったから
関数の方でレスしちゃったｗ

**デフォルトの名無しさん** · 2014/03/30(日) 11:57:24.64

>>149
> value.foo().bar().baz()

bar( ) の挙動確認したいから、この行の bar( ) の呼び出しでブレーク掛けられるデバッガ教えてくれ

**デフォルトの名無しさん** · 2014/03/30(日) 12:01:26.08

訂正（笑）

> baz(bar(foo(value, 1, 2), true), "test");

bar( ) の挙動確認したいから、この行の bar( ) の呼び出しでブレーク掛けられるデバッガ教えてくれ

**デフォルトの名無しさん** · 2014/03/30(日) 12:07:13.82

メソッドチェーンならこれが使える。

メソッドチェーンの p デバッグ? それ tap でできるよAdd Starasakichy
http://d.hatena.ne.jp/mas-higa/20100805/1281018189

function p(obj) { print obj }
value.foo(1,2).bar(true).tap(p).("test");

まあ関数でも使えるよ。見難くなるけどねｗ
baz(p(bar(foo(value, 1, 2), true)), "test");

**デフォルトの名無しさん** · 2014/03/30(日) 12:32:55.33

難しいことをしようとすれば、何を使っても複雑になる。
言語やパラダイムが複雑なんじゃなくて、解決しようとしている問題が複雑なだけなんだ。

**デフォルトの名無しさん** · 2014/03/30(日) 12:47:55.23

えと、ああ、うん、
言語の違いっていうのは、問題がどうとかじゃなくて
読みやすさと書きやすさの違いの話なんだけどね。

**デフォルトの名無しさん** · 2014/03/30(日) 13:17:38.07

>>151
え？そんな簡単なこともできない開発環境でオブジェクト指向とか大笑いだな

**デフォルトの名無しさん** · 2014/03/30(日) 13:27:57.55

>>141
>シェルスクリプトで言えば
>cat var | foo | bar | baz というのを
このとき、foo や bar が何もしないプログラムであっても baz の前に入れることに
意味はありますか？関数型で組む場合は、何もしない関数 foo(), bar() を挟み込む
発想になったことがありません。必要になったとき、何かをしたくなったとき、その
ときに追加しています。

**デフォルトの名無しさん** · 2014/03/30(日) 13:31:27.59

>>102
思うことは二つある。

1) 結局中身って見なくてもよくね？
どんな糞名前、糞用途でもAPIとして資料があって

　int aaaaaaaaabbbbbbbbbbb(int x, int y)
　x + yが素数のとき0を返し、それ以外のときyを返します。

となっていれば、中身は見なくてよくね？
実装なんてどーでもいいし想像したくもない。

2) 用途と名前が優れていればなおよし
シンプルな名前で表現されていれば、
APIリファレンスを紐解くことすら不要。
bool isprime(int x)ならこれだけで十分。

**デフォルトの名無しさん** · 2014/03/30(日) 13:35:22.35

継承とインターフェイスだけで十分便利

**デフォルトの名無しさん** · 2014/03/30(日) 14:01:44.17

>>157
たぶんお前の説明が下手くそだと思うんだが、いかなる場合も何もすることがない関数なんて言語問わず存在意義あるわけないじゃん
メソッドチェーン関係なく単に修正ミスとかだろ

もしくは、お前が知らないだけで何かの意味があるんだよ
よくみるなら具体例出してみろ

**デフォルトの名無しさん** · 2014/03/30(日) 14:29:06.62

With...End With ステートメント (Visual Basic)
http://msdn.microsoft.com/ja-jp/library/wc500chb.aspx

メソッドチェーンなんていらない。
言語側でwithステートメントを用意すれば済む話。

**デフォルトの名無しさん** · 2014/03/30(日) 14:30:58.29

それでどうやって一行で書くの？