1. 前言
抽象是我们常用的思维过程。一系列事物通过大脑的提炼，归纳和综合，让我们可以从无序中找出有序，从一个个具体的问题中找出通用的解决方法。编程中的抽象是从面相对象的程序设计，后文称为OOP，开始才有了比较完善的语言支持。如今软件复杂程度越来越高，OOP一直都是解决复杂软件设计的重要方法。使用OOP可以屏蔽各个任务具体的细节，抽象出一个简化而统一的流程，从而降低复杂软件开发的难度。这是一个建模的过程，也是OOP能够成功解决问题的原因。但是OOP的抽象能力是有限的，OOP的滥用反而会使复杂度无控制地上升。鄙文会浅讨OOP抽象适用的场景，并会阐述为什么作者觉得everyting is object是一个错误的设计。这个系列的文章后面还会探讨另外一种抽象能力更强大的范式，泛型编程GP。鄙文不是引战OOP与GP孰优孰劣，而是以抽象为线索，浅讨如何编写出能应付更加复杂程序的方法。
2. 传统OOP中的抽象
OOP有一个经典的案例。鱼会游泳，鸟会飞行，而它们都是动物。于是用OOP就很自然的有了下面的代码：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
class animal { public: virtual char const* species() = 0; }; class bird : public animal { public: char const* species() override { return "bird"; } virtual void fly() { std::cout << "bird::fly" << std::endl; } }; class fish : public animal { public: char const* species() override { return "fish"; } virtual void swim() { std::cout << "fish::swim" << std::endl; } }; |
许多文章和书籍对OOP都是这样教的。从animal继承以扩展新的动物类，如哺乳类。从bird或fish继承，以扩展出具体的物种。当然还有许多文章也拿这个例子作为OOP的反面教材。因为当我们要实现飞鱼的时候，飞鱼既可以游泳，也可以飞行，这个继承结构无所适从。那么究竟是哪里出了问题？
熟悉OOP的人会说，这里违反了里氏里氏替换原则（LSP）。飞鱼属于鱼类，但是我们抽象的鱼类无法满足要求。那我们给鱼增加一个fly接口：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
class fish : public animal { public: char const* species() override { return "fish"; } virtual void swim() { std::cout << "fish::swim" << std::endl; } virtual void fly() { std::cout << "I can`t fly" << std::endl; } }; class flying_fish : public fish { public: void fly() override { std::cout << "flying_fish::fly" << std::endl; } }; |
这能解决飞鱼这一个情况，但现实中好像还有更多复杂的情况。例如天鹅属于鸟类，但是它既会走路，也会飞行，当然也会游泳。这个时候我们又不得不扩充鸟类的接口。问题似乎变复杂了，绝大部分的鱼并不会飞行，但是为了兼容飞鱼我们为鱼类添加了fly接口。其实，真正的问题在于，我们为了实现一个可以游泳的动物，根据有限的经验抽象出了鱼类，并把这个动物归为鱼类。这种抽象的方式的代价，就是给实现类与抽象类之间，增加了一个is_a的关系，这个关系是一个很强的依赖关系。
对于我们举的这个例子而言，这种错误很容易发现，这是得益于动物这个话题是人们所熟知的。但是现实的问题往往都是未充分了解的，所以我们的抽象会很容易地违反LSP。其次，仅仅使用接口的异同类对事物进行抽象和归属，似乎并不是一个很好的主意。于是OOP有了改良，对行为的抽象看起来要更合理一些。
3. 接口编程与行为抽象
来到了接口编程，我们不再为类别进行抽象了，而是抽象行为。例如，上面的例子，我们不再为动物区分哺乳类，鸟类和鱼类等，也不会为鱼类实现飞鱼或者鲈鱼等其他具体的物种。简单起见，假设动物的行为有飞行，行走和游泳，于是我们抽象出了这三个接口。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
class flyable { public: virtual void fly() = 0; }; class walkable { public: virtual void walk() = 0; }; class swimmable { public: virtual void swim() = 0; }; |
飞鱼既可以飞行也可以游泳，我们只要实现这两个行为，飞鱼的问题就很好地解决了：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
class flying_fish : public flyable , public swimmable { public: void fly() override { std::cout << "flying_fish::fly" << std::endl; } void swim() override { std::cout << "flying_fish::swim" << std::endl; } }; |
如果语言不支持多重继承，可以使用组合的方式实现。目前的设计好像能应付所有的动物，甚至能推广得更远。例如，实现飞机也很容易:
|
1 2 3 4 5 6 |
class plane : public flyable { public: void fly() override { std::cout << "plane::fly" << std::endl; } }; |
现在我们要实现一个功能，让我们实现的飞鱼先飞行再游泳。在OOP中，对象的具体语义是不可知的，例如我们访问飞鱼的fly接口是通过flyable接口对象，对于swim同样是从swimmable对象访问，而我们并不知道flyable和swimmable是否是从飞鱼而来的。OOP在这里会带来运行期的额外开销。呃，这里好像碰到了点什么问题。我们如何保证flyable和swimmable两个接口对象，都来自于同一个飞鱼对象？
在我们继续往下解决这个问题之前，让我们在回想一下，为什么要抽象。抽象是为了屏蔽每个任务具体的细节，提炼出一个统一的处理流程。也就是说，统一的处理流程是我们抽象的目标。而现在的这个先飞行再游泳的功能，无法在我们现有抽象的模型中表达。问题已经很清楚了，是我们的抽象出了问题。这就是OOP在设计的时候一定要避免的误区，我们的抽象是为了得到统一的处理流程，而不是为了适应更广泛复杂的真实世界的模型而过度抽象，遵守KISS很重要。
对于这个例子，如果我们的需求只是希望在程序中，统一控制实体先飞行再游泳，应该这样抽象
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
class fly_then_swim_behavior { public: virtual void fly_then_swim() = 0; }; class flying_fish : public fly_then_swim_behavior { public: // ... void fly_then_swim() override { std::cout << "flying_fish::fly, interval..., swim." << std::endl; } }; class swam : public fly_then_swim_behavior { public: // ... void fly_then_swim() override { std::cout << "swam::fly, landing..., swim." << std::endl; } }; |
如果我们的需求是想统一控制实体的fly和swin行为，并能够灵活地组合这些行为，可以这样抽象：
|
1 2 3 4 5 6 7 8 9 10 11 |
class flyable_and_swimmable { public: virtual void fly() = 0; virtual void swim() = 0; }; class flying_fish : public flyable_and_swimmable { public: void fly() override { // .... } void swim() override { // ... } }; |
OOP的抽象的程度应该到此为止，如果问题更复杂可以适当使用设计模式解决，当然设计模式不是鄙文探讨的范围。坚守KISS原则是一件很难的事情。Everything is object，这个极具诱惑和理想主义的咒语，一直在不停地将我们拉入深渊。是的，一直有一条路通往那里。
4. 深渊，从这里开始
下面的设计，不应该归于OOP的范畴了。因为它们为了试图用统一的方法解决一切问题，而且都违背了KISS最基本的教义。首先，如果我们想要继续坚持之前的设计，又希望问题能够得到解决，本着接口统一的原则，我们可以像COM一样，提供一个接口查询的机制：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
using interface_base = void*; class object_base { public: virtual void query_interface(uuid_t id, interface_base*& i) = 0; }; class flyable { public: uuid_t id; virtual void fly() = 0; }; class swimmable { uuid_t id; virtual void swim() = 0; }; class flying_fish : public object_base , public flyable , public swimmable { public: // ... omitted codes here void query_interface(uuid_t id, object_base*& i) override { if(id == flyable::id){ i = static_cast<flyable*>(this); } else if(id == swimmable::id) { i = static_cast<swimmable*>(this); } else { i = nullptr; } } }; void fly_then_swim(object_base* obj) { interface_base fly, swim; obj->query_interface(flyable::id, fly); obj->query_interface(swimmable::id, swim); if(fly && swim) { reinterpret_cast<flyable*>(fly)->fly(); reinterpret_cast<swimmable*>(swim)->swim(); } } |
还有一个解决方案，就是使用发送消息：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
class object_base { public: virtual void send_message(uuid_t msg, void* data) = 0; virtual bool message_processible(uuid_t msg) = 0; }; class flying_fish : public object_base { public: // omitted codes void send_message(uuid_t msg, void*) override { if(msg == fly_msg) std::cout << "flying_fish::fly" << std::endl; else if(msg == swim_msg) std::cout << "flying_fish::swim" << std::endl; } bool message_processible(uuid_t msg) override { return msg == fly_msg || msg == swim_msg; } }; void fly_then_swim(object_base* obj) { if(obj->message_processible(fly_msg) && obj->message_processible(swim_msg)) { obj->send_message(fly_msg, nullptr); obj->send_message(swim_msg, nullptr); } } |
以上两个方法很类似，就放在一起讨论。两个方法都引入了一个共同的公共基类，object_base. 对！Everything is object就从这里开始了。第一种方法提供了一个统一的接口查询机制，而后者提供了一个统一的发送消息机制。两者都需要全局唯一的ID来区分不同的接口或者消息。接口查询的方式会带来接口对象不安全强转，而发送消息会招致不安全的数据转换。就目前而言所引入的公共基类和全局ID的负载，还有不安全的代码都不是很严重的问题。例如后者，可以在对象语义完整的时候，创建代理来绑定操作，从而抵消不安全的代码。最严重的问题是，OOP在这里已经荡然无存了。没有了接口的约束，之前抽象的模型也毫无意义了，这于过程式编程毫无差别。如此抽象的结果，却是写出了等同之前毫无抽象的代码，这种设计难道不是一个悖论吗？
深渊也是有底部的，我们继续把查询接口与查询消息推广，其实就是现代语言都提供的反射。反射是一种内省机制，可以让我们查询对象的成员方法和成员数据。当然，与其这样使用反射，何不去使用一门动态语言？
5. 小结
OOP使用的接口抽象的方法，本质上是围绕接口进行的归类方法。这种方法可以做到统一调度流程，屏蔽具体的细节，但同时也许多代价：
1. 围绕接口进行抽象，只利用了语法约束，但丢弃了语义；
2. 归类引入了很强的is_a的依赖关系，而程序中的归类结果通常与现实中经验相差甚远；
3. 对于静态类型，有很明确的编译期的语言，OOP把负担都扔给了运行期；
OOP有着适中的抽象能力，用来对现实问题的简化模型进行抽象，而everything is object是OOP的滥用。
下一篇，我们将讨论静态强类型语言所擅长的泛型编程。GP具有比OOP强大许多的抽象能力，它比OOP更适合于抽象复杂的模型。我们会以最大公约数算法为线索，讨论GP在C++编程语言中的实践方法。
