鸭子模型_如果它看起来像鸭子，嘎嘎像鸭子，但需要电池-您的抽象错误

鸭子模型

因此，您知道一般的编码方式，了解面向对象的编程，学习过C ++并完成了至少一门软件开发课程（如果您还没有，那么这些文章不适合您）。如果您至少知道一种编程语言，则可以轻松编写软件，但是您的代码有好处吗？能做得更好吗？它干净吗（这到底意味着什么）？您的架构好吗？您应该使用其他架构吗？那设计模式呢？这些是我刚开始时遇到的一些问题，回答这些问题有助于我提高专业水平。这就是为什么我将这些系列SOLID编写为Rock设计原理的原因。大号 iskov公司的S ubstitution P rinciple在C ++中是第二次在这个系列，我将在这里讨论的原则。

您在本系列文章中看到的代码段是简化而不是复杂的。因此，您经常看到我不使用诸如override，final，public（同时继承）之类的关键字只是为了使代码紧凑且可消耗（大部分时间）是在单个标准屏幕尺寸内。我也更喜欢使用struct而不是class来保存行，因为有时不写“ public：”，并且还错过了虚拟析构函数，构造函数，复制构造函数，前缀std ::，故意删除了动态内存。我也认为自己是一个务实的人，他希望以最简单的方式而不是标准的方式或使用术语来传达想法。

注意：

如果您直接在这里偶然发现，那么我建议您经历一下什么是设计模式？首先，即使是微不足道的。我相信它将鼓励您探索有关此主题的更多信息。
在本系列文章中遇到的所有这些代码都是使用C ++ 20编译的（尽管在大多数情况下，我使用的是Modern C ++的功能，直到C ++ 17为止）。因此，如果您无权访问最新的编译器，则可以使用https://wandbox.org/ ，它也已预装了boost库。

意图

子类型必须可以替代其基本类型，而不会改变程序的正确性

如果我在C ++上下文中解决这个问题，那么字面意思是使用基类的指针/引用的函数必须能够被其派生类替代。
Liskov替代原则围绕确保正确使用继承。

违反李斯科夫的替代原则

一个说明LSP的伟大而传统的例子是，有时以自然语言听起来正确的东西有时在代码中不太起作用。
在数学中，正方形是矩形。实际上，它是矩形的一种特殊形式。 “ IS A”使您想使用继承对其进行建模。但是，如果在代码中让Square从Rectangle派生，则Square应该可以在您期望Rectangle的任何地方使用。这导致一些奇怪的行为，如下所示：

struct Rectangle {Rectangle( const uint32_t width, const uint32_t height) : m_width{width}, m_height{height} {}uint32_t get_width() const { return m_width; }uint32_t get_height() const { return m_height; }virtual void set_width ( const uint32_t width)  { this ->m_width = width; }virtual void set_height ( const uint32_t height)  { this ->m_height = height; }uint32_t area() const { return m_width * m_height; }protected :uint32_t m_width, m_height;
};struct Square : Rectangle {Square( uint32_t size) : Rectangle(size, size) {}void set_width ( const uint32_t width) override  { this ->m_width = m_height = width; }void set_height ( const uint32_t height) override  { this ->m_height = m_width = height; }
};void process (Rectangle &r)  {uint32_t w = r.get_width();r.set_height( 10 );assert((w * 10 ) == r.area()); // Fails for Square <--------------------
}int main ()  {Rectangle r{ 5 , 5 };process(r);Square s{ 5 };process(s);return EXIT_SUCCESS;
}

如上所示，我们在void process（Rectangle＆r）函数中违反了Liskovs的替代原理。因此Square不是Rectangle的有效替代品。
如果从设计角度来看，从Rectangle继承Square的想法不是一个好主意。因为Square没有高度和宽度，所以它具有边的大小/长度。

C ++中Liskov替代原理的示例

不太好

