Liskov Substitution Principleは、IntrospectionまたはDuck Typingと互換性がありませんか？

アヒル型言語で通常行われているように、オブジェクトを自分自身で検査できる言語では、リスコフ置換原理を遵守できないことを正しく理解できますか？

例えば、Rubyで、クラスの場合B、クラスから継承Aし、すべてのオブジェクトのためxのA、x.class返すために起こっているAが、場合xの目的はB、x.class返却するつもりはありませんA。

LSPの声明は次のとおりです。

ましょうQ（x）はオブジェクトに関するプロパティ証明可能であるxは型のT。次いで、Q（y）は、オブジェクトのために証明可能であるべきであるY型のS Sは、のサブタイプであるT。

たとえば、Rubyでは、

class T; end
class S < T; end

プロパティq（x） =で見られるように、この形式のLSPに違反していますx.class.name == 'T'

添加。答えが「はい」（イントロスペクションとLSPの互換性がない）の場合、私の他の質問は次のようになります。性質。

更新。参考のために、ウェブで見つけたLSPの別の定式化を以下に示します。

基本クラスへのポインターまたは参照を使用する関数は、知らないうちに派生クラスのオブジェクトを使用できる必要があります。

そしてもう一つ：

SがTの宣言されたサブタイプである場合、タイプSのオブジェクトは、タイプTのオブジェクトとして扱われる場合、タイプTのオブジェクトとして動作するはずです。

最後のものには次の注釈が付いています。

LSPはすべて、オブジェクトの予期される動作に関するものであることに注意してください。オブジェクトの予想される動作が明確である場合にのみ、LSPを追跡できます。

これは元のものよりも弱いようで、観察できるかもしれませんが、それが形式化されること、特に予想される動作を誰が決めるかを説明したいと思います。

LSPはプログラミング言語のクラスのペアのプロパティではなく、クラスのペアと特定のプロパティのセットのプロパティであり、祖先クラスによって満たされていますか？実際には、これは、LSPを尊重するサブクラス（子孫クラス）を構築するために、祖先クラスの考えられるすべての使用法を知っている必要があることを意味しますか？LSPによると、先祖クラスは任意の子孫クラスに置き換えられるはずですよね？

更新。 私はすでに答えを受け入れましたが、質問を説明するためにRubyからもう1つの具体例を追加したいと思います。Rubyでは、クラスはClassクラスの子孫であるという意味で、各クラスはモジュールですModule。しかしながら：

class C; end
C.is_a?(Module) # => true
C.class # => Class
Class.superclass # => Module

module M; end
M.class # => Module

o = Object.new

o.extend(M) # ok
o.extend(C) # => TypeError: wrong argument type Class (expected Module)

ここだ実際の原則は：

ましょうタイプのq(x)オブジェクトについて証明可能なプロパティになります。そして、オブジェクトのための証明可能であるべきタイプののサブタイプです。xTq(y)ySST

そして、素晴らしいウィキペディアの要約：

コンピュータープログラムでは、SがTのサブタイプである場合、タイプTのオブジェクトは、タイプSのオブジェクトに置き換えられます（つまり、タイプSのオブジェクトは、タイプTのオブジェクトに置き換えられます）。そのプログラムの望ましいプロパティ（正確性、実行されたタスクなど）。

そして、論文からのいくつかの関連する引用：

必要なのは、サブタイプの動作を制限する強力な要件です。オブジェクトが実際にそのタイプのサブタイプのメンバーである場合でも、オブジェクトの推定タイプの仕様を使用して証明できるプロパティは保持する必要があります...

タイプ仕様には、次の情報が含まれます。-
タイプの名前。
-タイプの値スペースの説明。
-タイプのメソッドごとに：
---その名前。
---その署名（通知された例外を含む）;
---事前条件と事後条件の観点からの動作。

質問に続きます：

アヒル型言語で通常行われているように、オブジェクトを自分自身で検査できる言語では、リスコフ置換原理を遵守できないことを正しく理解できますか？

番号。

A.classクラスを返します。
B.classクラスを返します。

より具体的なタイプで同じ呼び出しを行い、互換性のある結果を得ることができるため、LSPが保持されます。問題は、動的言語では、結果に基づいてそれらが存在することを期待できることです。

