OOP
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/09/10(金) 19:44:500268デフォルトの名無しさん
2010/09/18(土) 14:42:53少なくとも、近年では差分プログラミングを目的とした継承(IS-A)より、
インタフェースを介したオブジェクト間での委譲(HAS-A)がより良いとされているよ。
0269デフォルトの名無しさん
2010/09/18(土) 15:07:47バグ修正するときどうすんだよ
0270デフォルトの名無しさん
2010/09/18(土) 15:18:07has-aなら利用側と全く変わらない理解度でおkだし、誤った継承もしにくいよ
0271デフォルトの名無しさん
2010/09/18(土) 15:19:06まあ、間違った挙動に依存しているコードがあるかもしれないから、
おいそれとなおさねーよがMSの流儀ですね。
0272デフォルトの名無しさん
2010/09/18(土) 15:42:43ただし被せたらうまくいかない
つまり継承は×
0273デフォルトの名無しさん
2010/09/18(土) 16:02:39俺の知識では、それは多態の話だとおもうが。
それに、インタフェースはクラス全体で見ると差分プログラムと言えなくもないが
メソッドレベルだと、新規プログラミングで差分プログラミングじゃない。
>>269
既存ソースがなくてもバグは取れる。
そもそも前提条件が違う、業務運用を長年行なって品質の確かな
既存クラスに影響を与えず、機能追加・削除出来るから継承を使う。
>>270,271
同意。
0274デフォルトの名無しさん
2010/09/18(土) 16:49:55メソッド全体で見ると差分プログラムと言えなくもないが
行レベルだと、新規プログラミングで差分プログラミングじゃない。
とか言いそうな勢いだな。
0275デフォルトの名無しさん
2010/09/18(土) 16:57:210276デフォルトの名無しさん
2010/09/18(土) 17:24:24>既存ソースがなくてもバグは取れる。
具体的にはどうすんの？
オーバーライドしてメソッド書き直すの？
0277デフォルトの名無しさん
2010/09/18(土) 17:27:220278デフォルトの名無しさん
2010/09/18(土) 18:53:59継承でインターフェイス整えるのが便利って言うならまだ分かるんだよ。
ただ、「マルチメソッドはどうするの？」って切り返させてもらうが。
でもまだ分かるよ、気持ちはな。
差分プログラミング目的の継承は論外だよ。
ありえるのは、実は本人はインターフェイス周りに利点を感じているのにもかかわらず、
上手く思いを表現できずに、出てくる言葉が差分プログラミングどうのこうのになってるっていう、
いわゆるケイ君状態。こっちにエスパーしろってか？付き合いきれねぇ。
語学力というより、数学力が無いのだろう。
0279デフォルトの名無しさん
2010/09/18(土) 18:56:44すまん、マルチメソッドってそんなのかいな？
0280デフォルトの名無しさん
2010/09/18(土) 18:58:04そりゃそうなんだが、オープンクローズド原則って、
変更するときゃ継承しなよ、ってことだろ？ あれはどうなん？
oosc本によると、差分プログラミングで(ﾟДﾟ)ｳﾏｰと書いてるようにすら見えるが。
0281デフォルトの名無しさん
2010/09/18(土) 19:02:11インターフェース(抽象クラス)使うなら、
変更するクラスは一から作り直すことになる。
0282デフォルトの名無しさん
2010/09/18(土) 19:34:26バグを修正するために継承はないわ
0283デフォルトの名無しさん
2010/09/18(土) 20:28:220284デフォルトの名無しさん
2010/09/18(土) 20:31:100285デフォルトの名無しさん
2010/09/18(土) 21:16:08Wikipediaの開放閉鎖原則のページによれば、オリジナルはそういう意味だったが、
最近はインタフェースを利用汁という解釈に変化した、って書いてあるね。
0286デフォルトの名無しさん
2010/09/18(土) 21:28:12OOPだった連中ですら、今はもうインターフェース使えって言ってる。
インターフェース中心に考える・・・つまりオブジェクト指向ではなくインターフェース指向だと。
もうOOPは完全に消えてなくなったんだね。ﾅﾑﾅﾑ
0287デフォルトの名無しさん
2010/09/18(土) 21:41:28boost::operatorsとか、Haskellの型クラスのデフォルトメソッドみたいな
「多態性」を考慮しない実装継承なら有効
逆に言えば「多態性」を使うなら継承は使いにくいと思う
インターフェース継承+委譲とか、ダックタイピングとか使ったほうがマシ
0288デフォルトの名無しさん
2010/09/18(土) 21:42:060289デフォルトの名無しさん
2010/09/18(土) 21:48:28でもさ、OOPを、インタフェース志向に置き換えるのは、
すごくいいアイデアだと思う。モジュール性をよりプッシュ。
0290デフォルトの名無しさん
2010/09/18(土) 21:53:56そのほうが考えやすいって奴は、昔風の人ってこったろう。
それはそれで別にかまわないんだけど、今は21世紀だし、そんな思考回路じゃそのうち干されちゃうよ。
数学習ったんだろ？コミュニケーションが大事だって散々言われてるんだろ？
物事の関係を抽出して上手くまとめて機能させる、それが創造性だろ？
神は細部に宿るって言うだろ？目では見ること出来ない「関係」に神は宿ってるんだよ。
少なくとも「物」には神は宿らないよ、八百万の神じゃあるまいし、古臭い。
発展途上国の人たちはバイクのことをホンダと言い、トラクターのことをクボタと言うらしいが、
まだまだ機能で考える文化が無いんだろうね。これからに期待しよう。
でもお前らは運よく日本で生まれて中学校まで義務教育で、大体の奴は高校へ行き、今なら大学行くのも当たり前で、
高等な教育を受けれるラッキーな環境で育ったんだから、もうちょっと頑張れるよな。
OOPなんぞの古い考え方にハマって折角のチャンスを無碍にするなよー。田代並みに残念な奴らだ。
0291デフォルトの名無しさん
2010/09/18(土) 22:27:530292デフォルトの名無しさん
2010/09/18(土) 22:33:42長い上に分かりづらい。
お前の言う関係って何？
コラボレート？
手続き？
何と何の関係なの？
客の要望からいきなり抽出出来るもんなの？
0293デフォルトの名無しさん
2010/09/18(土) 22:59:46正しく理解せず無駄に頑張って「関係も物として〜」とかやり始めてたら、
いよいよ収拾がつかないwww手の施しようの無い狂人に成り果てる。
0294デフォルトの名無しさん
2010/09/18(土) 23:02:55実装継承しないで元のソースにアクセス出来るなら現実的にはコピペコードを作ることになるけど、継承とどっちがマシなのか？
0295デフォルトの名無しさん
2010/09/18(土) 23:40:03なんだ。
神だの何だの言ってるから何事かと思ったら、
単なる宗教家か。
無説明に恐怖心を煽って判断力を奪おうとする辺り、
とても新興宗教的。
0296デフォルトの名無しさん
2010/09/18(土) 23:41:32オブジェクト指向設計の実装方法がインターフェース指向だってだけなんですが。
0297デフォルトの名無しさん
2010/09/18(土) 23:43:39自分の理解できない概念をFUDしてるだけだしな。
全員が自分と同レベルになれば、何も勉強しなくていいしおまんまも食えるっていうチンケな心算。
0298デフォルトの名無しさん
2010/09/19(日) 00:13:17誰しも自分の持ってる物差しでしか把握出来ないし語れないのだから無理も無いが。
俺はOOPは意味が無いと言う。
彼は俺がOOPを理解できないと言う。
俺は意味の有る/無しを論点にする。
彼は理解できる/出来ないを論点にする。
そのままその人の価値基準の表れなのだろう。
0299デフォルトの名無しさん
2010/09/19(日) 00:13:37かなり邪悪な存在だと思うんだけど。
0300デフォルトの名無しさん
2010/09/19(日) 00:16:070301デフォルトの名無しさん
2010/09/19(日) 00:16:490302デフォルトの名無しさん
2010/09/19(日) 00:17:580303デフォルトの名無しさん
2010/09/19(日) 00:18:45初めから「インターフェース指向設計」でいいだろ。いちいち回りくどい。
0304デフォルトの名無しさん
2010/09/19(日) 00:20:140305デフォルトの名無しさん
2010/09/19(日) 00:20:430306デフォルトの名無しさん
2010/09/19(日) 00:31:57オブジェクト指向のスレなんだから
関数内static変数とか、ファイルネームスペースのstatic変数とかではないだろ
0307デフォルトの名無しさん
2010/09/19(日) 00:34:100308デフォルトの名無しさん
2010/09/19(日) 00:45:53アンチすら居なくなってOOP完全消滅か。
0309デフォルトの名無しさん
2010/09/19(日) 00:48:330310デフォルトの名無しさん
2010/09/19(日) 01:25:140311デフォルトの名無しさん
2010/09/19(日) 01:27:140312デフォルトの名無しさん
2010/09/19(日) 01:48:490313デフォルトの名無しさん
2010/09/19(日) 09:57:33>具体的にはどうすんの？
上でも書いたが、信頼性のあるクラスに影響を与えない為に
継承を使って差分プログラミングを行なう。
クラスのバグ修正は別の話。
>>279
>すまん、マルチメソッドってそんなのかいな？
俺もマルチメソッドってそんなものじゃないと思う。
マルチメソッドは継承や多態性とは関係ない。
>>280
>> 差分プログラミング目的の継承は論外だよ。
>そりゃそうなんだが
具体的に聞きたい、何故論外なんだ？
こちらも具体的な例を挙げるから、それについて書いてくれ。
例：あるメソッドの引数が和暦の誕生日だった。
ある日元号が新しくなる事になり、機能追加が必要になった。
俺はそのクラスを継承し、既存元号（明治〜平成）はスーパークラスのメソッドを実行し
新しい元号のロジックのみをサブクラスに実装した。
>>282
同意。
>>284
委譲も使うべきだが、それが差分プログラミングが駄目だという理由にはならない。
0314デフォルトの名無しさん
2010/09/19(日) 11:19:54個人的にはまだコピペコードのがマシじゃないかと思う。
というかコピペコードでもあんま問題にならんくらい
クラスはコンパクトにしとけと思う。
0315デフォルトの名無しさん
2010/09/19(日) 12:46:34なんかその例の設計自体がおかしい感じがするけど
普通に和暦を引数に取ってるメソッドそのものを修正したほうがいいと思うんだが
サブクラスに修正内容を実装しちゃったら、既存のスーパークラス使ってるロジックを
サブクラスに置き換えて修正する必要が出てくる気がするんだけど、それは許容するの？
0316デフォルトの名無しさん
2010/09/19(日) 12:47:24一旦今の仕組みじゃ無理とわかったら、目的のスーパークラスまでガッツリ穴掘って
カスタマイズポイントつくらないといけない。
そりゃ設計がヘボなんだと言われたら、あるいはそうかもしれんが
どんな仕様変更にも耐えうる何でもスーパークラスなんてもっと地雷だからな。
継承なんか極力使わずにできるだけ合成で済ませればそんな問題は起こらない。
0317デフォルトの名無しさん
2010/09/19(日) 15:42:19>なんかその例の設計自体がおかしい感じがするけど
>普通に和暦を引数に取ってるメソッドそのものを修正したほうがいいと思うんだが
具体的に書いてくれ。
>サブクラスに修正内容を実装しちゃったら、既存のスーパークラス使ってるロジックを
>サブクラスに置き換えて修正する必要が出てくる気がするんだけど、それは許容するの？
俺の中での常識では、自分が作ったクラス変数から直にオブジェクトを作成する
ハードコーディングは絶対に駄目だと思っている。
だから修正する必要はないように始めから作っている。
0318デフォルトの名無しさん
2010/09/19(日) 16:17:03継承での差分ってのは、動的な多態をする際にメリットがあるわけだけれども
その追加のやり方だと
(〜明治まで計算出来る)
(〜大正まで計算出来る)
(〜昭和まで計算出来る)
みたいなクラス階層が出来るが、これで多態すんの？
最新版以外は何の役にも立たないじゃん
is-a関係とか、全く気にしてないでしょ
>自分が作ったクラス変数から直にオブジェクトを作成する
>ハードコーディングは絶対に駄目だと思っている。
暗号すぎる
0319デフォルトの名無しさん
2010/09/19(日) 17:30:43まさに言葉の定義の曖昧なOOPらしい会話だ。
同じ概念なのに独自の言葉を再発明。
違った目的なのに、同じ文法。ポリモ、差分P、カプセル化、全部クラスの仕組みでやってねー。
頭悪くなるんだと思うよ、やってる連中も、そいつらに関わった奴も。
朱に交われば赤くなるって言うんだっけか。
0320デフォルトの名無しさん
2010/09/19(日) 18:18:26テンプレートも忘れないでください
0321デフォルトの名無しさん
2010/09/19(日) 18:18:550322デフォルトの名無しさん
2010/09/19(日) 19:20:35暗号ってｗ 前に彼女がソースを見たとき、暗号っぽいねと言ってたのを思い出したわｗ
知識の無い奴が見ると暗号なんだろうな >>317がどの言語を使っているかわからんが
メタクラスやクラス参照型、あとポインターもSingletonっぽく書けば出来るだろう
お前ら、インスタンス生成をハードコード で書いているのか？
これスレが噛み合わないのはレベルの違いだな
0323デフォルトの名無しさん
2010/09/19(日) 19:28:090324デフォルトの名無しさん
2010/09/19(日) 19:36:12文の切れ目が判らん、パーザがエラー起こすんだ
引用された文に括弧付けて貰うと助かる
0325デフォルトの名無しさん
2010/09/19(日) 20:34:35思いっきり実装でソースがドロドロしてる話だったなり
0326デフォルトの名無しさん
2010/09/19(日) 21:00:18クラスインスタンスとかクラス名の事を指していて、ハードコーディングというのはクラス名を直接書いてnewする事を指している
そしてなるべく具体的なクラス名を記述せずに実装するのが前提なので、コードの修正無しに差し替え可能だと言ってる……のかな
なんかのフレームワークが前提になってる？
0327デフォルトの名無しさん
2010/09/19(日) 21:10:430328デフォルトの名無しさん
2010/09/19(日) 21:58:28とりあえず、継承の欠点その1は、機能拡張の軸が二つ以上あるようなクラスの
継承を始めると、子クラスの数が爆発を起こすこと。
このような場合は、軸ごとにクラスを分けて委譲することで解決できる。
0329デフォルトの名無しさん
2010/09/19(日) 22:09:11無力だな。
0330デフォルトの名無しさん
2010/09/19(日) 22:40:03何でもいいから手を動かせよ
0331デフォルトの名無しさん
2010/09/19(日) 22:54:26多態性の話じゃない、それに
>最新版以外は何の役にも立たないじゃん
>is-a関係とか、全く気にしてないでしょ
「引数が和暦の誕生日」だから最新以外も使われる。
ちゃんと読んで書いてくれ。
>>319
>まじ暗号だな。
そんなに分かり難い表現だったのか？
>>326
その通りの意味で、メタクラスを使っている。
クラスを抽象化するのは基本だと思っていたが違うみだいだ。
しかし、クラス名をハードコーディングしたら
差分プログラミングは出来ないだろうに？
>>328
>とりあえず、継承の欠点その1は、機能拡張の軸が二つ以上あるようなクラスの
>継承を始めると、子クラスの数が爆発を起こすこと。
それはある。しかし俺が話しているのは多態性の話じゃなく差分プログラミング。
>このような場合は、軸ごとにクラスを分けて委譲することで解決できる。
多分BridgeパターンやDecoratorパターンみたいな解決方法をいっていると思うが？
その場合の委譲は、継承と組み合わせ場合が多いと思うが。
0332デフォルトの名無しさん
2010/09/19(日) 23:16:04さぁ、学術的回答が聞かれるかなｗ
0333デフォルトの名無しさん
2010/09/19(日) 23:18:48横から。
>>最新版以外は何の役にも立たないじゃん
>「引数が和暦の誕生日」だから最新以外も使われる。
明治、大正、昭和、平成が扱えるクラスががある時、
設計上、明治、大正、昭和が扱えるクラスは要るのか？
っつー話じゃね？
実装上は、内部のみで使ってるか知らんが。
0334デフォルトの名無しさん
2010/09/19(日) 23:22:500335デフォルトの名無しさん
2010/09/19(日) 23:34:300336デフォルトの名無しさん
2010/09/19(日) 23:35:280337デフォルトの名無しさん
2010/09/19(日) 23:41:02それも違うんじゃないか？
0338デフォルトの名無しさん
2010/09/19(日) 23:48:170339デフォルトの名無しさん
2010/09/20(月) 00:10:07ソースの作りかたにこだわるよりはラノベでも読んでおけよ
0340デフォルトの名無しさん
2010/09/20(月) 00:55:16リスコフ置換原則に反するようなやり方になりがちなのが問題、ということじゃないかと。
過去の自分と今の自分、そして未来の自分は、大抵において、相互に矛盾する考えを
持ってプログラミングしている可能性が低くないしね。別人だと言ってもいい。
0341デフォルトの名無しさん
2010/09/20(月) 09:58:44なるほど、しかし回答は同じだけど。
差分プログラミングはスーパークラスの仕様が分かっていれば設計は知らなくていい。
それに、多態性じゃなく差分プログラミングなんだから
>(〜明治まで計算出来る)
>(〜大正まで計算出来る)
>(〜昭和まで計算出来る)
じゃなく(〜昭和”まで”計算出来る) は (昭和”の”計算出来る) 見たいに積み重なっていくと思うけど。
確かにその設計は >それは明らかにクソ設計
かもしれない、そんな発想もなかった。３３３はよく理解出来たね？
>>336
駄目だ意味が分からない、ワンフレーズだと理解出来ないもんだ。
>>338
俺的に一番は、デグレード”予防”だと思う。
>>340
>リスコフ置換原則に反するようなやり方になりがちなのが問題、ということじゃないかと。
俺の考えでは逆。
既存を残して積み上げていくから「リスコフの置換原則」を守りやすい。
0342デフォルトの名無しさん
2010/09/20(月) 11:52:23単純に似たような物を作る時に既存部分を流用する手法程度に思ってたんだけど
0343デフォルトの名無しさん
2010/09/20(月) 12:15:52>３３３はよく理解出来たね？
むしろ341が理解できない。
積み重ねる、のニュアンスが致命的にズレてるのかも。
元号の判定は誰がすんの？
もう日本語よりJAVAか何かで話した方が早い気がしてきた。
0344デフォルトの名無しさん
2010/09/20(月) 12:45:16俺が言いたいのは、「既存を残して積み上げていく」手段として継承を使うと、
以前の要求に基づいたクラスと、現在の要求に基づいたクラスという、
二つの異なる考え方に基づいたコードが地層として積み重なるということが
起きるのは良くないのではないか、ってこと。
うまく作ればいいのかもしれないが、外部からそのオブジェクトの機能を見た時の
一貫性が失われる結果になる可能性は高い。
0345デフォルトの名無しさん
2010/09/20(月) 12:54:060346デフォルトの名無しさん
2010/09/20(月) 13:31:16うまく作れば
0347デフォルトの名無しさん
2010/09/20(月) 14:55:19なんか放っておくと、どんどん実装よりの小手先な話に話題が拡散していくな。
スレの話題が、数多ある地獄からヌーと伸びてきた手に引きづられ、自分たちのフィールドに持ってかれる。
それぞれ違った常識の中に生きてるから、話がまるでかみ合わない。こんな展開、OOPらしいっちゃらしいが。
が、しかし、2chのように色々な人が居る場所でそれやる意味あるか？
学術的どうのこうの言ってた人も居たけど、そういうことだろ。
・オブジェクトとは何か。
・メッセージングとはどういった行為か。
その辺から一つ一つ真面目に定義していけば、OOPの全貌が見えてくるし、
プログラミング、ソフトウェア工学、設計、そういったものの本質も見えてくるだろう。
その結果、OOPイラネってなるかもしれないし、使いどころだってなるかもしれないし、
必要悪だってなるかもしんないけど、それは各自の判断だろうに。
0348デフォルトの名無しさん
2010/09/20(月) 14:58:21> ・メッセージングとはどういった行為か。
> その辺から一つ一つ真面目に定義していけば、OOPの全貌が見えてくるし、
ないない。どういう設計的前提を置くかを明確にせずに、それだけ語っても宗教論争にしかならん。
0349デフォルトの名無しさん
2010/09/20(月) 15:01:230350デフォルトの名無しさん
2010/09/20(月) 15:12:09顧客要求は分かるよ、でも設計的前提wって何よ。
相手を自分の都合のいいフィールドに引きづり込むための制約か何かかw
設計的前提、設計的前提、設計的前提・・・
設計って「行為」なのに、「的」つけてわざわざ物みたいな扱いにしてるのが
OOP脳っぽいっちゃぽいな。
そういう些細な言葉のチョイスにその人と成りは表れてしまう。恐ろしいね。
まさに神は細部に宿る。
0351デフォルトの名無しさん
2010/09/20(月) 15:29:20・メッセージ=オブジェクトからメソッドを呼び出す行為
最低限のOOっていうか、OO言語の共通点ってこれくらいしかない
0352デフォルトの名無しさん
2010/09/20(月) 16:12:32かりに、そう定義したとして、
>オブジェクト=データと処理（メソッド）を持つもの。
データと処理をひとまとめにする意味は？
>メッセージ=オブジェクトからメソッドを呼び出す行為
メソッド呼び出して、結局のところ、何がしたいの？
その行為の意味は何？
俺らのしたがってることは一体何？
と、話題を発展することが出来る。
0353デフォルトの名無しさん
2010/09/20(月) 16:54:59>単純に似たような物を作る時に既存部分を流用する手法程度に思ってたんだけど
汎化だろ？俺もそう思っていた、たぶん341とのズレは新規か既存プログラムのどっちを
対象にしているかの違いじゃないのか？
0354デフォルトの名無しさん
2010/09/20(月) 17:48:360355デフォルトの名無しさん
2010/09/20(月) 19:15:32話がズレている。差分プログラミングの話なのに
なぜ継承元の構造をそこまで意識しないといけない？
あと >元号の判定は誰がすんの？
オブジェクト指向だから、オブジェクト自身が判断する。
>>344
>以前の要求に基づいたクラスと、現在の要求に基づいたクラスという、
>二つの異なる考え方に基づいたコードが地層として積み重なるということが
>起きるのは良くないのではないか、ってこと。
意味が理解出来ない、「以前の要求に基づいたクラス」と「現在の要求に基づいたクラス」は
インスタンスが違うだから、「異なる考え方」でも問題はないと思うが？
もちろん、クラスは抽象化してインスタンス作成もクラスに任せるから呼び出し側に
意識させないようにするけおど。
>>347
>なぁ、いつもの人だけど、そろそろ俺の出番じゃね？
まかせる。
0356デフォルトの名無しさん
2010/09/20(月) 19:53:35機能の拡張に継承は駄目でなるべくコンポジションを使うべきとか聞いた記憶があります
何故駄目なんでしょうか？
例:
標準のイベントハンドラを拡張したハンドラ、それ用の補助メソッドや振舞設定用インタフェースを実装するダイアログボックスExtendedDialogを作るときに
標準のダイアログボックスクラスDialogを継承することで、標準の実装を利用し実装した
尚Dialogは継承されることを前提とした作りにはなっているとする
それとも「なるべく」なだけで、こういう場合なら大きな問題はないのでしょうか？
0357デフォルトの名無しさん
2010/09/20(月) 20:19:11オブジェクト指向と言ったら継承っしょみたいなノリで継承が多用されてる
しかし、一口に継承と言っても
実装の継承: コードの使い回しを目的にした継承
概念の継承: 多態性を利用する目的の継承（インターフェース継承）
の二つの継承があり、この二つが混同されることによって厄介な問題が起きる。
ちなみに、C++はprivate継承といって、実装だけの継承も出来るのだけど、
boost::operatorsみたいな特殊なパターンを除いては、コンポジションが推奨されてるみたい。
0358デフォルトの名無しさん
2010/09/20(月) 20:43:48ズレてるってか多分俺が理解できてない。
>なぜ継承元の構造をそこまで意識しないといけない？
今のところ、凄くやっつけ仕事を言ってるに見えてるから。
システム全体として引き継ぎ易い構造になるの？
0359デフォルトの名無しさん
2010/09/20(月) 21:30:24言語や開発環境でいろいろなケースがあると思うけど、俺が考えつくのは
ライブラリや開発環境が比較的代わりやすい場合は
コンポジションの方が影響を受け難い。
コンポジションは別クラスに実装するから、相手のフィールドやメソッドを直接操作出来ない。
これは欠点でもあるし、影響を受け難い利点にもなる。
継承の場合、スーパークラスが修正されると影響が出るから安定したクラスを親にしないと。
言語はjavaとか？
>>358
>今のところ、凄くやっつけ仕事を言ってるに見えてるから。
差分プログラミングの例だから、そこまで考えていない。
和暦を入力パラメータにもつメソッドに
新元号が追加される単純な話だから。
0360デフォルトの名無しさん
2010/09/20(月) 21:50:40契約プログラミング的な考え方を非常に大雑把に言えば、
「あるインタフェースを持つオブジェクトがユーザに対して見せる機能は、
常に一貫していなければならない」と言えると思う。
差分プログラミングを、「要求の変化に対し、過去のコードを拡張することで対応する」
という考え方だとするなら、それは契約プログラミングとは必ずしも一致しないし、
むしろ相反する場合の方が多いのではないか、というのが俺の意見。
もちろん、両者が一致する範囲内での話なら特に問題はないと思う。
0361デフォルトの名無しさん
2010/09/20(月) 21:58:500362デフォルトの名無しさん
2010/09/20(月) 22:46:19なるほど、そう言うことが言いたかったのか。
>差分プログラミングを、「要求の変化に対し、過去のコードを拡張することで対応する」
>という考え方だとするなら、それは契約プログラミングとは必ずしも一致しないし、
>むしろ相反する場合の方が多いのではないか、というのが俺の意見。
俺の意見は、差分プログラミングは基本包含になるから継承しても事前/事後条件は守られる。
俺の浅いEiffelの知識でも大丈夫だったと思うが。
ただ機能削除や別機能なら言う通りだと思う。
0363デフォルトの名無しさん
2010/09/20(月) 23:05:34肝心の、「オブジェクトがメソッドを持つべきかどうか」に関しては何も考えない、というか、それが当たり前と思ってるのな。
OOPのグダグダは全部そこから始まってるといっても過言ではないのに。
そこ無視して小手先のフォローに走る。OOPらしいっちゃらしいが。
0364デフォルトの名無しさん
2010/09/20(月) 23:33:15やるなら多態だけにして、あとはできるだけ合成しろって事でしょ。
0365デフォルトの名無しさん
2010/09/20(月) 23:37:10少しはこのスレの住人を説得してみろよ
0366デフォルトの名無しさん
2010/09/21(火) 00:39:54OOPだとモジュール構成の最小単位がオブジェクトで、
オブジェクト同士が協調しる手段としてメソッドがあるんたから、
オブジェクトはメソッドを持ってて当たり前だと思うけど。
「OOPはよろしくない」って話？
0367デフォルトの名無しさん
2010/09/21(火) 00:46:01多重ディスパッチのことを言ってるんじゃね
>>363
個人的には「オブジェクトがメソッドを持つべきか」は正直どうでもいいなあ
それが多重ディスパッチとかのことなのであればの話だが…
最低限多態さえ出来れば手段は何でもいいと思うよ
カプセル化や継承も、あったら便利だな程度の認識だわ俺は
■ このスレッドは過去ログ倉庫に格納されています