Existe-t-il un nom spécifique pour le paradoxe «Carré hérite du rectangle»?

Un certain échec de la POO est montré avec une classe Square héritant de Rectangle, où Square est logiquement une spécialisation de Rectangle et devrait donc en hériter, mais tout s'effondre lorsque vous essayez de modifier la longueur ou la largeur d'un carré.

Existe-t-il un terme spécifique pour décrire ce qui ne va pas dans ce cas?

object-oriented inheritance liskov-substitution

— Victor
source

pourriez-vous expliquer ce qui "va mal" exactement? Je ne comprends pas ce que tu veux dire

— moucher

En supposant qu'un rectangle possède une méthode virtuelle qui permet de définir la taille en passant la longueur et la largeur, définir une longueur et une largeur différentes sur un carré pourrait renvoyer un rectangle et définir une même longueur et largeur sur un rectangle pourrait retourner un carré. Tout code qui a besoin de connaître explicitement carré peut tenter de transtyper en carré. Je ne vois pas comment il y a un échec ...

Ce n'est pas un paradoxe. Il s'agit d'un cas de modélisation incorrecte du domaine problématique. La hiérarchie d'héritage ne va PAS nécessairement s'aligner sur la hiérarchie des choses dans le domaine problématique. C'est bien quand c'est le cas, mais l'astuce dans un bon modèle est de comprendre où vous devez faire les choses différemment du monde réel.

— Michael Kohne

FWIW: Plus précisément, le problème est que les interfaces de lecture et d'écriture ne correspondent pas. C'est-à-dire que vous pouvez lire un cercle comme une spécialisation d'une ellipse, mais seulement écrire une ellipse comme une spécialisation d'un cercle.

— Macke

@GrandmasterB Je me réfère à "toute personne, chose ou situation présentant une nature apparemment contradictoire." La contradiction est que si le carré a des propriétés différentes, nous devons dire "un carré n'est pas une sorte de rectangle", alors que nous nous attendons à ce que le carré soit un sous-type de rectangle. Aucune application réelle n'aurait probablement de types Rectangle et Carré, c'est juste une abstraction pour illustrer un certain type de problème qui peut apparaître dans les paradigmes basés sur les classes.

— Victor

Réponses:

Wikipedia se réfère simplement à lui comme le problème Circle-ellipse

Le problème de cercle-ellipse dans le développement de logiciels (parfois connu sous le nom de problème de rectangle carré ) illustre un certain nombre d'embûches qui peuvent survenir lors de l'utilisation du polymorphisme de sous-type dans la modélisation d'objets. Les problèmes sont le plus souvent rencontrés lors de l'utilisation de la programmation orientée objet.

Il s'agit du L dans l'acronyme SOLID qui est connu comme le principe de substitution de Liskov . Ce problème se pose comme une violation de ce principe.

Le problème concerne la relation de sous-typage ou d'héritage qui devrait exister entre les classes qui représentent des cercles et des ellipses (ou, de la même manière, des carrés et des rectangles). Plus généralement, le problème illustre les difficultés qui peuvent survenir lorsqu'une classe de base contient des méthodes qui mutent un objet d'une manière qui pourrait invalider un invariant (plus fort) trouvé dans une classe dérivée, provoquant la violation du principe de substitution de Liskov ...

— Mark Canlas
source

Et, en le lisant, Wikipedia mentionne l'explication la plus académique comme "[violation du] principe de substitution de Liskov". Merci :)

— Victor

Eh bien, ce n'est qu'une violation selon la façon dont vous le voyez. Personnellement, tous les cercles sont des ellipses; il n'y a pas de violation. Il commence à y avoir une violation si les méthodes d'ellipse deviennent trop restrictives. Ensuite, dans ce scénario particulier, un cercle ne peut pas être un sous-type de ce contrat particulier d'ellipse.

— Mark Canlas

@MarkCanlas Le problème est incontestablement une violation du principe de substitution de Liskov. Ce n'est peut-être pas une violation d'autres principes, mais personne ne l'a affirmé. Lorsque le problème ne se produit pas parce que les contrats n'incluent aucun invariant qui serait rompu (bien que je n'imagine pas un modèle utile où cela est vrai), il peut ne pas y avoir de violation du LSP, mais cela ne signifie pas que le problème , quand il se produit, n'est pas dû à une violation LSP.

@Mark Canlas: non, le cercle constant est une ellipse constante , le cercle mutable n'est pas une ellipse mutable. En géométrie, la constance est supposée, vous ne pouvez pas changer une ellipse, vous pouvez prendre une autre ellipse

— maxim1000

La contrainte / règle d'histoire du principe de substitution de Liskov dit que lorsqu'un sous-type ajoute de nouvelles méthodes, ces méthodes ne sont pas autorisées à manipuler l'état de l'objet de telle manière qu'il crée une histoire (c'est-à-dire une série d'états) qui n'est pas autorisé dans le supertype. Par exemple, vous ne pouvez pas créer un sous-type d'un mutable immuable, car lorsqu'il est uniquement manipulé via des méthodes du supertype, l'état est toujours le même, tandis que lorsqu'il est manipulé via les méthodes de mutation du sous-type, l'état change. C'est une histoire qui n'est pas autorisée par le supertype.

— Jörg W Mittag

Je considérerais cela comme une violation du principe de substitution de Liskov - la Squaresous - classe viole spécifiquement l'invariant selon lequel la longueur et la largeur sont indépendantes.

— Paul Phillips
source

À un niveau plus fondamental que le principe de substitution de Liskov, il s'agit d'une erreur de catégorie ou d'une erreur de catégorie

Dans le contexte de la modélisation du comportement, un carré n'est tout simplement pas un type de rectangle.

Lorsque vous réalisez cela, le problème disparaît car l'hypothèse initiale (un carré est un type de rectangle) est supprimée du jeu.

Le problème avec cette réponse est que depuis l'école, il est percé dans toute personne faisant de la géométrie qu'un carré est un type de rectangle. Mais il est très important de comprendre que cela n'est vrai que dans un contexte très spécifique (la classification des formes géométriques en fonction des propriétés de leurs angles internes). En termes de comportement, un carré n'est pas un rectangle. Voir un ensemble de classification dans le mauvais contexte est une erreur de catégorie.

— Cormac Mulhall
source