- オブジェクト指向の活用方法を教えて下さい
25 ：デフォルトの名無しさん[sage]：2014/03/26(水) 21:43:06.83 ID:dEVLbQ7F - >>23
そういうレイヤーの話じゃないんだよね。
あなた関数の中の話をしてるじゃない？関数の中の書き方の話じゃない。
関数ではないものにデータがある。データは関数ではない。
オブジェクト指向はデータにそのデータを扱う関数をまとめたもの。
関連があるものを別々に管理するよりも、まとめたほうがわかりやすい。
データと処理が一体で管理できるから、このデータを扱えることが出来る処理はどれだろう？
などと考えなくて良くなる。管理がものすごく楽になる。
このまとめた物がオブジェクト。
そしてオブジェクト指向は、そのまとめた、物 と 物。
物自体と物同士を組み合わせて使うときの考え方。
物の生成をどうするか？
物の構造をどうするか？
物の振る舞いをどうするか？
|
- オブジェクト指向の活用方法を教えて下さい
26 ：デフォルトの名無しさん[sage]：2014/03/26(水) 22:07:44.33 ID:dEVLbQ7F - >>21
たとえばゲームで考えるとね。キャラクターを横に1つ移動するはX座標をプラス1するだけ。
だけどこれだけじゃゲームとして成り立たない。キャラクターには座標以外にも色々な情報がある。
キャラクターが持ってるであろう情報にはどんなものがある？
と聞いたら、いくつも答えが出てくるでしょう？
ならそれをまとめて種類（クラス）として管理したほうが楽じゃない？
敵キャラとかキャラクター自体は一緒だけどデータ（座標など）が違うものってあるじゃない？
敵キャラという物がいてある場面になったら、この物を生成する必要があるじゃない？（敵出現）
敵と自分が戦うとしたら、それは物と物と関連があってそこである作用が発生するということ。
つまりこういうこと。
小さな処理ではなくて、巨大なアプリを作ることを考えてみよう。
座標を1動かすという小さな処理だけを見ていたら分からないが、
なにかアプリを作ろうと思ったら、その処理を沢山組み合わせて作ることになる。
その処理をバラバラに管理していたら複雑になりすぎる。複雑だと時間がかかるしバグも増える。
出来るか出来ないかではなく、複雑にならないように作るというのが実際の開発で必ず求められる要件。
じゃあ、複雑にならないようにある単位でまとめようと思うだろう？
その後はまとめた物同士をどう組み合わせるのがいいか考えるようになるだろう？
そこでオブジェクト指向を使うと自然な形でまとめやすくなるんだよ。
わからなければ実際に頭の中で考えてみたらいい。たとえばブラウザを作るってのはどう？
aタグなら〜、ulタグなら〜などと、いきなり詳細なものを考える前に、まずブラウザを構成している要素。
UI部分、HTMLレンダリング部分、JavaScript部分、CSS部分と分けて考えるでしょう？
そこから更に各部分を小さく分けて、それをまた小さく分けてって考えていくでしょう？
この時大抵の人ならデータと処理を分離せずに分けていくと思うから、それがオブジェクトになるんだよ。
オブジェクト指向でなかったら、最後にデータと処理に分けてそれを関連付ける処理まで考えなといけない。
分けるたびに数は増えるから最後は膨大になるよね。それは嫌だから一つ手前のオブジェクトにしておきましょう。
|
- オブジェクト指向の活用方法を教えて下さい
28 ：デフォルトの名無しさん[sage]：2014/03/26(水) 23:16:50.71 ID:dEVLbQ7F - オブジェクト指向使わないでも ”出来る” とかいうやつがいるけど、
出来るのは出来るんだよ。
重要なのはどれだけ複雑にしないで出来るかということ。
その複雑という観点が抜けてる意見は的外れで参考にならない。
たまに本当にオブジェクト指向じゃなくても複雑にしないで
できることもある。オブジェクト指向よりもシンプルに作れることもある。
それは問題領域が異なるから。上でSQLの話がでていたが
それはRDBMSからのデータ取得という問題だから。
SQLはその問題に特化した言語なのだから得意なのは当然。
でもアプリを作るという問題の場合は、オブジェクト指向が適していることが多い。
例題程度の短い問題で、オブジェクト指向の利点を感じないのも
短い問題だからという理由で説明できるね。
|
- オブジェクト指向は愚かな考え。
352 ：デフォルトの名無しさん[sage]：2014/03/26(水) 23:28:38.92 ID:dEVLbQ7F - 関数とサブルーチンに明確な境目はないけれど、
ちゃんとした関数なら副作用がなくてテストが容易で
コードの中身を見なくても処理が推測できるもので
だめな関数＝サブルーチンは、副作用がメインでテストが難しい
コードの中身を見ないと何をやっているのかさっぱりわからない。
ってイメージが有るな。
たとえば、コードが長くなったから
一部分をそっくり抜き出して、関数にすると
たいていダメな関数＝サブルーチンになってる。
そういうサブルーチンばっかり作っているような技術力の低い所だと
関数（実際はサブルーチン）を使うとあちこちにジャンプする必要があるから
コードが読みにくい！とか言うやつが出てくる。（本当はちゃんとした関数をかけてないから）
|