Le principe de substitution de Liskov est-il incompatible avec l'introspection ou le typage de canard?

Dois-je bien comprendre que le principe de substitution de Liskov ne peut pas être observé dans des langues où les objets peuvent s’inspecter eux-mêmes, comme ce qui est habituel dans les langues de type canard?

Par exemple, dans Ruby, si une classe Bhérite d'une classe A, alors pour chaque objet xde A, x.classva revenir A, mais si xest un objet de B, x.classne va pas revenir A.

Voici une déclaration de LSP:

Que q (x) soit une propriété démontrable sur les objets x de type T . Ensuite , q (y) doit être prouvable pour les objets y de type S , où S est un sous - type de T .

Ainsi, en Ruby, par exemple,

class T; end
class S < T; end

violer LSP sous cette forme, comme en témoigne la propriété q (x) =x.class.name == 'T'

Une addition. Si la réponse est "oui" (LSP incompatible avec l'introspection), alors mon autre question serait: existe-t-il une forme modifiée "faible" de LSP qui peut éventuellement tenir pour un langage dynamique, éventuellement sous certaines conditions supplémentaires et avec seulement des types spéciaux des propriétés .

Mettre à jour. Pour référence, voici une autre formulation de LSP que j'ai trouvée sur le web:

Les fonctions qui utilisent des pointeurs ou des références à des classes de base doivent pouvoir utiliser des objets de classes dérivées sans le savoir.

Et un autre:

Si S est un sous-type déclaré de T, les objets de type S devraient se comporter comme les objets de type T devraient se comporter, s'ils sont traités comme des objets de type T.

Le dernier est annoté avec:

Notez que le LSP concerne le comportement attendu des objets. On ne peut suivre le LSP que si l'on sait clairement quel est le comportement attendu des objets.

Cela semble plus faible que l'original et pourrait être possible à observer, mais j'aimerais le voir officialisé, en particulier expliqué qui décide du comportement attendu.

Le LSP n'est-il donc pas une propriété d'une paire de classes dans un langage de programmation, mais d'une paire de classes avec un ensemble donné de propriétés, satisfaites par la classe ancêtre? Concrètement, cela signifierait-il que pour construire une sous-classe (classe descendante) respectant LSP, toutes les utilisations possibles de la classe ancêtre doivent être connues? Selon LSP, la classe ancêtre est censée être remplaçable par n'importe quelle classe descendante, non?

Mettre à jour. J'ai déjà accepté la réponse, mais je voudrais ajouter un autre exemple concret de Ruby pour illustrer la question. En Ruby, chaque classe est un module dans le sens où la Classclasse est un descendant de Moduleclasse. Pourtant:

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)

Voici le principe réel :

Soit q(x)une propriété prouvable sur les objets xde type T. Cela q(y)devrait alors être prouvable pour les objets yde type Soù Sest un sous-type de T.

Et l'excellent résumé de wikipedia :

