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

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

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

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

アイ　オブジェクト　たべたい

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

オブジェクト指向の活用方法とあらためてきかれてもな。
仕事やってるなら、オブジェクト指向以外を使うことのほうが
まれだよ。まあ空気のようなものだ。

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

ポリモーフィズム

**デフォルトの名無しさん** · 2014/03/26(水) 00:23:07.66

もしオブジェクト指向がなかった場合に困るのであれば、あなたが一体どんな風に
困るのかを教えてください。自分は困ったことがないので。

**デフォルトの名無しさん** · 2014/03/26(水) 00:32:00.76

>>5
俺はオブジェクト指向以外の方法論を知らない。
逆にどういうのがオブジェクト指向じゃないのだ？

**デフォルトの名無しさん** · 2014/03/26(水) 00:43:25.50

SQLは関数型言語ですが何か？業務プログラマじゃないのがバレバレな発言だね。

**デフォルトの名無しさん** · 2014/03/26(水) 00:49:07.29

困るのは関数の数が数百だとか数千だとか、ある程度規模が大きい場合だな。

オブジェクト指向なんて呼び方しているけど、本質的には構造化言語でもやっていた
モジュール化だからな。大量の関数を個別に扱うなんて大変な事をするよりも、
分類してまとめたモジュールを単位として組み合わせた方がシンプルになるからね。

そういう便利なモジュール化を最初から言語仕様に取り込んで
class{} とするだけで誰でも簡単にモジュールが作れるようにしたのが
オブジェクト指向言語。

**デフォルトの名無しさん** · 2014/03/26(水) 00:52:05.00

へー、SQLは関数型なのか。
俺は業務プログラマじゃないよw

**デフォルトの名無しさん** · 2014/03/26(水) 00:56:46.58

SQLが関数型であるという考え方は、
C言語は関数を定義するから関数型だよね、と同じ

**デフォルトの名無しさん** · 2014/03/26(水) 00:59:32.24

SQLは宣言型言語だったかと。HTMLもそうだけど。

**デフォルトの名無しさん** · 2014/03/26(水) 01:47:31.32

>>8
それは関数名や変数名を区分して、ネームスペースを分けるというところまでで
十分目的を達成できるように思えるのだけれど、それで達成できないことは何？

**デフォルトの名無しさん** · 2014/03/26(水) 01:54:10.43

それで出来ないのは属性の隠蔽と、継承による親子関係だな
まあ継承には最初はそんなにお世話にならんが、ある程度のクラス群を定義してくと
それらにグループ的な物が出来てくると思う

**デフォルトの名無しさん** · 2014/03/26(水) 05:17:45.52

実は、SQLは集合論を基にしているという点で、ある種の関数型言語とも考えられる（言語と
しては制限が多すぎるにしても）。
thinkbiganalytics.com/programming-trends-to-watch-logic-and-probabilistic-programming/

**デフォルトの名無しさん** · 2014/03/26(水) 07:05:24.48

>>12
実運用

自分１人で自分だけしか触らないプログラムだったら別にそのやり方でもある程度まで出来るだろうけど、
複数人数だとか、他の人が触るだとかするようになると、決めてたことが守られなくなってスパゲティに
なるのが常。
それをしっかりと見張って、ルールを破ったソースは絶対に許さないと監視してくれるのが、
その言語のコンパイラさん。

ちなみに俺も、１人で行うC言語の開発ではオブジェクト指向的に関数名や変数名を区分して作る。

**デフォルトの名無しさん** · 2014/03/26(水) 07:48:30.63

>>14
集合論ベースなら論理型じゃないのか？

**デフォルトの名無しさん** · 2014/03/26(水) 09:03:17.98

SQLはクエリーであって、つまり問い合わせであって
それだけでアプリケーションになるわけないしな。

実際にSQLだけでアプリを作ったことあるのかい？って話。

**デフォルトの名無しさん** · 2014/03/26(水) 09:10:42.35

>>12
> それで達成できないことは何？

複雑さの低減かな。

たとえば、アセンブラ使って比較とジャンプで
ループは作れる。でも言語としてループがあれば簡単に書ける