void process (Rectangle &r)  {uint32_t w = r.get_width();r.set_height( 10 );if ( dynamic_cast <Square *>(&r) != nullptr )assert((r.get_width() * r.get_width()) == r.area());elseassert((w * 10 ) == r.area());
}

经常表示违反LSP的常见代码气味是多态代码块中存在类型检查代码。
例如，如果您在Foo类型的对象集合上有一个std :: for_each循环，并且在此循环内检查是否Foo实际上是Bar（Foo的子类型），那么几乎可以肯定违反LSP。相反，您应该确保Bar在所有方面都可以代替Foo，而不必包括此类支票。

一种好的方法

void process (Rectangle &r)  {uint32_t w = r.get_width();r.set_height( 10 );if (r.is_square())assert((r.get_width() * r.get_width()) == r.area());elseassert((w * 10 ) == r.area());
}

无需为Square创建单独的类。相反，您可以简单地在Rectangle类中检查是否有bool标志来验证Square属性。虽然不是推荐的方式。

使用适当的继承层次结构

struct Shape {virtual uint32_t area () const  = 0 ;
};struct Rectangle : Shape {Rectangle( const uint32_t width, const uint32_t height) : m_width{width}, m_height{height} {}uint32_t get_width() const { return m_width; }uint32_t get_height() const { return m_height; }virtual void set_width ( const uint32_t width)  { this ->m_width = width; }virtual void set_height ( const uint32_t height)  { this ->m_height = height; }uint32_t area() const override { return m_width * m_height; }private :uint32_t m_width, m_height;
};struct Square : Shape {Square( uint32_t size) : m_size(size) {}void set_size ( const uint32_t size)  { this ->m_size = size; }uint32_t area() const override { return m_size * m_size; }private :uint32_t m_size;
};void process (Shape &s)  {// Use polymorphic behaviour only i.e. area()
}

具有工厂模式

仍然需要创建或更改来处理Shape，然后应尝试使用Virtual Constructor和Virtual Copy Constructor，即Factory Pattern 。

struct ShapeFactory {static Shape CreateRectangle ( uint32_t width, uint32_t height) ;static Shape CreateSquare ( uint32_t size) ;
};

里斯科夫替代原则的好处

=>相容性

它实现了多个发行版和补丁之间的二进制兼容性。换句话说，它使客户端代码不受影响。

=>类型安全

这是通过继承处理类型安全的最简单方法，因为在继承时不允许类型发生变化。

=>可维护性

遵守LSP的代码之间相互依赖，并鼓励代码可重用。
遵循LSP的代码是进行正确抽象的代码。

用C ++制作Liskov替代原理友好软件的标尺

在大多数面向对象编程的介绍中，继承都以与继承对象的“ IS-A”关系进行讨论。但是，这是必要的，但还不够。如果将一个对象与继承的对象始终保持“ IS-SUBSTITUTABLE-FOR”的关系，则可以更恰当地说。
使用抽象基类的全部目的是，以便将来可以编写一个新的子类并将其插入现有的，有效的，经过测试的代码中。一个崇高的目标，但如何实现呢？首先，首先分解问题空间-域。其次，用简明的英语表达您的合同/界面/ 虚拟方法。

结束语

不要误会我的意思，我喜欢SOLID及其提倡的方法。但这是
只是深层原则的基础。上面的例子清楚地说明了这个原则在努力进行哪些工作，即松散的耦合和确保正确的继承 。

现在，到那里去，使您的子类可以互换，并感谢Barbara Liskov博士的有用原则。

/！\：最初发布于 www.vishalchovatiya.com 。

如果您还没有阅读我以前有关设计原则的文章，那么下面是快速链接：

SRP-单一责任原则
OCP-开放/封闭原则
LSP-Liskov替代原理
ISP-接口隔离原理
DIP-依赖倒置原则

翻译自: https://hackernoon.com/if-it-looks-like-a-duck-quacks-like-a-duck-but-needs-batteries-you-have-the-wrong-abstraction-1akm32ln

鸭子模型