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

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

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

**デフォルトの名無しさん** · 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が強力なプログラミン
グツールになります。