つまりは複雑さが減ってるわけ。

オブジェクト指向も同じで、使えば複雑さが減る。

読んで考えなきゃいけないことが、
単語一つで、あぁあれね。とすぐに知ることが出来る。
そういうコードになる。

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

>>17
オセロくらいなら作れそうだな
ちょっと面白そう

**デフォルトの名無しさん** · 2014/03/26(水) 19:13:13.84

SQLはチューリング完全じゃないんでしょ

**デフォルトの名無しさん** · 2014/03/26(水) 20:05:10.15

>>18 複雑さの低減のところ、詳しく。
オブジェクト指向について書かれた本だと例題がそもそも短いので、オブジェクト
指向の導入によって逆に長い記述になってしまうし、わざとらしい例ばかりなので
これで本当に分かりやすくなったの？生産性や保守性は本当に上がったの？という
点がいつまで経っても納得がいかない。
（いまどきの学校なら、先生がちゃんと教えてくれるんだろうか？）

**デフォルトの名無しさん** · 2014/03/26(水) 20:36:30.54

18じゃないが。
電気回路で例えたら、抵抗とかダイオードとかトランジスタがびっしり基板を埋め尽くす
回路を作っていたのを、ICチップ数個を配線して繋げればいいだけにした
みたいなものかな。

ICチップ自体を作るところで確かに手間はかかるけど、
そのICチップという単位で手軽に扱える便利さが出てくるよね。

**デフォルトの名無しさん** · 2014/03/26(水) 20:54:01.45

オブジェクト指向によるループの簡略化ってなんだ？アイテレータか？
foreach構文使える言語ならOOPしなくても簡略化できるぜ。

**デフォルトの名無しさん** · 2014/03/26(水) 21:17:17.67

構造化プログラミングでは「機能」で全体を切り分けてた。
それがC++などのオブジェクト指向プログラミングになると「オブジェクト」で全体を切り分けるようになる。

電気回路に例えるなら、
それぞれの機能は基盤ごと、チップごとに整理されているが電源が一つしかない状態が構造化プログラミング。
それぞれの機能が自前の電源を持ってるのがオブジェクト指向。

**デフォルトの名無しさん** · 2014/03/26(水) 21:43:06.83

>>23
そういうレイヤーの話じゃないんだよね。

あなた関数の中の話をしてるじゃない？関数の中の書き方の話じゃない。
関数ではないものにデータがある。データは関数ではない。
オブジェクト指向はデータにそのデータを扱う関数をまとめたもの。

関連があるものを別々に管理するよりも、まとめたほうがわかりやすい。
データと処理が一体で管理できるから、このデータを扱えることが出来る処理はどれだろう？
などと考えなくて良くなる。管理がものすごく楽になる。

このまとめた物がオブジェクト。
そしてオブジェクト指向は、そのまとめた、物と物。
物自体と物同士を組み合わせて使うときの考え方。

物の生成をどうするか？
物の構造をどうするか？
物の振る舞いをどうするか？

**デフォルトの名無しさん** · 2014/03/26(水) 22:07:44.33

>>21
たとえばゲームで考えるとね。キャラクターを横に1つ移動するはX座標をプラス1するだけ。
だけどこれだけじゃゲームとして成り立たない。キャラクターには座標以外にも色々な情報がある。

キャラクターが持ってるであろう情報にはどんなものがある？
と聞いたら、いくつも答えが出てくるでしょう？

ならそれをまとめて種類（クラス）として管理したほうが楽じゃない？
敵キャラとかキャラクター自体は一緒だけどデータ（座標など）が違うものってあるじゃない？
敵キャラという物がいてある場面になったら、この物を生成する必要があるじゃない？（敵出現）
敵と自分が戦うとしたら、それは物と物と関連があってそこである作用が発生するということ。

つまりこういうこと。

