在坏的设计中，数据往往是分散的，甚至是杂乱的，这就好像一群失去意识的猛兽，我们无法控制、协调以及管理它们。这种漫无头绪的散乱数据，犹如猛兽的肆意妄为，会给系统带来无尽的灾难。随着系统的演化，这种灾难会逐渐蔓延至系统的各个角落。因此，在面向对象设计过程中，对数据分类是识别对象的一个前提。但是，仅仅封装了数据的对象，如果没有操作数据的行为，仍旧是没有意识的死亡对象。 我始终认为，对象在拥有自己数据的情况下，应该是自治的。这种“自治”类似于SOA中服务自治的概念，但由于对象应该保持足够合理的细粒度，因此这种自治是有限度的自治；或者说它体现的是专家的自治。如果对象拥有足够的数据信息，就必须树立这些信息的权威，这些信息的处理就应该由对象自己来完成。如果它拥有的信息量不够，或者根本不具备，则可以委派给其他对象。此时，行为即对象的意识，是对象能够自治的前提。 对象自治依赖于面向对象设计的一个重要原则，即对象的数据与行为应该封装在一起。Craig Larman提出的“信息专家模式”正是说明了这一点，该模式认为拥有信息的对象才是处理这些信息的专家。 对象自治是一个很有趣的概念，我们把对象拟人化，使得对象成为组成社区的基本元素。在这个社区里，每个对象的行动都应该由自己来控制。无论是完成某个操作，还是发出请求，或者响应事件，对象都应该有自己的判断。判断的合理性来自于它掌握的信息量，以及我们赋予它的意识的灵性。在构建软件系统时，我们的目标就是要搭建这样一个由自治对象组成的社区，而不是无序的混沌世界。每当我们在操作数据时，发现数据开始具有发散、混乱、模糊、蔓延等特征时，就是封装数据的信号。不管这些数据的数量，还是大小，它都应该作为对象存在于系统，同时该对象应具备操作该数据的能力。 例如在报表系统中，我们试图将构建好的报表整体导出为Excel文件。我们为导出功能定义了专门的接口ExcelTableExporter，它接收一个报表对象和工作薄对象，导出报表到Excel文件中： public interface ExcelTableExporter {
public void export(ReportTable table, WritableWorkbook workbook);
}
这一接口的定义并无不妥之处。然而，当我们在实现export()接口方法时，事情开始变得难以控制。我们需要在export()方法中遍历整个报表，获得报表的行头、列头以及数据单元格，然后计算它们的坐标，获得它们的格式，再写入到Excel单元格中。显然，ExcelTableExporter要做的事情太多了，而它所要处理的报表数据也开始变得发散而混乱。虽然我们对报表进行了合理的分解与封装，但坐标依旧是散乱的，格式也没有和报表对象封装在一起。组成报表的元素对象仅仅拥有展现的数据值，却不知道自己该放在哪个位置，又该以什么面貌展现。换言之，这些组成报表的对象都不具备充分的自主意识，使得操作它们的ExcelTableExporter心力憔悴。它需要观察每个报表元素对象的数据，元素之间的依赖关系，考虑如何计算它们的坐标，获得符合客户要求的格式。如果我们将这种展现和导出报表的功能看做是将报表数据绘制在Excel画布上，那么ExcelTableExporter就好似一位不太高明的画师，奔忙于全局的掌控与细节的刻画，却因为能力不够而无法二者兼顾。如果我们让这些组成报表的元素对象拥有绘制自身的能力，境况是否焕然一新呢？此时，ExcelTableExporter只需要取出元素对象，放在Excel画布上，它们自己就知道该往哪儿去，该怎么绘制，根本不用ExcelTableExporter来操心。
根据单一职责原则（SRP），报表元素对象与报表直接相关，本身不应该承担绘制的责任，但放在导出报表这个场景来看，却又是合乎情理的。而且，与绘制相关的数据本身就与报表数据直接相关，例如报表元素的坐标，就依赖于报表数据的个数，以决定它占用的行数和列数。报表的格式同样设置在报表元数据中。不过，从抽象的角度来看，我们应该为其定义不同的接口，这也符合接口隔离原则（ISP）。同时，我们还需要考虑绘制行为的扩展。例如，在未来我们可能需要考虑将报表绘制为HTML网页。因此，我们可以定义一个绘制元素的接口：
public interface DrawingElement {
public void draw(ReportCanvas canvas);
public object getElement();
}
draw()方法负责将报表元素绘制到ReportCanvas对象中。ReportCanvas体现了“画布”的隐喻，作为载体用来添加绘制出来的报表元素。
public interface ReportCanvas {
public void addElement(DrawingElement element);
}
对于Excel而言，实现draw()方法就是在内部创建单元格对象。如果使用开源项目jxl来完成excel文件的生成，则该单元格对象可以是Label对象，也可以是jxl.write.Number对象。不过，ReportCanvas是不关心这些的，它只需要能够添加DrawingElement即可。这里就体现出了抽象DrawingElement的好处。当报表元素对象在实现该接口时，如果是针对Excel的导出，就可以把诸如Label和Number这样的单元格对象封装到实现类中。例如报表中的行头对象就可以实现DrawingElement接口：
public class RowHeaderExcelElement implements DrawingElment{
private object cell;
@Override
public void draw(ReportCanvas canvas) {
canvas.addElement(this);
}
@Override
public object getElement() {
if (isNumber()) {
cell = createNumberCell();
} else {
cell = createLabelCell();
}
return cell;
}
}
倘若将来需要支持Html，可以定义RowHeaderHtmlElement类实现DrawingElement接口。如果二者之间存在一些共同逻辑，则可以提取一个共同的基类RowHeaderElementBase。
因为引入了DrawingElement接口，报表元素对象就将绘制元素对象的数据与行为都封装了起来，使其成为了自治的对象。由于报表元素对象自身具备绘制功能，使得ExcelTableExporter的工作变得轻松自如，只需发出绘制的请求即可：
for (DrawingElement element : table.getReportUnits()) {
element.draw(canvas);
}
在实现上，我们还有一个问题需要解决。ExcelTableExporter的export()方法实现使用了jxl，DrawingElement类封装的Label或Number对象事实上需要绘制到jxl的WritableSheet中，而不是我们自己抽象的ReportCanvas。为了保证DrawingElment接口的抽象性，以及未来的可扩展性，draw()方法的输入参数必须是与实现无关的抽象类型。如果修改方法的定义为接受WritableSheet对象，就会限定为jxl，无法轻易变更，这是绝对不可取的。它违背了“供应商绑定”的反模式。
由于WritableSheet对象与ReportCanvas之间没有任何关系，强制的类型转换也无法保证将WritableSheet对象传递给DrawingElement对象的draw()方法。除非我们修改WritableSheet的定义，使其实现ReportCanvas接口。但这是不可能的，因为WritableSheet是第三方提供的公开接口，我们不能修改。这时，就需要考虑二者之间的适配。通过运用Adapter模式，我们可以引入一个间接对象WritableSheetAdapter，让其实现ReportCanvas接口，同时重用WritableSheet提供的职责。在jxl中，WritableSheet被定义为接口，通过WritableWorkbook创建。所以，我们可以考虑将WritableWorkbook创建的对象传递给WritableSheetAdapter：
public class WritableSheetAdapter implements ReportCanvas {
private WritableSheet sheet;
public WritableSheetAdapter(WritableSheet sheet) {
this.sheet = sheet;
}
@Override
public void addElement(DrawingElement element) {
sheet.addCell((WritableCell)element.getElement());
}
}
WritableSheetAdapter既实现了ReportCanvas接口，同时又组合了WritableSheet对象，完成了WritableSheet到ReportCanvas的适配，使得DrawingElement对象可以接受它：
WritableSheet sheet = workbook.createSheet(sheetName, 0);
WritableSheetAdapter sheetAdapter = new WritableSheetAdapter(sheet);
//遍历报表元素，以数据单元格为例
for (DrawingElement element : table.getCellGroups()) {
element.draw(sheetAdapter);
}
[/img]..
《简单之美》这本书的内容有些另类，绝不似书名所呈现的中规中矩，但确实体现了一种美，是一种简单到极致的优雅，似乎又繁复如星空般的深邃，包容如峭立千仞之高的山壁。这是一本可以称之为轻松加愉快的思想随笔，又是一篇如杜拉拉升职记般的职场小说，它还贯穿了整个软件开发过程，揭露了从方法论、需求、架构设计、编码实现，到测试与维护以及团队管理的诸多要诀。这正是本书的另类之处。 我在阅读本书时，情不自禁地被放在书中每章篇首的实践场景所吸引，甚至忽略了本书的重要内容，直接根据提示转到下一个章节的实践场景，一气呵成，直到将这些实践场景阅读完毕。作者挥洒自如的文笔，入木三分的人物刻画，以及细腻含蓄的情感描写，将我彻底吸引住了。在大结局中，孔如之与儿子在阳光中巴黎圣母院前的对话，让人意犹未尽，似乎满怀希望，却又历尽沧桑，真是让我产生“情何以堪”的感慨。 这是本书感性的一面了。只是看完这9篇由实践场景片段组成的小说，就已经值回票价了。而从技术书籍的角度来看，本书的意义显然并不在于此，作者完整地勾勒出软件开发的全貌，诸多感悟与体会都可以成为软件开发人员的重要借鉴。作为本书理性的一面，这些内容需要反复阅读和分析琢磨，才能引起你的共鸣，许多模糊在心头的概念，在作者简明扼要的叙述下，或许就会产生“拨开云层见月明”的感悟。 以本书第4章为例。作者给出了一个简单的实例描述了框架构建的过程。首先从背景描述出发，展现了对保险业务中对保单进行处理的需求功能。这段背景描述将复杂的保险需求阐述得非常清楚而富有条理，体现了作者撰写文档的高超能力。 接下来是作者对这一背景描述的抽象。这段抽象有理有据，较好地体现了从需求捕获到分析的过程演变，利用抽象搭建了基本的领域模型。紧接着是对约束的思考，这是架构师必须完成的工作。根据对需求的抽象和关于约束的思考，就能够做出合理的架构决策。作者在本书中反复强调的“使用自然语言和讲故事的方式”，通过实例得到了具体的展现。事实上，在Joel on software一书中，Joel Spolsky也提出了同样的观点，认为通过讲故事的方式描述用例场景，可以更好地促进理解与交流。本书作者扩大了这种方式的应用范围，引入到架构设计过程中。对这一做法，我深表赞同。事实上，我在架构过程中，也常常采用类似手法，通过在文档撰写设计的故事场景，帮助我梳理设计思路，有时候，甚至在文档中自问自答，在这样的编写过程中我慢慢找到了解决方案。 本书对领域模型的讨论也有着个人独到的见解。例如他对静态模型和动态模型的分类，又例如他提出了使用贫血模型的好处。在Martin Fowler提出贫血模型之后，业界曾经掀起过对贫血模型与充血模型的争论。然而，争论到了最后，也没有一个确切的结果。从经典的OO原则来看，它要求将对象的数据和行为组织在一起，这正是批判贫血对象的主要论据。我比较倾向于这个观点，认为对象没有行为，就是“死”的，缺乏自治的能力。但在实际开发过程中，我也常常体会到贫血模型的好处，尤其是在模型重用与解耦方面，贫血模型都有其显著的优势。本书作者认为，贫血模型的“第一个好处是，有利于信息交换。第二个好处是，清晰了对象的职责。第三个好处是，实体对象（贫血对象）的实现更加灵活。第四个好处是，可以确保实体对象（贫血对象）只能在内存中用于计算。”这些好处都说到了点子上。虽然，我对于贫血对象的使用仍然抱有谨慎态度，但本书对此的阐述依旧给我提供了不错的参考。 在项目管理方面，书中强调了“负责制度”的实施。这首先关系到责任定位的问题。项目延迟或失败，究竟是项目管理的问题，还是架构设计的问题？是编码实现的问题，还是测试维护的问题？作者认为，负责制度的缺失可能会影响项目的质量。书中提到：“在软件开发过程中，人是最重要的因素，而责任、权利和利益是保证这个因素发挥作用的关键。”“建立负责制度的目的，不是为了惩罚某人，也不是为了永久取消某人的职业发展权利，它只是通过责任人利益损失的形式，来表明这样一个事实：没有金刚钻，别揽瓷器活。”事实上，负责制度的关键不在于制度的确立，而在于执行。如果没有创建公平、公开、公正的执行环境，这种制度只会给软件开发带来负面影响。这也是作者仅仅提出问题，却没有给出好的答案原因所在。相对而言，我个人更倾向于Scrum“回顾会议”，在基于迭代与渐进式开发的基础上，这种方式更能够有效解决项目开发中存在的问题。 倘若是新手阅读本书，由于缺乏足够的工作阅历与开发经验，很难理解作者写作的意图。但我们绝对不能因为这种认识上的障碍，而将本书拒之千里之外。事实上，越早阅读本书，越能够开拓读者的眼界，提前感受业界的真实与谎言，反而能够帮助新手更快地确立自己的职业生涯规划。对于混迹行业多年的老鸟而言，阅读本书，一定能找到那些似曾相识的画面。作者对技术的深入探讨，也一定能给予我们启发，即使观点不同，也可以求同存异。所谓“嘤其鸣矣，求其友声”，这是我在阅读本书时收获的如遇旧友般的快乐！[/img]..
读罢《测试驱动开发的艺术》，忽然想起中国传统文化中的“道器之辩”。《易经》曰：形而上者谓之道，形而下者谓之器。中国的传统文化常常是重道轻器，认为道本器末，即道是根本，其他一切是道的外在表现，器是道的从生与从属。这就导致我们常常喜欢把“道”与“器”割裂开来，一味地重视过度抽象的“道”，进而形成一种形而上学的玄幻，使得“道”高高在上，未能落于实处。重道轻器给传统文化带来的缺失告诉我们，“道”与“器”应该是统一的，道是本质，却又必须依赖于器，受制于器。 从软件开发的角度来看，TDD的本质思想即为“道”，这其中包括按照意图编程的思想，提高可测试性的设计原则，以及测试的模式与面向对象的基本思想。而“器”则包含对TDD的合理运用，针对不同的用例场景做出的测试手法，以及对测试工具的使用。 本书第一部分《TDD入门》阐述的正是TDD之道。虽然是入门知识，却高屋建瓴地阐明了TDD的真谛。例如本书写道： 在TDD周期中的第一步中，我们会写测试，实际上这并不只是写测试而已，而是在做设计。我们是在设计API，即用来访问新功能的接口。编码之前写测试，我们会自然地考虑新代码的调用方式。……测试先行的编码方式会促使我们站在代码用户（开发人员）的角度考虑，设计出更易用的API。 很多开发人员并不愿意接受TDD的开发方式，认为这种先写测试后编码的方式既别扭而又浪费时间，原因就在于他们没有真正体会这种测试驱动设计的好处。TDD最重要的一个字眼儿就是drive（驱动），事实上，这种驱动力正是所谓“按照意图编程”的重要思想。 意图编程，顾名思义，就是说写代码时先假设其他部分代码都已经存在了（即使事实并非如此）。使用这种编程方法时，我们可以把注意力集中在能有的，而不是已经有的东西上。使用意图编程，我们能让代码读起来更流畅，容易理解和使用，也能使代码清晰地表达出自己的本意，而不会过于强调实现细节。 个人认为，本书第一部分给出的邮件模板子系统的范例更贴近开发真实，却又不至于晦涩难懂。作者在选择范例上的匠心独运，使得本书既具有很强的实践指导意义，又不至于陷入复杂的业务需求和技术细节中。范例给出的第一个测试、伪实现以及重构的手法，都是自然而然的TDD过程，而不是为了写作本书生拉硬拽，东拼西凑，有着强烈地雕琢痕迹。若能在阅读过程中，比照着这样的过程动手实验，相信能够获得更大的提高。 从本书的第二部分开始，就迈入了TDD“器”的部分。之所以说是TDD之“器”，在于它介绍了针对特定技术应用TDD的内容，这其中包括对Web组件、数据访问、多线程、Swing代码的测试驱动开发。在讲解的过程中，作者还介绍了大量用于这些特定技术应用TDD的工具或框架，例如JspTest、EasyMock、MockObjects、HSQLDB、Jemmy、Abbot等。这些都是Java平台下常用的支持TDD的有力工具。本书的第三部分则着重介绍了ATDD（验收测试驱动开发），包括对用户故事的介绍，验收测试的特征与实现，ATDD的过程以及相关工具Fit。这在许多介绍TDD的书籍中都是不多见的内容。 这两部分内容给出了许多贴近开发真实的例子，提出了许多卓有成效的测试方法。这些内容如此地实用，涵盖的知识如此地全面，基本上可以解决我们在企业开发中进行TDD可能遇到的问题。事实上，这些内容大多数都可以说是TDD实践过程中的拦路虎，尤其是针对表现层和多线程技术的TDD方法，大多数开发人员都缺乏这方面的知识，甚至因为这样而放弃TDD。本书极具实践指导意义的阐述弥补了这一空白。遗憾的是，本书介绍的内容主要针对Java开发人员，因而提及的工具也都基于Java平台，对于其他平台下的开发人员而言，无疑削弱了几分价值。 本书还有一点不足就是“道”与“器”的不统一。前面提到，本书的第一部分开篇名义，用极简洁的语言道明了TDD的本质。然而本书的第二部分与第三部分，几乎只停留在TDD方法和工具的使用上，而忽略了测试对于设计的驱动力。书中的例子仅仅给出了如何完成测试用例，如果建立Mock对象，却不再介绍为何要这样编写测试用例，驱动我们进行设计的意图何在。换言之，后面的例子省略了驱动对设计进行推导的过程。这种驱动设计的能力恰好是很多程序员所不具备的。“器”固然重要，但它必须遵循“道”的要义，在其指引下实施。本书内容“道”与“器”兼顾，却将二者割裂开来，未能形成统一的整体，不能不说白璧微暇，略有遗憾。[/img]..
社区：
