OOP 2
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/11/10(水) 22:51:25OOPってよくわかんないよね
http://hibari.2ch.net/test/read.cgi/tech/1284115490/
0352デフォルトの名無しさん
2010/11/25(木) 20:42:34私は>>349ではないけれど、プログラミング言語を道具という感覚には
ついて行けない。言葉と思考は一体のものだな。先行して「目的」が
あるというところが何かあやしい。
0353デフォルトの名無しさん
2010/11/25(木) 20:52:52道具云々はともかく、目的もなく作業したって意味がないじゃない。
0354デフォルトの名無しさん
2010/11/25(木) 21:03:11疑問に思った事は
「OOPではスパゲティコードで作らないことが必須」なのか？
もちろんスパゲティコードにしない方がいいが
OOPにはそんな制約はないし
メソッドのコードをスパゲティコードで作ってもOOPは実現出来る。
OOPを誤解している人の多くは、いままでの経験上の延長線で
OOPを考えている人が多いと思う。
（情報隠蔽（カプセル化）こそがOOPだと主張する人とか）
OOPは構造化とは別次元の考えでパラダイムシフトだと思うけど。
0355デフォルトの名無しさん
2010/11/25(木) 21:10:30すまん、もう少し主張を整理してもらえる？
0356デフォルトの名無しさん
2010/11/25(木) 21:26:390357デフォルトの名無しさん
2010/11/25(木) 21:34:54「コード間の依存関係」が高まることの結果として生まれるのが、
メンテナンス不能のコード、即ち「スパゲッティコード」であり、それを防ぐには、
依存関係の低い状態である「疎結合」を保たなければならない。
オブジェクト指向の様々なコンセプトは、その意味では特別なものではないし、
逆に、それらのコンセプトの裏にある「本質」を無視して書かれたプログラムは、
たとえオブジェクト指向言語で書いたとしてスパゲッティになる。
という内容でしょ、あの記事は。
0358デフォルトの名無しさん
2010/11/25(木) 21:48:29特別な意味じゃないのは「疎結合」という目的のほうだろ
0359デフォルトの名無しさん
2010/11/25(木) 21:55:13フィールドへのアクセスは、かならずアクセサを通す。
引数に取るのは、intやdoubleなどの基本型のみ。
この二つを守れば、どうやったって疎結合になるよ。
OOPだからどうだってんじゃ無くて、C言語レベルの話でしょ。
0360デフォルトの名無しさん
2010/11/25(木) 21:57:08また、どんな言語を使おうが機能的・データ的に「祖結合」が有用なのは
変わらないわけで。
それを用いてOOPの何たるかを語る事自体が意味がない。
結局の所一時期のOOブームで、まるで銀の弾丸のように説明して
分野を広げすぎた事にOOの問題を感じる。
OOPLによる、OOPはいいものだけどな。
0361デフォルトの名無しさん
2010/11/25(木) 21:58:15分かり難いか、すまない。
簡単に書くと、「メソッドでGOTO文を使っても良い」ということ。
構造化では禁止されているけどOOPではそんな制約はないし
GOTO文を使ってもOOPは実現出来る。
そもそもGOTO文を「使う使わない」とかとは観点が違うと思う。
0362デフォルトの名無しさん
2010/11/25(木) 21:59:38いや、クラスで囲ったとしても、機能的に簡単にスパゲッティはできる。
0363デフォルトの名無しさん
2010/11/25(木) 22:06:49相手のフィールドの存在を意識しなければならないというのは密結合の度合いが強めな証拠
0364デフォルトの名無しさん
2010/11/25(木) 22:15:26だから、ここで最初の結論に戻る。
「オブジェクト指向設計無くしてオブジェクト指向プログラミング無し」
オブジェクト指向言語という有用な道具を生かすには、相応の設計が必要だってこと。
0365デフォルトの名無しさん
2010/11/25(木) 22:21:18フィールドなのかメソッド(アクセサ)なのかコードを見ただけだとパッと見はわからない
しかしIntellisense使うときにでるアイコンでばれる。残念
0366デフォルトの名無しさん
2010/11/25(木) 22:26:18「コード間の依存関係」を整理する、という目的に対して、
オブジェクト指向がどんなメリットを提供しているかを考えるべきだろう。
少なくとも、言語の文法レベルの話をしてもあまり意味がないだろう、というのが俺の意見。
例えば、オブジェクト指向に、なぜ依存性注入(DI)のような手法が登場したかを説明できない。
私見では、疎結合に保ちたい状態の操作を、オブジェクトの提供する「サービス」として
見せるあたりがキモだと思うけど。
0367デフォルトの名無しさん
2010/11/26(金) 03:05:04疎とか密とかは方針としてわからなくはないけど、実際のプログラム開発では気にしない。
たとえばよくあるWebプログラムで言うと、サーバーサイドスクリプトをA、データベースをBオブジェクトを作り、
相互に必要なメッセージをやりとりして、結果をクライアントに応答するように書くけど、
A,B間でメッセージのやりとりをする部分をわざわざ疎にしようとか密にしようとかは考えない。
なぜならどういう機能をどれだけ盛り込むかは要求仕様で決まるから。
疎にするために機能を削るというのは非現実的。何しろお客の要求なんだから。
A,B間で連携して処理する作業が多ければA,B間の関係は自然に密になってしまう。
これが良くないからと言って疎にできるんだろうか？
無理じゃね？
0368デフォルトの名無しさん
2010/11/26(金) 07:44:290369デフォルトの名無しさん
2010/11/26(金) 08:17:28メンテナンス性とは違うが、スケールアウトできるようにA,B間を疎結合に、
というのが、むしろ最近の流れじゃない？ 二つが密結合になってると、
そこがボトルネックになるからね。
本題に戻ると、その例で言えば「DAOはやめてModelを作るべき」みたいな話はあるよね。
スキーマをインタフェースとして直接露出するDAOではなく、
ビジネスロジックとして自然なインタフェースを定義して、制約を作りこんでModelとし、それ経由で永続化を行う。
ま、この辺のやり方は色々と議論があるところみたいだが。
あと、密結合にせざるを得ない部分があるにせよ、その部分全体を外部に対して疎結合に
するようにプログラムすることはできるわけだし。
疎というのは、互いの依存性の話であって、機能の多い少ないとは直接の関係はないよ。
0370デフォルトの名無しさん
2010/11/26(金) 11:42:34A, B間の連結を疎にするというのは
Bが扱うデータベースがGDBM（Key-Valueストア）から突然MySQL（RDB）に変わったとしても、
Bの変更だけで済むようにするということ。
具体的にはAがDBのスキーマを意識してSQL文吐くのでは無くて、
B.get○○などのインターフェースを通じて必要な情報を取得するようする。
パフォーマンスの問題はついて回るかもしれないが、
プログラマに人件費かけるくらいならマシンにかけた方がマシ
0371デフォルトの名無しさん
2010/11/26(金) 12:51:300372デフォルトの名無しさん
2010/11/26(金) 12:56:500373デフォルトの名無しさん
2010/11/26(金) 21:14:02この流れなら
カプセル化とそれに伴うインターフェースと実装の分離が
オブジェクト指向の中心的な技術(手法?)
と言ってしまってもそんなに違和感がないのでは？
本質はいいすぎな気がするから「中心的な技術」に言い換えちゃうけど
0374デフォルトの名無しさん
2010/11/26(金) 21:37:28いいんじゃね別に、本質つっても。
成り立ちから考えろ、シミュレーションが本質だ！つって息を荒げる人以外は同意するんじゃね？
実装とインタフェースの分離は、どっちかっつーと、
モジュール性ってレベルの話題の一つかもしれんが。
0375デフォルトの名無しさん
2010/11/26(金) 22:42:33当然、多重ディスパッチも充分OOPの要素たりえると考えてる。
んなわけでOOPを否定するためにマルチメソッドを主張する思想は全く理解できない。
だってそれらは、両立するどころか、むしろ相性の良いものだと思ってるから。
強いて言えば、それ以外の…個人的には多態ほど重要ではないけど
やっぱり一応抑えておきたい要素である、カプセル化との相性が若干疑問かな。
名前空間を適切に分離してやれば解決できそうではあるけど。
0376デフォルトの名無しさん
2010/11/26(金) 23:26:180377デフォルトの名無しさん
2010/11/27(土) 01:20:52別にそれ以上の意味は無くて、多態だの分離だのはデザインパターンの範疇。
0378デフォルトの名無しさん
2010/11/27(土) 01:23:30そういう整理の仕方のがいいかもな。
0379デフォルトの名無しさん
2010/11/27(土) 02:35:57IBMのSystem/38そのものではないか。だからどうということもないけど。
0380デフォルトの名無しさん
2010/11/27(土) 06:17:34アプリからファイルを開く、も出来るんだけど
ファイルに「開く」って指令を与えてやると、適切なアプリで開いてくれる。
0381デフォルトの名無しさん
2010/11/27(土) 06:25:42OOPにおいて「オブジェクト」とはどういう概念なのよ？
0382デフォルトの名無しさん
2010/11/27(土) 08:33:06オブジェクト = データ + メソッド
0383デフォルトの名無しさん
2010/11/27(土) 09:09:00「データ + 手続き」か「フィールド + メソッド」でないと変だと思います。
C言語プログラマ向けなら「変数 + 関数」という説明もありですね。
0384デフォルトの名無しさん
2010/11/27(土) 09:50:45オブジェクト指向の経験が長く、改修の多い技術者は
差分プログラムが重要だと考えている。
オブジェクト指向の経験が長く、新規案件が多い技術者は
多態が重要だと考えている。
オブジェクト指向の経験が少ない技術者は
カプセル化が重要だと考えている。
この三種類が重要だと考える人が多いけど
経験や業務の差で意見が分かれていると思う。
0385デフォルトの名無しさん
2010/11/27(土) 09:58:35OOPの問題じゃなく、その人間の差だな。
0386デフォルトの名無しさん
2010/11/27(土) 10:41:29> オブジェクト指向の経験が長く、改修の多い技術者は
アジャイル開発みたいに「要求はどんどん変化するし、それは必然だ」という立場を取るなら、
新規開発だろうが改修だろうがこっちになるけどね。
あと、「差分プログラミング」と呼ばれるとしっくり来ないな。
「モジュールを切って疎結合なインタフェースを定義する」という方針を一語で表す言葉って何だろ。
つまり、要求の変化に強いコードを書くのが目的なのであって、差分開発によって工数を減らすという
のは、結果的に享受できるメリットのうちの一つでしかない。
この立場では、（継承以外の）オブジェクト指向の各コンセプトは「道具として」重要だ、となる。
カプセル化は、オブジェクトの利用者に対して事前に設計した制約を強制することができるし、
多態は、制約を与えつつも柔軟さを生み出すのに有益。
「ある程度の規模のソフトウェアを」「複数人で」開発する必要があるかが分かれ目かな、と思う。
俺の意見では、一人でやる場合でも有益な考え方だと思うけど。
0387デフォルトの名無しさん
2010/11/27(土) 11:12:29if (confirm("Q1"))
return input_text("Q2");
return NULL;
のような手続きをイベント駆動に書き直すとなると、当然call treeは全く違ったものになる。
手続き指向や関数型なら、プログラムの設計を大幅に見直さなければならない可能性が高い。
ところがオブジェクト指向でうまく設計してあれば、クラス同士の依存関係、
インスタンスの所有関係などはそのままに、メソッドのインターフェースを変えるだけで済んだりする。
この利点は、オブジェクト指向でスパゲティを作るとデバッグが非常に困難になる問題と表裏一体だが。
0388デフォルトの名無しさん
2010/11/27(土) 11:38:52>アジャイル開発みたいに「要求はどんどん変化するし、それは必然だ」という立場を取るなら、
>新規開発だろうが改修だろうがこっちになるけどね。
開発中の仕様変更・追加と改修を一緒だと考えるのは無理があるのでは？
>つまり、要求の変化に強いコードを書くのが目的なのであって、差分開発によって工数を減らすという
>のは、結果的に享受できるメリットのうちの一つでしかない。
「要求の変化に強いコードを書くのが目的」それは新規開発時の目的では？
その目的で作られたシステムを改修していく時には別の目的があると思うが。
あと、差分が「工数を減らす」だけとしか考えられないはどうかと。
>「ある程度の規模のソフトウェアを」「複数人で」開発する必要があるかが分かれ目かな、と思う。
>俺の意見では、一人でやる場合でも有益な考え方だと思うけど。
その考え方自体が、新規開発時を想定していないのか？
0389デフォルトの名無しさん
2010/11/27(土) 11:42:46ウォーターフォールのような、完全な設計を作ってから開発に入る系の開発手法ならそうなるね。
ここでは、ウォーターフォール vs. アジャイルみたいな話に踏み込むのはやめておくが。
0390デフォルトの名無しさん
2010/11/27(土) 11:44:16OOPナニソレ？→デカイ案件→設計とは何ぞや、柔軟な設計とはなんぞや
→デザパタとは何ぞや→ポリモの旨み→差分でやる旨み→OOPの旨みってなんぞや
→モジュール性を高めるにはどうしたらいいか→どうしたら理想の設計に近づくか
→もっともっと有用なクラス設計をしたい→使いやすい単位でやりくりしたい
→もっともっとカプセル化 ←今ここ
カプセル化ってのは、privateメンバに対してアクセッサを設けることではなく、
非privateメンバ、関数を増やさないことだと今は思ってる。
protectedすら、無いほうがいい。
自分のことだけに集中させればさせるほど、使いやすい単位になる。
使いやすいオブジェクトを実行時に組み合わせてラクするのが極意だと思ってる。
0391デフォルトの名無しさん
2010/11/27(土) 12:07:18KISSの原則と真っ向から対立する考え方ですね。
一人でやるなら汎用的なクラス＋差分プログラミングより
シンプルなクラス＋リファクタリングで単純なクラス構成を目指したくなりませんか？
業務プロジェクトの場合は「動いているものをいじるな」という圧力が大きいですが
ソースを引き継ぐ人には歴史的経緯による複雑なクラス構成は迷惑なだけだと思います。
0392デフォルトの名無しさん
2010/11/27(土) 12:07:43>ウォーターフォールのような、完全な設計を作ってから開発に入る系の開発手法ならそうなるね。
ウォーターフォールを誤解しているのでは？ ウォーターフォールでも前工程への後戻りも認められている。
0393デフォルトの名無しさん
2010/11/27(土) 12:10:31横からだけど、デザパタがどうの、OOPがどうの、
という前にKISSを徹底したほうがよっぽど効果出るといつも思う。
0394デフォルトの名無しさん
2010/11/27(土) 13:17:36「変化に強いコード」は、どんな要求が来ても予め対応できるようにしておく（汎用的）こととは全く違うよ。
むしろ、あなたの言うとおり、クラスのインタフェースやクラス構成をシンプルに保つことが一番重要。
>>392
けど、実際には、ウォーターフォールでの手戻りの発生は多大なコストを伴うよね？
特に、開発がある程度進行してからの手戻りは凄惨の一語。
0395デフォルトの名無しさん
2010/11/27(土) 13:18:15両方やればいいがな
0396デフォルトの名無しさん
2010/11/27(土) 13:59:360397デフォルトの名無しさん
2010/11/27(土) 14:34:22・アメリカ人なら、新大陸で身分制度のないアメリカでは”自由”を大事する。
・ヨーロッパ人なら、貴族社会があって革命により民主主義になったから”平等”（社会民主主義）を大事する。
・日本人なら、お互いが助け合う（年功序列や終身雇用など）”博愛”を大事にする。
こんな感じかで、本当は優越をつけるものではないのかもしれない。
一番大事なのは他を否定することじゃなくバランス感覚を持つことかも。
0398デフォルトの名無しさん
2010/11/27(土) 14:38:41という考え方は、つまり「汎用性」と言った時の文脈を予め固定して考えることであるわけで、むしろナンセンス。
本当の意味で文脈に依存しない汎用的なものは、多くの場合はフレームワークとして世に出てる物を使えばいいわけだし。
0399デフォルトの名無しさん
2010/11/27(土) 14:40:36要求の変化に応じて変更しなければならない領域がなるべく狭くなるようにします。
0400デフォルトの名無しさん
2010/11/27(土) 15:44:38フレームワークを汎用的と言われると違和感がある。
フレームワークは特定の業務や環境に”特化”しているもの。
限られた部分での汎用性はあるが、OOPとは別次元。
そもそもフレームワーク自身がOOPで作られている。
0401デフォルトの名無しさん
2010/11/27(土) 16:01:59構造化設計時代の言葉。
0402デフォルトの名無しさん
2010/11/27(土) 16:54:260403デフォルトの名無しさん
2010/11/27(土) 18:02:06>>398
多分フレームワークは>>398本題じゃないんだろうけど。
フレームワークに乗っけて開発プログラムに特化した部分を
実装していくのはまさに
「汎用的なクラスを作って差分プログラミングする」
という行為に見える。
極端に言えばフレームワークを自分で作るか、
外部から調達するかだけの差であって、
フレームワークがフォロー出来る範囲が違う程度。
>>400
「環境」って例えば何？
言語とかの開発環境？
OSとかの実行環境？
OOPで使うフレームワークは、OOPで作られてるというより、
OOPによる実装の、よくある一部分を汎化した物じゃないのか？
そもそも実装において、範囲を限られない汎用性なんて有り得るの？
0404デフォルトの名無しさん
2010/11/27(土) 18:19:21逆に、将来を見越したつもりで具体例が乏しいままに抽象化すると、
セマンティクスが曖昧になって逆に拡張性が無くなってしまうこともよくある。
UNIX関係でありがちな、ユーザーに自由がありすぎてプログラムの側が何もできない状況も同根。
0405373
2010/11/27(土) 20:01:45論点(というか本質の定義)にズレがあるような気がします
>>373は
「オブジェクト指向をオブジェクト指向たらしめている技術」
という意味での発言です
「オブジェクト指向を使って実現することが出来る技術」
ではありません
0406398
2010/11/27(土) 20:58:00や、もちろん「汎用的なクラスを作って差分プログラミングする」が適切な場合はある。
けど、それをやるべきケースはわりと限定されているのでは、というのが俺の意見。
特に、「汎用的なクラスを作る」の部分は、車輪の再発明と化す場合も多い。
0407398
2010/11/27(土) 21:04:05それだけで一個プロジェクトが立ち上げられるレベルなんじゃないかな。
あるいは、多人数開発で、少数の優秀なアーキテクトがプロジェクト全体の開発プロセスを
統制する目的で注意深く作成する、みたいなケースか。
0408デフォルトの名無しさん
2010/11/27(土) 21:38:460409デフォルトの名無しさん
2010/11/27(土) 21:44:360410デフォルトの名無しさん
2010/11/27(土) 23:17:290411デフォルトの名無しさん
2010/11/28(日) 00:02:04そろそろ処理構造の汎化の正規化とか誰か作らないかな
0412デフォルトの名無しさん
2010/11/28(日) 00:06:270413デフォルトの名無しさん
2010/11/28(日) 00:44:13意味無いと思うぞ。
だって、データ構造が抜け落ちてるから。
プログラムは、大まかに分けて、制御構造とデータ構造で成り立っている。
おのおのを単体で見るなら、なんら難しいことは無いが、
両者が絡み合うと途端に難しくなる。
http://www.nhk.or.jp/kanadigi-blog/photos/shiorin022.jpg
これは電波の図だが、制御構造とデータ構造のイメージは概ねこんな感じ。
互いに影響しながら振り子運動をする。
また、振り子運動における、位置エネルギーと速度エネルギーの関係とも言っていいし、
電圧と電流の関係とも言える。
おのおの単体で扱えれば簡単なんだが、互いに相互作用するから、
切り離せないんだ。
どっちかを基準にして考えることも出来ない。交互に頭を切り替えながら考える必要がある。
http://trickart.up.seesaa.net/image/rubin.gif
この絵のようにな。
0414デフォルトの名無しさん
2010/11/28(日) 00:55:42わりとデータよりの発想で、だからバランスが悪いと俺はね。
マルチメソッドにしろというのはそういうこと。
0415デフォルトの名無しさん
2010/11/28(日) 00:56:480416デフォルトの名無しさん
2010/11/28(日) 04:02:25それを処理するメルチメソッド関数が何個も必要になる。3個、4個と増えればそれらの相互関係を処理するために
幾何級数的にマルチメソッド関数が増える。しかも1個でも書きもらせばバグになる。いたずらに複雑になるだけで
わかりやすさとはほど遠い。見た目がただの関数にしか見えないのもOOPらしくない。
0417デフォルトの名無しさん
2010/11/28(日) 06:07:45関数の数は、例えばオブジェクト2個なら片方をObjectか何かで取って
多態を使って変換してやるだけだろうし
ただいつもの人の場合は手段と目的がぐちゃぐちゃ
ただ批判したいがために出してる感じ
0418デフォルトの名無しさん
2010/11/28(日) 11:01:37だって、お前らオーバーロードは受け入れているんだろ？
あれは、全ての引数の型に基づいて関数を決定するぞ。
あれがよくて、なんでマルチメソッドはダメなんだ？
普通に機能強化なんだから、問題ないだろ。
OOPが好きな奴も嫌いな奴も納得できる、良い落しどころだろ。
テンプレートが便利なのも、いまや誰もが認めるところだろ。
あれが動的になるだけじゃん。
マルチメソッド+ダックタイピング、良いね。
次のスタンダードになりうると思うよ。
0419デフォルトの名無しさん
2010/11/28(日) 11:21:43ワークフローエンジンなんかは、いくつか出てるね
0420デフォルトの名無しさん
2010/11/28(日) 12:27:34プログラマを楽にすることに全く貢献してないから。
「あれもできる、これもできる」というのは、使いやすさとは関係ないんだよ。
0421デフォルトの名無しさん
2010/11/28(日) 12:36:100422デフォルトの名無しさん
2010/11/28(日) 12:39:06あるクラスのメソッド呼び出しで、引数型をみて(ダックタイピングでも)
動的ディスパッチするだけなら特に問題はない。
動的言語としちゃ普通に便利だろ。
# ある開発において、動的と静的のどちらが向いてるかの問題はある。
いつもの人は
「クラスは無くして全てマルチメソッドで表現すべき」
などと言うから頂けないんだ。
0423デフォルトの名無しさん
2010/11/28(日) 12:56:51それに、マルチメソッドなのに、「クラスメソッド」って呼び名は変だろ。
オーバーロードの関数を、クラスメソッドって言うか？
0424デフォルトの名無しさん
2010/11/28(日) 12:58:49複数のクラスに属しているメソッドだから、クラス定義部に書くことは出来ないぞ。
クラスメソッドって言えるか？
0425デフォルトの名無しさん
2010/11/28(日) 13:00:28もう一度言うぞ。
「機能等価であることと、使いやすさや読みやすさは関係ない」
0426デフォルトの名無しさん
2010/11/28(日) 13:02:48機能等価の方が汎用性があっていいに決まってるじゃん。
0427デフォルトの名無しさん
2010/11/28(日) 13:03:26あのカオスをまた増殖させるのか？
0428デフォルトの名無しさん
2010/11/28(日) 13:05:18より一層シンプルになるわな。
0429デフォルトの名無しさん
2010/11/28(日) 13:06:450430デフォルトの名無しさん
2010/11/28(日) 13:09:31カプセルの外から、総称アルゴリズムでオブジェクトを扱うためのグルーだ。
クラスを作る側がメソッドを提供する場合であっても、
マルチメソッドのインターフェースを決めるのは使う側で、
それをフックする考え方になる。
0431デフォルトの名無しさん
2010/11/28(日) 13:09:51それがよければそちらをどうぞ。超シンプルだぜ。
多態がオーバーロードに吸収されて、オーバーロードとして残る。
動的オーバーロード=動的多態=マルチメソッド
ってだけじゃん。何が複雑なのか解らない。
0432デフォルトの名無しさん
2010/11/28(日) 13:12:56どれだけの弊害が起こるか想像できないんだね。
君は、一人だけでプログラムを作ってる人だと、見え見え。
0433デフォルトの名無しさん
2010/11/28(日) 13:13:53プログラミングにおいて、過剰に汎用性がある機能は逆に使いにくい。
理由は色々あるが、一つは、その機能を使って書かれているコードの意図が曖昧になるから。
他人が読んだときに分かりにくいコードなんて、第一級のバグの温床となりうる。
多くのオブジェクト指向言語が、「オブジェクト」にメソッドを従属させているのは、
ある機能群をグループ化できるということの他に、使う側がそのメソッドを使っている文脈を明確化できるから、だと思う。
0434デフォルトの名無しさん
2010/11/28(日) 13:15:25オーバーロードも多態も全て動的オーバーロードで解決しようって言ってるのに、
>１つの機能を実現する方法が複数有っただけでどれだけの弊害(ry
になるのか解らない。なんで逆を言うの？
方法が複数？一本化しようって言ってるのに？
なんでなんで。
0435デフォルトの名無しさん
2010/11/28(日) 13:16:58だったら、多態も差分プログラミングもカプセル化も全部同じ文法の、
C++やJavaはもっとダメだね。
0436デフォルトの名無しさん
2010/11/28(日) 13:19:08↑これが過ちなんだろうな。
クラスベースOOPLで言うと、
クラスの実装をしてる時は、変数＋関数を扱ってるんだが、
クラスの実装が終わったあと、さぁOOPでラクしようってときに、
外からそのオブジェクトを見たときは
オブジェクト＝インタフェース＝型とメソッド名と引数と戻り値
こう考えられるからこそ、使うときラクできる。
変数も関数の実装も、考えなくていい。開放される。
0437デフォルトの名無しさん
2010/11/28(日) 13:23:32func( obj1, obj2 );
でも同じだろ。
funcの実装も、obj1とobj2の実装も、何も気にしなくて良い。
つーか、そんなのOOPの話じゃなくて、Cレベルの話だろ。
0438デフォルトの名無しさん
2010/11/28(日) 13:26:45同じ文法って何の話だ？
それに、別のレイヤの話をごちゃ混ぜにして何が言いたい。
0439デフォルトの名無しさん
2010/11/28(日) 13:28:15マルチメソッドの問題は、コンパイラの実装が困難なこと。
使い勝手が悪いって方向から攻めても無駄なんだよ。
オーバーロードはOKで、マルチメソッドはNGって主張は、
説明がつかないんだよ。
だから、マルチメソッドをどうしても否定したいなら、
コンパイラの実装について言及するのが正しいんだ。
0440デフォルトの名無しさん
2010/11/28(日) 13:31:55結局それなんだろうな。
コードを書くという事の本質的な困難は、機能をコードを落とす所それ自体にはないというのは、
大規模なコードを書いたり、複数人で開発したりする経験がないとなかなか分からないのかも。
0441デフォルトの名無しさん
2010/11/28(日) 13:33:54実装のできない処理系とか、プログラマ的には完全に無意味だと思うんですが。
自分が全知全能なら混沌とした世を平らげられるのに、と妄想してる中学生と何が違うの？
0442デフォルトの名無しさん
2010/11/28(日) 13:35:200443デフォルトの名無しさん
2010/11/28(日) 13:36:35例えばstrlen()を使うとき、
char obj[]の中身が'\0'で終わっている事を気にしなくちゃいけない。
それは、関数の実装により強いられていることで、
渡す引数もそれに対応して準備しなきゃ使えない。
一方、OOPでのstringクラスは、終端文字がどうであるかは問われない。
string#size()を呼び出すときも何も気にすることが無い。
0444デフォルトの名無しさん
2010/11/28(日) 13:36:46妄想処理系の擬似コードがいくらあっても、お腹はいっぱいにならんのですが。
0445デフォルトの名無しさん
2010/11/28(日) 13:36:59そうしたものがどっかからポンと出て来た時に、これは続けられるんですか？」論だな
0446デフォルトの名無しさん
2010/11/28(日) 13:38:44len( string );
append( string, "hoge" );
で、何か問題があるの？
0447デフォルトの名無しさん
2010/11/28(日) 13:45:02(append "abcde" "hoge")
の方がすっきりしているとはおもわないのかね
0448デフォルトの名無しさん
2010/11/28(日) 13:46:44len "abcd";
append "abcde" "hoge";
0449デフォルトの名無しさん
2010/11/28(日) 13:51:440450デフォルトの名無しさん
2010/11/28(日) 13:59:07ああそうか。そうやってすれば結局は同じか…。
privateにはならないだけで。
Cは関数のオーバーロードできないから、
名前はどんどん苦しくなってくると思うけど。
問題はそれくらいのもんか。
そのstruct stringは、stringクラスを作った場合の、
メンバ変数を全部網羅してるものと考えていい？
0451デフォルトの名無しさん
2010/11/28(日) 14:03:52考えて言うだけより考えて実行するべき
何言ってるのかわからないが
■ このスレッドは過去ログ倉庫に格納されています