Il indique que, dans un programme informatique, si S est un sous-type de T, les objets de type T peuvent être remplacés par des objets de type S (c'est-à-dire que les objets de type S peuvent être remplacés par des objets de type T) sans altérer les propriétés souhaitables de ce programme (exactitude, tâche effectuée, etc.).

Et quelques citations pertinentes du document:

Ce qu'il faut, c'est une exigence plus forte qui contraint le comportement des sous-types: les propriétés qui peuvent être prouvées en utilisant la spécification du type présumé d'un objet devraient tenir même si l'objet est en fait membre d'un sous-type de ce type ...

Une spécification de type comprend les informations suivantes:
- le nom du type;
- Une description de l'espace des valeurs du type;
- Pour chacune des méthodes du type:
--- Son nom;
--- Sa signature (y compris les exceptions signalées);
--- Son comportement en termes de pré-conditions et post-conditions.

Passons donc à la question:

Dois-je bien comprendre que le principe de substitution de Liskov ne peut pas être observé dans des langues où les objets peuvent s’inspecter eux-mêmes, comme ce qui est habituel dans les langues de type canard?

Non.

A.classrenvoie une classe.
B.classrenvoie une classe.

Étant donné que vous pouvez effectuer le même appel sur le type le plus spécifique et obtenir un résultat compatible, LSP est valide. Le problème est qu'avec les langages dynamiques, vous pouvez toujours appeler des choses sur le résultat en vous attendant à ce qu'elles soient là.

Mais considérons un langage typé structurellement (canard). Dans ce cas, A.classretournerait un type avec une contrainte qu'il doit être Aou un sous-type de A. Ceci fournit la garantie statique que tout sous - type de Adoit fournir une méthode T.classdont le résultat est un type qui satisfait cette contrainte.

Cela fournit une affirmation plus forte que LSP détient dans les langues qui prennent en charge la frappe de canard, et que toute violation de LSP dans quelque chose comme Ruby se produit davantage en raison d'une mauvaise utilisation dynamique normale que d'une incompatibilité de conception de langue.

Dans le contexte du LSP, une "propriété" est quelque chose qui peut être observé sur un type (ou un objet). Il s'agit en particulier d'une "propriété prouvable".

Une telle "propriété" pourrait exister une foo()méthode qui n'a pas de valeur de retour (et suit le contrat fixé dans sa documentation).

Assurez-vous de ne pas confondre ce terme avec "propriété" car dans " classest une propriété de chaque objet dans Ruby". Une telle "propriété" peut être une "propriété LSP", mais ce n'est pas automatiquement la même chose!

Maintenant, la réponse à vos questions dépend beaucoup de la rigueur avec laquelle vous définissez la «propriété». Si vous dites « la propriété de la classe Aest que .classrenverra le type de l'objet », alors Beffectivement fait avoir cette propriété.

Si, cependant, vous définissez la "propriété" comme " .classretours A", alors évidemment, elle Bn'a pas cette propriété.

Cependant, la deuxième définition n'est pas très utile, car vous avez essentiellement trouvé un moyen détourné de déclarer une constante.

Si je comprends bien, il n'y a rien sur l'introspection qui serait incompatible avec le LSP. Fondamentalement, tant qu'un objet prend en charge les mêmes méthodes qu'un autre, les deux doivent être interchangeables. Autrement dit, si votre code attend un Addressobjet, il n'a pas d' importance si elle est un CustomerAddressou une WarehouseAddress, tant que les deux fournissent (par exemple) getStreetAddress(), getCityName(), getRegion()et getPostalCode(). Vous pouvez certainement créer une sorte de décorateur qui prend un type d'objet différent et utilise l'introspection pour fournir les méthodes requises (par exemple, une DestinationAddressclasse qui prend un Shipmentobjet et présente l'adresse de livraison en tant que Address), mais ce n'est pas obligatoire et certainement pas 'empêche pas le LSP d'être appliqué.

Après avoir parcouru l'article original de Barbara Liskov, j'ai trouvé comment compléter la définition de Wikipedia afin que LSP puisse en effet être satisfait dans presque toutes les langues.

Tout d'abord, le mot "prouvable" est important dans la définition. Elle n'est pas expliquée dans l'article de Wikipédia, et les "contraintes" sont mentionnées ailleurs sans s'y référer.

Voici la première citation importante de l'article:

Ce qu'il faut, c'est une exigence plus forte qui contraint le comportement des sous-types: les propriétés qui peuvent être prouvées en utilisant la spécification du type présumé d'un objet devraient tenir même si l'objet est en fait membre d'un sous-type de ce type ...

Et voici le second, expliquant ce qu'est une spécification de type :

Une spécification de type comprend les informations suivantes:

• Le nom du type;
• Une description de l'espace des valeurs du type;
• Pour chacune des méthodes du type:
  • Son nom;
  • Sa signature (y compris les exceptions signalées);
  • Son comportement en termes de pré-conditions et post-conditions.

Ainsi, LSP n'a de sens que par rapport à des spécifications de type données , et pour une spécification de type appropriée (pour la vide par exemple), il peut être satisfait dans probablement n'importe quelle langue.

Je considère que la réponse de Telastyn est la plus proche de ce que je cherchais car les "contraintes" étaient explicitement mentionnées.

Pour citer l'article de Wikipedia sur LSP , «la substituabilité est un principe de la programmation orientée objet». C'est un principe et une partie de la conception de votre programme. Si vous écrivez du code qui en dépend x.class == A, c'est votre code qui viole le LSP. Notez que ce type de code cassé est également possible en Java, aucun type de canard n'est nécessaire.

Rien dans le typage canard ne brise intrinsèquement LSP. Seulement si vous en abusez, comme dans votre exemple.

Réflexion supplémentaire: la vérification explicite de la classe d'un objet ne contredit-elle pas le but de la saisie de canard, de toute façon?