Month: October 2009

比如说，要判断本公司某员工是否为中国人，在系统中可以分别通过调用两种接口来获取结果：   a.护照上写的是中国人 => 此人是中国人   b.工作证上“国籍”一栏填了“中国” => 此人是中国人 这两个逻辑冗余了，因为它们可以解决同一个问题，在现实世界里，这是很现实的事；但在IT系统中，不应该让这两种逻辑同时存在。也就是说，要判断一个人是否为中国人，只能去查他的护照，不准通过其它途径来判断。 为什么要这样？ 因为如果不这样的话， 两条冗余规则中一旦改了一条，除了该规则自己的调用者受影响之外，另一条规则的调用者可能也会有问题。 比如说，如果上面的规则b改成 ［ 工作证上“国籍”一栏填了“中国” 或 "香港" =》 此人是中国人］，那么我们除了要改一下b接口 and/or 它的调用者，还要注意一下 规则a  and/or 它的调用者： 香港人的护照也是中国护照吗？ 是，则万事大吉；如果不是，那就要把a接口改一下，或者把a接口的调用者都改一下。

比如说， 人和兽都是动物，业务规则是：直立者即人，爬行者为兽。 那么 在“动物”表中， 除了要有 “行走方式” 这个字段，要不要再搞一个 “是人是兽” 字段？ 隐方：不必了。通过站立方式已经可以推导出是人是兽了， 再搞一个字段就是冗余了，众所周知，冗余有很多坏处。 显方：我觉得应该搞一个“是人是兽”的字段。先不说冗余的问题，先说搞一个这样的字段有哪些好处。    1. 最重要的一点，是可以帮助业务逻辑之间解耦，降低系统复杂度。  比如说，系统里判断一个动物能否说话时，先要判断这个动物是人还是兽，而要判断动物是人还是兽，要先判断它的行走方式是否为直立。 这样的话，“能否说话” 就依赖了 “是否直立行走”，如果这种依赖关系多了，这些关系就会在系统中形成一个网状结构，很复杂。而如果我们显式地搞一个 “是人是兽” 的 Mediator，网状结构就可以退化成星形结构，这样可以增强系统的可维护性。    2. 业务逻辑之间解耦后，还可以减少公司里业务专家的压力。很多程序员，尤其是新来的五谷不分的程序员，并不知道直立的就是人，趴着的就是兽。要了解这一点，他们就得去问业务专家，即老工程师或者产品经理，这个代价可大可小。他也可以去查文档，但按我们的现状，文档未必完整，而且篇幅巨大，查起来也非常费劲。 隐方：对你的第二点我很赞同，但关于第一点，我觉得还是设计技巧的问题。 你在业务层写一个接口用于判断“是人是兽”，不就可以了吗？而且这样还可以封装判断的细节，当判断规则改变时，接口的调用者可以不必改写代码。 显方：这么看来至少你赞成搞一个“显式”的接口了，只不过是放在业务层；这样既可以实现业务逻辑的解耦，又可以避免数据库中的冗余。 隐方：是啊，很完美吧？ 显方：但你的想法 需要一个大家定一个规矩：即所有人都必须通过个接口来进行人兽判断。这在代码不多、并且软件复用思想深入人心的小型团队里倒是很适用，因为这个规矩很容易执行；但在大型团队里，这个规矩很难执行；因为 很多人对业务层的重用并没有什么概念，他们会直接绕道去找数据库；而且 即使他们愿意重用业务接口，在项目紧张时也懒得去找相应的接口规格，因为他们根本不知道这个接口是否存在，也不知道应该去找谁问这个问题。 隐方：这是另外一个问题了，主要跟软件过程有关系，或者可以借鉴SOA实践中的一些思想，我们另开一个话题再聊吧。