Quelqu'un peut-il fournir un exemple du Principe de Substitution de Liskov (LSP) à l'aide de Véhicules?
Le Principe de Substitution de Liskov indique qu'un sous-type doit être substituables pour ce type (sans altérer l'exactitude du programme).
- Quelqu'un peut-il donner un exemple de ce principe dans le domaine des véhicules (automobile)?
- Quelqu'un peut-il donner un exemple d'un violation de ce principe dans le domaine des véhicules?
J'ai lu sur le carré/rectangle, par exemple, mais je pense qu'un exemple avec des véhicules qui me donnera une meilleure compréhension de la notion.
Vous devez vous connecter pour publier un commentaire.
Pour moi, ce 1996 Devis de Oncle Bob (Robert Martin C) résume les LSP de mieux:
Ces derniers temps, comme une alternative à l'héritage des abstractions basées sur des sous-classement d'un (généralement abrégé) de la base/super classe, nous avons également souvent utiliser interfaces pour polymorphe de l'abstraction. Le LSP a des implications à la fois pour le consommateur, et la mise en œuvre de l'abstraction:
LSP Conformité
Voici un exemple d'utilisation d'une interface
IVehicle
qui peut avoir plusieurs implémentations (sinon, vous pouvez utiliser l'interface d'une classe de base abstraite avec plusieurs sous-classes - même effet).Cette mise en œuvre d'un consommateur de
IVehicle
reste dans les limites de la LSP:Violation flagrante - Runtime type de commutation
Voici un exemple d'une violation de LSP, à l'aide de RTTI et ensuite de Passer - Oncle Bob appelle cela une "flagrante violation":
La violation de la méthode va au-delà de l'contracté
IVehicle
de l'interface et des hacks un chemin d'accès spécifique pour un connu de la mise en œuvre de l'interface (ou une sous-classe, si l'utilisation de l'héritage au lieu d'interfaces). Oncle Bob explique également que LSP violations utilisant de type comportement de commutation généralement aussi violer la Ouvert et Fermé principe ainsi, depuis permanent de modification de la fonction sera nécessaire afin d'accueillir de nouvelles sous-classes.Violation de Pré - condition est renforcé par un sous-type
Une autre violation par exemple, un "condition préexistante est renforcé par un sous-type":
Ici, le Scooter sous-classe tente de Violer les LSP qu'il essaie de les renforcer (restreignent encore davantage) la condition sur la classe de base
Drive
méthode quimiles < 300
, à présent un maximum de moins de 50 miles. Ce n'est pas valide, puisque, de par la définition de contrat deVehicle
permet de 300 miles.De même, les Conditions ne peuvent pas être affaibli (c'est à dire détendue) par un sous-type.
(Les utilisateurs de Les Contrats De Code en C# notera que les préconditions et les postconditions DOIT être placé sur le interface via un
ContractClassFor
classe, et ne peut pas être placé à l'intérieur de la mise en œuvre des classes, afin d'éviter la violation)Subtile Violation de l'Abus d'une interface de mise en œuvre par une sous-classe
Un
more subtle
violation (également de l'Oncle Bob, la terminologie) peut être indiqué avec une douteuse dérivée de la classe qui implémente l'interface:Ici, indépendamment de la façon dont la mesure la
ToyCar
est entraîné, le carburant restant sera toujours zéro, ce qui peut être surprenant pour les utilisateurs de laIVehicle
de l'interface (c'est à dire infini MPG consommation - mouvement perpétuel?). Dans ce cas, le problème est que, malgréToyCar
avoir mis en œuvre toutes les exigences de l'interface,ToyCar
juste fondamentalement n'est pas un vraiIVehicle
et juste "tampons" de l'interface.Une façon de prévenir de vos interfaces ou des classes de base abstraites à partir d'une utilisation abusive de cette façon est d'assurer une bonne série de Tests Unitaires sont disponibles sur l'interface /classe de base abstraite pour vérifier que toutes les implémentations de répondre aux attentes (et toutes les hypothèses). Les tests unitaires sont aussi très documentation d'utilisation typique. par exemple, cette
NUnit Theory
rejetteraToyCar
de le faire dans votre code de production de base:Modifier, Re: OpenDoor
Ouverture des portes sonne comme une autre préoccupation entièrement, de sorte que doit être séparé en conséquence (c'est à dire la "S" et "Je" SOLIDE), par exemple
IVehicleWithDoors
, qui pourrait hériterIVehicle
IDoor
, puis des véhicules commeCar
etTruck
serait de mettre en œuvre les deuxIVehicle
etIDoor
interfaces, maisScooter
etMotorcycle
ne serait pas.ou même 3 interfaces,IVehicle
(Drive()
),IDoor
(Open()
) etIVehicleWithDoors
qui hérite à la fois de ces.Dans tous les cas, pour éviter toute violation des LSP, le code qui exige des objets de ces interfaces ne doivent pas abattu l'interface pour accéder à des fonctionnalités supplémentaires. Le code doit sélectionnez l'interface minimum /(super)de la classe dont il a besoin, et de se contenter de l'contracté des fonctionnalités de l'interface.
OpenDoors
. Mais de caoutchouc estampage méthodes est une indication claire de l'abus de la conception que nous essayons de faire quelque chose de "s'adapter" ou "conforme à" une interface qui n'est tout simplement pas applicable dans ce cas. @anotherdave donne un autre bon exemple d'approuver machinalement.Image que je veux louer une voiture quand je suis en cours de déménagement. Je l'anneau de la compagnie de location et de leur demander quels modèles ils ont. Ils me disent que je vais être compte tenu de la prochaine voiture qui vient disponibles:
Mais ils m'ont donné une brochure qui me dit que tous leurs modèles sont livrés avec ces caractéristiques:
Qui sonne tout ce que je cherche, donc je réserver une voiture & s'en aller heureux. Le jour du déménagement, une voiture de Formule un se montre à l'extérieur de ma maison:
Je ne suis pas heureux, parce que j'ai été essentiellement menti par leur brochure — il n'a pas d'importance si la voiture de Formule Un a une fausse botte de ressemble il peut contenir des bagages, mais ne s'ouvrent pas, c'est inutile pour le déménagement!
Si je me dit que "ce sont les choses de l'ensemble de nos voitures", puis toute la voiture que je suis doit se comporter de cette façon. Si je ne peux pas faire confiance les détails dans la brochure, c'est inutile. C'est l'essence même de la Principe de Substitution de Liskov.
NotSupportedException
et des exceptions semblables sont certainement une odeur de la rupture de la LSP.Car
ne serais pas aussi d'utiliser des instances de sa classe dérivée,FormulaOneCar
sans le savoir—, par conséquent, la violation LSPLe Principe de Substitution de Liskov états d'un objet avec une certaine interface peut être remplacé par un autre objet qui implémente cette interface tout en conservant l'exactitude du programme d'origine. Cela signifie que non seulement l'interface d'avoir exactement les mêmes types, mais le comportement doit rester correct ainsi.
Dans un véhicule, vous devriez être en mesure de remplacer une partie à une autre partie, et la voiture de continuer à travailler. Disons que votre vieille radio ne dispose pas d'un tuner numérique, mais que vous souhaitez écouter la radio HD afin de vous acheter une nouvelle radio qui a un récepteur HD. Vous devriez être en mesure de retirer le vieux de la radio et de brancher la nouvelle à la radio, tant qu'il a la même interface. Sur la surface, cela signifie que la prise électrique qui relie la radio de la voiture doit être la même forme sur la nouvelle radio c'est sur la vieille radio. Si la voiture est prise est rectangulaire et a 15 broches, puis la nouvelle à la radio de la prise doit être de forme rectangulaire et ont 15 broches ainsi.
Mais il y a d'autres considérations, en plus de la mécanique ajustement: le comportement électrique sur la fiche doit être le même, aussi. Si la broche 1 du connecteur de la vieille radio est le +12V, puis la broche 1 du connecteur de la nouvelle radio a également à +12V. Si la broche 1 sur la nouvelle radio a été la "gauche de la sortie du haut-parleur" la broche, la radio en court-circuit, ou faire sauter un fusible. Que serait une violation claire de la LSP.
Vous pourriez aussi envisager une situation de décote: disons que votre cher radio meurt, et vous ne peut se permettre une radio AM. Il n'a pas de stéréo, mais il a le même connecteur que votre radio. Disons que la spec a la broche 3 en cours de haut-parleur de gauche, et la broche 4 le droit d'être enceinte. Si votre radio AM joue le signal monophonique deux broches 3 et 4, on pourrait dire que son comportement est cohérent, et qui serait acceptable de substitution. Mais si votre nouvelle radio AM joue audio uniquement sur la broche 3, et rien sur la broche 4, le son serait déséquilibré, et qui probablement ne serait pas acceptable de substitution. Cette situation pourrait également constituer une violation de la LSP, parce que même si vous pouvez entendre des sons, et pas de fusible saute, la radio n'est pas de répondre à la spécification complète de l'interface.
Tout d'abord, vous avez besoin de définir ce qu'est un véhicule automobile et sont. Selon Google (pas très définitions complètes):
Véhicule:
une chose utilisé pour le transport de personnes ou de marchandises, esp. sur la terre, comme une voiture, un camion, ou un chariot.
Automobile:
d'un véhicule routier, avec généralement quatre roues, propulsé par un moteur à combustion interne ou électrique
moteur et capable de transporter un petit nombre de personnes
Si une automobile est un véhicule, mais un véhicule n'est pas une automobile.
À mon avis, pour obtenir le LSP, sous-types peuvent ne jamais ajouter de nouvelles méthodes publiques. Juste privé de méthodes et de champs. Et bien sûr sous-types peuvent remplacer les méthodes de la baseclass. Si un sous-type a une seule méthode publique qui le basetype n'ont pas, vous simplement ne peut pas remplacer le sous-type avec le basetype. Si vous passez un exemple de méthode qui vous permet de recevoir un sous-type de l'instance, mais le paramètre type est le basetype ou si vous avez une collection de type basetype où subytpes font partie, alors comment pouvez-vous appeler la méthode de la sous-type de la classe sans avoir à le demander du type à l'aide d'un si de tresorerie et si le type correspond à, faire un moulage de ce sous-type afin d'appeler la méthode.