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

**デフォルトの名無しさん** · 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部分と分けて考えるでしょう？
そこから更に各部分を小さく分けて、それをまた小さく分けてって考えていくでしょう？

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