[导入]唯一性与自洽性

http://xp.c2.com/OnceAndOnlyOnce.html
http://c2.com/cgi/wiki?DontRepeatYourself

     OAOO(Once And Only Once)是我们在软件开发中需要关注的基本原则之一. 唯一性当然是一个值得追求的目标. 从正交分解的角度上说，系统可以由少数的正交基通过组合构造出来。尤其在分析阶段，我们需要牢牢把握住系统内核的几个变化维度。但是这并不意味着我们最终能够做到每种可以想见的软件元素都是唯一的，也不意味着保持唯一性永远都是最好的。
     唯一性在软件中最直接的体现就是代码的重用(reuse), 除了实现起来节省了工作量之外，代码重用的另一个作用在于维护了系统中概念的唯一性，或者更广泛的说，它维护了系统中知识的唯一性。例如，如果我们经常用到圆周率Pi，我们可以选择在各处都直接写3.1415926, 也可以选择定义一个系统常数PI, 在使用的时候引用这个常数，保持关于PI值的知识的唯一性。其实只要各处的PI值是相同的，甚至只要是在误差范围内相互匹配的（例如有些地方用3.14, 有些地方用3.1415926)，程序就可以正确无误的运行，这样就达到了我们开发程序的目的，并不需要什么常数定义。只是为了保证这种知识的一致性，定义一个常数无疑是最简单直接的一种方法。从理论上说，我们实际需要的只是知识在软件中能够得到一致的表达，或者更加抽象一些，我们所需要的只是知识的自洽性，而唯一性无疑是维持自洽性的一种廉价方法。特别是在一个不断演化的系统中，保持形式上的唯一性可能是实现自洽性的唯一可行的方法。
     但是， 我们需要认识到知识的一致性与代码的唯一性并不是等同的,例如同样是释放资源的函数, 在不同的应用情形下我们可能将其命名为close, 也可能是destroy, 或者是dispose, 如果我们使用一个接口IDisposable.dispose(), 则引入了一种形式上的唯一性要求. 在使用reflection的情况下, 我们可以放松要求, 不要求对象实现特定的接口, 只要提供指定的函数名(例如dispose)即可. 我们也可以更加宽容, 通过外部描述性数据指定函数的用途, 只要求概念上的一致性, 例如spring中通过destroy-method属性指定对象资源释放函数. 没有语言级别的形式唯一性, 我们就无法依赖于编译器来维护其隐含的知识的一致性, 此时我们所能使用的通用方法就只有测试(test)了. 实际上, 很多知识上的自洽性要求都无法在程序中直接得到表达, 而只能通过一个构造的测试网络来进行验证.

     正如排他锁（exclusive lock)是实现transaction的一种强形式一样, 唯一性也是自洽性的一种强形式。在保持了唯一性的情况下，当然不可能出现冲突的情况，也就自然的维持了系统的自洽性。但是，很多时候概念的多样性也是我们不得不考虑的内容。在C语言中, memmove函数的功能包括memcpy的功能,到底要不要取消memcpy以避免无谓的错误可不是一件容易决定的事情. 在数学上，同一个定理可能存在着多种非平凡(non-trivial)的等价表述形式, 从表面上看,它们可以是完全不相关的,但是原理上是等价的. 而不同的表述往往适用于不同的应用情形. 同样的，在软件系统中，It is ok to have more than one representation of a piece of knowledge provided an effective mechanism for ensuring consistency between them is engaged. 在软件设计中, 引入中间层是在控制内在统一性的同时获得丰富的外在表现的一种重要方式. 在CORBA中idl编译器将idl文件翻译成不同程序语言的版本, 我们在程序中使用的是特定程序语言的版本而不是直接的idl接口文件, 这些版本之间的自洽性是通过idl编译器来保证的. idl编译器所做的只是一对一的翻译工作, 它本身并没有提供额外的知识, 而它所生成的各个程序语言版本所表达的知识也是相同的. 可以想见, 一种更加复杂的,甚至是具备一定推理能力的引擎(engine)可以基于元知识进行更加复杂的变换工作, 并可以融合其他外部的知识, 最终输出一系列自洽的表现结构.例如, 我们可以根据一个描述文件生成所有CRUD(Create Read Update Delete)操作的程序代码和界面代码. 这些生成的文件中可能存在着重复的代码,可能重复的表达了某个知识, 例如界面布局等, 但是它们之间通过引擎隐蔽的存在着稳固的联系