結局OOpが役に立たないのはなぜ?
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/04/14(水) 01:14:080237デフォルトの名無しさん
2010/04/25(日) 18:12:13> インターネットが、ほんの僅かの単純な機能を成り立たせるために、
> 一体どれだけ複雑なシステムになってしまっていることか。
目の前の問題を短絡的に解決するだけの技術だったら、
ここまで色々な使い方を容れられるインフラにはならなかったよ。
人が構築物を作り上げるのに「神」の視点をもってすることの愚かさを知るべき。
> しかしまたこれらの発明者たちも、これらの問題を直接ゴリ押しでは(「神」のようにという
> 言い方も出来る)解決出来ないと感じる程度に賢明だった。その代わり、このような問題
> に対する巧妙な手口を見つけ出したのだ。兵術の前に策略を用い、失敗を回避せずに
> 受け止める事だった。
0238デフォルトの名無しさん
2010/04/25(日) 18:24:09アランケイのその文章ってSqueakの文系的宣伝だよね？
SunがJavaに関して吹きまくっていたハイプとそっくりだわ
0239219
2010/04/25(日) 18:24:39自分で書いたことも忘れたのか？
>>222
>「主体的に動くオブジェクト」って考え方が、Actorモデルだって言ってんだろ。
見苦しい、いくら言い分けしても、お前が「主体的に動くオブジェクト」を
アクターモデルと考えたことに変わりない。
>>235
>日本語力に問題がある奴と話をするとほんと疲れるな。。
日本語が得意なお前に質問だ。 日本語が得意なお前なら分かるよな。
>「主体的に動くオブジェクト間のメッセージパッシング」って
>アクターモデルだろう
この場合の述語「アクターモデルだろう」が指している主語はどれだ？
①「主体的に動くオブジェクト間のメッセージパッシング」は、アクターモデル。
②「主体的に動くオブジェクト」は、アクターモデル。
③「オブジェクト」は、アクターモデル。
④「オブジェクト間のメッセージパッシング」は、アクターモデル。
⑤「メッセージパッシング」は、アクターモデル。
お前は、書いた”本人”じゃないのに、⑤「メッセージパッシング」は間違いで
②「主体的に動くオブジェクト」と決め付けた、なぜそれだと思った？
詳しく説明してくれ。
0240デフォルトの名無しさん
2010/04/25(日) 18:45:22人間は分業したからこそ、ここまでの技術力を持ったんだよなあ。
0241デフォルトの名無しさん
2010/04/25(日) 18:49:020242デフォルトの名無しさん
2010/04/25(日) 18:55:09少なくとも、問題領域を分割して分業するための優れた方法ではある。
唯一の方法だとは誰も言っていない。
0243デフォルトの名無しさん
2010/04/25(日) 19:35:45そりゃすまんかった
もう少し、具体的に例でも出して問題意識とか得意不得意を挙げていかないと
建設的な話に転がっていかない気がするよ
哲学だけじゃ腹の足しにはなりゃしねえ
ttp://www.sampou.org/haskell/article/whyfp.html
これはただの宣伝文じゃなくて、少なくとも具体的だ
0244デフォルトの名無しさん
2010/04/25(日) 19:40:56> 具体的に例
デザインパターン。
0245デフォルトの名無しさん
2010/04/25(日) 19:53:11デザパタから始めるのは視野が狭い
たとえば関数型なら、状態を扱うデザパタの多くは問題外だろう
0246デフォルトの名無しさん
2010/04/25(日) 22:10:590247デフォルトの名無しさん
2010/04/25(日) 22:24:47kwsk
0248デフォルトの名無しさん
2010/04/25(日) 22:49:240249デフォルトの名無しさん
2010/04/26(月) 11:08:43正確には「デザインパターンの大部分はバッドノウハウである」じゃないでしょうか。
>>247
関数型言語なら状態を扱うデザパタは不要です。
動的型言語なら静的型言語の制約を緩めるデザパタは不要です。
GoFデザインパターンの大部分はC++やJavaが手続き型で静的型だから
必要なのであって他の言語であればそもそも不要だから
C++やJavaに固有のバッドノウハウです。
0250デフォルトの名無しさん
2010/04/26(月) 18:23:10> >日本語力に問題がある奴と話をするとほんと疲れるな。。
> 日本語が得意なお前に質問だ。 日本語が得意なお前なら分かるよな。
あーごめん、それ書いたの俺じゃないんだ。
お前普通に痛い子だから、多分あちこちに敵が居るぞ。
いいかげん、お前の面倒見るの大変だから、さっさとお仲間さんのところへ行ったら？
>>237
いや、そうなんだけど、なんて言うかな。
インターネットってすげぇ壮大な仕組みだけど、
最終的な機能だけに着目すれば、データのコピーが出来るだけ。
C言語で言えばmemcpy相当。
インターネットの猿真似すりゃ、memcpyですら、あんな壮大になってしまうわけで、
よほどの制限が無い限りは真似すべきじゃないよね、って話。
インターネットは色々な制約の元、ああいう形態になってるわけだけど、
それらの制約は今の自分たちには、課せられてないかもしれない。
だから、インターネットを持ち出してOOPの有用性を語るのはナンセンスかなぁと。
0251デフォルトの名無しさん
2010/04/26(月) 18:31:44静的型言語はアレはアレで有用なんだけど、
C++やJavaで、中途半端に仮想関数なんぞ取り入れたのがマズかったんだろうな。
失敗作ってことで。
0252デフォルトの名無しさん
2010/04/26(月) 18:38:18実用性を全く考えないアカの人ですか？
0253デフォルトの名無しさん
2010/04/26(月) 20:07:34それに、GoF本の一章に書かれているような話（「インタフェースに対してプログラミングせよ」、
「継承よりコンポジション」等）の具体例がデザパタなのであって、要素技術だけ取り出して論じるのは無意味。
0254デフォルトの名無しさん
2010/04/26(月) 20:22:11大昔に小規模なコードを書いてる限りにおいては、それでも良かったかもしれない。
一命令単位で削るチューニングや、ワンライナー的な小手先の職人芸がもてはやされた時代だな。
しかし、変化のスピードが早まった昨今において、要求の変化に対して耐性がないコードには
もはや価値はない。昨今、動的型言語の柔軟さに対するニーズが高まっている理由はそこにある。
話が逆なんだよ。今、まさにそういったものが求められているのであって、特定のコンテキストに
依存した「単純さ」に未来はない。
0255デフォルトの名無しさん
2010/04/26(月) 20:36:20> 依存した「単純さ」に未来はない。
俺は適材適所だと思うぞ。予算と納期の制限もあるし。
Cで書いたプログラムをシェルで組み合わせて使うという昔ながらのスタイルも未だに有用だし、
DBならSQLだし。
上から下まで同じ言語でってのには無理があると思う。
俺は素直だから、こう考えるよ。
異なった制約を持ってるなら、言語の仕様も異なっててかまわない、と。
0256デフォルトの名無しさん
2010/04/26(月) 20:44:16単一メモリ空間で動くプログラムを書くときに、インターネットの成り立ちをお手本にしようとは思わないし、
大きなシステムを組むときでさえ、自然の生態系をお手本にしようとも思わない。
http://metatoys.org/oxymoron/oxymoron.html
0257デフォルトの名無しさん
2010/04/26(月) 20:54:55> 上から下まで同じ言語でってのには無理があると思う。
それは当然。>>254は「特定の言語以外はダメだ」なんて話は全くしていない。
重要なのは、「変化に対する柔軟性を持った設計・コードであるか」ということ。
俺はずっと静的型言語でやってきたが、そこに柔軟さを持ち込むベストプラクティスが、
（具体例としての）デザインパターンだし、動的型言語の需要も同じところから発している。
再利用性と柔軟性に対する配慮を欠いた「単純さ」は、それがいかに最短ルートに見えても、
いずれ必ず行き詰まり、高い代償を払うハメになる。
付け加えるなら、俺は「コードは複雑で遅くてもいい」とも思わない。
柔軟性を確保しつつ、高速に動作するコードを書ける人間は、今後ますます重要になる。
しかし、そうした高速化が実現されるのは、アルゴリズムやアーキテクチャのレイヤにおいて。
ここでも、やはり小手先の「単純さ」や「早さ」はお呼びでない。
0258デフォルトの名無しさん
2010/04/26(月) 21:03:16もう、80486なスタンドアロン・コンピュータでコードを動かす時代じゃないんだよ。
組み込み機器でさえ、高性能ハードウェアにAndroidのような汎用OSを積んで、
ブラウジングやWebアプリ連携が大前提の時代に移行しつつあるのに。
0259デフォルトの名無しさん
2010/04/26(月) 21:12:46windows bitmap はbitmapを表現するとてもシンプルな言語で、拡張性は皆無だが、
それを利用したからといって、行き詰るとも高い代償を払う羽目になるとも思わないね。
俺から見りゃお前は、「このままだと地球が駄目になります！」よろしく適当煽ってるだけに見える。
>>258
お前もまたそういう風に煽るだけ煽るよな。
そこにどういう制約が発生しているのか見極めて、同じような制約を持ってる他のものからヒントをもらえばよい。
単に漠然とインターネットの成り立ちがどうのこうの、自然の生態系がどうのこうの、じゃ話にならん。
組もうとしているシステムと自然の生態系の持ってる制約が、
同一であることは殆どないだろうし、単に真似しても上手くいかないだろう。
それぞれに固有の制約や問題があるし、適材適所だね。
0260デフォルトの名無しさん
2010/04/26(月) 21:24:530261デフォルトの名無しさん
2010/04/26(月) 22:15:11>お前普通に痛い子だから、多分あちこちに敵が居るぞ。
>いいかげん、お前の面倒見るの大変だから、さっさとお仲間さんのところへ行ったら？
まったく、知識・技術がない人間、決まって最後は
相手の人間性や性格の悪口を書く。
知識がない人間は、書き込まなければいいのに。
0262デフォルトの名無しさん
2010/04/27(火) 05:42:27> windows bitmap はbitmapを表現するとてもシンプルな言語で、拡張性は皆無だが、
> それを利用したからといって、行き詰るとも高い代償を払う羽目になるとも思わないね。
そりゃ、画像ファイル・フォーマットは基盤技術だからね。そもそも人間が読み書きする言語でもないが。
>>257はそんなことは書いてない。
あえて言うなら、画像を利用するコードがBitmapの仕様べったりなケースでは柔軟性を欠く場合はあるだろう。
> それぞれに固有の制約や問題があるし、適材適所だね。
当前。だが、要求に合わせた「進化」や、他のシステムとの連携を前提としないソフトウェアの出番が、
相対的に低下しているのは事実。
インターネットや「生態系」のメタファは、そういう風に解釈しておけば良いんじゃない。
0263デフォルトの名無しさん
2010/04/27(火) 05:55:150264デフォルトの名無しさん
2010/04/27(火) 11:51:50・理解が難しくなる
・無駄が多くなる
・修正しにくくなる
というデメリットが出てくる場合があると思います。
オブジェクトに自律的に動作させるのではなく、オブジェクトは最低限のメソッドを持ち、その組み合わせを外部から制御する方法はいかがでしょうか。
たとえばRubyのNet:HTTPResponseからセミコロン区切りでクッキーを取り出すコードは次のように書けます。
response['Set-Cookie'].split(/path=\/, */).map { |item|
(item =~ /^([^;]+;)/) ? $1 : '' }.join
左から右へオブジェクトを加工しながら流すスタイルです。
メソッドはオブジェクトが持ち、その組み合わせを外部で制御しています。
0265デフォルトの名無しさん
2010/04/27(火) 12:11:010266デフォルトの名無しさん
2010/04/27(火) 12:58:110267デフォルトの名無しさん
2010/04/27(火) 20:22:260268デフォルトの名無しさん
2010/04/27(火) 20:25:030269デフォルトの名無しさん
2010/04/27(火) 20:28:59commons使え。
0270デフォルトの名無しさん
2010/04/27(火) 21:35:14> オブジェクトは最低限のメソッドを持ち、その組み合わせを外部から制御する方法
むしろ、普通にオブジェクト指向的な発想だと思うが。
> response['Set-Cookie'].split(/path=\/, */).map { |item| (item =~ /^([^;]+;)/) ? $1 : '' }.join
流れの中で出てくる各オブジェクトの責務がきちんと最小化されているなら全く問題ない。
同様の処理が複数箇所で何回も出てくるなら、もう一つ上のレイヤでラップすることを
検討するべきかもしれないが。
0271デフォルトの名無しさん
2010/04/27(火) 22:31:16例のメッセージパッシング君だけだから放っておいていいよ。
メソッドに書くべき処理は、そのオブジェクト内に関する処理だけ。
対象とするオブジェクト以外には、副作用しないほうが良い。
void object.method( const type *object ){}
こんな感じで、引数にポインタ取る場合は、constであることが望ましい。
複数のオブジェクトに副作用する処理は、普通に関数で書け。
void func( type1 *object1, type2 *object2 ){}
大体こんな感じでまとまってきているような。
0272デフォルトの名無しさん
2010/04/27(火) 23:07:490273デフォルトの名無しさん
2010/04/27(火) 23:21:54今オブジェクト指向言語と言われてるものの多くがifだのforだのといった
手続き的な構文を持っていて、xにeqメッセージを渡して得られた
booleanオブジェクトにifメッセージを渡したりするわけではない
ピュアな意味でのオブジェクト指向なんてほぼ現存しないものと
思っていいんじゃないの
0274デフォルトの名無しさん
2010/04/27(火) 23:25:090275デフォルトの名無しさん
2010/04/28(水) 00:16:13生きてると言うつもりは無いけどさ
0276デフォルトの名無しさん
2010/04/28(水) 00:19:520277デフォルトの名無しさん
2010/04/28(水) 00:36:09http://smalltalk.cincom.jp/
http://squeak.org/ http://scratch.mit.edu/ http://www.opencroquet.org/index.php/Main_Page
http://smalltalk.gnu.org/
http://www.object-arts.com/content/navigation/home.html
http://www.exept.de/en/products/smalltalk-x/stx-overview
http://www.instantiations.com/VAST/prod/vast.html
http://seaside.gemstone.com/ http://ruby.gemstone.com/
0278デフォルトの名無しさん
2010/04/28(水) 00:39:150279デフォルトの名無しさん
2010/04/28(水) 03:32:40>オブジェクトに自律的に動作させるのではなく、オブジェクトは最低限のメソッドを持ち、その組み合わせを外部から制御する方法はいかがでしょうか。
なぜ、オブジェクト指向がメッセージパッシングじゃないと駄目なのかは、例えば
①A.Method1;
②A.Method2;
③A.Method3;
この順番で実行(制御)しなと正しく処理されないとして
下記のように②と③の途中で別のオブジェクトから①が呼ばれた場合処理が不正になる。
S1オブジェクトから-->A.Method1;
S1オブジェクトから-->A.Method2;
M1オブジェクトから-->A.Method1;
S1オブジェクトから-->A.Method3;
使う方は、このルールを知らないといけない。単純な１つのメソッドからの呼び出しなら大丈夫かもしれないが
複数のメソッドや１つのメソッドでも処理が離れている場合など複雑になる。
処理手順を覚えないと使えないオブジェクトは、「>理解が難しくなる」と思わないか？
> response['Set-Cookie'].split(/path=\/, */).map { |item|
> (item =~ /^([^;]+;)/) ? $1 : '' }.join
Rubyはよくわからないけど、これは相手のフィールドは変更されないでしょう？
取得したクッキーの編集の話しだから、外部からの制御じゃなく内部で処理していると思うけど、よくわからん。
0280デフォルトの名無しさん
2010/04/28(水) 07:39:350281デフォルトの名無しさん
2010/04/28(水) 08:24:100282デフォルトの名無しさん
2010/04/28(水) 11:38:12自分としては、>>264は純粋なオブジェクト指向ではなく、以下の関数型の特徴（？）を入れたハイブリッドな書き方を提案したつもりでした。
・オブジェクトの状態を変更せず、戻り値で新しいオブジェクトを返す
・オブジェクトを次々に関数（外部から与える高階関数）に渡して処理をする
・引数を使う。変数は使わないか、使う場合は再代入を避ける
メソッドチェーンに関しては、以下のものに違反しているので、純粋なオブジェクト指向の世界では良くない（お行儀の悪い）コードになっているのではと思います。
・デメテルの法則（http://ja.wikipedia.org/wiki/%E3%83%87%E3%83%A1%E3%83%86%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87）
・ドット1つルール（http://d.hatena.ne.jp/asakichy/20090616/1245112830）
0283デフォルトの名無しさん
2010/04/28(水) 11:38:28引数で渡されたオブジェクトの状態を変更しない方がいい、ということに同意します。
>>279
おっしゃる通り、副作用がある場合、メソッドを順番通りに呼ばないといけないとしたら理解が難しくなると思います。
>>264は副作用がない場合（新しいオブジェクトを連鎖的に返していく）の話でした。
副作用がある場合、順番通りに呼ぶ必要がメソッドは、まとめて1つのメソッドにすべきだと思います。
0284デフォルトの名無しさん
2010/04/28(水) 12:31:43OOそんなに詳しくないけど
RubyのブロックみたいなのってSmalltalkが元ネタだよね？
デメテルの法則とか言ってたら、Smalltalkじゃコードなんて書けないんじゃないの？
逆にその意味で「お上品」に書けるコードってのは
「純粋なオブジェクト指向言語」じゃない気がするんだが
0285デフォルトの名無しさん
2010/04/28(水) 12:40:35あなたの言う意味でお上品な書き方してる場合、OO的なガワの部分を
お上品に書いてるだけで、
実際には中身は手続き的または関数的に書いてんじゃないのかってことね
これはただの直観だけど
ピュアリズムみたいなのにこだわる意味が見出せない、という総論的な意味では同意
何でもかんでもオブジェクトとメッセージで考えるより
式と評価（ラムダ計算）、文と実行（チューリングモデル）で捕らえたほうが
現実的で便利で分かりやすいケースが多いから、ピュアリズムは
流行らないんだと思うし
0286デフォルトの名無しさん
2010/04/28(水) 14:41:490287デフォルトの名無しさん
2010/04/28(水) 20:16:590288デフォルトの名無しさん
2010/04/28(水) 21:49:54>複数のオブジェクトに副作用する処理は、普通に関数で書け。
>void func( type1 *object1, type2 *object2 ){}
それはオブジェクト指向じゃないから、君は勉強が足りないよ。
0289デフォルトの名無しさん
2010/04/28(水) 21:59:16みたいな表現はoopの理解を
ものすごくさまたげているとおもう
0290デフォルトの名無しさん
2010/04/28(水) 22:00:01>>271
この人が一番駄目だよな。
0291デフォルトの名無しさん
2010/04/28(水) 22:08:44オブジェクト指向が理解できていない。
0292デフォルトの名無しさん
2010/04/28(水) 22:21:44エセOOはやってないね。エセOOをOOの言葉でやるから。
0293デフォルトの名無しさん
2010/04/28(水) 22:50:31オブジェクト指向の勉強をはじめたころは
同じように感じたこともあったけど
理解が進むとわかってくるよ。
0294デフォルトの名無しさん
2010/04/29(木) 00:07:33それは理解の妨げになる、と同義のような。
0295デフォルトの名無しさん
2010/04/29(木) 01:23:01変なオレオレオブジェクト指向を身に着けてこられるより１００倍マシ。
0296デフォルトの名無しさん
2010/04/29(木) 06:07:01んっ？ それが理解していくことだと思うけど。
>>295
>変なオレオレオブジェクト指向を身に着けてこられるより１００倍マシ。
たしかに、オレオレオブジェクト指向でアンチされてもこまるからね。
0297デフォルトの名無しさん
2010/04/29(木) 06:56:040298デフォルトの名無しさん
2010/04/29(木) 10:01:46それは理解の妨げになる、と同義のような。
0299デフォルトの名無しさん
2010/04/29(木) 10:45:32同じ“オブジェクト指向”にも、ストラウストラップ／メイヤー／リスコフらの「抽象データ型のＯＯ」と
ケイの「メッセージングのＯＯ」があります。
世の多くの“ＯＯ”の解説は、これら本来なら区別すべき異質の考え方をよいとこ取りした勝手定義で、
前者の「カプセル化、継承、多態性」の話をしつつ後者の「オブジェクトにメッセージを～」なんて関係ない話を
平気で持ち出してきたりします。こういう「メッセージ―」の出し方は明らかに前者の理解を妨げます。
一方で、最初から後者や後者から派生的に生じたＯＯＡＤを学ぶなら必ずしもメッセージングの話は
妨げにはならない（というか、軸となる考え方なのでむしろ欠かせない）、と。
0300デフォルトの名無しさん
2010/04/29(木) 13:47:59>問題はあるかもしれないけど、学習パスとしてはデザパタ丸暗記とかでもいいと思う今日この頃。
丸暗記は別にして、GoFぐらいは理解してほしい。
オブジェクト指向で作れなくてもいいけど、こっちが作ったソースぐらいは読めると嬉しい。
「○○パターン」と書いているソースを、「このソース意味が分かりません」と言われても
こっちは、「GoFを勉強して」と言うしかない。いちいち教えていられない。
0301デフォルトの名無しさん
2010/04/29(木) 15:15:160302デフォルトの名無しさん
2010/04/29(木) 19:38:37お前ら本当に大変だな。
理解が大変、理解が得られない、そういったものは元々から間違っている可能性すらもある。
まーOOPの定義すら無いわけで、理解しようもないのだが。
0303デフォルトの名無しさん
2010/04/29(木) 20:11:260304デフォルトの名無しさん
2010/04/29(木) 20:19:34早い話が開放/閉鎖原則とか単一責任原則とか。
ただ、個別具体の方法論の部分で同じ名前を名乗る複数の流派があるのが問題ではある。
あと、俗流OOの類が大量にあるのも問題を助長しているな。
0305デフォルトの名無しさん
2010/04/29(木) 20:36:06それカプセル化の話だよね。それがOOPの本質なの？
違う人に聞けば、本質はポリモだって言うかもしれないし、
メッセージパッシング君に聞けば、本質はメッセージパッシングだって言うだろうし。
カプセル化が好きな人と、ポリモが好きな人と、継承の差分プログラミングが好きな人と、
メッセージパッシングな人が、一堂に会してOOPの議論しはじめたら、
さぞ大変なことになるんだろうな。
で、まとまらないから、最大公約数的に、
「オブジェクトの振る舞いを定義して～」っていつもの。
0306デフォルトの名無しさん
2010/04/29(木) 21:09:58SICPでは「Data Abstruction」と呼んでいるが
そこで用いられるのは関数型言語のSchemeだ
0307デフォルトの名無しさん
2010/04/29(木) 21:12:23俺はオブジェクト指向分析・設計については詳しくないから断言はできないが、
おそらく開放/閉鎖原則みたいなのは設計レイヤの話と言っていいんじゃないかな。
君が挙げているのは、あくまで実装手法やその理論でしょ。
0308デフォルトの名無しさん
2010/04/29(木) 21:13:50誰も守ってないだろ
0309デフォルトの名無しさん
2010/04/29(木) 21:14:240310デフォルトの名無しさん
2010/04/29(木) 21:24:47これを実現するために、いろろな機能が誘導されてくるんじゃないか
0311デフォルトの名無しさん
2010/04/29(木) 21:30:14正解
0312デフォルトの名無しさん
2010/04/29(木) 21:53:170313デフォルトの名無しさん
2010/04/29(木) 21:59:400314デフォルトの名無しさん
2010/04/29(木) 22:00:260315デフォルトの名無しさん
2010/04/29(木) 23:24:35オブジェクト指向を理解していない人の典型だとおもう。
ここまで駄目駄目だと．．．
0316デフォルトの名無しさん
2010/04/29(木) 23:31:16>だから、動的オーバーロードでいいんだろ？
なにがいいの？ 動的オーバーロードがオブジェクト指向だと思う理由は？
0317デフォルトの名無しさん
2010/04/29(木) 23:34:450318デフォルトの名無しさん
2010/04/29(木) 23:47:420319デフォルトの名無しさん
2010/04/29(木) 23:49:520320デフォルトの名無しさん
2010/04/30(金) 00:00:500321デフォルトの名無しさん
2010/04/30(金) 01:01:540322デフォルトの名無しさん
2010/04/30(金) 09:24:27>>早い話が開放/閉鎖原則とか単一責任原則とか。
>それカプセル化の話だよね。それがOOPの本質なの？
カプセル化？ なぜ開放/閉鎖原則や単一責任原則がカプセル化の話だと思う？
君はバカのひとつ覚えで、なんでもカプセル化だね。
>メッセージパッシング君に聞けば、本質はメッセージパッシングだって言うだろうし。
本当にオブジェクト指向が理解出来ていないね。
開放/閉鎖原則や単一責任原則とメッセージパッシングは、矛盾した概念じゃない。
内部的観点と外部的観点の違いだけ。
>で、まとまらないから、最大公約数的に、
>「オブジェクトの振る舞いを定義して～」っていつもの。
まとまっているから、理解出来ていないのは君だけ。
もういいよ、ひとりレベルが違いすぎるから、話の質が落ちる。
イチから勉強してから、またおいで。
0323デフォルトの名無しさん
2010/04/30(金) 14:50:48君は洗脳されているんだよ！
0324(u＿・y) ◆rT33C51l9k
2010/04/30(金) 15:03:08で。 その形の設計を出来る奴は二種類
１ プログラミングの果てをみている
２ 同じようなプログラムを何度も何度も作ってきた
このどちらかでもねーならOOなんて無理なの！！！！！！！！！！！！！
おｋ？？？？？？？？？
死ね
それでもわからないっていうなら、同じようなプログラムを5回くらいゼロから設計しなおして
一切のソースを流用しないで作ると良いよ
完全に最適化された辿り着く形はOOか、関数型どっちかしかねーんだから。
関数型は一般的じゃない。 だからゴミみたいな奴が身に付けられるのはOOのみ。
0325(u＿・y) ◆rT33C51l9k
2010/04/30(金) 15:06:28手段でしかないのに、議論する意味がないｗｗｗｗｗｗｗｗｗｗ
外部から参照させたらまずいものを見えなくするのなんて当たり前だし、
今後、もしかしたら外部から見えたほうがいいかもしれないものは見えるようにするのが当たり前、
関数を使いやすくするためにポリモるのも当たり前
それすら出来ないってどういうこと
ポリモや、クラスが無くて、C言語が主流だった時代に、
現在のOOのようなソースが世界中のどこにも無かったとかおもってるわけ
無かったらなかったらで、 他の表現でOOすればいいだけ
0326デフォルトの名無しさん
2010/04/30(金) 15:07:040327デフォルトの名無しさん
2010/04/30(金) 15:11:38テンプレートと型推論と動的オーバーロードが有ればそれで良い。
オブジェクト「指向」する必要は無い。
0328デフォルトの名無しさん
2010/04/30(金) 15:54:24テンプレートと型推論と動的オーバーロードで、ソフトウェア開発のどういう課題が解決できるの？
0329デフォルトの名無しさん
2010/04/30(金) 21:17:27話の流れが良く見えてない状況で茶々をいれてみる
再帰下降パーサが必要になる局面なんてのはよくあるパターンなんだが
OO の人たちって書けない人の上が多いでしょ?
0330デフォルトの名無しさん
2010/04/30(金) 21:24:56そんな初歩的なことは普通にできるだろ。
0331デフォルトの名無しさん
2010/04/30(金) 21:29:09パーサのアルゴリズムとオブジェクト指向の間に何の関係があるの？
0332デフォルトの名無しさん
2010/04/30(金) 22:52:41俺たちはいずれOOPの中で生きることになる。
0333デフォルトの名無しさん
2010/04/30(金) 23:23:310334デフォルトの名無しさん
2010/05/01(土) 00:56:03例えば、絵画の書籍を何十冊よんでも絵画は描けない。
本人は描けるつもりでも、実際描こうとすると思うように描けない。
これは、本人の知識が不足しているから、細かいテクニックや本質は
実践で取得する。
オブジェクト指向の場合、規模が大きいときに長所が発揮される。
つまり大規模開発を行なわないと、オブジェクト指向の長所が体感として取得出来ない。
最低でも数十万ステップの開発をオブジェクト指向で行なうと、
オブジェクト指向の長所・短所が分かってくる。
と、文章で説明してみる。
0335デフォルトの名無しさん
2010/05/01(土) 01:26:100336デフォルトの名無しさん
2010/05/01(土) 04:01:51OO な設計ってこまわり効かなくね?
つか, 副作用前提で考えるか否かの問題なんだろうけどさ
問題領域によっては OO 思考されるとすごくじゃまなことがある
■ このスレッドは過去ログ倉庫に格納されています