小さな処理ではなくて、巨大なアプリを作ることを考えてみよう。
座標を1動かすという小さな処理だけを見ていたら分からないが、
なにかアプリを作ろうと思ったら、その処理を沢山組み合わせて作ることになる。
その処理をバラバラに管理していたら複雑になりすぎる。複雑だと時間がかかるしバグも増える。
出来るか出来ないかではなく、複雑にならないように作るというのが実際の開発で必ず求められる要件。

じゃあ、複雑にならないようにある単位でまとめようと思うだろう？
その後はまとめた物同士をどう組み合わせるのがいいか考えるようになるだろう？
そこでオブジェクト指向を使うと自然な形でまとめやすくなるんだよ。

わからなければ実際に頭の中で考えてみたらいい。たとえばブラウザを作るってのはどう？
aタグなら～、ulタグなら～などと、いきなり詳細なものを考える前に、まずブラウザを構成している要素。
UI部分、HTMLレンダリング部分、JavaScript部分、CSS部分と分けて考えるでしょう？
そこから更に各部分を小さく分けて、それをまた小さく分けてって考えていくでしょう？

この時大抵の人ならデータと処理を分離せずに分けていくと思うから、それがオブジェクトになるんだよ。
オブジェクト指向でなかったら、最後にデータと処理に分けてそれを関連付ける処理まで考えなといけない。
分けるたびに数は増えるから最後は膨大になるよね。それは嫌だから一つ手前のオブジェクトにしておきましょう。

**デフォルトの名無しさん** · 2014/03/26(水) 22:19:45.69

要は、プログラマが問題解決の為に注目するスコープを、小さくするって事だよな。

**デフォルトの名無しさん** · 2014/03/26(水) 23:16:50.71

オブジェクト指向使わないでも ”出来る” とかいうやつがいるけど、
出来るのは出来るんだよ。
重要なのはどれだけ複雑にしないで出来るかということ。
その複雑という観点が抜けてる意見は的外れで参考にならない。

たまに本当にオブジェクト指向じゃなくても複雑にしないで
できることもある。オブジェクト指向よりもシンプルに作れることもある。

それは問題領域が異なるから。上でSQLの話がでていたが
それはRDBMSからのデータ取得という問題だから。
SQLはその問題に特化した言語なのだから得意なのは当然。

でもアプリを作るという問題の場合は、オブジェクト指向が適していることが多い。

例題程度の短い問題で、オブジェクト指向の利点を感じないのも
短い問題だからという理由で説明できるね。

**デフォルトの名無しさん** · 2014/03/26(水) 23:42:37.18

(A) オブジェクト指向だとクラスやインスタンスに名前を付けなければならない
　→ 手間が増えるところ
(B) だけどクラス内のプロパティとメソッドの関連付けに対して名前を付ける必要がない
　→ 手間が減るところ

普通、ひとつのクラスには複数(多数)のプロパティ、メソッドがあるので、

abs(B) ＞ abs(A)

ということになり、これが「複雑さの低減」という理解で合ってますか？

**デフォルトの名無しさん** · 2014/03/26(水) 23:52:53.55

もしそうだとすると、自分がオブジェクト指向のありがたみが分からないのは

abs(B) ＝ abs(A)

のような、１つのクラスに１つのプロパティと１つのメソッドしかないような
ものばかり作っているのが原因ではないかと思えてきました

**デフォルトの名無しさん** · 2014/03/26(水) 23:55:51.39

>オブジェクト指向だとクラスやインスタンスに名前を付けなければならない
javascriptみたく、プロトタイプベースのオブジェクト指向あるから、
これは必ずしもオブジェクト指向に当てはまる性質とは違う。
もちろん、名前付けてもいいけど。

**デフォルトの名無しさん** · 2014/03/26(水) 23:56:29.04

>>30
ちょっと違うな。　そこは大した問題じゃ無いよ。
問題にしてる複雑さっていうのは、どう頑張っても理解できない複雑な構造の事。

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

>>29
少し微妙なところはあるけれど、

>>30の
> のような、１つのクラスに１つのプロパティと１つのメソッドしかないような
> ものばかり作っているのが原因ではないかと思えてきました

ということであれば、その程度じゃ理解し難いと思うよｗ
処理と定義文の行が同じぐらいだろうからね。