しかし、静的に構造化された（アヒル）型付き言語を考えてみましょう。この場合、A.class必要な制約Aまたはのサブタイプを持つ型を返しAます。これにより、サブタイプの任意のサブタイプが、その制約を満たすタイプの結果となるAメソッドT.classを提供する必要があるという静的な保証が提供されます。

これにより、ダックタイピングをサポートする言語でLSPが保持され、RubyのようなものでのLSP違反は、言語設計の非互換性よりも通常の動的な誤用によるものであるという強い主張が得られます。

LSPのコンテキストでは、「プロパティ」は型（またはオブジェクト）で観察できるものです。特に、「証明可能な財産」について語っています。

このような「プロパティ」には、foo()戻り値を持たないメソッドが存在する可能性があります（そしてドキュメントに設定されたコントラクトに従います）。

この用語を「プロパティ」と混同しないようにしてください。「プロパティ」は「classRubyのすべてのオブジェクトのプロパティ」です。このような「プロパティ」は「LSPプロパティ」になりますが、自動的に同じではありません！

さて、あなたの質問に対する答えは、「プロパティ」をどの程度厳格に定義するかに大きく依存します。あなたが言う場合は、「クラスのプロパティはAつまり.class、オブジェクトの種類を返します」、そしてB実際に行い、そのプロパティを持っています。

ただし、「property」を「.classreturns A」と定義した場合、明らかにそのプロパティBはありません。

ただし、2番目の定義はあまり有用ではありません。定数を宣言するためのラウンドアバウト方法を本質的に見つけたからです。

私が理解しているように、イントロスペクションについてLSPと互換性のないものはありません。基本的に、オブジェクトが別のメソッドと同じメソッドをサポートしている限り、この2つは交換可能である必要があります。それはあなたのコードが期待するならば、あるAddressオブジェクトを、それはだ場合、それは問題ではないCustomerAddressか、WarehouseAddress限り、両方が（例えば）を提供するよう、getStreetAddress()、getCityName()、getRegion()とgetPostalCode()。確かに、異なる種類のオブジェクトを受け取り、イントロスペクションを使用して必要なメソッド（オブジェクトDestinationAddressを受け取り、配送Shipment先住所をとして提示するクラスなど）を提供するある種のデコレータを作成できますAddressが、これは必須ではなく、確かにそうではありませんLSPの適用を妨げません。

Barbara Liskovの元の論文を調べた後、ほぼすべての言語でLSPを満足させるために、Wikipediaの定義を完成させる方法を見つけました。

まず第一に、「証明可能」という言葉は定義において重要です。ウィキペディアの記事では説明されておらず、「制約」はそれを参照せずに他の場所で言及されています。

論文の最初の重要な引用文は次のとおりです。

必要なのは、サブタイプの動作を制限する強力な要件です。オブジェクトが実際にそのタイプのサブタイプのメンバーである場合でも、オブジェクトの推定タイプの仕様を使用して証明できる プロパティは保持する必要があります...

次に、2番目のタイプ仕様について説明します。

型指定には、次の情報が含まれます。

• タイプの名前。
• タイプの値スペースの説明。
• タイプのメソッドごとに：
  • その名前;
  • その署名（通知された例外を含む）;
  • 前提条件および事後条件に関するその動作。

そのため、LSPは特定の型仕様に関してのみ意味を持ち、適切な型仕様（たとえば空の仕様）については、おそらくどの言語でも満たすことができます。

私が考えるTelastynの答えは、「制約」が明示的に言及されたので、私は探していたものに近いこと。

ウィキペディアのLSPに関する記事を引用すると、「代替性はオブジェクト指向プログラミングの原則です。」これは、プログラムの設計の原則および一部です。に依存するコードを記述する場合x.class == A、LSPに違反しているのはコードです。この種の壊れたコードはJavaでも可能であり、アヒルの入力は必要ありません。

カモタイピングで本質的にLSPを壊すものはありません。あなたの例のように、あなたがそれを誤用する場合のみ。

追加の考え：オブジェクトのクラスを明示的にチェックすることは、とにかくアヒルのタイピングの目的に反しないか