每当我阅读有关继承的内容时，总是会对某个示例感到困惑。
通常会有类似下面的示例：
class Shape
{
public:
Shape() {}
virtual ~Shape () {}
virtual void Draw() = 0;
};
class Cube : public Shape
{
public:
Cube(){}
~Cube(){}
virtual void Draw();
};
Shape* newCube = new Cube();
newCube->Draw();
我的问题是为什么由Shape自己负责绘制？难道不应该由渲染器类知道如何绘制形状并将形状提供给渲染器来处理吗？如果我们想要记录尺寸变化怎么办？等等。我们会在Shape内部为每个不同的任务都编写一个方法吗？
看到这样的例子时，有时让我怀疑我是否能够正确地分配类的职责。我是否没有理解类只有一项职责的含义？
Draw()作为基类的方法取决于上下文——即要解决的具体问题。为了让问题更加清晰，这里提供另一个例子，我经常用来测试面向对象技能。document.print(Printer &p);
printer.print(Document &d);
Print()既不应该属于文档对象，也不应该属于打印机对象，因为多态行为可能需要从打印机和文档的组合中得到。在这种情况下，您需要双重分派。假设你希望以通用的、多态的方式绘制图形，请考虑如何实现。形状将被绘制在什么上面？形状会知道画布如何工作吗？它应该知道它需要拿起画笔，蘸一些颜料然后绘制自己吗？它应该知道显示驱动程序如何工作吗？设置位以打开像素的正确位置，以便您的显示器显示正确的形状？
显然，深入到这个级别给了形状太多的责任，所以你定义一组图形基元（例如：点和线），并构建一个可以渲染这些基元的图形 API。然后，一个“形状”可以使用这些基元告诉 API 绘制什么。图形 API 不知道它正在绘制一个正方形，但通过告诉它绘制四条线，嘿，它就绘制了一个正方形。所有这些都使“形状”只有一个责任，即知道它的点和定义它的线。
当你孤立地学习某些设计模式时，很难看到其好处，因为构建软件是关于让事物一起工作；没有什么东西是孤立存在的。
shape可以做很多不同的事情，只要这些行为确实符合对象的全局职责，即：“描述Shape可以执行的所有任务”。 - Mik378Shape已经改变为不同尺寸的历史记录。我认为这不是Shape的责任来记录和跟踪这些更改...注入一个日志记录器并调用Shape->log(logger)是否正确？ - Tek形状不应该知道它如何被绘制。设计的项目越大，这个决定就越关键。
对我来说，这归结于循环依赖，在除了最边缘的情况下，只会带来麻烦。
模型-视图-控制器的基本原则是，你所做的事情（动词或“视图”）与被操作或分析的东西（名词或“控制器”）明确分离：表现层与逻辑层分离，“模型”扮演中间人角色。
这也是单一职责原则：“每个类都应该有一个单一职责，且该职责应完全封装在该类中。”
原因在于：循环依赖意味着任何更改都会影响所有内容。
单一职责原则的另一个摘录（缩短版）：“一个类或模块应该有一个且仅有一个变化的原因。单一职责原则认为，问题的实质和表面方面是两个不同的责任，因此应该在不同的类或模块中处理。将因为不同原因在不同时间而发生变化的两件事耦合在一起是一种糟糕的设计。”（重点是我的）
最后，关注点分离的概念：“目标是设计系统，使得函数可以独立于其他函数进行优化，从而一个函数的失败不会导致其他函数失败，并且通常使得理解、设计和管理复杂的相互依赖的系统更加容易。”（重点是我的）
Shape中。虽然非常依赖于正在设计的项目的类型和大小，但渲染可以通过一个RenderingUtils类完成，该类仅包含执行大部分工作的公共静态函数。Renderable接口作为模型层。 Shape实现Renderable，因此不知道或不关心如何绘制。而进行绘制的任何内容都不需要了解Shape。Shape，并且还允许您呈现与Shape截然不同的东西，而无需更改绘图代码。只有对象才真正知道如何绘制自己。
想象一下锁匠...他可以打开1000种不同类型的锁。我可以去商店，买任何一把锁交给他，他都能打开，因为他熟悉锁技术。
现在想象一下我是一个发明家，开始制造自己设计独特、革命性的锁。他能够打开它们吗？也许可以，但也许不行...这取决于我在锁内部做了什么，我是否使用他/她所知道的技术等等。
你的形状对象也是如此，取决于它们在内部的实现方式，决定了它们是否可以被某些通用的渲染引擎呈现。如果你要求每个对象自己绘制，则无需担心这个问题。
纯虚函数用于当算法的行为对于一组集合并不明确定义，但算法的存在对于一组集合是明确定义的。
我希望这不会太难理解，但也许从函数分析的课程中可以得到启示。我偏离了虚函数的集合论含义。
让集族A具有属性{x：P（x）}
让A是家族的一个元素
让A'也是家族的一个元素
A和A'可能属于以下三个类别之一。
（1）A和A'是等价的
对于A的所有a元素，a是A'的元素
并且对于~A的所有b元素，b是~A'的元素
（2）A和A'相交
存在A的元素a，其中a是A'的元素
还存在A的元素b，其中b是~A'的元素
(3) A和A'是不相交的
不存在一个元素a属于A且也属于A'
其中~X指的是所有不属于集合X的x
在情况（1）中，我们将定义一个非抽象行为，当且仅当U是家族A的元素时，存在一个单一值u，使得对于所有作为家族A元素的U，u = P(U)
在情况（2）中，如果U是家族A的元素，则定义虚拟行为意味着存在一个单一值u，使得u = P(U')，其中U'是U的子集。
而在情况（3）中，我们将定义纯虚拟行为，因为A和A'只是相似的成员，它们都是家族A的成员，A和A'的交集为空集，这意味着A和A'没有任何共同的元素
考虑语法在逻辑定义方面的含义，您就能回答以下问题：
（1）这个函数需要是抽象的吗？（对于情况1，不需要；对于情况2和3，需要） （2）这个函数需要是纯虚函数吗？（对于情况1和2，不需要；对于情况3，需要）
在情况2中，还取决于行为所需的信息存储在基类还是派生类中。
你不能从DISPLAY中呈现SHAPE，而不让DISPLAY寻找并非SHAPE定义的必要信息。由于DISPLAY无法看到从SHAPE派生的类型的定义，除了为SHAPE定义的内容之外。因此，任何依赖于包含在派生类型中的信息的功能都必须在派生类中为抽象函数定义。
Document应该有一个打印函数。文档只是某个东西而已，它没有任何操作。打印机是一种接受数字文档并以不同形式输出（纸张，PDF）的机器。为什么要改变这个类比呢？Printer接口可以抽象出所有差异（点阵，激光，操作系统版本等）。 - aliteralmind