リスコフ置換原則への取り組み（続々、Birthday改めBirthdate問題、もしくは、僕たちはフインキで型安全している）
-
Tanaka9230
- 7169
- 16
- 0
- 0
-
- いいね！0
すえなみ
@a_suenami
SOLIDのうち、僕が重要視してるのはSとIでそれ以外は状況によるね？と考えていて、要はバランスパーソンっぷりをいかんなく発揮している
2019-09-10 15:13:53
qsona
@qsona
リスコフの置換原則は、その重要度はともかく100%守られたほうがいいと思ってたけど、どうなのかなぁ。そもそもあんまり継承しないから感覚が twitter.com/a_suenami/stat…
2019-09-10 15:23:21
takasek
@takasek
@qsona Uncle Bobが「クラス継承だけでなく、今は適用範囲が広がり、インタフェースと実装に関する原則」みたいなこと言ってました。サブタイピングはクラスでなくとも発生しますし、そこでリスコフの置換原則を守らないことは処理の安全性を毀損するのは同じですね
2019-09-10 18:52:28
天重誠二
@tenjuu99
ruby の refinement 使えばDCIのRoleをインジェクトするようなコードを書けるのだけど、リスコフ置換原則に違反してしまう。 mikepackdev.com/blog_posts/35-…
2019-09-11 03:29:39
たなかこういち
@Tanaka9230
BirthdateというVOの是非問題（※"-date"とする）： みなさまの課題感を整理。 (1)BirthdateにgetAgeを持たせること (2)意味的に`Birthdate extends Date`と特化型となること (3)モデル的に例えば`被保険者.誕生日`などの属性のはずで、それを型にすること (4)Java言語による実装において実施すること
2019-09-11 22:15:08
たなかこういち
@Tanaka9230
以降はこれらについての「私見」です。 (1)について： これはモデル的に依存関係的にアウト、でFA。 `Age::ctor(Birthdate)`ならOK。
2019-09-11 22:15:08
たなかこういち
@Tanaka9230
(2)について： 別に悪くない。 しかしカジュアルに特化型を作るとLSP違反が気になる。 →実は、それこそドメインが存在することの表れ（久保さんより） →実はimmutable前提なら特化型でLSP違反は起こり得ないのでは？（田中の考え）
2019-09-11 22:15:09
たなかこういち
@Tanaka9230
(3)について： まず、モチベーションとしては確かにここでは型というより特定の属性を表したいのだ、という点はたしかにYes。 それを（実装に用いるプログラミング言語の）型で表すことの是非については、、
2019-09-11 22:15:09
たなかこういち
@Tanaka9230
、、 a)プログラミング言語自体のOO的な意味論を大切にするなら、良くない感じがする立場 b)プログラミング言語の型をあくまでツールとして利用するとしたら、それもありとする立場 たなかは(b)の立場をとる。
2019-09-11 22:15:10
Atsuhiro Kubo
@iteman
@Tanaka9230 私のツイートは、ドメインが存在することの現れではなく、ドメイン（さらにいえば存在＝オブジェクト）の創造のチャンス、なので活用せよ、という意味合いでした。 twitter.com/iteman/status/…
2019-09-11 22:36:02
Atsuhiro Kubo
@iteman
負の可変性の現れは、新たなドメイン（さらにいえば存在）の創造のチャンスなんだと思います。 github.com/phpmentors-jp/… twitter.com/tenjuu99/statu…
2019-09-10 01:24:34
天重誠二
@tenjuu99
コンストラクタで誕生日の値の範囲を制限するだけなら、リスコフ置換原則には違反しない。仮に値の範囲を制限するためだとしたら「なぜ値の範囲を制限したいのか」という疑問があるのだけど、たぶんこの時点ですでにアプリケーションの要件が入ってしまっている。
2019-09-12 01:40:14
たなかこういち
@Tanaka9230
@tenjuu99 ここでLSP気になるのはmutatorメソッドが生えてる場合に限られる、immutable前提に出来るなら問題にならない仮説、 どう思います？
2019-09-12 08:58:02
たなかこういち
@Tanaka9230
CSの理論的には怪しいこと言ってるかもですが、、現場的に型安全欲しいのはきっと本質的にはstructural subtyping。nominal-はおまけ。namespaceスコーピングで文脈だかドメインだかを容易に表せるならnominal-のは無くてもよい。
2019-09-12 09:17:16
たなかこういち
@Tanaka9230
LSPはnominal subtypingでの話。ほんとは別にnominal subtypingしたい訳じゃないので、現場的に型安全言ってる文脈ではLSP違反は気にならない。structural subtyping出来ないから流用してるだけ。
2019-09-12 09:17:17
たなかこういち
@Tanaka9230
ちな、たなかの理解では、Duck typingとstructural subtypingは多分ほとんど同じもので前者は動的型付け界隈での言葉、後者は静的型付け界隈での言葉。
2019-09-12 09:17:18
たなかこういち
@Tanaka9230
・・・みたいなことをかつてまとめた。 tanakakoichi9230.hatenablog.com/entry/72673426…
2019-09-12 09:40:20
天重誠二
@tenjuu99
@Tanaka9230 immutable前提といえるかどうかは kmizu さんのこちらの一連のツイートで「別名付け」と呼ばれている箇所がたいへん勉強になりました。 twitter.com/kmizu/status/8…
2019-09-12 10:13:14
kmizu
@kmizu
ところで、Liskovの想定する、というか一般的なサブタイプありのシステムで取り扱わなければいけない話として、オブジェクトの別名付けを考慮に入れなければいけない。これは皆知ってる話だと思うので、ざっくり言うと、別の名前で同じオブジェクトを操作できるということ。
2017-05-26 23:13:29
たなかこういち
@Tanaka9230
@tenjuu99 まさに。 たなかの仮説は、継承ツリーにmutatorメソッドをもつMutableなのが一切登場しないならLSP違反ケース出現し得ないのでは？というのは、悪く無さそうに見受けました。
2019-09-12 10:38:48
天重誠二
@tenjuu99
@Tanaka9230 > 継承ツリーにmutatorメソッドをもつMutableなのが一切登場しない これってプログラマーを規約で縛る以外ないのではないでしょうか？もしそうならすでにリスコフの想定する型安全の議論から離れているような気がします。
2019-09-12 10:49:12
takasek
@takasek
@Tanaka9230 @tenjuu99 dates = [日付(), 誕生日()]; birthday = dates[1]; if (birthday is 誕生日) { ... } else { ... }; LSP違反が問題になるのは型自身ではなく、それを使う側がOCPを守れなくなることなのですよね
2019-09-12 11:01:21