《程序设计与数据结构》——框架与重用

其内部关于该操作的实现（结构）。

接口在很大程度上可以认为是类的外部视图的设计者和类的内部实现的实现者之间的一种"契约"，同时也是需要（使用）该接口的类（如调用该接口所提供的操作）和提供该接口的类之间的一种约定。即将一个较大问题的不同功能通过子契约被分解为小问题，没有别的情况比在设计类时更能体现这种思想。一个单独的对象就是一个具体的实体，在系统中扮演某个角色。

将接口从实现中分离出来是通过抽象类来实现的，抽象类包含一个或多个没有提供任何具体实现的方法。Validator之所以是一个抽象类，因为无法对它实例化。比如：

这与契约有什么关系？首先，希望所有与视图对应的显示函数都使用相同的语法调用，比如，实现的每一种视图都包含一个名为validate的方法。其次，每个类都要对自己的动作负责，因此类不仅要提供相应的方法，还必须提供它自己的实现代码。比如：

由此可见，采用这种方式，就有了一个真正多态的Validator框架。系统中每个与视图对应的显示函数都可以调用validaate方法，而调用每个与视图对应的显示函数时都会得到不同的结果。实际上，向一个对象发送一个消息时，会根据对象的不同而产生不同的响应，这正是多态的根本所在。

>>>   4.5.3 建立契约

定义契约的规则是通过抽象类提供一个未实现的方法，当设计一个子类实现某个契约时，它必须为父类中未实现的方法提供实现，因为契约带来的好处可以标准化代码。如果开发人员不遵循契约设计类，那么使用类的所有人都必须查看文档。比如：

虽然这样做也能够实现范围值和奇偶校验功能，但不符合契约。因为面向对象的主要优势之一是可以重用类，重用的高层次的抽象接口比高度具体的接口更有用。

>>>   4.5.4 教条的危害

著名的语言专家王垠认为，"很多编程的人喜欢鼓吹各种各样的原则，并将那些所谓的原则奉为教条或者秘方。以为兢兢业业地遵循这些原则，空喊几句口号，就可以写出好的代码。同时对违反这些原则的人嗤之以鼻——你不知道，不遵循或藐视这些原则，那么你就是菜鸟。"因此不要盲目地迷信各种各样的原则，比如，DRY原则（Don’t Repeat Yourself，不要重复你自己）在实际的工程中带来了各种各样的问题，却经常被忽视。DRY原则说，如果你发现重复的代码，就提取它们为一个父类。 然而"避免重复"并不等于"抽象"，有时候适当的重复代码是有好处的。

代码的"抽象"和它的"可读性"，其实是相互矛盾的关系。适度的抽象和避免重复可以提高代码的可读性，如果你尽"一切可能"从代码里提取共性，甚至将一些微不足道的"共性"也提出"共享"，反而破坏了程序的可阅读性。如果盲目地将以下代码：

修改为：

当你看到TypeA和TypeB的定义时，再也不能一目了然地看到int a。其实完全没有必要提取这中无关紧要的共性，造出一个新的父类，因为可见性是程序员产生直觉的关键。奉行DRY原则的人存在的问题，在于是他们随时都在试图发现"将来可能重用"的代码，而不是等到真的出现重复的时候再去做抽象。

抽象思想的关键在于"发现两个东西是一样的"，然而很多时候，开始时觉得两个东西是一回事，最后发现它们其实只是肤浅的相似，而本质完全不同。同一个int a，其实可以表示很多种风马牛不及的性质。你看到都是int a就提出来为父类，反而让程序的概念变得混乱。有些东西开始时貌似同类，当添加了新的逻辑之后，发现它们的用途开始特殊化了。因此过早地提取共性，反而捆住了手脚，为了所谓的"一致性"，而重复一些没用的东西。这样的一致性，其实还不如针对每种情况分别做特殊处理。

防止过早抽象的方法其实很简单，它的名字叫做"等待"。其实就算你不重用代码，也不会影响程序的准确性和可读性，时间能够告诉你一切。如果你发现自己仿佛正在重复以前写过代码，请先不要停下来，坚持将这段重复的代码写完。如果你不将它写出来，你将无法准确地发现重复的代码，因为它们很有可能到最后其实是不一样的。

我们应该避免没有实际效果的抽象，如果代码才重复了两次，就开始提取共性，也许到最后会发现，这个模板总共也就只用了两次。只重复了两次的代码，大部分时候是不值得为它提取模板的。因为模板本身也是代码，而且抽象思考本身是需要一定代价的。所以最后总的开销，也许还不如就让那两段重复的代码待在里面。

而优秀的程序员等到事实证明重用一定会带来好处时，才会开始提取共性进行抽象。实践经验证明，每一次积极地寻找抽