普通は一つのクラスに、複数のプロパティとメソッドある。
関数やクラスの定義のための行よりも、処理の行数のほうが圧倒的に多い。

小さな問題なら関数さえ使わなくていい。
数行で終わる単純なスクリプトなら実際にそうする。

多くのプログラミング技術っていうのは、大きくて複雑な問題を
解決するために考えだされているものだから、
簡単な問題を使わなくても出来るというのは意味がなくて
大きな問題で比較しないといけない。

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

ICチップの例でいうなら、その中に１個のダイオードしか入っていないものを作っている
ので、ICにする意味がない（なかった）、ということです

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

>>29
実際にやって見るのがいいと思う

C#とかなら、書き込みや読み込みを行う抽象クラスであるStreamをとるメソッドに、ファイル、メモリ、ネット、データベースなんかを区別なく渡せたりする
自分でStreamを実装したクラスを作れば、それを利用する側は一切の修正なしに自作のStreamを使える、とか。

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

>>34
そのダイオードがオブジェクトだよ。
ダイオードには入力と出力があってダイオードの仕事をするだろう。
入出力というinterfaceがわかれば、中はブラックボックスでいい。
外から見た時に、中がどんな仕組みなのかは知らなくてもいい。
それがオブジェクト指向だ。

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

クラスを作る目的の１つは、ある変数に対してアクセスする関数群を同じクラスにまとめて、
変数自身は極力非公開にして、どこからか勝手にいじられないように隠蔽することだよ。
カプセル化というんだけどね。

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

>>36
それは関数も同じでは？
入出力が分かれば、中はブラックボックスでいいよね？

むしろ単機能という点ではダイオードはむしろ関数に近いかと。

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

俺もダイオードは関数だと思わ。

そんな単機能のものではなく、
ダイオードなどを使って作られる製品。
ダイオードなどのパーツを組み合わせて作る製品

その製品を作るために各パーツどうやって組み合わせて効率よく作るか
という方法論としてソフトウェアではオブジェクト指向があると思うよ。

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

>>37 そうだとすると、１つのプロパティしかないような場合でもクラスにする価値が
あるということなんだろうけど、勝手にいじられるものが"変数"なのか"関数"なのか
というだけなので、結局同じに思えてしまうなあ
(暴走を引き起こすような)でたらめな値を設定できないようにするということかな？

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

>>38,39
クラス内部もオブジェクト指向で書くんだよ。
だから関数・メソッドもオブジェクトとして捉える。
ICの中にもICが入ってるだろ？
注目するスケールが違うだけで、方法論は変わらない。

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

フリップ・フロップならオブジェクトかもしれないね

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

一つのプロパティしかないクラスであっても
アプリ全体で、そのクラスだけしか使ってないってことはまず無い。

小さなクラスしか見てないからわからないのであって
アプリ全体という大きなもので考えよう。

小さなクラスが数個あろうが、このクラスは他のクラスと
協調して動くでしょう？そういうところまで含めて考えないとダメだよ。

小さな視点ではなく、大きな視点を持つこと。
大きな視点を持てば、たまたまプロパティが一つしか
無いクラスがあったとしても、それがシステム全体として
必要なことであればなんら不思議ではない。

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

javaなんかだと標準出力に文字を表示するのにSystem.out.println("Hello World!"); なんてことやってるわけで
ダイオードがstreamの一種ならオブジェクトで問題ない。
仕組みの複雑さが外から見えないという意味で、ダイオードは実に成功していると言えるだろう。

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

オブジェクト指向の話で
クラスとインスタンスの話で
終わっちゃう人がいるけど、

オブジェクト指向の話には
インスタンスとインスタンスを組み合わせて動かすという
構造の話、組み合わせ方の話も含まれるよ。

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

インスタンスとインスタンスを組み合わせだけじゃなくて
クラスとクラスの組み合わせも。
（クラスの代わりにインターフェースだったりもする）

ほんと関数の中身などという小さな部分じゃなくて
全体を見ないとね。

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

