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

**デフォルトの名無しさん** · 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 するとプログラムの実行順と同じ順序で
表示されて便利です。