お願いします。言語は問いません。
オブジェクト指向言語じゃなくても
オブジェクト指向の話であれば問題ありません。
アイ オブジェクト たべたい
オブジェクト指向の活用方法とあらためてきかれてもな。
仕事やってるなら、オブジェクト指向以外を使うことのほうが
まれだよ。まあ空気のようなものだ。
4 ：
デフォルトの名無しさん：2014/03/25(火) 22:27:48.82 ID:NjDRIK2T
ポリモーフィズム
もしオブジェクト指向がなかった場合に困るのであれば、あなたが一体どんな風に
困るのかを教えてください。自分は困ったことがないので。
>>5 俺はオブジェクト指向以外の方法論を知らない。
逆にどういうのがオブジェクト指向じゃないのだ？
SQLは関数型言語ですが何か？業務プログラマじゃないのがバレバレな発言だね。
困るのは関数の数が数百だとか数千だとか、ある程度規模が大きい場合だな。
オブジェクト指向なんて呼び方しているけど、本質的には構造化言語でもやっていた
モジュール化だからな。大量の関数を個別に扱うなんて大変な事をするよりも、
分類してまとめたモジュールを単位として組み合わせた方がシンプルになるからね。
そういう便利なモジュール化を最初から言語仕様に取り込んで
class{} とするだけで誰でも簡単にモジュールが作れるようにしたのが
オブジェクト指向言語。
へー、SQLは関数型なのか。
俺は業務プログラマじゃないよw
SQLが関数型であるという考え方は、
C言語は関数を定義するから関数型だよね、と同じ
SQLは宣言型言語だったかと。HTMLもそうだけど。
>>8 それは関数名や変数名を区分して、ネームスペースを分けるというところまでで
十分目的を達成できるように思えるのだけれど、それで達成できないことは何？
それで出来ないのは属性の隠蔽と、継承による親子関係だな
まあ継承には最初はそんなにお世話にならんが、ある程度のクラス群を定義してくと
それらにグループ的な物が出来てくると思う
実は、SQLは集合論を基にしているという点で、ある種の関数型言語とも考えられる（言語と
しては制限が多すぎるにしても）。
thinkbiganalytics.com/programming-trends-to-watch-logic-and-probabilistic-programming/
>>12 実運用
自分１人で自分だけしか触らないプログラムだったら別にそのやり方でもある程度まで出来るだろうけど、
複数人数だとか、他の人が触るだとかするようになると、決めてたことが守られなくなってスパゲティに
なるのが常。
それをしっかりと見張って、ルールを破ったソースは絶対に許さないと監視してくれるのが、
その言語のコンパイラさん。
ちなみに俺も、１人で行うC言語の開発ではオブジェクト指向的に関数名や変数名を区分して作る。
SQLはクエリーであって、つまり問い合わせであって
それだけでアプリケーションになるわけないしな。
実際にSQLだけでアプリを作ったことあるのかい？って話。
>>12 > それで達成できないことは何？
複雑さの低減かな。
たとえば、アセンブラ使って比較とジャンプで
ループは作れる。でも言語としてループがあれば簡単に書ける
つまりは複雑さが減ってるわけ。
オブジェクト指向も同じで、使えば複雑さが減る。
読んで考えなきゃいけないことが、
単語一つで、あぁあれね。とすぐに知ることが出来る。
そういうコードになる。
>>17 オセロくらいなら作れそうだな
ちょっと面白そう
SQLはチューリング完全じゃないんでしょ
>>18 複雑さの低減のところ、詳しく。
オブジェクト指向について書かれた本だと例題がそもそも短いので、オブジェクト
指向の導入によって逆に長い記述になってしまうし、わざとらしい例ばかりなので
これで本当に分かりやすくなったの？生産性や保守性は本当に上がったの？という
点がいつまで経っても納得がいかない。
（いまどきの学校なら、先生がちゃんと教えてくれるんだろうか？）
18じゃないが。
電気回路で例えたら、抵抗とかダイオードとかトランジスタがびっしり基板を埋め尽くす
回路を作っていたのを、ICチップ数個を配線して繋げればいいだけにした
みたいなものかな。
ICチップ自体を作るところで確かに手間はかかるけど、
そのICチップという単位で手軽に扱える便利さが出てくるよね。
オブジェクト指向によるループの簡略化ってなんだ？アイテレータか？
foreach構文使える言語ならOOPしなくても簡略化できるぜ。
構造化プログラミングでは「機能」で全体を切り分けてた。
それがC++などのオブジェクト指向プログラミングになると「オブジェクト」で全体を切り分けるようになる。
電気回路に例えるなら、
それぞれの機能は基盤ごと、チップごとに整理されているが電源が一つしかない状態が構造化プログラミング。
それぞれの機能が自前の電源を持ってるのがオブジェクト指向。
>>23 そういうレイヤーの話じゃないんだよね。
あなた関数の中の話をしてるじゃない？関数の中の書き方の話じゃない。
関数ではないものにデータがある。データは関数ではない。
オブジェクト指向はデータにそのデータを扱う関数をまとめたもの。
関連があるものを別々に管理するよりも、まとめたほうがわかりやすい。
データと処理が一体で管理できるから、このデータを扱えることが出来る処理はどれだろう？
などと考えなくて良くなる。管理がものすごく楽になる。
このまとめた物がオブジェクト。
そしてオブジェクト指向は、そのまとめた、物 と 物。
物自体と物同士を組み合わせて使うときの考え方。
物の生成をどうするか？
物の構造をどうするか？
物の振る舞いをどうするか？
>>21 たとえばゲームで考えるとね。キャラクターを横に1つ移動するはX座標をプラス1するだけ。
だけどこれだけじゃゲームとして成り立たない。キャラクターには座標以外にも色々な情報がある。
キャラクターが持ってるであろう情報にはどんなものがある？
と聞いたら、いくつも答えが出てくるでしょう？
ならそれをまとめて種類（クラス）として管理したほうが楽じゃない？
敵キャラとかキャラクター自体は一緒だけどデータ（座標など）が違うものってあるじゃない？
敵キャラという物がいてある場面になったら、この物を生成する必要があるじゃない？（敵出現）
敵と自分が戦うとしたら、それは物と物と関連があってそこである作用が発生するということ。
つまりこういうこと。
小さな処理ではなくて、巨大なアプリを作ることを考えてみよう。
座標を1動かすという小さな処理だけを見ていたら分からないが、
なにかアプリを作ろうと思ったら、その処理を沢山組み合わせて作ることになる。
その処理をバラバラに管理していたら複雑になりすぎる。複雑だと時間がかかるしバグも増える。
出来るか出来ないかではなく、複雑にならないように作るというのが実際の開発で必ず求められる要件。
じゃあ、複雑にならないようにある単位でまとめようと思うだろう？
その後はまとめた物同士をどう組み合わせるのがいいか考えるようになるだろう？
そこでオブジェクト指向を使うと自然な形でまとめやすくなるんだよ。
わからなければ実際に頭の中で考えてみたらいい。たとえばブラウザを作るってのはどう？
aタグなら～、ulタグなら～などと、いきなり詳細なものを考える前に、まずブラウザを構成している要素。
UI部分、HTMLレンダリング部分、JavaScript部分、CSS部分と分けて考えるでしょう？
そこから更に各部分を小さく分けて、それをまた小さく分けてって考えていくでしょう？
この時大抵の人ならデータと処理を分離せずに分けていくと思うから、それがオブジェクトになるんだよ。
オブジェクト指向でなかったら、最後にデータと処理に分けてそれを関連付ける処理まで考えなといけない。
分けるたびに数は増えるから最後は膨大になるよね。それは嫌だから一つ手前のオブジェクトにしておきましょう。
要は、プログラマが問題解決の為に注目するスコープを、小さくするって事だよな。
オブジェクト指向使わないでも ”出来る” とかいうやつがいるけど、
出来るのは出来るんだよ。
重要なのはどれだけ複雑にしないで出来るかということ。
その複雑という観点が抜けてる意見は的外れで参考にならない。
たまに本当にオブジェクト指向じゃなくても複雑にしないで
できることもある。オブジェクト指向よりもシンプルに作れることもある。
それは問題領域が異なるから。上でSQLの話がでていたが
それはRDBMSからのデータ取得という問題だから。
SQLはその問題に特化した言語なのだから得意なのは当然。
でもアプリを作るという問題の場合は、オブジェクト指向が適していることが多い。
例題程度の短い問題で、オブジェクト指向の利点を感じないのも
短い問題だからという理由で説明できるね。
(A) オブジェクト指向だとクラスやインスタンスに名前を付けなければならない
→ 手間が増えるところ
(B) だけどクラス内のプロパティとメソッドの関連付けに対して名前を付ける必要がない
→ 手間が減るところ
普通、ひとつのクラスには複数(多数)のプロパティ、メソッドがあるので、
abs(B) ＞ abs(A)
ということになり、これが「複雑さの低減」という理解で合ってますか？
もしそうだとすると、自分がオブジェクト指向のありがたみが分からないのは
abs(B) ＝ abs(A)
のような、１つのクラスに１つのプロパティと１つのメソッドしかないような
ものばかり作っているのが原因ではないかと思えてきました
>オブジェクト指向だとクラスやインスタンスに名前を付けなければならない
javascriptみたく、プロトタイプベースのオブジェクト指向あるから、
これは必ずしもオブジェクト指向に当てはまる性質とは違う。
もちろん、名前付けてもいいけど。
>>30 ちょっと違うな。 そこは大した問題じゃ無いよ。
問題にしてる複雑さっていうのは、どう頑張っても理解できない複雑な構造の事。
>>29 少し微妙なところはあるけれど、
>>30の
> のような、１つのクラスに１つのプロパティと１つのメソッドしかないような
> ものばかり作っているのが原因ではないかと思えてきました
ということであれば、その程度じゃ理解し難いと思うよｗ
処理と定義文の行が同じぐらいだろうからね。
普通は一つのクラスに、複数のプロパティとメソッドある。
関数やクラスの定義のための行よりも、処理の行数のほうが圧倒的に多い。
小さな問題なら関数さえ使わなくていい。
数行で終わる単純なスクリプトなら実際にそうする。
多くのプログラミング技術っていうのは、大きくて複雑な問題を
解決するために考えだされているものだから、
簡単な問題を使わなくても出来る というのは意味がなくて
大きな問題で比較しないといけない。
ICチップの例でいうなら、その中に１個のダイオードしか入っていないものを作っている
ので、ICにする意味がない（なかった）、ということです
>>29 実際にやって見るのがいいと思う
C#とかなら、書き込みや読み込みを行う抽象クラスであるStreamをとるメソッドに、ファイル、メモリ、ネット、データベースなんかを区別なく渡せたりする
自分でStreamを実装したクラスを作れば、それを利用する側は一切の修正なしに自作のStreamを使える、とか。
>>34 そのダイオードがオブジェクトだよ。
ダイオードには入力と出力があってダイオードの仕事をするだろう。
入出力というinterfaceがわかれば、中はブラックボックスでいい。
外から見た時に、中がどんな仕組みなのかは知らなくてもいい。
それがオブジェクト指向だ。
クラスを作る目的の１つは、ある変数に対してアクセスする関数群を同じクラスにまとめて、
変数自身は極力非公開にして、どこからか勝手にいじられないように隠蔽することだよ。
カプセル化というんだけどね。
>>36 それは関数も同じでは？
入出力が分かれば、中はブラックボックスでいいよね？
むしろ単機能という点ではダイオードはむしろ関数に近いかと。
俺もダイオードは関数だと思わ。
そんな単機能のものではなく、
ダイオードなどを使って作られる製品。
ダイオードなどのパーツを組み合わせて作る製品
その製品を作るために各パーツどうやって組み合わせて効率よく作るか
という方法論としてソフトウェアではオブジェクト指向があると思うよ。
>>37 そうだとすると、１つのプロパティしかないような場合でもクラスにする価値が
あるということなんだろうけど、勝手にいじられるものが"変数"なのか"関数"なのか
というだけなので、結局同じに思えてしまうなあ
(暴走を引き起こすような)でたらめな値を設定できないようにするということかな？
>>38,39
クラス内部もオブジェクト指向で書くんだよ。
だから関数・メソッドもオブジェクトとして捉える。
ICの中にもICが入ってるだろ？
注目するスケールが違うだけで、方法論は変わらない。
フリップ・フロップならオブジェクトかもしれないね
一つのプロパティしかないクラスであっても
アプリ全体で、そのクラスだけしか使ってないってことはまず無い。
小さなクラスしか見てないからわからないのであって
アプリ全体という大きなもので考えよう。
小さなクラスが数個あろうが、このクラスは他のクラスと
協調して動くでしょう？ そういうところまで含めて考えないとダメだよ。
小さな視点ではなく、大きな視点を持つこと。
大きな視点を持てば、たまたまプロパティが一つしか
無いクラスがあったとしても、それがシステム全体として
必要なことであればなんら不思議ではない。
javaなんかだと標準出力に文字を表示するのにSystem.out.println("Hello World!"); なんてことやってるわけで
ダイオードがstreamの一種ならオブジェクトで問題ない。
仕組みの複雑さが外から見えないという意味で、ダイオードは実に成功していると言えるだろう。
オブジェクト指向の話で
クラスとインスタンスの話で
終わっちゃう人がいるけど、
オブジェクト指向の話には
インスタンスとインスタンスを組み合わせて動かすという
構造の話、組み合わせ方の話も含まれるよ。
インスタンスとインスタンスを組み合わせだけじゃなくて
クラスとクラスの組み合わせも。
（クラスの代わりにインターフェースだったりもする）
ほんと関数の中身などという小さな部分じゃなくて
全体を見ないとね。
ハローワールドでさえオブジェクト指向の真髄に触れてるわけで、
小さいプログラムだからOOPの恩恵が無いなどということはない。
Javaでは十分に抽象化され、簡便に使えるように用意されたライブラリ群を使っているではないか。
でも何でもかんでもオブジェクトにしてしまおうとするのは疑問だな。
組み合わせが固定的な場合、一見オブジェクトに見えても単なる構造化にすぎないことが
多い。新しいオブジェクトをくっつけようとして、全部のオブジェクトを書き換えるはめになる。
依存性が多すぎるのだ。究極まで依存性をなくして何でも接続できるようにしたものを、
Inversion of Control (IoC), とか dependency injection (DI) と呼ぶ。テスト環境と本番環境と
で、まったく同じモジュールを動かしてテストできるようになる。が、何もかもIoCやDIにでき
るわけではないので、本当に使えるケースはあまりない。仕掛けが大掛かりすぎて、一行の
SQLやスクリプトに負けてしまうことも多い。
IoCやDIを使うところは構造に関する所だと思う。
クラスがアプリの構造を表している所だと思う。
クラス（インスタンス）を値として使う場合
たとえば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ファイル
です
>>50 えと、そのコードを客観的に評価してもらったことある？
たとえばコードメトリクスツールで計測するとか。
その評価がないと、それ見てもなんの参考にもならない。
体育会系的に無駄で非効率な努力すれば
行数なんて稼げるしね。
コピペがだめな行為だってのは言うまでもないと思うけど、
コピペをすると簡単に行数稼げるよ。
>>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個）評価が低くなってる。
関数や変数は多めに数えたんですが、こういった規模でもオブジェクト指向を活用できるのか
どうかを知りたかったのです。関数はさておき、変数はがんばって捻出しても増やせないと思
います。関数は増やせるかもしれませんが、無理をしそうな気がします。つまり不自然なソー
スになりそうです。
>>50 > 2.1 1,000行～10,000行
> 2.2 5個～20個
1関数あたり、200行～500行ってことでいい？
これは多い。コードを把握するために一目で
スクロールしないで見渡せることが重要なので一画面が目安。
だいたい50行～長くても100行
>>53 変数は増やす意味は無い。
それで良いコードになったりも悪いコードになったりもしない。
どちらかと言えば少ない方がいいが、
少なくするほどいいってことでもなく無駄を無くす程度でいい。
オブジェクト指向はプログラムの問題というより人間の問題に近い。
オブジェクト指向にすれば、人間らしい仕様変更に比較的強いというだけの話。
>>54 いや、違います。１関数あたり10行位です。残りがメインルーチンです。
>>50 1ファイルで10000行は見通し悪くないかねw
俺のは簡単に言うとだが、シンセで80ファイル、各200から1000行程度。
電卓で50ファイル、各100から1500行ってところだな。
長い関数で120行ぐらいだよ。
ものによるんじゃない？
テキストフィルターがどういうものかわからないけど、変更に強くするとか再利用できるようにするとか
ただ、無理に小分けにしても返って複雑になることもありうる
アンチパターン（悪いコートパターン）本に
"メイン"ルーチン という名前がでてきたら
それはアンチパターンだって書いてあった気がするなｗ
1関数10行？それが5個で
1000行 - 10*5 = メインルーチンが950行？
関数20個でもメインルーチン800行だよね？
一度コード品質計測してみるといいよ。
10点満点中1点未満とか言われるだろうから。
着目したい変数/関数があったとき、grep するとプログラムの実行順と同じ順序で
表示されて便利です。
で、なんでコードの品質の話をしたかだけど、
技術力が低い人は、良いコードとダメなコードの違いがわからないから。
>>50の内容から、君がまだ良いコードがどんなものか
わからないレベルだろうってことがわかるわけ。
だからそのレベルでオブジェクト指向の利点がわからないのも無理はないし、
現時点でオブジェクト指向は意味が無いって結論づけたらダメだよ。
単に君がまだ未熟だから（それははっきりわかった）ってだけだから。
>>61 プログラムの実行順が気になる？
それは抽象化ができてないから。
長いコードがあって、その順番まで意識しないといけなくなってる。
つまりそのコードは細かい断片で考えることができないということだよ。
変数もスコープが広くなってるね。着目したい変数でgrepしてわかるということは
変数名は長くなっているはず。でないと他の変数名とかぶるはずだからね。で、関数は使われてないと。
（関数が適切に使われていれば同じ"ローカル"変数名が何度も出てくる。同じでいいから名前考える手間省けるよ？）
関数は引数と戻り値があるだけ。それはいつどのタイミングでも使っても良い。
このようになっていれば、全体のことは考えずにその関数という小さな部分で考えることが出来る。
大きなものを大きなまま作るのではなく小さな物にしていく。
そうすれば順番なんて気にすることはないよ。
順番なんて気にしていたら、ユニットテストで関数をテストするときどうするのさ？
ユニットテストではある関数を狙い撃ちでテストするのよ？
>>63 なんでそう思ったの？
俺は新人に教育している気分なんだけどｗ
LoCは何かと馬鹿にされがちだけど、
逆にCOCOMO2でとか言われても誰が答えられるってんだっていう。
つか変数や関数の数って何だよ。どうしてそれが気になる。コボラーか？
俺はどれも気にしないし、計測ツールもいれてねえよチクショウ。
(オブジェクト指向から離れちゃうけど)関数を一画面に収まる規模にして、複数の関数から
構成するようにすると、関数呼び出しが発生することになってしまいます。それが必然性が
ないものだったら、ロジックを追いづらいし、メンテしずらくなってしまうような気がしま
す。大体、関数の名前を考えるのに苦労してしまって、変な名前をつけちゃいそうです。
個人の技術力の問題であれば、しばらくROMってます。
LoCは「同じ仕様のアプリを作った時に短いほうが優れているだろう」という
判断には使えるがそれ以外の目的では使えないよ。
LoCが多くてもは生産性が高いことにはならない
（たとえばコピペをすれば簡単に水増しできるが、これは品質を下げる行為）
Javaは現代のCOBOL
>>67 > 関数呼び出しが発生することになってしまいます。それが必然性が
> ないものだったら、ロジックを追いづらいし
それも俺の中では答えが出てる。
それは関数呼び出しをした時、関数の中まで見ないとロジックが
わからないようなコード（関数）になっているから。
たとえば、printf()という関数、その関数の中まで追ってみないでしょう？
それは関数名さえ見れば、中を追わなくてわかるから。
追わなくてもわかるというのは、脳に記憶できているということ。
関数の仕様がわかりやすいものは記憶できるが
中で何やっているかさっぱりな関数は記憶できない。
そういう関数は複雑ということ。記憶できないような関数を作らない。
大きなアプリを作るとき、コードをいちいち読んでいたらいくら時間があっても足りない。
だから読む時間を記憶することで圧縮する。とはいっても複雑なものは記憶できないし、
数が多くても記憶できない。俺は記憶術の天才じゃないのでね。
だから、関数はできるだけ単純な機能にする。複雑で高機能なものをたくさん作るよりも
（たくさん作ると名前をつけるのに困るし）
単純なものを少数作って、それを組み合わせるほうが覚えることが少ない。
中を見ないとわからないような関数は作らない。そういうのはだめな関数。
（オブジェクト指向にする理由としてオブジェクトという単位でグループ分けしておけば、覚えやすいというのもある）
そうやって読むべき所を減らしていけばいいんだよ。関数の中を見なくて済むような
そんな関数にしていけば、関数呼び出しが発生してもロジックは追える。見なくて言い分早く追える。
オブジェクト指向のこころは良い本だ
72 ：
デフォルトの名無しさん：2014/03/27(木) 07:26:53.08 ID:6dxUJoHd
「オブジェクト」が参照なのって割と不便だよね。
関数型プログラミング的に言うと、
副作用（内部情報を持つ、外部デバイスにアクセスする等）のある関数は
プログラムを複雑にする悪玉菌扱いなんだけどね。
かといって純粋関数だけでプログラムかけるかっていう現実問題はあるけど。
しかし問題の切り分け方として、データと処理がセットになることが必ずしも礼賛されるかというとそうでもない。
もっとも身近なオブジェクト指向の概念って、
ファイルやソケットのディスクリプタかな
説明もしやすいし理解も早い
ファイラー上で見るファイルオブジェクト
あれのポップアップメニューが変化するのを見せるのがよさそう
>>75 俺はStringクラスだと思うね。
この例を出すとどうも必ず叩かれるんだけどｗ
前提として長さをprivateで持ってる実装を考える（例えばjava.lang.Stringね）。
それを、連続したchar領域などと比較する。
strlenしないと長さが得られないのが後者で、
内部に既に長さを持ってるのが前者。
文字列データと、長さ、っていう非常に近い関係のものが、
内部に一緒に揃ってる。
一緒にあったほうがマシだから、一緒にある。
クラスの内側にそれを隠し持ってる。
そして、いろんなメソッドの内部でふんだんに参照してる。
strlenしないと長さが得られないのか、最初から長さを持ってるのか、
中身がどういう仕掛けになってるのか気にしなくていいのがオブジェクト指向なんじゃないの？
昔はそう思ったこともあるが実装とI/Fがあまりにも近すぎてよくない
80 ：
デフォルトの名無しさん：2014/03/27(木) 16:23:36.30 ID:R9FKO6iJ
JavaのStringだと、lengthはフィールドじゃなくてメソッドでは？
内部で保持してるのかどうかは知らんが
>ファイルやソケットのディスクリプタかな
ハンドル持ち回りはCによる実装レベルでも十分確立されてるし
OO言語じゃないと実装がとても大変って例はないもんかね
>>77 オブジェクト指向の真髄はポリモーフィズムだと思ってるので
>>77の考え方に反逆するわ
>>74 > 実際にはprintf()の中身は複雑なんですけどね。
いや、知ってるってｗ
複雑だけど、関数にすることで、
”中を見なくて良くなっている"
これがいい関数の例。
中を見ないと、どんなことやってるかわからないよ～。
となってるのが、悪い関数の例。
C++のストリーム演算子らへんは何をやってるのかさっぱり判らない悪い例じゃないの
>>84 何をやってるのかさっぱりわからないのは、
ストリーム演算子の中身の話であって、
そのストリーム演算子を使う人は
中身を見なくても、使えるでしょう？
関数の中身を見ないとロジックが追えないというのは
つまりこういうことだよ。（関数名は例ではない）
function process() {
initialize();
calc_price();
save_data()
}
>>85 お話が通じないことが良く判ったよ
俺流オペレータが何をやってるのかは中を見なと判らないでしょ
だからストリーム演算子の例を出したのに「使う人は使える」
>（関数名は例ではない）
ちゃんとした関数名にすれば中身見る必要無いだろ
printfも可変引数の仕組みと書式の関係が判ってようやく
初めて使えるレベルになるものだと思うけどな
それって結局中身見ないとまともに使えないでござるよ…って事にならないかね？
まさかこんなスレでprintfの中身を一度も見たことない奴なんていないだろうから
きっと錯覚してるだけだよ
そういう意味だと上のハンドル志向が一番解りやすい
中を見たいとも思わないし
誰かJava8のStreamの話をしてくれ。
かなりprintf族もハンドル取るのあるだろ
いやそういうことではなくて、関数名だけでちゃんと表現できてれば中身見る必要なんてないんだよ
結局いくら関数化しても中身見ないといけないようなケースは必ず存在するんだよ
今言う中身は実装じゃね？
実装を知らなくても使い方が分かればいいと
例は良くわかんない
実装を知らなくても使い方を想像できるってのは
裏返せば過去に自分が似たような物を作ったり設計書見たりとか
それなりの経験のある中の事じゃないの？
実装がさっぱり想像できないのをいくら眺めたところで
使い方が判るようになるとはとても思えないけど
コメントとか仕様書とかに使い方が書いてあれば実装を見なくても済む
printfのすべての実装なんて見たことないけど、仕様書どうりの動作をするとわかっている
想像して使うってのはよく分からないけどsleep()とかsystem()はそれに近いかも？
使い方を知って、かつそれが曖昧になっても関数名や引数で思い出せるってところが分かり易さじゃない？
逆に見ても分からないってのは設計として複雑な気が
std::coutでいえば<<なら直感的だけど>>だと途端に恐怖を覚える
GoogleのC++スタイルガイドではストリームはやめろprintf使っとけって事になってるな。
他の言語に全く採用されないところをみるに、たんに演算子いじれてすごいでしょアピールで実利はなかったんだったんだろう
可変引数は呼び出し側自己申告以外にチェック機能が無いからバグの温床になりやすく
標準ライブラリからは除外したかったと昔どっかで読んだよ
正規表現みたいに書式と引数の型から判定するような仕組みは作れたはずだけど
それを言語仕様に含めてしまうと1関数でしかなかったprintfの書式文字列を
今更特別扱いするのは抵抗がとか紆余曲折あって全く別の方向に逃げた
コンパイラが警告してくれるけどね
>>86 > 俺流オペレータが何をやってるのかは中を見なと判らないでしょ
いつオペレータの話したの？
ストリーム演算子の話だったよね？
俺流オペレータの代表格だわな
代表格 ＝ 同じではないという意味。
そのストリーム演算子を使う人は
中身を見なくても、使えるでしょう？
関数の中身を見ないとロジックが追えないというのは
つまりこういうことだよ。（関数名は例ではない）
function process() {
initialize();
calc_price();
save_data()
}
定義済みのストリーム演算子は覚えればいいから、中を見ないでわかる。
俺俺オペレータで中を見ないとロジックを追えないようなものは
上に書いてあるのと同じ問題がある。
関数がダメなんじゃなくて使い方の問題。
オペレータもそれ自体がダメなんじゃなくて、使い方の問題。
中を見ないとロジック追えないような関数（オペレータも）はダメな関数。
話はこれと何も変わっとらん。反論にはなっていない。むしろ俺と同じことを言ってるだけ。
例えばさ、AppleとかMicroSoftのAPIは実装非公開だし、実装知らなくても使ってますよみんな。
つか、中身はブラックボックスでいいって表現に語弊があるのかな。
全体の構造を見てるときは個々の中身は気にしなくてもいい、
個々の中身を検討してるときは他のオブジェクトは気にしなくてもいいって意味だよ。
スコープを小さくすればわかりやすいよねってこと。
そういうこと。全体の構造を見ている時に
個々の中身を気にしなくちゃいけないコードを書いているから
>>67 みたいに
> 関数呼び出しが発生することになってしまいます。それが必然性が
> ないものだったら、ロジックを追いづらいし
関数呼び出しでロジックが追いづらくなっちゃうわけ。
それは関数の作り方が悪いせいであって関数のせいじゃないんだよ。
本来シフト演算子なはずの << やら >> を入出力に使うっていうのが、
演算子オーバーロードの悪い使い方(=俺流オペレータ)の代表格だっていう話では。
(構造化プログラミングのスレかな？)
（ここまでオブジェクト指向の活用方法の具体例なし）
>>105 話ずれてるなぁ。
良い関数と悪い関数の違いの話だよ？
自分で勝手に作った関数でその中を見ないと
呼び出し元が何やってるかわからないのがダメって話。
ストリーム演算子は普通に記憶してるじゃんか。
中見ないでしょ？
具体例ならエロい人のソースを覗き見…
ぐへへ
>>102 > function process() {
> initialize();
> calc_price();
> save_data()
> }
その三つの関数は、再利用もしないし、他からも呼ばれないんじゃないの？
だったら、中身を見る必要ないよね。
中身を見る必要があるとしたら、バグフィックスか仕様変更のときかでしょ。
> 中身を見る必要があるとしたら、バグフィックスか仕様変更のときかでしょ。
ほら中見てるじゃんｗ
中身を見なくていい ＝ 機能もバグ取りもドキュメントも完成してるってことだから
今自分または開発チームが手がけてる関数は全て悪い関数ということになる。
>>112そうとは言い切れないよ。
関数の仕様がシンプルで覚えやすければいい。
覚えるには何度も使うことが必須で
結果的に汎用性が高い（だから何度も使える）ものってことになる。
>>111 > ほら中見てるじゃんｗ
見ないとロジック追えないだろ。
どんな関数でもメソッドでも同じ。
バグフィックスか仕様変更が必要なら、どんな場合でもそのコードを見る必要がある。
このことと、その関数の良し悪しは関係無い。
>>114 > > ほら中見てるじゃんｗ
> 見ないとロジック追えないだろ。
君は少し勘違いしてるね。
上位関数のロジックを追う時に
下位関数のロジックを追わないとわからないって話だよ。
> function process() {
> initialize();
> calc_price();
> save_data()
> }
上位関数 = processのロジックを追う時に
下位関数 = initializeやcalc_priceやsave_data の
ロジックを追わないと上位関数が何をしているのかわからない。
function process(name) {
printf("hello " + name);
}
でもこの場合は上位関数（process）のロジックを追っている時に
下位関数（printf）のロジックは追わない。
上位関数のロジックを追う時に
下位関数のロジックを追わないとわからないような
コードになってるから、
コードを解析するときに、関数があるたびに
下位関数の実装先にあっちこっちジャンプしていって大変なことになる。
ここから発展して、
privateメソッドが、privateメソッドを読んでいて
そのprivateメソッドが、更にprivateメソッドを読んでいて
更にそのprivateメソッドが、privateメソッドを・・・みたいに
（再帰ではなく）文法上のコールスタックが深いものも
ダメな関数の一例だろうね。
なぜなら、privateメソッドは通常汎用的ではない。
汎用的なものに比べたら使われる回数が少ない。
こんなものは覚えられないし、覚える必要もない。
だから上位関数のロジックを追ってる時に
下位関数のロジックを追うことになる。
>>116からの
>>117は誤解を生むだろう。
関数への切り分けが適切であれば、利用している関数内で何してようが関係ない。
そうでないから、切り分けがまずいから結果としてサブのサブまで降りていかないといけないというのはわかるが、
構造としてサブのサブを呼び出すことが悪というのは真ではない。
オブジェクト指向は1990年代の話題
当時は実装メモリも少なかったので、コンパイルサイズの上限に達しないように
コンパイル単位となるファイルや関数を小さくしなければならなかった。また
CPUの性能も低かったので、コンパイル単位を小さくすることで再makeにかかる
時間を節約していた。そうでなければとてもじゃないが、実務では使えなかった。
現代では分かりやすさを犠牲にしてまで、小さい関数を量産する必要はなくなっ
ている。
以上、教科書に載らないオブジェクト指向の歴史
>>29 名付けを手間と思ってる時点で…
そういうやつに限ってコメントはダラダラズラズラ書く
そのコメントへの労力をまるごとメソッド名なり変数名なりの名付けに当てれば問題ない
>>67 ずっと読んでて思ったけど、もしかしてこの人がstaticおじさん？
ようやくスレ全部読んだが、ポリモーフィズムとか委譲とかDIとかやってて、そういう話をしてるもんだと思って覗いたから
なんか逆に新鮮な気持ちになったぜ
俺が恵まれてるだけなんだろうが、50行を超える関数には出会ったことがない
自分でも書いたことがない
50行を超える関数ぐらい出会うだろ？
オープンソースのコード読んだことある？
オブジェクト指向で作られたライブラリを手続きの中で利用するのがベスト。
自身の構造をオブジェクトのネットワークで表現するのは問題を複雑にするだけ。
オブジェクト指向は基盤レイヤーで収まっていればいい。
より上のレイヤーは構造化プログラミングとモジュール化で対応すべきだ。
>>125 >自身の構造をオブジェクトのネットワークで表現するのは問題を複雑にするだけ。
ならプログラマーなんかやめたほうがいい。適性なし。
言いたい事はわかる。きれいに階層化されたツリー構造の方が処理を追いやすい。
しかし、どうしてもオブジェクトグラフがネットワーク状になる場合があるし、
ユーザーがオブジェクトどうしを自由に接続できるアプリだってある。
プログラマ適性なしは言い過ぎ
最近は非オブジェクト指向の言語も注目されてきてるよね
関数型の次はなんだ？
OOだろうが非OOだろうが、
粒度の小さなデータ構造でネットワークを形成することを
「複雑にする」と思う時点でプログラミングに向いていない。
メインルーチンでまとめて管理すればいいものを、
処理とデータをセットにすることに拘った挙句、
メディエータパターンなんてマヌケな再発明を強いられるOOPに哀愁を禁じえない。
巨大なメインルーチンねえ。描画とかどうすんのかな。
描画はイベントドリブンか、メインループの中で描画オブジェクトの配列を作るわ。
しかたない。SEにでも転職するか。
適性とかそういう話じゃないなコレ、教育不足に経験不足だ
数珠つなぎのメソッドチェーンを呼び出して何をするのかと思ったら、単に変数
に値を代入(または取得)して終わり、みたいのをよく見かけます。途中に現れる
メソッド名を見ても必然性を感じません。その階層で何をするでもないのです。
そういう場合はただの変数の代入に書き換えます。
(ついでなので)変数の名前はその目的が分かる名前に直します。
まるでオブジェクト指向の本質は多重のメソッド呼び出しだ、と言わんばかりな
のです。自分はそんなことより、単なる変数・関数であったとしても命名を重視
したいです。
規模の大きいソフトウェアの場合、名前をグルーピングして、階層を持たせて命
名することに異論はありません。でもそもそもそんなに大きいソフトウェアを
作っているわけではないんです。
世界にひとつだけの名前にして衝突を未然に防ぎたい、ということでしょうか？
同じことがメソッド呼び出しにも言えます。チェーンしているメソッドがそれぞ
れ何を意味しているのか分かりづらい上、記述の順序と実行の順序が異なるので
す。
例えば文章において、姓名は「姓」と「名」を近くに記述することで「姓名」と
なって、ひとりの人を表わすことができます。日付の「年」「月」「日」も電話
番号の「市外局番」「市内局番」「加入者番号」も同様です。これらをばらばら
に離して記述すると読み解くのに苦労することでしょう。
記述の順序が実行の順序と一致しないというのは、そういう状況に似ています。
ソースプログラムがまるでなぞなぞのようになってしまうのです。
実行順序が隣り合っているものは隣り合わせて記述すると分かりやすいプログラ
ムになります。修正も簡単です。テキストエディタやgrepが強力なプログラミン
グツールになります。
>>137,138
オブジェクト指向の必要性とは、規模とか複雑さとか再利用性の問題だから、
当てはまらなければ気にしなくてもいいんだよ。
メソッドチェーンが何かを知らない人に説明しておくと、
value を foo関数で加工して、bar関数で加工して、baz関数で加工するという、
シェルスクリプトで言えば
cat var | foo | bar | baz というのを
baz(bar(foo(value))) という逆順で書くのではなく、
value.foo().bar().baz() という風に
処理の順番の通りにかけるようにした方法です。
ただそれだけのことです。
どちらがわかりやすいかは言うまでもありませんね。
メソッドチェーンだと書いている順番に
処理が実行されるからわかりやすいんだよな。
オブジェクト指向だと、メソッド名短くても
かぶらないからその点でもメリットがある。
なあんだ！どっちの目を使うかなんだね！
> baz(bar(foo(value))) という逆順で書くのではなく、
これって引数無いからまだわかりやすいけど、
引数あると見にくいんだよね。
baz(bar(foo(value, 1, 2), true), "test");
呼び出しが深くなるにつれて、bazと"test"みたいに距離がどんどん離れちゃう。
これがメソッドチェーンだと
value.foo(1,2).bar(true).baz("test");
このように関数と引数が近くに集まる。
これもオブジェクト指向の活用方法の一つだろうね。
だらだら連ねて1文に詰め込むのはデバッガで追いにくくなるからあまり好きじゃない。
>>139 >オブジェクト指向の必要性とは、規模とか複雑さとか再利用性の問題だから、
はずれ。
返り値をチェックして独自のエラーログを出したいｗ
>>146 つまり、
baz(bar(foo(value, 1, 2), true), "test");
こういうのを
v = foo(value, 1, 2);
v = bar(v, true);
v = baz(v, "test");
って書くってこと？
おっと、メソッドチェーンとは関係ない話だったから
関数の方でレスしちゃったｗ
>>149 > value.foo().bar().baz()
bar( ) の挙動確認したいから、この行の bar( ) の呼び出しでブレーク掛けられるデバッガ教えてくれ
訂正（笑）
> baz(bar(foo(value, 1, 2), true), "test");
bar( ) の挙動確認したいから、この行の bar( ) の呼び出しでブレーク掛けられるデバッガ教えてくれ
メソッドチェーンならこれが使える。
メソッドチェーンの p デバッグ? それ tap でできるよAdd Starasakichy
http://d.hatena.ne.jp/mas-higa/20100805/1281018189 function p(obj) { print obj }
value.foo(1,2).bar(true).tap(p).("test");
まあ関数でも使えるよ。見難くなるけどねｗ
baz(p(bar(foo(value, 1, 2), true)), "test");
難しいことをしようとすれば、何を使っても複雑になる。
言語やパラダイムが複雑なんじゃなくて、解決しようとしている問題が複雑なだけなんだ。
えと、ああ、うん、
言語の違いっていうのは、問題がどうとかじゃなくて
読みやすさと書きやすさの違いの話なんだけどね。
>>151 え？そんな簡単なこともできない開発環境でオブジェクト指向とか大笑いだな
>>141 >シェルスクリプトで言えば
>cat var | foo | bar | baz というのを
このとき、foo や bar が何もしないプログラムであっても baz の前に入れることに
意味はありますか？関数型で組む場合は、何もしない関数 foo(), bar() を挟み込む
発想になったことがありません。必要になったとき、何かをしたくなったとき、その
ときに追加しています。
>>102 思うことは二つある。
1) 結局中身って見なくてもよくね？
どんな糞名前、糞用途でもAPIとして資料があって
int aaaaaaaaabbbbbbbbbbb(int x, int y)
x + yが素数のとき0を返し、それ以外のときyを返します。
となっていれば、中身は見なくてよくね？
実装なんてどーでもいいし想像したくもない。
2) 用途と名前が優れていればなおよし
シンプルな名前で表現されていれば、
APIリファレンスを紐解くことすら不要。
bool isprime(int x)ならこれだけで十分。
継承とインターフェイスだけで十分便利
>>157 たぶんお前の説明が下手くそだと思うんだが、いかなる場合も何もすることがない関数なんて言語問わず存在意義あるわけないじゃん
メソッドチェーン関係なく単に修正ミスとかだろ
もしくは、お前が知らないだけで何かの意味があるんだよ
よくみるなら具体例出してみろ
それでどうやって一行で書くの？
かりにメソッドチェーンという糖衣構文があるからといって実際に使う時は
object.func1(arg1, arg2, arg3)
.func2(arg1, arg2, arg3)
.func3(arg1, arg2, arg3)
...
.funcN(arg1, arg2, arg3);
って書くわけで、別にワンライナーしたいとかいう話ではないはず。
一つのオブジェクトに対して連続的にメソッドを呼び出す場合に、
それが手続きや意味ある関連として成立しないならまぎらわしいからやめろっていうのが
>>137-138の主張じゃないの。
メソッドチェーンまで糖衣構文かよｗ
これのどこが構文なんだ？
ライブラリの仕様だろ。
Withは見にくいからやめろという主張をよく聞くが
メソッドチェーンの利点はメソッドで加工を行ってそれを別のメソッドに引き渡せるっていうこと
同じオブジェクトにたいして関連したメソッドをいくつも呼ぶ時も行を分けたりとかしなくて済むから見やすい
>>165 withが見にくくてメソッドチェーンが見やすいってのも変な話だな。
記述に大差ないのに。
みんな、見やすいかどうかは
文字列の長さや行数で変わるってことを
理解してないよ。
たとえばこの二つ。
var newValue = value.fooFooFooFooFooFoo().barBarBarBarBarBar().bazBazBazBazBaz();
var newValue = value.foo().bar().baz();
単に文字列の長さが違うだけでやってることは全く一緒。
だけど上の方は見難くて下の方は見難くはない。
つまりどういうコードが見やすいかどうかは、単に文字列の長さだけでも変わってくるということ
だから文字列が長くなる場合にメソッドチェーンで一行にすることは不適切。
逆に言えば、文字列が短い場合に有効なのがメソッドチェーンというわけ。
withが見やすいのは、文字列が長くなった場合の話で
短いならばメソッドチェーンの方が見やすい。
どちらが、どんな場合でも見やすいなんてことにはならないんだよ。
短かろうと一行にするのはよくないと思うな。
オブジェクトが無い場合に
foo(); bar(); baz();
なんて書けるけど、実際はたとえ関連があっても横に連ねては書かないし。
メソッドチェーンにしたって
graphics.clearRect(0,0,640,480).drawRect(100,100,50,50).drawCircle(50,50,100)...
なんて横には書かなくね。
> foo(); bar(); baz();
>
> なんて書けるけど
書けないよ。
baz(bar(foo()));
こうだろ
>>170 今の話の流れにおけるメソッドチェーンでは
自身のインスタンスをreturnするから、
その例のような意味でつなげてるのでは無いよ。
>>170 インスタンスに対して操作をするんだろう？
じゃあ、何らかの引数がなければ、
同じ意味にならないじゃないか。
>>156 で、具体的なデバッガの名前とやり方は？
>>169 複数の文を一行で書くのはなんか嫌だけど、メソッドチェーンなら気にならないな
ifの後ろとかにつけていたい目を見そうだからかな
しかし、メソッドチェーンもやっぱりAndroidみたいに何十行にも渡るのは読みかにくいからせいぜい数行が限度だとは思う
逆に数文字の命令が何十行にも渡って書かれる光景はイライラする
>>174 関数型言語はわからんが、重宝するならなんか意味があるんだろ？
>>160 具体例は公開できないので申し訳ない
その1. メソッド名が訳の分かる名前ならば、その中身を心配して見にいく必要はない
⇒ これはレスや参考図書がよく使う 'foo' だの 'bar' だののレベルの名前を開発
しているプログラムに使っていることが問題なのだと思う
その2. 場合によっては改名するつもりで中身を見にいくと、なんでこれを括りだしたの？
という疑問が発生(もとから括り出す必要はなくて、名前も要らないんじゃないの？)
⇒ メソッドの中身をメインルーチンにコピペして解決!!
オブジェクト指向の話がいつの間にかコピペの話に...
オブジェクト指向って、どんな場合に役に立つのか、また活用方法を知りたい
のです
あるいはオブジェクト指向があるから常に使わなければならない、という考えは
間違いで、使うか使わないかは便利か便利じゃないか、解決しようとしている
問題や環境・状況に合わせて、判断すればいいものなのか？
そのとき、判断材料には本人や周りのひとのスキルを含めなくていいのか？
人のスキルに関係なく、いつでも・絶対にオブジェクト指向が有利なのか？
メソッド呼びさえしていればオブジェクト指向なので後ろ指さされることは
ないものなのか？
>>176 なんだ、昨日の続きならそうかけよ
当然、 fooとbarとかの名前なら書いたやつが無能なだけ。
jQueryとかrubyみたいにわかりやすい名前がいい
中身はどこかでまたつかうとか、メソッドチェーンでシンプルに書けるなら有用かもしれない
オブジェクト指向は完璧ではないし、スキルがない人ならやらなくてもいいんじゃない？
ただし、C＃とかJavaみたいにオブジェクト指向ありきで設計された言語はやっぱり知識は必要
標準ライブラリ自体オブジェクト指向専用だからね
C#でStreamではなくFileStreamしか受けないメソッドとかを作ってしまったら不便だし、不要なフィールドを公開したら危険だ
>>176 オブジェクト指向を使うと、同じものを2つ以上同時に扱うのが簡単なんだよね。
2つのファイルを同時に編集するとか
ぷよぷよの画面を2つならべてみるとか
5人のボンバーマンが同時に動くとかさ。
>>173 スモールトーク系のデバッガーはメソッドチェーンのそれぞれのメソッド呼び出しごとにステップ実行できるらしいよ
>>179 具体的な名前書けっつーてるのに...
結局 ID:CUSBQvN9 は口先番長かよ (w
性能低下を防ぐためにメソッドの内容をメインルーチンに直に展開する作業は、
処理系にまかせることもできるだろうが、それによって多態性は失われる。
それよりもソフトウェアを細かく分割して構成する以上、バージョンの依存
関係が複雑に絡み合うほうが問題として大きい。
>>180 スモールトークっていったらスクイークとかじゃないの？
口先番長認定するまえに自分で調べてみたの？
口の中にご飯をスプーンで入れてもらうまで
馬鹿みたいに口開けて上を向いているタイプの人なの？
>>182 で、そのスクイークとやらは、ブレークかけられんのか？
当然調べたんだよな (w
>>4 ポリモーフィズムはリリースされたプログラムをユーザーが部分的に更新しな
がら使う(ライブラリやDLLを更新する)と、プログラマが当初考えていた以上
の使われ方をして、動作の保証ができなくなる、ってことにならないの？
昔でいうgoto文や、メモリーリークを起こしがちなC言語のポインタみたいに
やっかいなことにならないの？
動作の保証ができなくなるようなことを許すのは単なる欠陥でしょ
メソッドごとにコメントアウトすればいいよ
てかメソッドチェーンとしてのチェックってあるかね
いい加減に認めろよ……
そもそも仮に「メソッドチェーンはデバッグできない」としても、それは「オブジェクト指向」を否定するのに大事な要素でもないじゃん
何かこだわりでもあるの？
>>189 > いい加減に認めろよ……
何を認めるんだ？
ブレーク掛けられるなら
>>151 が情弱と言うことだし、かけられないなら
>>156 が口先番長と言うだけのことだろ。
どこから、オブジェクト指向の否定が出てきたんだよ (w
>>188 ちゃんとしたSmalltalk処理系では（つまりGNU Smalltalkとかの変わり種を除けば）一般に
value foo halt bar baz で、bar のコール直前でデバッガを起動させて bar のステップ実行ができる
ってそういうことではなく？ ちなみに halt は古典的なSmalltalkにおけるブレイクポイントみたいなもの。
みんなSmalltalk使ってたのかよ
スモールトークがオブジェクト指向の元祖だからな
スモールトークでできるならオブジェクト指向の欠点とは胃炎な
ていうか、一つの式に詰め込んだら便利かどうかなんてオブジェクト指向と関係なくね？
Smalltalkには、コードを英文のように読み下せるように書く慣習みたいなものがあって、
value foo bar baz みたいな式だとちょっとメリットをイメージしにくいですが、たとえば
「1 から 9 までの数を配列にして、それをシャッフルして最初の３つを得る」みたいな処理を、
(1 to: 9) asArray shuffled first: 3 というふうに一気にメソッドチェーンにして書くようなことはよくします。
そんなこともあって、メソッドチェーンだからデバッグしづらいというような制約はほとんどうけない仕組みになっています。
>>194 そもそもオブジェクト指向についてあんまり語ってないからいいんじゃね
>>191 なるほど、ブレーク+ステップ実行なのね
まあ実用上は十分かな
C# とかでもできるようにしてほしい
C++じゃなくてObjective-Cが流行ってれば
オブジェクト指向絡みの論争は半分になったんじゃないかと
思えてしかたがない。
オブジェクト指向が、じゃなくてC++が採用した方法は、な議論大杉
クラスベース vs プロトタイプベース
Objective-C十分流行ってるじゃん
ここ5年ぐらいでiOS用で一気に拡まったけど90年代を通じて
一般の想定するオブジェクト指向と言ったらC++だったからな…
90年代後半からはそこにJavaが加わり…的な。
ある意味バカみたいに基本に忠実なObjective-Cの方が
オブジェクト指向とは～って議論のたたき台としてはよかったよな的な。
>>197 と言うか、行単位でのブレークポイントなのはデバッガの都合でしかないんだよなあ
>>202 式の途中にブレークポイントを入れるのはデバッガだけでは無理っす。
>>203 いや、だからそれって 今の デバッガだからだろ？
技術的にできない訳じゃなかろ
最低限、コンパイラにも手を入れる必要があると思うぞ。
デバッガのブレークポイントの指定が
行単位ってだけで、関数単位でのステップは可能。
そして関数単位で止めたいなら
関数ごとに改行すればいいだけじゃない。
>>206 > デバッガのブレークポイントの指定が行単位ってだけで、
たいていの IDE は行単位ではなくてステートメント単位じゃね？
> 関数ごとに改行すればいいだけじゃない。
そもそもそんなことしたくないか、発端だろ。
デバッグのためにソース弄るとかは最後の手段だろ。
>>206 だーかーらー、
コンパイラが出す行情報以外にどうやって
ブレークかけるアドレスを取り出すわけ？
関数ごとに改行したところで
普通のコンパイラはステートメント単位でしか行番号情報ださねーぞ。
もしかして、単にデバッガのUIの問題だと思ってた？
甘杉
そういうスレたててやれ
いったいどのデバッガやコンパイラについて話してるのか知らんが、
VS2013とかにはメソッドチェーンのデバッグ機能あるぞ……
メソッドチェーン中の個々のメソッドについて戻り値とその型を表示してくれる
オブジェクト指向を使うには、変数や関数がある程度以上の個数がないと無意味。
あとインスタンスが２個以上必要な場合じゃないと意味がない。
俺の分野ではどちらも当てはまらないので、オブジェクト指向が活用できない
という結論に至った。みんな、ありがとう。
オブジェクト指向が活用できない分野ってどんな分野よ
書き換えて再利用とか機能の追加が少ない機械みたいな分野だったら
(構造化言語の)Cそのまんまで十分じゃないの、とは思う。
>>212の日本語訳
「俺がいつも書くコードはオブジェクト指向になっていない。
だから俺の分野ではオブジェクト指向は使えない。」
「オブジェクト指向」の部分にどんな技術を入れても成立する
魔法の言い訳だな。
同じものが沢山作れる、ってのは確かにオブジェクト指向のミソだが、
インスタンスが一つだろうと、オブジェクト指向プログラミングによって得られるものは色々あるぞ
再利用性とか、単体テストのしやすさとか、拡張性とかな
あと、オブジェクト指向プログラミングの重要なデザインパターンに「シングルトン」というのがあって、こいつはインスタンスを一つに限定するものなんじゃな
インスタンス一つだから役に立たない、ってのは世の中のプログラマには通じないと思われる
記述側がより人間の思想に近くなったメリットと、実装側でからくり（C++ なら vtable）を生成コードに常に追加するコストとを天秤にかけたら、どっちに軍配があがるかは人それぞれだね
ライナスは OO をぼろくそにけなしているね
>>216 > 再利用性とか、単体テストのしやすさとか、拡張性とかな
単体テストはべつにして、再利用性とか拡張性とか広い意味では複数インスタンスじゃね？
あと、同じものをたくさんじゃなくって、ちょっと違うものを作れるって言うのがミソかと。
>>217 > ライナスは OO をぼろくそにけなしているね
ライナスだけじゃね？ｗ
しかも俺らはカーネル作ってるわけじゃないから、
用途によって言語は変えるべきという正しい考え方からすると、
ライナスが何言っても何使っても関係ないよねｗ
どっちに軍配があがるかは人それぞれというより
用途によりけりってことだろう。
で、大概の用途にOOに軍配が上がると。
ここまでの内容ならライブラリで十分。オブジェクト指向は不要。
ライブラリとオブジェクト指向を同列に語ってる馬鹿は黙ってろよ
こういうのを見ると、やっぱりオブジェクト指向が一般的であることがよく分かるよ。
.NETにおけるSOLID設計原則とデザインパターン
http://www.infoq.com/jp/news/2013/09/solid-principles-revisited SOLIDとは５つの設計原則の頭字語である。氏の簡潔な説明を借りれば：
単一責務の原則(Single Responsibility Principle)
すべてのオブジェクトは唯一の責務を持たなければならない。すなわち，実行することはただひとつでなければならない。
開放/閉鎖の原則(Open-Closed Principle)
クラスは拡張に対しては開いて(Open)，修正に対しては閉じて(Close)いなければならない。
Liskovの置換原則(Liskov Substitution Principle)
派生クラスは親クラスの置換として使用可能でなければならない。なおかつ，同じ振る舞いをしなければならない。
インターフェイス分離の原則(Interface Segregation Principle)
使用しないインターフェースへの依存をクライアントに強制してはならない。
依存関係逆転の原則(Dependency Inversion Principle)
具体的な実装よりも抽象に依存するべきである。これはコードの分離に有効だ。
>>223 vtableを生成コードに常に追加するコストに見合うものかどうか疑問だね
vtableの生成コストとか言い出したら、スクリプト言語なんて論外じゃねーかw
C++だとvtableは必要なとこにしか付かないよね
ぷらぷら。ぼくはvirtualなメソッドじゃないよ。
なんでここだけC++初心者スレみたいになってんの？
一番知名度のあるオブジェクト指向プログラミング言語はJavaの筈なのにね
致命度？
いいや、Objective-Cが最後に勝つね
Objective-C++が節操なくて素敵だよw
オブジェクト指向に相対するパラダイムってなによ
関数型＋代数的データ型？
それは相対する、ってほどでも無いような
オブジェクト指向自体も考え方が複数あるからなあ…
関数型はともかく、手続き型でオブジェクト指向に真っ向から相対して組むとすれば
・データと処理がお互いに依存しないように組む、例えば特定のユーザ定義型に依存する処理などは控え、ひとつずつ引数で渡してもらうなどする
・モジュールは流れに沿って切り分ける、例えば全てのデータはデータモジュールに、全ての初期化は初期化モジュールに、本処理はメインモジュールに書く
とか、そんな感じになるのかな
向いてる方向が違うんだから、遠い近いはあるだろうけど相対って言うのはないんじゃね？
昔DDDっていうデバッガ使ってたな...
DDT (CP/M-80) じゃなくて？
最近ベクトル演算をする必要が出てきたので、オブジェクト指向のプロパティを
使って実現しようと考えている。
○か×か？
実際にベクトルクラスがあるからそれ参考にする
同じメソッド呼び出しを何度も行うと呼び出しのコードをコピペすることになっ
てしまいます。何もせず名前の意味も不明な多重のメソッド呼び出しはコピペを
防ぐためだったと判明しました。もちろん手打ちしたとのことです。
オブジェクト指向脳っていうんですか？本当に怖いです。
>>243 それ違う。関数脳っていうの（笑）
同じ関数呼び出しを何度も実行すると
関数を何度もコピペすることになるからね（爆笑）
>>243 それ違う。アセンブラ脳っていうの（笑）
同じニーモニック呼び出しを何度も実行すると
ニーモニックを何度もコピペすることになるからね（大爆笑）
>>243 人生で同じ英単語・アルファベットを何度もコピペする略（ゲラゲラ）
なんか面白いんだろうな...
俺には理解できないけど
プログラマはソースのコピペを恐れないでください。誰でも最初は初心者で、
しかも誰もが成長するとは限らないのです。
成長を強いるオブジェクト指向が、万人の解決策になり得ないのは明らかです。
コピペこそが、初心者からベテランまで、万人の解決策となり得るのです。
第一、grepすらできないソースをメンテナンスできるはずありません。
コピペによるプログラミングは、複雑に絡まったバージョン依存問題を解決する
という、潜在的なポテンシャルがあります。
大体、オブジェクト指向を推進する人は、協調性がない人が多く、共同で作業す
るには向いていないのです。冗談のセンスすらありません。
全部反対のことを言っていると見抜けば
>>248が言っていることに納得できるはずｗ
なんか面白いんだろうな...
俺には理解できないけど
ここで僕らは「良いソフト部品は、有名なのだけだ」という原則に立ち戻る必要があるだろうね。
誰も使ってない、メンテナンスもされない俺様オブジェクト部品を使うくらいなら、コピペの方がましな
んだよ。宣言型か関数型が使えるならその方がいいし、使えなければテストの自動化で乗り切る
しかないと、もう１０年も前からいわれて続けているわけだ。
research.microsoft.com/en-us/um/people/blampson/70-SoftwareComponents/70-SoftwareComponents.htm
うん、まったくだ。
有名なソフトは良い。
有名じゃなくても良いソフトはまれにあるけど、
多くの、つまり何万、何十万とある無名なソフトはクソでしかない。
ストラウストラップが「オブジェクト指向というのは継承と再利用なんだよ！」ってやったせいで
えらい風評被害やな。
単にクラスというCでの関数に代わる単位の取り回し方法だから
Objective-C辺りじゃ継承…めんどいから使わない
NSObjectってクラスの基本的ふるまいを持った基底クラスから
テキトーなクラス作って、その中に使えるクラスぶち込んで
メッセージ(メソッド)オーバーライドでふるまい変えて使う。
クラスとは単にレゴブロックみたいなパーツ扱い。
＞NSObjectってクラスの基本的ふるまいを持った基底クラスからテキトーなクラス作って
継承してるじゃないの。
むしろC++の方が継承なしのパーツ扱いが多いんじゃないの。
いわゆるObjectクラスが必要な理由って何かあるの？
Objective-Cはとにかくクラスの実体ありきで
言語的にひな型からインスタンスを作るんじゃなくて
起動時に存在するファクトリクラスにallocとinitを送って
クラスに"自分のインスタンスを作らせる"から
すべてのクラスはallocやinit、retainカウント、deallocを受け付け管理する
NSObjectを継承していないとクラスとして存在しえないので…
動的な言語だとだいたいObjectクラスが必須だよね
>>256 別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな
動的な言語でも本来はObjectなんて要らない。
Smalltalk-80だってnilのサブクラスを作れたし。
値の型が動的なのと
変数の型が動的なのとを
区別つけろよ。アホ。
Objectが必要なのは変数に型があって
値の型が動的な場合なだけだ。
変数に型があるが、そこで記述された型だけではなく
互換性がある型を入れられる。
そういう言語でどんな型にも互換性があるのがObject型だ。
変数に型がない言語ではどんな値でも入れられるから
Objectは要らない。変数にはどんな型でも入れられる
とはいうものもコードは互換性がある型を入れてないと
結局正しく動かないんだけどなｗ
値の型が動的ってどういう事？
さっきまでStringだったけど今みたらIntに変わってたわ！みたいな？
変数の型は固定なんだよ。
この変数は、Numeric型みたいに。
でもNumeric型って書いてあっても
その値は実はInt型だったりFloat型だったりと
Numeric型に互換性がある型に変わっていたりする。
変数の型は固定なのに値の型は違う。
それに対して、変数に型が決まってない言語があるの。
変数に型が書いてないなら変数aにどんな型でも入れられる。
Objectって全部に共通の動作を定義するために使われてるよね普通は。
例えば、自分の型を返すとか。
値が型情報持ってない言語は一応あるね、C言語とか
あれは変数側にしか型がない
>>261 SmalltalkではさっきまでByteStringだったオブジェクトが今みたらWideStringだったぜとか普通
266 ：
デフォルトの名無しさん：2014/04/13(日) 18:07:49.11 ID:+sscY2hT
>>263 それがルート(基底)クラスだな。
Objective-Cで言えばNSObjectで、全てのクラスのルート。
全部に共通の動作なんてものが必要なうちはダメだな
>>265 それは参照してるオブジェクトが変わったんじゃないの？
共通の動作がなければ、てんでばらばらって事じゃんw
>>269 Smalltalkではbecome:というメソッドで
ポインタレベルでのオブジェクトの差し替えが可能なんで
| x y |
x := y := 'abc'
x become: 3.14.
y. "=> 3.14 "
これを応用してオブジェクトの型の変更も容易なんですよ
>>259 よく知らないんですけどSmalltalkのnilとObjectって
お互い継承関係にあるんじゃないんですか？
>>271 SmallTalk知らないんだけど、それってxというオブジェクトにbecome:という動作をさせてるの?
そうなら、become:という動作は全オブジェクトに共通だよね。
>>271 Smalltalkよくしらないから適当言語だけど...
x = "x"; y = "y"; z = y;
の状態で
y become: x;
とやったら、
zの指してるオブジェクトは"x"になるって事？
>>268 つ proxyパターン
>>272 nilはクラスではないところがポイント。
>>273 全オブジェクトに共通ではない。
>>274 なる。xが"x"のままの流派と"y"になる流派とがある。
よく知らない三連星ワロタ
>>275 なるほどそういう意図ですか
1. nillはUndefinedObjectのインスタンス
2. UndefinedObjectはObjectの継承している
3. Objectはnilを継承している
こうかな？
となると全てのクラスの共通となる祖先が存在してるんで
不要論として出すのはやっぱおかしくないですか？
知れば知る程Smalltalkのウンコさが身にしみる
proxyパターンと共通の動作にどういう関係があるのかわからん。
>>258 ＞別にObjectじゃなくても言語仕様でやればいいじゃんと思うんだけどそれじゃマズイことってあるのかな
いま、C++とかがそこに起因する泥沼に嵌ってるけど
オブジェクトクラスの側は言ってしまえば実装だしライブラリだから
将来に動作を変更されるうるし、実際に変更されるけど
言語仕様はもう一段上のルールだから変更が実に困難だという…
>>259 要らないつうか、それだと基本的なオブジェクトとしてのふるまいを持ってないから
Objective-Cで生のC関数書いたりObjective-C++でC++のクラス扱ってる状態なだけじゃ…
>>276 nilはクラスではないから共通の祖先となるクラスではないよ。
というか基底クラスが複数あるのはそんなに珍しいことではないが、
一体何がわからないのかわからない。
>>281 nilを継承できる事と所謂Object型が不要になる事の繋がりが分からないんですよね
nillオブジェクトとObjectクラスは親子関係にあるのになんでだろう
って思って質問したんです
> 3. Objectはnilを継承している
それが真であれば、Objectはnilの特徴を持っていないといけない。
Objectはnilではないので、これは間違い。
>>280 要らないんじゃなくて、あった方がやり易いってことだよな。
別にObjective-CでもNSObject無視してクラス自作できるけど、まずそんな事しない。
Rubyだと
・nil は Nilクラスの唯一のインスタンス
・NilクラスはObjectクラスから派生したサブクラス
$ irb2.0
irb(main):001:0> nil.class
=> NilClass
irb(main):002:0> NilClass.superclass
=> Object
Smalltalkは知らん
>>283 あ、そうなんですか
Wikipediaに
> 基本的な派生元となるObjectやProtoObjectは、それらから派生したUndefinedObjectのインスタンスオブジェクトであるnilを継承しており再帰関係を持つ。
と書いてあったんでそういうものだと思ってました
あと
Object isKindOf: nill
が true を返すのはなんででしょう？
>>285 つまりnilとNilは別々のオブジェクトであり、
NilがObjectのサブクラスであることとnilは何の関係もない、
ということだね。
>>286 つまりnilとUndefinedObjectは別々のオブジェクトであり、
UndefinedObjectがObjectのサブクラスであることとnilは何の関係もないし、
nilはクラスではないし
Squeak4.4ではObject isKindOf: nilはfalseだし、
Object new isKindOf: nilもfalseだし、
仮にtrueになる処理系があっても、nilはクラスではないからnilはObjectの基底クラスではない、
ということだね。
>>287 ありしゃす、Object isKindOf: nil の結果は実装依存なんですね
true になるのはGNU Smalltalkでした
>>287 >つまりnilとNilは別々のオブジェクトであり、
nil はインスタンスでありNil はクラスだから、別々のオブジェクトってこと
>NilがObjectのサブクラスであることとnilは何の関係もない、
Nil と Object とは「サブクラス-スーパークラス」という継承関係であり、
Nil と nil とは「クラス-インスタンス」というインスタンス化関係であり、
二種類の関係をごっちゃにしてはいけない、ってこと
>>286 >> 基本的な派生元となるObjectやProtoObjectは、
>>それらから派生したUndefinedObjectのインスタンスオブジェクトである
>>nilを継承しており再帰関係を持つ。
Rubyの場合
・ClassクラスのスーパークラスはModuleクラスである（継承関係）
・ModuleクラスのスーパークラスはObjectクラスである（継承関係）
・ObjectクラスはClassクラスをインスタンス化したオブジェクトである（インスタンス化関係）
$ irb2.0
irb(main):001:0> Class.superclass
=> Module
irb(main):002:0> Module.superclass
=> Object
irb(main):003:0> Object.kind_of?(Class)
=> true
結果として、各クラス間の関係は「循環的」に定義されることになる
ただしRubyコミュニティでは、それを(その循環関係)を「再帰的」と呼ぶ事はない
Smalltalkは知らんけど、おそらく、そのWikipediaの著者が
継承とインスタンス化をごっちゃに理解しているんじゃないかと思われ
>>288 GNU Smalltalk は名前から受ける印象と違って
単なるファンお手製の勝手実装なうえに、
Smalltalk としてもかなりの変わり種なので
あれを元に Smalltalk がどういうものか学ぶのはちょっと問題が。
できれば VisualWorks 、悪くても Squeak/Pharo で
試すようにするのがよいと思います。
（これらの処理系はそれぞれ独自の進化を遂げてはいますが、
いちおう古典的 XEROX Smalltalk-80 からの直系の派生物で、
その名残を多く残しています）
大量のベクトル演算をオブジェクト指向で行うのはいい考えではありませんでした。
パフォーマンスが話になりません。
あらためてオブジェクト指向の活用方法が知りたいです。
あたりまえやないかw インラインでやれ。
>>292 それはmeta cyclicというのであってrecursionとは全く別だよ
>>296 まず、
全てのクラスの基底となるクラスが存在するかどうかという
>>255の話は継承関係の話で、
クラス-インスタンス関係で構成されるメタタワーの話である
>>296の話とは
全く別々の話だということはOK？
>>297 はいそれは分かってるつもりです
自分が疑問に思ったのは
>>259なんで、
nilを継承できる事とObjectが不要である事の関連性を
説明して貰えるとありがたいんですが…
isKindOf:等のクラス階層へのアクセスを使わない限りにおいて、
全てのクラスは基底クラスから継承したインスタンス変数やメソッド等を取り込むことで
nilからの継承による実装に置き換えることが出来るのはOK？
>>297と
>>299を前提とすれば、
全てのクラスの基底クラスとしてのObjectは不必要であることは自明だというのはOK？
>>301 いいえ、その飛躍が判りません
nilにObjectクラスと同じ能力があるからObjectクラスは不要だという事ですか？
>>302 いいえ、nilにObjectと同じ能力があるなんて誰か言ってるのですか？
>>303 じゃあ
>>299の解釈が間違ってますね
うーん、Objectの代わりにnilから派生できるよ、としか汲み取れません
でもそれだとクラス階層のルートの必要性とは無関係の話だから違うんだろうな
自明の部分を取り違えないように省略せず説明して頂けませんか？
今更な反応だけど
メソッドチェーンのデバッグどうのこうのは
パワーアサートである程度解決できるんじゃね
テストとデバッグを同一視すんなとか言われそうだけど
そこはなんやかんやで
みんなモデリングツール使ってる？
UMLは手書きのノートに万年筆で描いてるけど？
ああ、もうすぐ司法試験なんだよなぁ・・・
今年も申し込みしてねーや。
仕事辞めたいわ
ぜひ弁護士資格を取って人売り屋を訴えてやってください。
弁護士より裁判官志望なんだけどな。
知財専門の裁判官やるわ。
裁判官になるのはある意味、終身刑になるようなもの
仕事にやりがいはないし、趣味、嗜好、信仰の類は一切行えない
どうしてもやりたいというなら止めないが、いいもんじゃないぞ
確かに日本語ネイティブじゃないと解り難い表現ではある
急にスレが死んだ
>>217 >ライナスは OO をぼろくそにけなしているね
Linusが批判したのはOOPじゃなくてC++だろ（Cとの比較で）。
似たようなものさ‥Linus が GC の存在を受け入れるわけがない
そりゃ、カーネルやドライバレベルの開発でGC付きの言語環境は要らんわ。
OOPの話題でリーナス発言を引き合いに出すのは的外れすぎる。
OOPって結局、こういう考え方すれば分かりやすくなりますよって例でしかないからな
その考え方を前提に置けば、こういう表現ができますよって利点はいろいろな実装があるけど
完全性や効率性を犠牲に、可読性を上げて保守性や再利用性、試験性なんかを上げましょうってそういうものだと思うんだけど
OOPって結局、…でしかないからな
という奴って、OOP以外にも関数型言語でもアジャイルプロセスでも受託ビジネスでも
みーんな「結局、…でしかないからな」とわかったような気になるだけで
実際には何も身についてないんだよなw
>>31 「結局、ただの方法論でしかないからな」
方法を知っているかとそれをビジネスで生かせるかは全く別のスキルだしなー
321 ：
デフォルトの名無しさん：2014/12/15(月) 00:00:56.39 ID:Ovh10mZl
カプセル化 ポリモーフィズム 継承を理解して設計出来る人って実際、何人に一人ぐらいに感じる？
ひとそれぞれ解釈違うからなんとも言えん
323 ：
デフォルトの名無しさん：2014/12/15(月) 11:05:06.23 ID:cy4sFuPq
ｶﾌﾟｾﾙ化＆オブジェクト化の行き先は関数型プログラミングじゃないの？
絶対違う
>>323 北極と南極の違いだろ。
OOPの落伍者のパラダイスが関数型なんだから。
ポリモーフィズムは分かりやすいんだけどカプセル化がいまいちわからない
ゲッターセッター書いて何になるの？ってレベルの理解しかないから優しく教えて
>>326 カプセル化はむしろ単純セッター書いたら負け
そのクラスの機能のみ提供して、内部実装を隠すのが要点
カプセル内では、他のオブジェクトの定義を知らなくても済むように書く。
閉じたオブジェクトにすればいい。
>>326 基本的にそのクラスのメンバーはそのクラス内でいじられることを保障するため。
実装を隠す
→知らなくても使えるように設計する
→使い方さえ変えなければいい
→中は変え放題、新しい使い方も追加放題
>>329 よくあるサンプルみたいに全メンバアクセッサ実装してるようなクソクラスだと
その原則破るための効果の方が強くなってしまうからなぁ
クラスの中から≠クラスファイルの中から
クラスの中から＝クラス機能の中から
327-330
いろいろありがとう
公開したいとこだけ公開すりゃいいのね
極論を言えば「公開」したら負けなのがカプセル化
>>326 getter-setter をかましておけば、なにかのときに簡単に監視やフックを追加できる
>>333 ちょっとした用途ならリフレクションから呼べば良いじゃん
機能として提供する必要が出来たならそんな直接参照するような裏ワザ使わないで継承するなり追加するなりしようよ
影響が外に広がらないようにカプセル化して直接参照する手段を封じるんだから
直接参照できるセッターやゲッターつけたら保証できなくなるじゃん
>>334 リフレクションは悪、コンパイル時に検出できるエラーがリフレクションにすると検出できなくなってしまう‥
まあ何でもかんでもsetter-getter で公開してしまうのはどうかと思うが（ましてやプロパティを公開してしまうのは最悪）
336 ：
デフォルトの名無しさん：2014/12/18(木) 15:10:59.93 ID:ZOTu6c+H
おいおいインスタンスにアクセサなかったら、
そいつの状態を変えたりモニターしたりどうやるんだよ。
>>336 状態をモニタするのは「モニタする」メソッドでやるべきじゃね？
状態を変えるなら、状態を変えるメソッドを通すべきだと思うし
もちろん、カプセル化の観点から見たら、の話ね
何か目的があってカプセル化を崩すなら、それはそれだろうし
338 ：
デフォルトの名無しさん：2014/12/18(木) 15:31:32.87 ID:ZOTu6c+H
いやそのためのメソッドがsetter/getterだろうと。
>>335 > ましてやプロパティを公開してしまうのは最悪
.NETのクラスは山ほどプロパティを公開してるけど、これも最悪なの？
>>339 >>335 はプロパティをフィールドと混同している気がする。
フィールドを公開するのが最悪、なら納得できるもん。
>>338 setter/getterはあくまで、結果としてそうなるだけのものだよ。
あくまで例えばの話だけど setLeft(), setRight(), setWidth() という3つのsetterがあったとして、
内部データは「left,right」でもいいし「left,width」でも「center,width」でも
「center,half_width」でもいい、もっと言えば「width,right」でも構わない。
まあよほど処理上の都合がないかぎり最後のを選ぶ人は少数だと思うけど、
どれが単純なsetter/getterになるのか、どれが違うのかは外からは分からない。
そして、それは分からなくていいものだと思うよ。
状態が最初にあって、それを見たり弄ろうと思うとsetter/getterになっちゃうけど
まずそのオブジェクトで何をしたいのかを考えて、それを実現するための内部構造と考えると
自然とカプセル化されてくもんじゃないかな。
341 ：
デフォルトの名無しさん：2014/12/18(木) 22:32:07.68 ID:ZOTu6c+H
>>340 いやだからアクセサでオブジェクトの状態を変える・モニターするのは別に普通だろと言ってるの。
342 ：
デフォルトの名無しさん：2014/12/18(木) 22:55:00.66 ID:CbZTNJ5S
Entityにgetsetつけてるのって何も考えてないとしか思えない
状態変更やモニタするメソッドの名前をgetやsetにするのは自由だけど・・・命名規則的にそれってどうなの？
それに当然モニタリング機能を提供すべき責任を負ってるクラスだけだからな
状態を変更するメソッドならバリデーションや整合性チェック、状態変化に伴う動作まで含めて一つの完結した機能として定義すべきかな
状態変化監視するならオブザーバパターンで、JavaならpropeatyChangeListenerとか
実装して受け取るべきだと思う
もしくは監視用ステータスオブジェクトを返す感じとかか？
344 ：
デフォルトの名無しさん：2014/12/18(木) 23:28:53.90 ID:ZOTu6c+H
ああ、俺が言ってるのは単純にプロパティの事だよ。
こういう説明はどうだろう？
NG:状態変数を取得するために状態変数取得メソッドを作った
OK:状態取得メソッドを作ったので保管場所として状態変数を作った
少なくとも設計段階でデザインするべき物かな
そうやってデザインの結果として一部にクラスに、
結果的に単純プロパティのような形の実装になった物が出来るの悪いことではないと思う
346 ：
デフォルトの名無しさん：2014/12/19(金) 00:25:25.61 ID:kXOboZoh
始めからプロパティとして定義するものもあれば、
プライベート変数を後からプロパティに変更する事もあれば、
プロパティだったものをプライベート変数に変更する事もあるよ。
CTMCPでggr
C++とかjavaは元来の意味でのオブジェクト指向じゃないからね
あくまで、オブジェクト指向に便利な機能つけた手続き言語
オブジェクト指向をきちんと使いたいならsmalltalk参考にしてる言語のほうがいいと思われる
例として、整数を文字列に変換するときに
Java
String.valueOf(48)
Ruby
48.to_s
48さんに文字列になって欲しければ、48さんのメソッド呼ぶのが本来のオブジェクト指向ー
同じように、通信をするconnectionってインスタンスがあったとして
connection.status = Status::FINISHED
とかやっちゃうのはオブジェクト指向らしくなくて
connection.finish
で、終了処理から内部状態変更やらやってくれるのがオブジェクト指向
>>348 Staticメソッドを引き合いに出してJavaをけなしてもねえ……
>>348 そりゃ OO 的には美しいが、レジスタ一個で収まるところをごてごてとデコレートするのもね‥
手続きとOOを排他扱いする時点でお察し
まぁ、速度優先するならOOPだの関数型だの構造化だのオーバーヘッドの必要なルール止めて
シーケンシャルに処理手書きしていけよってなるしな
保守性とかほかの目的で冗長な記述をルール化してるんだし
354 ：
デフォルトの名無しさん：2014/12/27(土) 21:08:42.89 ID:Dl8SRIg9
文字列とか数値とか考えないのがオブジェクト思考じゃないの？
基底クラスが「人」で、3つの派生クラスを作ってそれぞれに「.work()」を記述した場合で
3つの派生クラスの全インスタンスの「.work()」を実行したいときどのように管理すれば良いのでしょうか
自分では派生クラス毎にループを回すことしか思いつきませんでした
基底クラスにwork()を定義して、派生クラスでオーバーライドするとか
>>355 「職業」インターフェースを追加して、work()を定義するかな
work()を使う側は、人に対して命令しているのではなく、職業の役割に対してその通り働けと言ってるわけだから
>>355 そんなん、クラスが「基底か」「派生か」ということとは関係ないじゃん。
基底クラスのインスタンスを複数作成した場合でも、同じでしょ。
複数インスタンスに同時にメッセージを送るということなんだから。
ヒントはリスナー。
>>355 > 3つの派生クラスの全インスタンスの「.work()」を
> 実行したいとき
例えば Smalltalk なら
人 allSubinstances do: #work
とかそういうこと？
Javaでクラスメソッド書いてると罪悪感あるんだけど、
副作用のない関数を書くんなら問題ないよね？
OOPっぽくないというのが罪悪感の原因だろうけど、
public staticで副作用のない関数だとむしろ書いていくべきだよね？
>>360 気にするとすれば、そのクラスに対して作用を持たないメソッドが何でそのクラスにあるの？ってところかな
クラスって、データと「そのデータに対する」操作の集まりだから。
影響を受けるデータの方に自身の操作として定義した方が良くない？
良くあるアンチパターンの機能クラスと、データクラスに分かれちゃってる手続き型設計
> そのクラスに対して作用を持たないメソッドが何でそのクラスにあるの？ってところかな
クラスを定義しないと関数を書けないからね。
> クラスって、データと「そのデータに対する」操作の集まりだから。
Math.sinなどのメソッドは、どのデータに対する操作かな？
やっぱ、関数、っていう使い方は生き残ると思うんよね。
オブジェクト指向的にはstrategyっぽくオブジェクトにしとくべきなんだろうとは思う
んで、普通はAngleオブジェクトがあってそれがsinやらcosやらのオブジェクト持ってる感じじゃない？
この話題でJava固有の話をするのは本意ではないんだけど、
やっぱプリミティブ型ありきの現状考えると、
式の中にAngle a = new Angle(PI/4)からのa.getSin().doubleValue()みたいなんが出てくるのも、
式の途中で new Angle(a + b) みたいな生成が混じるのもシンドイ気がする。
次に、プリミティブ以外に目を向けたとしても、
関数的に表現したほうが自然に見える操作もある。
たとえばファイルのコピーをするメソッドを考えたとき、
file.copyTo(other)というふうにするより、
FileUtils.copy(File src, File dst)となってるほうが自然に見える。
実際、Javaの標準ライブラリにおいてもjava.nio.file.Filesにおいて、
public static Path copy(Path source, Path target, CopyOption... options)
となってる。これも関数的アプローチの無くならない理由というか証拠のような気もする。
>>364 public static Angle fromDegree(double degree);
public static Angle fromRadian(double radian);
public double sin();
public double cos();
...
でいいじゃん。
Angle.fromDegree(45).sin()とか。
三角関数自体は角度の持っている特性だからAngleから取り出せるものだけど、
数学としてそれを導き出す関数で概念化した法則≒数式はMathとして定義されていてもおかしくはないか
ただ、数式自体はオブジェクト(物)を扱わず、その法則のみを抜き出して机上で扱う関数の集合、
数学自体が物事をオブジェクトで表現せずに、関数で表現したもの(ただし、直接使え無いと超非効率になる)
って感じかな
>>364 ファイルのコピーはファイル自体の機能ではなく、その上のストレージに自身の保持してるファイルを複製せよって命令する感じのような
>>365 そのnewを書く書かないとかcreateメソッドを準備するとかは興味なくて、
パラメータ→結果 で済む世界の話に短命オブジェクトを挟むのが嬉しくないよね？
絶対嫌だとか、困るとか言うつもりもないけど、今んとこメリットも見えないような。
>>366 関数型言語に詳しくてウンチクのひとつも言えるなら、
この気持ちスッキリ表せるんだろうけど、今の俺が言えるのは、
関数ありだよね、特に、式には関数だよね、みたいなことだけ…。
ファイルのコピーの例はご指摘を受け、自分の中では少なくとも、
「メソッド方式よりも、関数方式でスッキリする例」で無くなってしまったｗ
関数方式でスッキリするのはやっぱ数式関係だけ、なのかも。
基本的に読みやすいと言うか、その処理がどういう本質のものかをコード自体で示してるのが良いコードなワケで
数学関係の処理は、元が元だけに関数形式が一番本質に近いから、そりゃ関数形式が読みやすくもなるわな
>>367 Angleがどうして短命なわけ？Pointとの本質的な違いは？
全てはあんたの一方的な思い込みだよw
>>367は関数型に詳しくないだけじゃなくオブジェクト指向も初心者レベルだよw
372 ：
デフォルトの名無しさん：2015/01/29(木) 11:14:38.08 ID:FsmC2LI9
beanというかバリューオブジェクト？とユーティリティクラスって
効率のためにあえてオブジェクト指向の設計を崩して、
構造化プログラミングで設計するときに利用するものって考えでいいんですかね？
構造体と機能モジュールの関係そのまんまだし
ブログラマの質にできるだけ影響を受けないように
プログラムの質を維持するのが目的だろ。
プログラマの質の水準をどの程度と見るかで
求められる効果が変わってくる。