ハローワールドでさえオブジェクト指向の真髄に触れてるわけで、
小さいプログラムだからOOPの恩恵が無いなどということはない。
Javaでは十分に抽象化され、簡便に使えるように用意されたライブラリ群を使っているではないか。

でも何でもかんでもオブジェクトにしてしまおうとするのは疑問だな。

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

組み合わせが固定的な場合、一見オブジェクトに見えても単なる構造化にすぎないことが
多い。新しいオブジェクトをくっつけようとして、全部のオブジェクトを書き換えるはめになる。
依存性が多すぎるのだ。究極まで依存性をなくして何でも接続できるようにしたものを、
Inversion of Control (IoC), とか dependency injection (DI) と呼ぶ。テスト環境と本番環境と
で、まったく同じモジュールを動かしてテストできるようになる。が、何もかもIoCやDIにでき
るわけではないので、本当に使えるケースはあまりない。仕掛けが大掛かりすぎて、一行の
SQLやスクリプトに負けてしまうことも多い。

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

IoCやDIを使うところは構造に関する所だと思う。
クラスがアプリの構造を表している所だと思う。

クラス（インスタンス）を値として使う場合
たとえばBigInt型みたいな、int値の巨大版みたいな
"値" にはDIを使わない方がいい。
こういう場合は値として普通にnewした方がいい。

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

規模の話が出てきたので、アンケートをとってもよいでしょうか？

1. 作成しているアプリケーションの分野は？
2. アプリケーションの規模について
　2.1 行数
　2.2 関数の個数
　2.3 変数の個数
　2.4 複数のファイルから構成されているならば、そのファイル数

ちなみに俺は
1. テキストフィルタ
2.1 1,000行～10,000行
2.2 5個～20個
2.3 10個～30個
2.4 1ファイル
です

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

>>50
えと、そのコードを客観的に評価してもらったことある？
たとえばコードメトリクスツールで計測するとか。
その評価がないと、それ見てもなんの参考にもならない。

体育会系的に無駄で非効率な努力すれば
行数なんて稼げるしね。

コピペがだめな行為だってのは言うまでもないと思うけど、
コピペをすると簡単に行数稼げるよ。

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

>>50
ちょうど手元に今作っているソフトのカバレッジ結果を
開いていたから書くわ。オープンソースなので詳細は伏せるけど

1. 秘密
2.1 行数約750行
2.2 関数の数 98個
2.3 変数の数不明 (計測する意味が無い)
2.4 ファイル数 20個
2.5 クラス 25個
3. コードメトリクス　10点満点中 9.5
4. カバレッジ 90%

ちなみに一番、評価が低い関数だけど行数32行
行数は問題ではなくて、一つの関数にifとループが
多いから（と言っても8個）評価が低くなってる。

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

関数や変数は多めに数えたんですが、こういった規模でもオブジェクト指向を活用できるのか
どうかを知りたかったのです。関数はさておき、変数はがんばって捻出しても増やせないと思
います。関数は増やせるかもしれませんが、無理をしそうな気がします。つまり不自然なソー
スになりそうです。

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

>>50
> 2.1 1,000行～10,000行
> 2.2 5個～20個

1関数あたり、200行～500行ってことでいい？

これは多い。コードを把握するために一目で
スクロールしないで見渡せることが重要なので一画面が目安。
だいたい50行～長くても100行

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

>>53
変数は増やす意味は無い。
それで良いコードになったりも悪いコードになったりもしない。
どちらかと言えば少ない方がいいが、
少なくするほどいいってことでもなく無駄を無くす程度でいい。

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

オブジェクト指向はプログラムの問題というより人間の問題に近い。
オブジェクト指向にすれば、人間らしい仕様変更に比較的強いというだけの話。

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

>>54 いや、違います。１関数あたり10行位です。残りがメインルーチンです。

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

>>50
1ファイルで10000行は見通し悪くないかねw
俺のは簡単に言うとだが、シンセで80ファイル、各200から1000行程度。
電卓で50ファイル、各100から1500行ってところだな。
長い関数で120行ぐらいだよ。

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

