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

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

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