在设计游戏时，出现了一个问题。假设有一个接口IUnit，它由所有描述单元的类实现。但是对于这些类，一些代码可能是相同的，因此，您要么必须复制代码，这与函数的目的相矛盾，要么添加默认行为。
我决定这样做：接口仍然存在，但添加了一个抽象类，该类UnitBase实现了某些方法的默认行为，并且描述单元的类要么显式实现接口，如果它们根本不相似UnitBase，或者继承UnitBase以避免代码重复。
然而，有一种观点认为继承破坏了封装，因此抽象类的继承是不好的，我的方法也不好。这是真的吗？这种架构如何与 OOP 的规范相对应？
建议的方法是相当合理的。消除重复的愿望是值得称赞的，应该得到鼓励。
总的来说，如果默认行为
UnitBase可能不适用于某些单位，那么名称可能不应该是UnitBase，而是更具体，例如，GroundUnit等AirUnit。一般来说，由于 C++ 中没有真正的接口（如在 Java 或 C# 中），根据上一段的含义，
IUnit和的分离原则上是没有必要的。UnitBase在一个类中至少有一个纯虚函数来禁止它的实例化而不实现显式的后继者就足够了。奇怪的意见，很高兴知道你在哪里听到的。封装是隐藏数据并通过公共函数提供对它的访问，将这些数据结合到一个框架（类）中。如果隐藏实现正确，公共函数的使用不违反类的不变量，并且类的公共继承遵循“派生类的对象是基类的对象”的原则，那么可以没有封装违规。
另一件事是继承使架构更加僵化，如果一个类被指定为另一个类的继承者，这种关系就不能再动态地改变了。因此，您经常可以听到用聚合代替继承的建议。那些。向类添加一个类型字段，
IBase*并且已经可以在运行时更改此指针，提供不同的行为，具体取决于特定的实例化类。