ものによるんじゃない？
テキストフィルターがどういうものかわからないけど、変更に強くするとか再利用できるようにするとか

ただ、無理に小分けにしても返って複雑になることもありうる

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

アンチパターン（悪いコートパターン）本に
"メイン"ルーチンという名前がでてきたら
それはアンチパターンだって書いてあった気がするなｗ

1関数10行？それが5個で
1000行 - 10*5 = メインルーチンが950行？
関数20個でもメインルーチン800行だよね？

一度コード品質計測してみるといいよ。
10点満点中1点未満とか言われるだろうから。

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

着目したい変数/関数があったとき、grep するとプログラムの実行順と同じ順序で
表示されて便利です。

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

で、なんでコードの品質の話をしたかだけど、
技術力が低い人は、良いコードとダメなコードの違いがわからないから。

>>50の内容から、君がまだ良いコードがどんなものか
わからないレベルだろうってことがわかるわけ。

だからそのレベルでオブジェクト指向の利点がわからないのも無理はないし、
現時点でオブジェクト指向は意味が無いって結論づけたらダメだよ。
単に君がまだ未熟だから（それははっきりわかった）ってだけだから。

**デフォルトの名無しさん** · 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

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

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

かりにメソッドチェーンという糖衣構文があるからといって実際に使う時は
object.func1(arg1, arg2, arg3)
　　　　.func2(arg1, arg2, arg3)
　　　　.func3(arg1, arg2, arg3)
　　　　...
　　　　.funcN(arg1, arg2, arg3);

って書くわけで、別にワンライナーしたいとかいう話ではないはず。
一つのオブジェクトに対して連続的にメソッドを呼び出す場合に、
それが手続きや意味ある関連として成立しないならまぎらわしいからやめろっていうのが
>>137-138の主張じゃないの。

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

メソッドチェーンまで糖衣構文かよｗ
これのどこが構文なんだ？
ライブラリの仕様だろ。

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

Withは見にくいからやめろという主張をよく聞くが

メソッドチェーンの利点はメソッドで加工を行ってそれを別のメソッドに引き渡せるっていうこと
同じオブジェクトにたいして関連したメソッドをいくつも呼ぶ時も行を分けたりとかしなくて済むから見やすい

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

>>163
糖衣？…構文？？

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

>>165
withが見にくくてメソッドチェーンが見やすいってのも変な話だな。
記述に大差ないのに。

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

みんな、見やすいかどうかは
文字列の長さや行数で変わるってことを
理解してないよ。

たとえばこの二つ。

var newValue = value.fooFooFooFooFooFoo().barBarBarBarBarBar().bazBazBazBazBaz();

var newValue = value.foo().bar().baz();

単に文字列の長さが違うだけでやってることは全く一緒。
だけど上の方は見難くて下の方は見難くはない。

つまりどういうコードが見やすいかどうかは、単に文字列の長さだけでも変わってくるということ
だから文字列が長くなる場合にメソッドチェーンで一行にすることは不適切。
逆に言えば、文字列が短い場合に有効なのがメソッドチェーンというわけ。

withが見やすいのは、文字列が長くなった場合の話で
短いならばメソッドチェーンの方が見やすい。

どちらが、どんな場合でも見やすいなんてことにはならないんだよ。

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

短かろうと一行にするのはよくないと思うな。
オブジェクトが無い場合に

foo(); bar(); baz();

なんて書けるけど、実際はたとえ関連があっても横に連ねては書かないし。
メソッドチェーンにしたって
graphics.clearRect(0,0,640,480).drawRect(100,100,50,50).drawCircle(50,50,100)...
なんて横には書かなくね。

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

> foo(); bar(); baz();
>
> なんて書けるけど

書けないよ。

baz(bar(foo()));

こうだろ

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

>>170
今の話の流れにおけるメソッドチェーンでは
自身のインスタンスをreturnするから、
その例のような意味でつなげてるのでは無いよ。

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

>>170
インスタンスに対して操作をするんだろう？

じゃあ、何らかの引数がなければ、
同じ意味にならないじゃないか。

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

>>156
で、具体的なデバッガの名前とやり方は？

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

