OOP
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/09/10(金) 19:44:500655デフォルトの名無しさん
2010/10/11(月) 15:32:52ライターは火打石かも知れんぞ。
0656デフォルトの名無しさん
2010/10/11(月) 15:40:32横からだけど、俺もＯＯを勉強したてのころは
お前みたいに訳の分からん事をいっていたよ、懐かしいな。
頑張れよ。
0657デフォルトの名無しさん
2010/10/11(月) 16:04:04喫煙者.一服 タバコ ライター
ってどうなんだろうね。
タバコ無しじゃタバコすえないし、タバコ吸うことはタバコのメイン機能なんだから、
タバコ.一服 喫煙者 ライター
が正解のように思える。
だけど、一服の形は人それぞれで、もしかしたらタバコをすわない場合もあるかもしれない。
だから、やっぱり一服は喫煙者に紐付けしたほうが良いかもしれない。
ほらもう解らないよね。
でも言うんだろ？それはどういった状況を前提にしているかによる、と。
だけどそれは裏を返せばコードを使いまわせないってことでもあって、墓穴掘ってるんだよね。
0658デフォルトの名無しさん
2010/10/11(月) 16:05:23現実に例えて説明するとそういう疑問が出てくるから駄目なんだよな
0659デフォルトの名無しさん
2010/10/11(月) 16:09:41なんて駄目な設計なんだ・・・ どうしてこんな設計に・・・
まず、
＞Aの持ってるC → Cを管理してるD
これはCを、AとDが二重に管理しているという解釈でいいよな？
なんで二重に管理する必要があるんだ、どうせ機能は同じようなものなんだからまとめてしまえ。
Cを管理するA(D)
もしくは、DはAを管理するようにする。
Cを管理するA ← Aを管理するD
つぎ、
＞Cを管理してるD → Dの基本クラスのE → Eの持ってるB
そもそもDはEを継承しているんだから、Bも直接管理できるはずだろう。（出来ないならそれは継承するべきではない）
基本クラスのEを気にする必要は無い。
BとCを管理するA(D)
もしくは、
Cを管理するA ← AとBを管理するD
超すっきり。
そもそも、上にAとBを管理するクラスがあるのに、
＞A → B
なんて直接アクセスするような、行き当たりばったりなコーティングをするからいけないんだ。
これはAがやる仕事じゃないだろ。なんで上に管理させてるんだよ。
0660デフォルトの名無しさん
2010/10/11(月) 16:10:30でも、
いっぷく ( &タバコ, &ライター, &喫煙者 );
で示されるタバコとライターと喫煙者の関係は、現実でも成り立つのだ。
あっても、引数の順番に野次が飛ぶぐらい。
0661デフォルトの名無しさん
2010/10/11(月) 16:32:54＞タバコ.一服 喫煙者 ライター
タバコ自体が一服の機能を持つとか、タバコが喫煙者を使うとか、
そんな馬鹿なこと言ってんじゃねーよ。
0662デフォルトの名無しさん
2010/10/11(月) 16:37:53現実に例えて説明するとそういう疑問が出てくるから駄目なんだよな
0663デフォルトの名無しさん
2010/10/11(月) 16:47:20＞ボタンクラスを継承してくださいとか
こういうことをするメリットはちゃんとあるぞ。
たとえば、ボタンクラスを使うフォームクラスがあるとする。
フォーム．ボタン配置（ボタン）
これは普通に使う分には問題ないよね？
じゃあ、このフォームクラスに渡すボタンクラスの機能を変えたいとする。
もし、ただ単純に新しいボタンクラスを作っただけだと、
フォームクラスにそれは渡せないよね？
それがどういうものかフォームクラスには分らないから当然なんだが。
でも、フォームクラスがそれをどういうものか分れば話は別だ。
それを実現する機能が、継承なんだ。
新しいボタンクラスに、元のボタンクラスを継承させると、
新しいボタンクラスに、元のボタンクラスの機能とインターフェースが出来る。
フォームクラスは元のボタンクラスの機能とインターフェースの仕様は知っているので、
新しいボタンクラスに、元のボタンクラスの機能とインターフェースが備わっていれば、
フォームクラスはまるで元のボタンクラスを使うように、新しいボタンクラスも使えるようになるんだ。
0664デフォルトの名無しさん
2010/10/11(月) 16:49:23疑問が出てくるから何？
それは全く関係ないプログラムの機能の話とは、全く繋がらないぞ。
関連性がまるでない。それを見てどうしろと言うんだ。
0665デフォルトの名無しさん
2010/10/11(月) 17:31:36人それぞれ抽象度や理解力が違うからなの？
0666デフォルトの名無しさん
2010/10/11(月) 17:36:52実空間の物体の用法や使用例が、
自分の作るプログラムの用法や使用例に合っていないと、
分析しても変な結果になる。
そこに原因があるんじゃないかと。
0667デフォルトの名無しさん
2010/10/11(月) 17:39:340668デフォルトの名無しさん
2010/10/11(月) 17:41:43鳥クラスを作ってflyインタフェースをつけてもペンギンやダチョウは飛べない
そういう現実の分類と実際とのギャップは色々ある
長方形を継承して正方形を作るのが失敗だという古典的な例とか調べてみれば
0669デフォルトの名無しさん
2010/10/11(月) 17:43:21そうだなｗ
ただ、その何とか動いているものに、
何かしらの手を加える必要に迫られることは、絶対にあるから大変。
0670デフォルトの名無しさん
2010/10/11(月) 17:58:07その通り。
だから、型やオブジェクトにメソッドじゃーなんじゃーって機能を持たせても意味ない。
そのオブジェクトがどう使われるかは、使う人次第。
画像ファイルに展開用コードが内包されていないのと同じ。
ヘッダでフォーマットさえわかればよい。
どう扱うかはプログラムが決める。
0671デフォルトの名無しさん
2010/10/11(月) 18:03:51自販機の中のジュースを、外の人間が自由に取り扱ってもいいなら、それでもいいけどな。
0672デフォルトの名無しさん
2010/10/11(月) 18:32:30あと、データそのものと、データの入れ物を一緒にすんなよ？
0673デフォルトの名無しさん
2010/10/11(月) 19:22:03相当都合の悪いこと言っちゃったかな。
0674デフォルトの名無しさん
2010/10/11(月) 19:34:41別途買うなり借りるなりでセットして、一服は引数無し。
属性コーヒーが非nullなら、一緒に飲んだって構うまいよ。
0675デフォルトの名無しさん
2010/10/11(月) 19:39:30俺もわからん
0676デフォルトの名無しさん
2010/10/11(月) 19:40:480677デフォルトの名無しさん
2010/10/11(月) 20:35:56Cは何かの操作を提供するインターフェース的オブジェクトで
操作の実態はDがまとめて実行しているかもしれない
Bはいくつかアルゴリズムを持ったデータベース的オブジェクトで、
E(D)はこのアルゴリズムを参照してCで受け付けた操作を実行しているかもしれない
そしてDはEによって回される処理の実装かもしれない
今、Aの内部状態によってBのアルゴリズムを切り替える必要が出てきたとする。
ここまで行くとDが処理の基幹を担う重要なオブジェクトであることはうっすらみえてくるはず。
Dが直接AやBを管理して結合を強めることに危険を感じ無いか？
ましてやAとDが同一なんて有り得ない。
0678デフォルトの名無しさん
2010/10/11(月) 21:06:01そして色んなコードが自分の都合のいいようにデータを操作しまくって収集がつかなくなるんですね、わかります。
0679デフォルトの名無しさん
2010/10/11(月) 21:30:10画像データはデータそのもの。
型やオブジェクトはデータの入れ物。
ちゃんと言った方がよかったな。
0680デフォルトの名無しさん
2010/10/11(月) 22:07:25これで一度納得したのに、
>E(D)はCで受け付けた操作を実行
で、Cがなんなのかよくわからなくなった。
Cが実行する操作を決めてるの？
>DはEによって回される処理の実装
これなら、DがEを継承する必要なくね？
EがDを呼び出すだけでいい。
>Dが直接AとBを管理して結合を強めるのに危険を感じないか？
感じない。
そもそも、Dと、AやBの間に何かかませても、結合は弱くならない。面倒なだけ。
それより、AやDが、Cを別々に管理や操作する方が危険を感じる。
感じない奴はプログラマやめろ。
>AとDが同一なんてあり得ない
そこはよくわからなかったから、二通り考えたけど、もう一方はどう思う？
0681デフォルトの名無しさん
2010/10/11(月) 22:15:360682デフォルトの名無しさん
2010/10/11(月) 22:25:17平行線ですよね
0683デフォルトの名無しさん
2010/10/11(月) 22:29:590684デフォルトの名無しさん
2010/10/11(月) 22:32:55Dと似た振る舞い（この場合ばBのアルゴリズム利用の何らかの実装）をする
Eを継承したオブジェクトが他に存在すると考えるのが妥当
もっと言うとDやEを継承した他オブジェクトを保持したり扱ったりするクラスも他に存在するんだろう
0685デフォルトの名無しさん
2010/10/11(月) 22:35:42可能であれば他に一切変更を加えずに自動的にボッコシ穴あけてアクセスできるような仕組みが
（ようするにそれによって依存関係が崩壊しない保証ができるような機構が）
存在すればOOPももう一歩価値が高まるのに、って話では
0686デフォルトの名無しさん
2010/10/11(月) 22:53:32>継承するってことは、多態が必要
なにそれ初耳。どこの情報？
>Dと似た振る舞い
何が？
Eがということなら、なに当たり前(ry
>DやEを継承したクラスが他に存在
Dが継承されてるなら、慎重にやる必要があるな。
でも、Eが他のクラスに継承されてたとしても、Dには何の関係も無いだろう。
ところでこれは>>680に対する反論なのか？
0687デフォルトの名無しさん
2010/10/11(月) 22:56:10そんな行き当たりばったりなコーティング、オブジェクト指向じゃなくても有害だわwww
0688デフォルトの名無しさん
2010/10/11(月) 23:09:27つ 読解力
0689デフォルトの名無しさん
2010/10/11(月) 23:11:10依存関係が崩壊しない保証があればどれだけ行き当たりばったりでもそれは問題にならない
OOは依存関係を整理するためにあるんだから
0690デフォルトの名無しさん
2010/10/11(月) 23:17:44>>684から他に何を読み取れと。
説明も何もないぞ。
0691デフォルトの名無しさん
2010/10/11(月) 23:21:26いままでの話を無視すんな><
そもそも、依存関係が崩壊しない保証を確認してコーティングするのは、行き当たりばったりじゃなくね？
0692デフォルトの名無しさん
2010/10/11(月) 23:31:59これをチーム開発にしたとたんわけわからんイベントが多数発生する。
この原因を理解して言葉にしたいんだが。
0693デフォルトの名無しさん
2010/10/11(月) 23:50:41つジョエルテスト
最近知ったやつだけど、チームの問題を探る役に立つかも？
0694デフォルトの名無しさん
2010/10/11(月) 23:58:350695デフォルトの名無しさん
2010/10/12(火) 00:29:14だからそういう保証が簡単に取れる仕組みがあれば良いねって話でしょ
0696デフォルトの名無しさん
2010/10/12(火) 00:35:12チームに居ると割と複雑なバグだしよる
0697デフォルトの名無しさん
2010/10/12(火) 00:41:22横からで悪いが、お前はオブジェクト指向が分かっていない。
いい加減、自分だけレベルが低いことに気付け。
0698デフォルトの名無しさん
2010/10/12(火) 00:43:360699デフォルトの名無しさん
2010/10/12(火) 00:44:58いや、そんな話しはしてなかった。
>>603の例の設計は駄目だねって、俺が始めた話し。
0700デフォルトの名無しさん
2010/10/12(火) 01:15:33別に提案自体はそんなに悪筋じゃないし、そういう言い方せんでも良いのでは。
0701デフォルトの名無しさん
2010/10/12(火) 06:39:29分かってないのはお前だ。
どうせOOの一番の特徴は再利用性とでも思っているのだろう。
0702デフォルトの名無しさん
2010/10/12(火) 11:00:35>差分プログラミングとOOPの区別が付いてないから厄介
差分プログラミングとOOPが別物だと言う人間は始めて見たな。
これはどんな根拠なんだ？ 誰か教えてくれ。
0703デフォルトの名無しさん
2010/10/12(火) 11:14:58馬鹿な人間が考えることは、普通の人間には解らん。
まっ天才が考えることも普通の人間には解らんが。
0704デフォルトの名無しさん
2010/10/12(火) 12:06:09差分プログラミングはあくまでOOPが広めた一要素でしかないのであって
OOP＝差分プログラミングでは無いんだが
何故かやたらと差分プログラミングのための継承を乱発する奴が居る
という意味だと思う
0705デフォルトの名無しさん
2010/10/12(火) 19:13:53最近の考え方では誤りを含んでいる可能性が高いとされる。
0706705
2010/10/12(火) 19:15:54考えてみた方が良いと思う。
0707デフォルトの名無しさん
2010/10/12(火) 19:32:540708デフォルトの名無しさん
2010/10/12(火) 21:50:07設計は問題あるかもしれないけど
これって別に悪いことじゃないよね？
OOPというかカプセル化は上記のようにするのが目的だと思うんだが
0709デフォルトの名無しさん
2010/10/12(火) 22:20:31その意味だと”区別”とは言わない。
0710デフォルトの名無しさん
2010/10/12(火) 22:29:33同じ基本クラスAを継承したクラスBとクラスCがあったとして
クラスAが使われている部分を全部クラスBやクラスCに置き換えても正常に動作しなければならない
つまり多態を必要としていなければ継承は使うべきでない
0711デフォルトの名無しさん
2010/10/12(火) 23:29:43クラス図を書いて見たけど、全然悪くないと思う。
例えばMVCのビジネスロジックDクラスがCクラスを管理して
そのCクラスをViewでコンポジションするなど普通に行なう。
Dクラスがスーパークラスを持っていてもおかしくないし
そのクラスが別のクラスを持つことも普通にある。
駄目だと言っている人間は本当に実践でOOPを使えているのか？
0712デフォルトの名無しさん
2010/10/12(火) 23:38:10俺が何を駄目と言ったかちゃんと見た？
まあ、その文の様子だと見てないんだろうけど。
0713デフォルトの名無しさん
2010/10/12(火) 23:48:190714デフォルトの名無しさん
2010/10/12(火) 23:49:48>>659です。
0715デフォルトの名無しさん
2010/10/12(火) 23:54:55お前C++房だろう。OOPを勉強して出直せ
他の言語を知っている人間ならそんなバカなこと書かないぞ。
0716デフォルトの名無しさん
2010/10/12(火) 23:57:320717デフォルトの名無しさん
2010/10/13(水) 00:00:130718デフォルトの名無しさん
2010/10/13(水) 00:03:15それ、単なるLSPじゃねーの
0719デフォルトの名無しさん
2010/10/13(水) 00:07:05まじで OOP って声高にさわぐ奴って何なのよ?
理屈、説明しても分からない
要求仕様を渡しても自分の都合のいいように改変してくる
数式渡しても全然別のものを作ってくる
まともな頭もってる奴って OO って叫ばないぞ
0720デフォルトの名無しさん
2010/10/13(水) 00:11:12659を読んだから実践でOOPが使えない人だと思ったけど。
0721デフォルトの名無しさん
2010/10/13(水) 00:12:41OOは知らんが、OOPは言語によって形態が違うな。
共通してるのはカプセル化ぐらいだ。
0722デフォルトの名無しさん
2010/10/13(水) 00:18:02本当かよww
一応言っとくけど、俺は>>711の、全く悪く無い、ってところ以外は同意してるぞ。
>>659もそれが前提になってるし。
0723デフォルトの名無しさん
2010/10/13(水) 00:18:540724デフォルトの名無しさん
2010/10/13(水) 00:21:33メリットがないときは使わないほうがいいでしょう。
0725デフォルトの名無しさん
2010/10/13(水) 00:23:38継承やらテンプレートやら。
0726デフォルトの名無しさん
2010/10/13(水) 00:41:19そんなこと言ってるんじゃないんだな, これが…
たとえばの話なんだが,
MPEG シリーズってのは、規格書の書式含めて、ある意味 OO の産物なわけだ
これをふまえて, この規格書のここからここまでを何とかしたいとか言うわけ
で、連中、プログラム書いてくるんだが、
規格書に書いてあることに堂々と違反する
規格書中の数式を理解できないんだろうけど, アルゴリズムがおかしい
わかりやすく数式書き直してあげても数式通り動かない
でも, 「うちは OO してますから， 大丈夫なはずです！！！」と声高に言う
つか、 OO ってやってるふりしてりゃ許してもらえる隠れみのになってるだろw
0727デフォルトの名無しさん
2010/10/13(水) 00:46:02それOO以前の問題じゃねwww
プログラマに必要な技能が備わって無いwww
0728デフォルトの名無しさん
2010/10/13(水) 00:46:18「思考の限界は言語の限界」だと言っている。
まっ思考には非言語的要素もあるから、これが全て正しい訳じゃないが
しかし、ほとんどの思考は言語で考え、言語で表現する。
だからC++房は駄目なんだよ。C++言語の限界が思考の限界になっている。
C++に無い部分が理解出来ない。
0729デフォルトの名無しさん
2010/10/13(水) 00:52:17そだよ！ じゃなくって、
「OO してますって言えば世間が許してくれる」
と思う、その感性ってどぉよ？？？
0730デフォルトの名無しさん
2010/10/13(水) 00:55:06そいつらはきっと、世間から無視されるだけだからほっとけ。
0731デフォルトの名無しさん
2010/10/13(水) 00:59:22相手に仕様が伝わらないのは、お前の日本語が”変”だからじゃないのか。
0732デフォルトの名無しさん
2010/10/13(水) 01:02:22>>726は、説明書が読めないやつが居る、って言ってるんだよ。
0733デフォルトの名無しさん
2010/10/13(水) 01:02:36なんで日本語しゃべらんとあかんの？
数式読めないみたいだから、数式を高校生でも読める数式に書き換えただけなのに
0735デフォルトの名無しさん
2010/10/13(水) 01:17:05>なんで二重に管理する必要があるんだ、どうせ機能は同じようなものなんだからまとめてしまえ。
そもそも２重管理じゃない。他で管理しているインスタンスを集約しているケースなどいくらでもある。
>そもそもDはEを継承しているんだから、Bも直接管理できるはずだろう。（出来ないならそれは継承するべきではない）
>基本クラスのEを気にする必要は無い。
Privateフィールドでのコンポジションを認めないのか？これも普通に存在するケースだ。
0736デフォルトの名無しさん
2010/10/13(水) 01:23:43>説明書が読めないやつが居る、って言ってるんだよ。
説明書ｗ お前が読めていない。
0737デフォルトの名無しさん
2010/10/13(水) 01:24:020738デフォルトの名無しさん
2010/10/13(水) 01:25:24>なんで日本語しゃべらんとあかんの？
何語で喋っているの？
0739デフォルトの名無しさん
2010/10/13(水) 01:35:27＞そもそも２重管理じゃない。他で管理しているインスタンスを集約しているケースなどいくらでもある。
百歩譲って二重管理じゃないとしても、Aの所有物にDが干渉していいのか？
データの整合性ちゃんととれるのか？
そもそもそれはプログラム的に自然なのか？
＞Privateフィールドでのコンポジションを認めないのか？これも普通に存在するケースだ。
コンポジションを知らなかったので、wikipediaで調べた。
＞コンポジションは、両クラス間に強いライフサイクルの依存がある場合に使用する。
＞つまり、コンポジション関係にあるクラスの集約しているオブジェクトが削除されると、必ず集約されている側のオブジェクトはすべて削除される。
Privateフィールド関係なくね？ というのは置いといても、
全く関係ないこと言ってないかこれ。
0740デフォルトの名無しさん
2010/10/13(水) 01:36:17比喩も認めない頭の固い人か。
0742デフォルトの名無しさん
2010/10/13(水) 02:17:35>百歩譲って二重管理じゃないとしても、Aの所有物にDが干渉していいのか？
603が正しく理解出来ていないのか？ 管理しているのはDなんだから
Dが所有物CをAが参照(委譲)しているよ考えるだろう。
何をもって干渉やデータの整合性と言っているのか分からないが
オブジェクト指向はオブジェクト内で完結するように作るものだ。
>Privateフィールド関係なくね？ というのは置いといても、
>全く関係ないこと言ってないかこれ。
まぁコンポジションでも集約でもどちらでもいいんだが
Eが管理クラスだから生成・破棄を制御するのが普通だと思ってコンポジションにした。
俺が言いたいのは、PrivateフィールドならEを継承したDから直接Bを参照するのは不可能だと言うことだ。
Privateフィールドを子クラスが参照出来ないぐらい理解出来るだろう。
>基本クラスのEを気にする必要は無い。
だからこれは間違い。
0743デフォルトの名無しさん
2010/10/13(水) 02:27:34喋れるのは中国語か韓国語だと思ったよ。
>そだよ！ じゃなくって、
そだよｗ
まぁこれ以外にもおかしな日本語いっぱい使っているし大丈夫かｗ
0744デフォルトの名無しさん
2010/10/13(水) 02:30:24なぜそこで比喩を使う？ 言い訳が苦しいなｗ
0745デフォルトの名無しさん
2010/10/13(水) 11:35:24wikipediaのMVC項目、「MVCのシナリオ」で、下記の疑問をもちました。
・Vにイベントハンドらを関連付ける人はこのモデルの上位に当たるオブジェクトが担当する？
・Cはオブザーバー的な役割を持っている？
・VはMを参照として持っている？なのでVが直接Mからデータを参照するのだろうか？
・Cは入力のオブザーバー的な役割のようだが、出力は担当しないのだろうか？
記事の下部にありますシナリオですが、
私としては以下のように読み取りました。
1. ユーザがviewに入力を行う
2. viewからの入力により、Vに登録したcontrollerのイベントハンドラやコールバック等がよばれる。
3. controllerが必要に応じたmodelのメソッドを呼び、ステータスを更新する。
4. 3の結果を表示する為にviewがmodelから必要なデータを取得し出力する。
また、概念図では相互残照を行っているように見受けられます・・・。
0746デフォルトの名無しさん
2010/10/13(水) 11:56:59特にシナリオの部分は酷い、出典が書いてないオレオレ脚注とか付いてるレベルだよ
要出典タグつけたの俺だし
>また、概念図では相互残照を行っているように見受けられます・・・。
あの図はUMLではないし、Observerパターンがわかってれば別に変でもない
0747デフォルトの名無しさん
2010/10/13(水) 12:44:45＞管理しているのはDなんだから
＞Dが所有物CをAが参照(委譲)しているよ考えるだろう。
ふーん。>>742はそう見ているのか。
まあ、実はどっちでもいいんだけどｗ
＞何をもって干渉やデータの整合性と言っているのか分からないが
え？ ・・・え？
干渉はまだしも、データの整合性が分らないとな・・・？ お前それ本気で言ってる？
どんなプログラムでも、二つ以上の別々の場所から参照されてるデータは、
データの整合性の問題が付きまとうものなんだがなあ・・・
＞俺が言いたいのは、PrivateフィールドならEを継承したDから直接Bを参照するのは不可能だと言うことだ。
＞Privateフィールドを子クラスが参照出来ないぐらい理解出来るだろう。
ああ、そうか。 それだと直接管理することは出来ないな。
確かに、Eは気にする必要がある。
と言っても、protectedやpublicなメンバから管理することは出来るが。
で、これだとまた別の問題として、継承する意味はあるのか？と言うのはある。
委譲以上のメリットを見いだすなら、
protectedなメンバからそれなりに自由な管理が出来る、と言うのがメリットになるか。
直接管理するのと同じくらいの自由度でね。
・・・あとは、>>742の用語の理解度は大丈夫か？ と言うのは、まあ置いとこう。
0748デフォルトの名無しさん
2010/10/13(水) 13:23:39レス、ありがとうございました。
あの記事は当てになりませんが・・・。
出直してまいります。
0749デフォルトの名無しさん
2010/10/13(水) 15:06:51結局603を間違いじゃないと認めたな。
しかし、>>659は酷いな、お前Privateフィールドも分からないとは
オブジェクト指向でプログラム作ったことないだろう。
0750デフォルトの名無しさん
2010/10/13(水) 15:30:06いや、半分だけだぞ？
つーか、お前プログラム実装したこと無いだろ？
0751デフォルトの名無しさん
2010/10/13(水) 19:35:550752デフォルトの名無しさん
2010/10/13(水) 20:40:52設計は別に悪くないけど設計者(と開発体制)が悪い。
0753デフォルトの名無しさん
2010/10/13(水) 21:17:50AとかBとかCとかDとか頭沸いてるんじゃね。マトモな会話しやがれ。
原文は、やりたいことが素直に書けないから嫌だ、そういってるだけだろ。
やりたいことってのはつまりは手続きで、まぁアルゴリズムや制御構造や関数の類だな。
それが素直にかけない・・・まぁ当たり前だわな。
だってOOPは制御構造をオブジェクト単位でぶつ切りにしてパッパラパーにしちゃうからな。
だから、その指摘自体は何も間違っちゃいないんだぜ？
よくそんなことでこんな長文合戦が続くもんだな。
0754デフォルトの名無しさん
2010/10/13(水) 21:24:27こんなことになってるんだな。OOPもそうなんだけど、クラス云々言ったときに何目的ベースの話なのかが見え無いと言う。
ポリモとカプセル化と差分プロの話がごっちゃになって展開される。だから意味解らん。
もうね、構文わけときゃいいと思うよ。
カプセル化はカプセル化専用の構文なり機構なり作ってそれで固めると。
その固めたオブジェクトをどうコミュニケーションさせるかは、
また別の構文なり機構なりですると。
Unixだと、プログラムはプログラムで閉じてて、
それをシェルを使ってどう組み合わせるかはまた別の話だったりして。
だから解りやすいんだよ、設計するのも、こう言うところで会話するのも。
何使ってるかで目的が明確だから。
■ このスレッドは過去ログ倉庫に格納されています