放送大学のプログラミングの授業とリスコフ置換原則

タイトルの「リスコフ置換原則」以外にも色々あったみたいですが、とりあえずその話が多めだったのでこういうタイトルにしておきました。 tweetは自由に、追加、削除してください
26
S (ツイートはスレッド全体をご確認ください) @esumii

itpro.nikkeibp.co.jp/article/COLUMN… 「inheritance is not subtyping」「継承とis-a関係を混同してはいけない」(便乗ステマ)

2015-02-02 14:21:24
athos)))))))) @athos0220

@__obake @haruyama 横から失礼します。講義では、点→円→楕円という継承関係を扱っていましたが、これは継承の設計原則であるリスコフの置換原則に反するものになっています。たとえばこの場合、円クラスで定義される半径を返すメソッドは楕円クラスでは何を返すべきでしょうか?

2015-02-02 14:52:03
mzp @mzp

あの件、大学生たるもの授業で教えられることがすべて正しいと信じてはいかん、とか言われたら、まあそうだよなぁ、という気がしないでもない。

2015-02-02 16:38:20
S (ツイートはスレッド全体をご確認ください) @esumii

もう一回言いますけど便乗ステマとか冗談抜きに「inheritance is not subtyping」「継承とis-a関係を混同してはいけない」itpro.nikkeibp.co.jp/article/COLUMN… で、それはオブジェクト指向(の継承)自体の本質的難点です!

2015-02-02 18:45:30
S (ツイートはスレッド全体をご確認ください) @esumii

@esumii 正確には「クラスベースのオブジェクト指向の、実装の継承」の難点

2015-02-02 18:51:53
mzp @mzp

放送大学からは「意見ありがとう。講師に伝えますね」とのことです。

2015-02-02 19:34:11
S (ツイートはスレッド全体をご確認ください) @esumii

何となく風の息づかいを感じるので念のため、継承でリスコフの置換原則を守ろうとしたら、少なくともisEqualToみたくselftypeを引数とするメソッドは禁止するしかないので、「継承でリスコフの置換原則」はそもそも制限つきでしか成り立たないです

2015-02-02 19:46:17
mzp @mzp

LSPの話を持ち出すとそもそも入門としてどうなんだみたいな話になりそうだったので、Rubyに対する説明としてあきらかに間違ってる箇所の指摘と、動作だけ説明して利点を説明しないのは講義としてよくないと思うという意見だけです > 送ったメールの内容

2015-02-02 20:07:54
kmizu @kmizu

Liskovの置換原則が話題のようなので、つ web.cse.ohio-state.edu/~neelam/course… いや、置換原則とか一言で説明されるけどもっと面白い話なんだよと言いたいのでこの論文ことあるごとに話題に出す

2015-02-02 20:56:24
kmizu @kmizu

@esumii Objectを頂点とする型システムじゃなくて、class Equality[A]{ def eq(x: A, y: A): Boolean } StringEquality extends Equality[String] { def .... } みたいな感じ

2015-02-02 21:04:38
kmizu @kmizu

@esumii で(たとえば)equalityを定義する言語だったら、制限付きでも結構実用になったりしないでしょうか?

2015-02-02 21:05:35
kmizu @kmizu

@esumii あ、実装継承限定の話だったのですね。すいません。

2015-02-02 21:06:56
S (ツイートはスレッド全体をご確認ください) @esumii

@kmizu あ、はい、適当に省略しちゃっててすみません。そういうインターフェースの継承っぽいのがHaskellの型クラスだと思います(たぶん)

2015-02-02 21:45:55
kmizu @kmizu

@esumii はい。自分の場合は、それをより陽に表現したScalaのimplicit parameterを意識して書きましたがw

2015-02-02 22:21:11
S (ツイートはスレッド全体をご確認ください) @esumii

.@kmizu 実装の継承の例で楕円が円のサブクラスになってて議論が。円-楕円問題とか名前がついてるぐらい微妙な問題なので紛糾しています:-)

2015-02-02 22:24:36
トデス子'\ @todesking

何の必要があって円クラスと楕円クラスを定義するのか考えれば自ずと答えはわかるし要求なしに設計だけあってもどうしようもねーべ派です

2015-02-02 23:00:07
kmizu @kmizu

ところで、リスコフの置換原則は、*当然*、メソッドの事前条件、事後条件、クラス不変条件(+α(ややこしいので省く))が明らかになってないと満たしてるかどうか確かめられないので、まずその辺考えませう。

2015-02-02 23:15:11
HARUYAMA Seigo @haruyama

放送大学長 知識の問題はもちろんありますが, 授業用のテキストを書いてまともな人に査読してもらわなかった(ないしもらえなかった)のがやばいですね.

2015-02-03 09:22:08
athos)))))))) @athos0220

@__obake @haruyama その場合、半径を返すメソッドを使って円の面積を求める処理を書くと、楕円に対しては誤った結果が返るようになると思いますが、どうでしょう?

2015-02-03 10:13:16
トデス子'\ @todesking

楕円クラスと言ったところで意味が一意に定まるわけでなし、どのようなインタフェースなのかを明示すべきである。横に伸ばす操作が可能だったら真円クラスのスーパークラスにはなれないし、最長部の半径を返すメソッドしかないなら継承可能

2015-02-03 13:35:45
トデス子'\ @todesking

クラスを定義するということは意味を決めるということなんだ、意味を大切にしろ

2015-02-03 13:36:38
岡部洋一 @__obake

確かに違反しますね。この件、ちょっと勉強させていただきます。 @athos0220 @__obake @haruyama その場合、半径を返すメソッドを使って円の面積を求める処理を書くと、楕円に対しては誤った結果が返るようになると思いますが、どうでしょう? #放送大学

2015-02-03 13:42:13
トデス子'\ @todesking

設計問題、まず動機を述べろよで全部片付く。意味もなく円と楕円クラスを定義したいだけなら勝手に定義しとけばいいであろう。

2015-02-03 13:50:28
ygn @ygnygnygn

@__obake @athos0220 @haruyama いわゆる,Ellipse-Circle Dilemmaというやつですね.この場合,overrideすればOK.

2015-02-03 15:04:37