>>160
関数型言語ではid関数は重宝するぞ

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

>>169
複数の文を一行で書くのはなんか嫌だけど、メソッドチェーンなら気にならないな
ifの後ろとかにつけていたい目を見そうだからかな

しかし、メソッドチェーンもやっぱりAndroidみたいに何十行にも渡るのは読みかにくいからせいぜい数行が限度だとは思う

逆に数文字の命令が何十行にも渡って書かれる光景はイライラする

>>174
関数型言語はわからんが、重宝するならなんか意味があるんだろ？

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

>>160 具体例は公開できないので申し訳ない
その1. メソッド名が訳の分かる名前ならば、その中身を心配して見にいく必要はない
　　　⇒ これはレスや参考図書がよく使う 'foo' だの 'bar' だののレベルの名前を開発
　　　　しているプログラムに使っていることが問題なのだと思う
その2. 場合によっては改名するつもりで中身を見にいくと、なんでこれを括りだしたの？
　　　という疑問が発生(もとから括り出す必要はなくて、名前も要らないんじゃないの？)
　　　⇒ メソッドの中身をメインルーチンにコピペして解決!!
オブジェクト指向の話がいつの間にかコピペの話に...

オブジェクト指向って、どんな場合に役に立つのか、また活用方法を知りたい
のです
あるいはオブジェクト指向があるから常に使わなければならない、という考えは
間違いで、使うか使わないかは便利か便利じゃないか、解決しようとしている
問題や環境・状況に合わせて、判断すればいいものなのか？
そのとき、判断材料には本人や周りのひとのスキルを含めなくていいのか？
人のスキルに関係なく、いつでも・絶対にオブジェクト指向が有利なのか？
メソッド呼びさえしていればオブジェクト指向なので後ろ指さされることは
ないものなのか？

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

>>176
なんだ、昨日の続きならそうかけよ

当然、 fooとbarとかの名前なら書いたやつが無能なだけ。
jQueryとかrubyみたいにわかりやすい名前がいい
中身はどこかでまたつかうとか、メソッドチェーンでシンプルに書けるなら有用かもしれない

オブジェクト指向は完璧ではないし、スキルがない人ならやらなくてもいいんじゃない？
ただし、C＃とかJavaみたいにオブジェクト指向ありきで設計された言語はやっぱり知識は必要
標準ライブラリ自体オブジェクト指向専用だからね
C#でStreamではなくFileStreamしか受けないメソッドとかを作ってしまったら不便だし、不要なフィールドを公開したら危険だ

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

>>176
オブジェクト指向を使うと、同じものを2つ以上同時に扱うのが簡単なんだよね。
2つのファイルを同時に編集するとか
ぷよぷよの画面を2つならべてみるとか
5人のボンバーマンが同時に動くとかさ。

**デフォルトの名無しさん** · 2014/04/01(火) 20:30:56.47

>>173
スモールトーク系のデバッガーはメソッドチェーンのそれぞれのメソッド呼び出しごとにステップ実行できるらしいよ

**デフォルトの名無しさん** · 2014/04/01(火) 21:54:52.60

