歩いたら休め

なんでこんな模様をしているのですか？

【プログラミング】リスコフの置換原則についてのメモ

プログラミング

会社のコードレビューで、同僚のコードが少しクラス設計が微妙だった（委譲で十分なのに継承でわかりづらくしていた）ことを指摘したことがあります。「こういう場合は委譲ではなく継承を使うべき」という指針として「リスコフの置換原則」や「is-a関係」を説明したかったのですが、

ja.wikipedia.org

T 型のオブジェクト x {\displaystyle x} x に関して真となる属性を q ( x ) {\displaystyle q(x)} q(x) とする。このとき S {\displaystyle S} S が T {\displaystyle T} T の派生型であれば、 S {\displaystyle S} S 型のオブジェクト y {\displaystyle y} y について q ( y ) {\displaystyle q(y)} q(y) が真となる。

いろいろな記事を説明してもこんな説明ばかりだったのでうまく説明できませんでした😅

また、いくつかの記事で気になる記述を見つけたので、今後調べる際のためにメモしておきます。「実装の継承」と「インターフェイスの継承（おそらくRustのtraitやHaskellの型クラスのような話だと思いますが）」などもワードも調べてみます。

togetter.com

何か間違ってたらコメントなどください。

「inheritance is not subtyping」問題

tech.nikkeibp.co.jp

　この現象は，is_equal_toのようなバイナリメソッド（自分と同じ型のオブジェクトを引数として受け取るメソッド）が原因で，いわゆる「inheritance is not subtyping」問題として広く知られている（http://portal.acm.org/citation.cfm?id=96721&dl=ACM&coll=portal）。このような問題があるので，「インタフェースの継承は必要だが，実装の継承は有害である」という議論すらあるぐらいだ。

　より正確には，「（実装の）継承とis-a関係を混同してはいけない」というべきだろう。「inheritance is not subtyping」問題からもわかるように，継承したからといって必ずしもis-a関係が成り立つとは限らないからだ。逆に，先のprintableの例からもわかるように，継承しなければis-a関係が成立しない，というわけでもない。

この記事をPythonで読み替えた説明の記事がありました。

uid0130.blogspot.com

実は友人とSlackで会話した時、以下のようなやり取りがあったのですが、実際にOCamlだと構造的部分型の機能でこれをカバーしてるそうです。

彼: 禁止しなくても守れそうだけどな。isEqualToの実装次第じゃない？

私: 親クラスで isEqualTo が実装されていた場合、 子クラス.isEqualTo(親クラス) でオーバーライドして実装するときにややこしそう

彼: isEqualTo の中身次第じゃない？ 「あるアトリビュートが同じだったら同じ」というメソッドだったら問題ないと思う。

Python記事からの引用

面白いのは, 継承しなくても, is-aの関係が成立してしまうケースが存在することで, 次のFruitとOarngeクラスの例が考えられます.

厳密な意味(?)でis-a関係が成立しているわけではないですが, equalsによる比較ができてしまい, 一種の部分型(is-a関係)のような振る舞いが可能になります. OCamlなどでは, この辺を型推論により自動的に型付けしてくれるようで, このような型を構造的部分型(structual subtyping)と呼ぶようです(前述のITProの記事より).

少なくとも、「equalsのように自分自身の型の引数をもつメソッドを継承する際、is-a関係（subtypingの関係）が壊れてエラーが出る場合がある」ということは正しそうです。

「実装の継承」と「インタフェースの継承」について

一般に，実装の継承と（is-a関係が成立するという意味での）インタフェースの継承は異なることに気を付けたい。

このあたり、Haskellの型クラスやRustのtrait（他言語の類似機能）と絡めた話が読んでみたいです。

Pythonの世界に落とし込めば、「通常の継承は禁止して、abcモジュールを使ったMixInのみ許可するほうがいい」と主張できそうな気もします。

www.buildinsider.net