Liskov替代设计原理适应

Question

假设我有一个抽象类鸟，它的一个函数是飞（int高度）。

我有许多不同的鸟类，每个类都有自己不同的飞的实现，这个函数在整个应用程序中被广泛使用。

有一天，我的老板来了，要求我添加一只鸭子，它做其他鸟类所做的一切，只是它不飞，而是在应用程序的池塘里游泳。

将duck添加为bird的子类型违反了Liskov替换规则，因为在调用duck时。我们要么抛出异常，要么什么也不做，要么违反正确性原则。

在牢记坚实的设计原则的同时，您将如何引入这一变化？

Answer 1

所以你的问题是

（1） 鸭子是一只鸟。

（2） 但它不能飞。

所以真正的问题是，

• 你已经实现了你的鸟类，假设"所有的鸟都会飞"。
• 但它真的不是。所以你要么之前没有想到角落的案例（比如鸭子），要么没有打算像鸭子一样上课。

解决方案：

因此，这里要采用的最简单和最明智的解决方案是为方法名使用通用名称，以便双方能够达成一致。因此，在这里您可以将方法Bird.fly（）重命名为Bird.move（）。

所以Duck.move（）和Crow.move（）都有意义，但它们有自己的方式。

所有其他可用的解决方案都将消除多态性（使用两个不同的基类）。这意味着您将无法通过一种方法同时调用Duck和Crow移动（分别是swime和fly）。（像鸟一样，移动）。

当你的应用程序建立在它之上时，你会花费很多，因为你必须通过显式或隐式类型转换来区分它们，这是非常糟糕的。这会浪费您的时间，使您的应用程序很难扩展和维护。：）

Answer 2

我看你有3个选择：

>

使用Bird作为公共功能的抽象基类，并从中派生FlyingBird和Aquatic Bird。

使用Zoran Horvat描述的对象组合和访问者模式：https://vimeo.com/195774910（在任何情况下，这都值得一看）-尽管如此，在手头的案例中，这似乎是一种过度的杀伤力。

使用您描述的解决方案。

最后，一切都是关于平衡的。如果你期待许多不同能力的鸟加入，那么你应该认真考虑选项2，否则取决于你如何使用这些类，在1和3之间选择。

根据Gilads关于选项2（对象组成）的评论进行更新

这里最主要的事情是，你可以有一个类鸟并将能力附加到它，例如飞行和游泳，也许以后你会决定你有其他能力或某种分类。您可以通过创建不同的接口（IFlyable，ISwimable）来实现这一点，并具有以下内容：

public class SomeFlyingBird : BirdBase, IFlyable 
{
 ....
}

public class Duck : BirdBase, ISwimmable
{
 ....
}

然后使用访问者模式访问具体的动作。

或者，如果你寻找更健壮和优雅的东西，你可以根据能力创建不同的类，并将它们附加到鸟类：

public class Bird/Animal
{
     string name;
     List<Ability> abilities = new List<Ability>();

     public Bird (string name)
     {
         this.name = name;
     }

     public void Add (Ability ability)
     { 
          this.abilities.Add(ability);
     }
}

您可以稍后使用一些静态类来创建鸟：

public static Bird CreateDuck ()
{
     var duck = new Bird("Donald");
     duck.Add(new SwimAbility());
     return duck;
}

能力和游泳能力可以如下所示：

public abstract class Ability
{
    public virtual void Accept(AbilityVisitor visitor) =>
        visitor.Visit(this);
}

public class SwimAbility : Ability
{
    public override void Accept(AbilityVisitor visitor)
    {
        base.Accept(visitor);
        visitor.Visit(this);
    }
}

我没有附上完整的代码，因为它不是我的，而且对于这个答案来说太长了。我再说一遍，对于你所描述的案件来说，这似乎是一种过度的杀伤力。

我强烈建议您观看Zoran Horvat的视频，并下载和播放他提供的代码：http://www.postsharp.net/blog/post/webinar-recording-object-composition

Answer 3

您发现的问题是由于模型的以下不兼容功能造成的。

1. 所有的鸟都会飞

您需要更改其中一个以使语句一致。更改哪一个将是一个最适合您使用的设计问题，以及进行更改所涉及的问题。

你可以通过引入分类来区分会飞的和不会飞的鸟来解决这个问题。也许为了使变化变小，你的鸟类继续飞行，所以鸭子不是鸟，而是不会飞的鸟。或者你可以扩展Bird来创建flyingbird类，并将fly方法移动到那里——两者都涉及到对现有代码的更改。

抛出异常有点像在第3点作弊——你的鸭子仍然没有真正飞起来，它只是把问题变成了运行时的问题，而不是设计时的问题。这可能很快，但这不是一个非常安全的方法，它需要调用代码，避免调用碰巧是鸭子的鸟上的苍蝇。

允许fly对ducks不做任何事情是否合适取决于您的调用代码通常期望fly做什么-实际上，您正在通过将第1点中fly的含义更改为“所有鸟类都可以被要求飞（尽管有些不会飞）”来修复不一致性。在这种情况下，fly真的变成了Flyifoucan，这可能是设计不完美的迹象，但可能是务实的解决方案——特别是在修改现有设计时。

事实上，您建议的“不做任何事情”选项可能表明了一条最不受影响的路线，因为如果您让fly对鸭子不做任何事情，那么您仍然需要一些鸭子特定的代码来让它游动，因此您可以接受在实际世界中鸭子可以飞，并且让鸭子特定的代码调用swim而不是fly-不如fly。

更一般地说，我认为您实际描述的是第1点的变化，从“所有的鸟都能飞”到“所有的鸟都能移动”，然后非鸭子实现像苍蝇一样移动，鸭子实现像游泳一样移动（无论它们是否也有飞的方法）。这可能涉及将一些现有呼叫更改为“飞”到“移动”呼叫。