>>179
具体的な名前書けっつーてるのに...
結局 ID:CUSBQvN9 は口先番長かよ (w

**デフォルトの名無しさん** · 2014/04/02(水) 21:15:51.80

性能低下を防ぐためにメソッドの内容をメインルーチンに直に展開する作業は、
処理系にまかせることもできるだろうが、それによって多態性は失われる。
それよりもソフトウェアを細かく分割して構成する以上、バージョンの依存
関係が複雑に絡み合うほうが問題として大きい。

**デフォルトの名無しさん** · 2014/04/02(水) 21:49:26.89

>>180
スモールトークっていったらスクイークとかじゃないの？
口先番長認定するまえに自分で調べてみたの？
口の中にご飯をスプーンで入れてもらうまで
馬鹿みたいに口開けて上を向いているタイプの人なの？

**デフォルトの名無しさん** · 2014/04/02(水) 22:04:27.79

>>182
で、そのスクイークとやらは、ブレークかけられんのか？
当然調べたんだよな (w

**デフォルトの名無しさん** · 2014/04/03(木) 00:45:59.14

>>4
ポリモーフィズムはリリースされたプログラムをユーザーが部分的に更新しな
がら使う(ライブラリやDLLを更新する)と、プログラマが当初考えていた以上
の使われ方をして、動作の保証ができなくなる、ってことにならないの？
昔でいうgoto文や、メモリーリークを起こしがちなC言語のポインタみたいに
やっかいなことにならないの？

**デフォルトの名無しさん** · 2014/04/03(木) 00:59:50.75

動作の保証ができなくなるようなことを許すのは単なる欠陥でしょ

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

メソッドごとにコメントアウトすればいいよ
てかメソッドチェーンとしてのチェックってあるかね

**デフォルトの名無しさん** · 2014/04/03(木) 04:56:35.67

>>183
できないと思ってるの？

**デフォルトの名無しさん** · 2014/04/03(木) 07:32:45.27

>>187
できるんなら、その方法書いてくれ。

**デフォルトの名無しさん** · 2014/04/03(木) 08:26:44.88

いい加減に認めろよ……

そもそも仮に「メソッドチェーンはデバッグできない」としても、それは「オブジェクト指向」を否定するのに大事な要素でもないじゃん
何かこだわりでもあるの？

**デフォルトの名無しさん** · 2014/04/03(木) 08:48:37.07

>>189
> いい加減に認めろよ……

何を認めるんだ？
ブレーク掛けられるなら >>151
が情弱と言うことだし、かけられないなら >>156 が口先番長と言うだけのことだろ。
どこから、オブジェクト指向の否定が出てきたんだよ (w

**デフォルトの名無しさん** · 2014/04/03(木) 15:05:44.04

>>188
ちゃんとしたSmalltalk処理系では（つまりGNU Smalltalkとかの変わり種を除けば）一般に
value foo halt bar baz で、bar のコール直前でデバッガを起動させて bar のステップ実行ができる
ってそういうことではなく？　ちなみに halt は古典的なSmalltalkにおけるブレイクポイントみたいなもの。

**デフォルトの名無しさん** · 2014/04/03(木) 15:25:06.01

みんなSmalltalk使ってたのかよ

**デフォルトの名無しさん** · 2014/04/03(木) 17:07:01.60

スモールトークがオブジェクト指向の元祖だからな
スモールトークでできるならオブジェクト指向の欠点とは胃炎な

**デフォルトの名無しさん** · 2014/04/03(木) 17:16:43.96

ていうか、一つの式に詰め込んだら便利かどうかなんてオブジェクト指向と関係なくね？

**デフォルトの名無しさん** · 2014/04/03(木) 19:17:35.74

Smalltalkには、コードを英文のように読み下せるように書く慣習みたいなものがあって、
value foo bar baz みたいな式だとちょっとメリットをイメージしにくいですが、たとえば
「1 から 9 までの数を配列にして、それをシャッフルして最初の３つを得る」みたいな処理を、
(1 to: 9) asArray shuffled first: 3 というふうに一気にメソッドチェーンにして書くようなことはよくします。

そんなこともあって、メソッドチェーンだからデバッグしづらいというような制約はほとんどうけない仕組みになっています。

**デフォルトの名無しさん** · 2014/04/03(木) 20:08:44.08

>>194
そもそもオブジェクト指向についてあんまり語ってないからいいんじゃね

**デフォルトの名無しさん** · 2014/04/03(木) 21:23:31.55

>>191
なるほど、ブレーク+ステップ実行なのね
まあ実用上は十分かな
C# とかでもできるようにしてほしい

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

C++じゃなくてObjective-Cが流行ってれば
オブジェクト指向絡みの論争は半分になったんじゃないかと
思えてしかたがない。
オブジェクト指向が、じゃなくてC++が採用した方法は、な議論大杉

**デフォルトの名無しさん** · 2014/04/04(金) 01:37:59.49

クラスベース vs プロトタイプベース

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

Objective-C十分流行ってるじゃん