オブジェクト指向の活用方法を教えて下さい
オブジェクト指向言語じゃなくても
オブジェクト指向の話であれば問題ありません。
仕事やってるなら、オブジェクト指向以外を使うことのほうが
まれだよ。まあ空気のようなものだ。
困るのかを教えてください。自分は困ったことがないので。
俺はオブジェクト指向以外の方法論を知らない。
逆にどういうのがオブジェクト指向じゃないのだ？
オブジェクト指向なんて呼び方しているけど、本質的には構造化言語でもやっていた
モジュール化だからな。大量の関数を個別に扱うなんて大変な事をするよりも、
分類してまとめたモジュールを単位として組み合わせた方がシンプルになるからね。
そういう便利なモジュール化を最初から言語仕様に取り込んで
class{} とするだけで誰でも簡単にモジュールが作れるようにしたのが
オブジェクト指向言語。
俺は業務プログラマじゃないよw
C言語は関数を定義するから関数型だよね、と同じ
それは関数名や変数名を区分して、ネームスペースを分けるというところまでで
十分目的を達成できるように思えるのだけれど、それで達成できないことは何？
まあ継承には最初はそんなにお世話にならんが、ある程度のクラス群を定義してくと
それらにグループ的な物が出来てくると思う
しては制限が多すぎるにしても）。
thinkbiganalytics.com/programming-trends-to-watch-logic-and-probabilistic-programming/
実運用
自分１人で自分だけしか触らないプログラムだったら別にそのやり方でもある程度まで出来るだろうけど、
複数人数だとか、他の人が触るだとかするようになると、決めてたことが守られなくなってスパゲティに
なるのが常。
それをしっかりと見張って、ルールを破ったソースは絶対に許さないと監視してくれるのが、
その言語のコンパイラさん。
ちなみに俺も、１人で行うC言語の開発ではオブジェクト指向的に関数名や変数名を区分して作る。
集合論ベースなら論理型じゃないのか？
それだけでアプリケーションになるわけないしな。
実際にSQLだけでアプリを作ったことあるのかい？って話。
> それで達成できないことは何？
複雑さの低減かな。
たとえば、アセンブラ使って比較とジャンプで
ループは作れる。でも言語としてループがあれば簡単に書ける
つまりは複雑さが減ってるわけ。
オブジェクト指向も同じで、使えば複雑さが減る。
読んで考えなきゃいけないことが、
単語一つで、あぁあれね。とすぐに知ることが出来る。
そういうコードになる。
オセロくらいなら作れそうだな
ちょっと面白そう
オブジェクト指向について書かれた本だと例題がそもそも短いので、オブジェクト
指向の導入によって逆に長い記述になってしまうし、わざとらしい例ばかりなので
これで本当に分かりやすくなったの？生産性や保守性は本当に上がったの？という
点がいつまで経っても納得がいかない。
（いまどきの学校なら、先生がちゃんと教えてくれるんだろうか？）
電気回路で例えたら、抵抗とかダイオードとかトランジスタがびっしり基板を埋め尽くす
回路を作っていたのを、ICチップ数個を配線して繋げればいいだけにした
みたいなものかな。
ICチップ自体を作るところで確かに手間はかかるけど、
そのICチップという単位で手軽に扱える便利さが出てくるよね。
foreach構文使える言語ならOOPしなくても簡略化できるぜ。
それがC++などのオブジェクト指向プログラミングになると「オブジェクト」で全体を切り分けるようになる。
電気回路に例えるなら、
それぞれの機能は基盤ごと、チップごとに整理されているが電源が一つしかない状態が構造化プログラミング。
それぞれの機能が自前の電源を持ってるのがオブジェクト指向。
そういうレイヤーの話じゃないんだよね。
あなた関数の中の話をしてるじゃない？関数の中の書き方の話じゃない。
関数ではないものにデータがある。データは関数ではない。
オブジェクト指向はデータにそのデータを扱う関数をまとめたもの。
関連があるものを別々に管理するよりも、まとめたほうがわかりやすい。
データと処理が一体で管理できるから、このデータを扱えることが出来る処理はどれだろう？
などと考えなくて良くなる。管理がものすごく楽になる。
このまとめた物がオブジェクト。
そしてオブジェクト指向は、そのまとめた、物 と 物。
物自体と物同士を組み合わせて使うときの考え方。
物の生成をどうするか？
物の構造をどうするか？
物の振る舞いをどうするか？
たとえばゲームで考えるとね。キャラクターを横に1つ移動するはX座標をプラス1するだけ。
だけどこれだけじゃゲームとして成り立たない。キャラクターには座標以外にも色々な情報がある。
キャラクターが持ってるであろう情報にはどんなものがある？
と聞いたら、いくつも答えが出てくるでしょう？
ならそれをまとめて種類（クラス）として管理したほうが楽じゃない？
敵キャラとかキャラクター自体は一緒だけどデータ（座標など）が違うものってあるじゃない？
敵キャラという物がいてある場面になったら、この物を生成する必要があるじゃない？（敵出現）
敵と自分が戦うとしたら、それは物と物と関連があってそこである作用が発生するということ。
つまりこういうこと。
小さな処理ではなくて、巨大なアプリを作ることを考えてみよう。
座標を1動かすという小さな処理だけを見ていたら分からないが、
なにかアプリを作ろうと思ったら、その処理を沢山組み合わせて作ることになる。
その処理をバラバラに管理していたら複雑になりすぎる。複雑だと時間がかかるしバグも増える。
出来るか出来ないかではなく、複雑にならないように作るというのが実際の開発で必ず求められる要件。
じゃあ、複雑にならないようにある単位でまとめようと思うだろう？
その後はまとめた物同士をどう組み合わせるのがいいか考えるようになるだろう？
そこでオブジェクト指向を使うと自然な形でまとめやすくなるんだよ。
わからなければ実際に頭の中で考えてみたらいい。たとえばブラウザを作るってのはどう？
aタグなら〜、ulタグなら〜などと、いきなり詳細なものを考える前に、まずブラウザを構成している要素。
UI部分、HTMLレンダリング部分、JavaScript部分、CSS部分と分けて考えるでしょう？
そこから更に各部分を小さく分けて、それをまた小さく分けてって考えていくでしょう？
この時大抵の人ならデータと処理を分離せずに分けていくと思うから、それがオブジェクトになるんだよ。
オブジェクト指向でなかったら、最後にデータと処理に分けてそれを関連付ける処理まで考えなといけない。
分けるたびに数は増えるから最後は膨大になるよね。それは嫌だから一つ手前のオブジェクトにしておきましょう。
出来るのは出来るんだよ。
重要なのはどれだけ複雑にしないで出来るかということ。
その複雑という観点が抜けてる意見は的外れで参考にならない。
たまに本当にオブジェクト指向じゃなくても複雑にしないで
できることもある。オブジェクト指向よりもシンプルに作れることもある。
それは問題領域が異なるから。上でSQLの話がでていたが
それはRDBMSからのデータ取得という問題だから。
SQLはその問題に特化した言語なのだから得意なのは当然。
でもアプリを作るという問題の場合は、オブジェクト指向が適していることが多い。
例題程度の短い問題で、オブジェクト指向の利点を感じないのも
短い問題だからという理由で説明できるね。
→ 手間が増えるところ
(B) だけどクラス内のプロパティとメソッドの関連付けに対して名前を付ける必要がない
→ 手間が減るところ
普通、ひとつのクラスには複数(多数)のプロパティ、メソッドがあるので、
abs(B) ＞ abs(A)
ということになり、これが「複雑さの低減」という理解で合ってますか？
abs(B) ＝ abs(A)
のような、１つのクラスに１つのプロパティと１つのメソッドしかないような
ものばかり作っているのが原因ではないかと思えてきました
javascriptみたく、プロトタイプベースのオブジェクト指向あるから、
これは必ずしもオブジェクト指向に当てはまる性質とは違う。
もちろん、名前付けてもいいけど。
ちょっと違うな。 そこは大した問題じゃ無いよ。
問題にしてる複雑さっていうのは、どう頑張っても理解できない複雑な構造の事。
少し微妙なところはあるけれど、
>>30の
> のような、１つのクラスに１つのプロパティと１つのメソッドしかないような
> ものばかり作っているのが原因ではないかと思えてきました
ということであれば、その程度じゃ理解し難いと思うよｗ
処理と定義文の行が同じぐらいだろうからね。
普通は一つのクラスに、複数のプロパティとメソッドある。
関数やクラスの定義のための行よりも、処理の行数のほうが圧倒的に多い。
小さな問題なら関数さえ使わなくていい。
数行で終わる単純なスクリプトなら実際にそうする。
多くのプログラミング技術っていうのは、大きくて複雑な問題を
解決するために考えだされているものだから、
簡単な問題を使わなくても出来る というのは意味がなくて
大きな問題で比較しないといけない。
ので、ICにする意味がない（なかった）、ということです
実際にやって見るのがいいと思う
C#とかなら、書き込みや読み込みを行う抽象クラスであるStreamをとるメソッドに、ファイル、メモリ、ネット、データベースなんかを区別なく渡せたりする
自分でStreamを実装したクラスを作れば、それを利用する側は一切の修正なしに自作のStreamを使える、とか。
そのダイオードがオブジェクトだよ。
ダイオードには入力と出力があってダイオードの仕事をするだろう。
入出力というinterfaceがわかれば、中はブラックボックスでいい。
外から見た時に、中がどんな仕組みなのかは知らなくてもいい。
それがオブジェクト指向だ。
変数自身は極力非公開にして、どこからか勝手にいじられないように隠蔽することだよ。
カプセル化というんだけどね。
それは関数も同じでは？
入出力が分かれば、中はブラックボックスでいいよね？
むしろ単機能という点ではダイオードはむしろ関数に近いかと。
そんな単機能のものではなく、
ダイオードなどを使って作られる製品。
ダイオードなどのパーツを組み合わせて作る製品
その製品を作るために各パーツどうやって組み合わせて効率よく作るか
という方法論としてソフトウェアではオブジェクト指向があると思うよ。
あるということなんだろうけど、勝手にいじられるものが"変数"なのか"関数"なのか
というだけなので、結局同じに思えてしまうなあ
(暴走を引き起こすような)でたらめな値を設定できないようにするということかな？
クラス内部もオブジェクト指向で書くんだよ。
だから関数・メソッドもオブジェクトとして捉える。
ICの中にもICが入ってるだろ？
注目するスケールが違うだけで、方法論は変わらない。
アプリ全体で、そのクラスだけしか使ってないってことはまず無い。
小さなクラスしか見てないからわからないのであって
アプリ全体という大きなもので考えよう。
小さなクラスが数個あろうが、このクラスは他のクラスと
協調して動くでしょう？ そういうところまで含めて考えないとダメだよ。
小さな視点ではなく、大きな視点を持つこと。
大きな視点を持てば、たまたまプロパティが一つしか
無いクラスがあったとしても、それがシステム全体として
必要なことであればなんら不思議ではない。
ダイオードがstreamの一種ならオブジェクトで問題ない。
仕組みの複雑さが外から見えないという意味で、ダイオードは実に成功していると言えるだろう。
クラスとインスタンスの話で
終わっちゃう人がいるけど、
オブジェクト指向の話には
インスタンスとインスタンスを組み合わせて動かすという
構造の話、組み合わせ方の話も含まれるよ。
クラスとクラスの組み合わせも。
（クラスの代わりにインターフェースだったりもする）
ほんと関数の中身などという小さな部分じゃなくて
全体を見ないとね。
小さいプログラムだからOOPの恩恵が無いなどということはない。
Javaでは十分に抽象化され、簡便に使えるように用意されたライブラリ群を使っているではないか。
でも何でもかんでもオブジェクトにしてしまおうとするのは疑問だな。
多い。新しいオブジェクトをくっつけようとして、全部のオブジェクトを書き換えるはめになる。
依存性が多すぎるのだ。究極まで依存性をなくして何でも接続できるようにしたものを、
Inversion of Control (IoC), とか dependency injection (DI) と呼ぶ。テスト環境と本番環境と
で、まったく同じモジュールを動かしてテストできるようになる。が、何もかもIoCやDIにでき
るわけではないので、本当に使えるケースはあまりない。仕掛けが大掛かりすぎて、一行の
SQLやスクリプトに負けてしまうことも多い。
クラスがアプリの構造を表している所だと思う。
クラス（インスタンス）を値として使う場合
たとえばBigInt型みたいな、int値の巨大版みたいな
"値" にはDIを使わない方がいい。
こういう場合は値として普通にnewした方がいい。
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ファイル
です
えと、そのコードを客観的に評価してもらったことある？
たとえばコードメトリクスツールで計測するとか。
その評価がないと、それ見てもなんの参考にもならない。
体育会系的に無駄で非効率な努力すれば
行数なんて稼げるしね。
コピペがだめな行為だってのは言うまでもないと思うけど、
コピペをすると簡単に行数稼げるよ。
ちょうど手元に今作っているソフトのカバレッジ結果を
開いていたから書くわ。オープンソースなので詳細は伏せるけど
1. 秘密
2.1 行数 約750行
2.2 関数の数 98個
2.3 変数の数 不明 (計測する意味が無い)
2.4 ファイル数 20個
2.5 クラス 25個
3. コードメトリクス 10点満点中 9.5
4. カバレッジ 90%
ちなみに一番、評価が低い関数だけど行数32行
行数は問題ではなくて、一つの関数にifとループが
多いから（と言っても8個）評価が低くなってる。
どうかを知りたかったのです。関数はさておき、変数はがんばって捻出しても増やせないと思
います。関数は増やせるかもしれませんが、無理をしそうな気がします。つまり不自然なソー
スになりそうです。
> 2.1 1,000行〜10,000行
> 2.2 5個〜20個
1関数あたり、200行〜500行ってことでいい？
これは多い。コードを把握するために一目で
スクロールしないで見渡せることが重要なので一画面が目安。
だいたい50行〜長くても100行
変数は増やす意味は無い。
それで良いコードになったりも悪いコードになったりもしない。
どちらかと言えば少ない方がいいが、
少なくするほどいいってことでもなく無駄を無くす程度でいい。
オブジェクト指向にすれば、人間らしい仕様変更に比較的強いというだけの話。
1ファイルで10000行は見通し悪くないかねw
俺のは簡単に言うとだが、シンセで80ファイル、各200から1000行程度。
電卓で50ファイル、各100から1500行ってところだな。
長い関数で120行ぐらいだよ。
テキストフィルターがどういうものかわからないけど、変更に強くするとか再利用できるようにするとか
ただ、無理に小分けにしても返って複雑になることもありうる
"メイン"ルーチン という名前がでてきたら
それはアンチパターンだって書いてあった気がするなｗ
1関数10行？それが5個で
1000行 - 10*5 = メインルーチンが950行？
関数20個でもメインルーチン800行だよね？
一度コード品質計測してみるといいよ。
10点満点中1点未満とか言われるだろうから。
表示されて便利です。
技術力が低い人は、良いコードとダメなコードの違いがわからないから。
>>50の内容から、君がまだ良いコードがどんなものか
わからないレベルだろうってことがわかるわけ。
だからそのレベルでオブジェクト指向の利点がわからないのも無理はないし、
現時点でオブジェクト指向は意味が無いって結論づけたらダメだよ。
単に君がまだ未熟だから（それははっきりわかった）ってだけだから。
なんでそんなに追い詰められてんの？
プログラムの実行順が気になる？
それは抽象化ができてないから。
長いコードがあって、その順番まで意識しないといけなくなってる。
つまりそのコードは細かい断片で考えることができないということだよ。
変数もスコープが広くなってるね。着目したい変数でgrepしてわかるということは
変数名は長くなっているはず。でないと他の変数名とかぶるはずだからね。で、関数は使われてないと。
（関数が適切に使われていれば同じ"ローカル"変数名が何度も出てくる。同じでいいから名前考える手間省けるよ？）
関数は引数と戻り値があるだけ。それはいつどのタイミングでも使っても良い。
このようになっていれば、全体のことは考えずにその関数という小さな部分で考えることが出来る。
大きなものを大きなまま作るのではなく小さな物にしていく。
そうすれば順番なんて気にすることはないよ。
順番なんて気にしていたら、ユニットテストで関数をテストするときどうするのさ？
ユニットテストではある関数を狙い撃ちでテストするのよ？
なんでそう思ったの？
俺は新人に教育している気分なんだけどｗ
逆にCOCOMO2でとか言われても誰が答えられるってんだっていう。
つか変数や関数の数って何だよ。どうしてそれが気になる。コボラーか？
俺はどれも気にしないし、計測ツールもいれてねえよチクショウ。
構成するようにすると、関数呼び出しが発生することになってしまいます。それが必然性が
ないものだったら、ロジックを追いづらいし、メンテしずらくなってしまうような気がしま
す。大体、関数の名前を考えるのに苦労してしまって、変な名前をつけちゃいそうです。
個人の技術力の問題であれば、しばらくROMってます。
判断には使えるがそれ以外の目的では使えないよ。
LoCが多くてもは生産性が高いことにはならない
（たとえばコピペをすれば簡単に水増しできるが、これは品質を下げる行為）
> 関数呼び出しが発生することになってしまいます。それが必然性が
> ないものだったら、ロジックを追いづらいし
それも俺の中では答えが出てる。
それは関数呼び出しをした時、関数の中まで見ないとロジックが
わからないようなコード（関数）になっているから。
たとえば、printf()という関数、その関数の中まで追ってみないでしょう？
それは関数名さえ見れば、中を追わなくてわかるから。
追わなくてもわかるというのは、脳に記憶できているということ。
関数の仕様がわかりやすいものは記憶できるが
中で何やっているかさっぱりな関数は記憶できない。
そういう関数は複雑ということ。記憶できないような関数を作らない。
大きなアプリを作るとき、コードをいちいち読んでいたらいくら時間があっても足りない。
だから読む時間を記憶することで圧縮する。とはいっても複雑なものは記憶できないし、
数が多くても記憶できない。俺は記憶術の天才じゃないのでね。
だから、関数はできるだけ単純な機能にする。複雑で高機能なものをたくさん作るよりも
（たくさん作ると名前をつけるのに困るし）
単純なものを少数作って、それを組み合わせるほうが覚えることが少ない。
中を見ないとわからないような関数は作らない。そういうのはだめな関数。
（オブジェクト指向にする理由としてオブジェクトという単位でグループ分けしておけば、覚えやすいというのもある）
そうやって読むべき所を減らしていけばいいんだよ。関数の中を見なくて済むような
そんな関数にしていけば、関数呼び出しが発生してもロジックは追える。見なくて言い分早く追える。
副作用（内部情報を持つ、外部デバイスにアクセスする等）のある関数は
プログラムを複雑にする悪玉菌扱いなんだけどね。
かといって純粋関数だけでプログラムかけるかっていう現実問題はあるけど。
しかし問題の切り分け方として、データと処理がセットになることが必ずしも礼賛されるかというとそうでもない。
実際には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
ファイルやソケットのディスクリプタかな
説明もしやすいし理解も早い
あれのポップアップメニューが変化するのを見せるのがよさそう
俺はStringクラスだと思うね。
この例を出すとどうも必ず叩かれるんだけどｗ
前提として長さをprivateで持ってる実装を考える（例えばjava.lang.Stringね）。
それを、連続したchar領域などと比較する。
strlenしないと長さが得られないのが後者で、
内部に既に長さを持ってるのが前者。
文字列データと、長さ、っていう非常に近い関係のものが、
内部に一緒に揃ってる。
一緒にあったほうがマシだから、一緒にある。
クラスの内側にそれを隠し持ってる。
そして、いろんなメソッドの内部でふんだんに参照してる。
中身がどういう仕掛けになってるのか気にしなくていいのがオブジェクト指向なんじゃないの？
内部で保持してるのかどうかは知らんが
ハンドル持ち回りはCによる実装レベルでも十分確立されてるし
OO言語じゃないと実装がとても大変って例はないもんかね
オブジェクト指向の真髄はポリモーフィズムだと思ってるので
>>77の考え方に反逆するわ
> 実際にはprintf()の中身は複雑なんですけどね。
いや、知ってるってｗ
複雑だけど、関数にすることで、
”中を見なくて良くなっている"
これがいい関数の例。
中を見ないと、どんなことやってるかわからないよ〜。
となってるのが、悪い関数の例。
何をやってるのかさっぱりわからないのは、
ストリーム演算子の中身の話であって、
そのストリーム演算子を使う人は
中身を見なくても、使えるでしょう？
関数の中身を見ないとロジックが追えないというのは
つまりこういうことだよ。（関数名は例ではない）
function process() {
initialize();
calc_price();
save_data()
}
お話が通じないことが良く判ったよ
俺流オペレータが何をやってるのかは中を見なと判らないでしょ
だからストリーム演算子の例を出したのに「使う人は使える」
>（関数名は例ではない）
ちゃんとした関数名にすれば中身見る必要無いだろ
初めて使えるレベルになるものだと思うけどな
それって結局中身見ないとまともに使えないでござるよ…って事にならないかね？
まさかこんなスレでprintfの中身を一度も見たことない奴なんていないだろうから
きっと錯覚してるだけだよ
中を見たいとも思わないし
いやそういうことではなくて、関数名だけでちゃんと表現できてれば中身見る必要なんてないんだよ
結局いくら関数化しても中身見ないといけないようなケースは必ず存在するんだよ
実装を知らなくても使い方が分かればいいと
例は良くわかんない
裏返せば過去に自分が似たような物を作ったり設計書見たりとか
それなりの経験のある中の事じゃないの？
実装がさっぱり想像できないのをいくら眺めたところで
使い方が判るようになるとはとても思えないけど
printfのすべての実装なんて見たことないけど、仕様書どうりの動作をするとわかっている
使い方を知って、かつそれが曖昧になっても関数名や引数で思い出せるってところが分かり易さじゃない？
逆に見ても分からないってのは設計として複雑な気が
std::coutでいえば<<なら直感的だけど>>だと途端に恐怖を覚える
標準ライブラリからは除外したかったと昔どっかで読んだよ
正規表現みたいに書式と引数の型から判定するような仕組みは作れたはずだけど
それを言語仕様に含めてしまうと1関数でしかなかったprintfの書式文字列を
今更特別扱いするのは抵抗がとか紆余曲折あって全く別の方向に逃げた
> 俺流オペレータが何をやってるのかは中を見なと判らないでしょ
いつオペレータの話したの？
ストリーム演算子の話だったよね？
100〜のスレッドの続きを読む