编程中的权威质疑与元编程探索

### 编程中的权威质疑与元编程探索 #### 1. 测试命名风格的选择 在编程中，测试方法的命名风格是一个值得探讨的问题。有两种不同的命名方式： ```java public void testUpdateCacheAndVerifyItemExists() { } public void test_Update_cache_and_verify_item_exists() { } ``` 相比之下，使用下划线分隔的命名方式可读性更强。在提出这个建议后，开发团队的反应不一，有些开发者立刻认可，而有些则表示不满。最终采用了下划线分隔的命名风格，事实证明这种风格在IDE的测试运行器中查看一长串测试名称时，可读性更佳。 这告诉我们，在编程中不能仅仅因为“一直都是这样做的”就坚持某种习惯。我们应该理解每种做法的原因，如果合理就继续保留，但同时也要不断质疑假设并验证其有效性。 #### 2. 流畅接口（Fluent Interfaces） 流畅接口是当前流行的特定领域语言（DSL）风格之一。它的核心思想是将长串的代码构建成类似句子的形式，就像自然语言中的完整思想表达一样，这样的代码更容易阅读，因为我们能清楚地知道一个逻辑的结束和下一个逻辑的开始。 以一个处理火车车厢的应用为例，最初的代码如下： ```java Car car = new CarImpl(); MarketingDescription desc = new MarketingDescriptionImpl(); desc.setType("Box"); desc.setSubType("Insulated"); desc.setAttribute("length", "50.5"); desc.setAttribute("ladder", "yes"); desc.setAttribute("lining type", "cork"); car.setDescription(desc); ``` 对于Java开发者来说，这段代码很正常，但业务分析师却不喜欢，他们希望直接了解代码的含义，而不是看Java代码。为了解决这个问题，创建了一个流畅接口： ```java Car car = Car.describedAs() .box() .length(50.5) .type(Type.INSULATED) .includes(Equipment.LADDER) .lining(Lining.CORK); ``` 业务分析师对这种方式更为满意，因为它减少了“正常”Java API风格中的冗余部分。其实现也很简单，所有的设置属性方法返回的是`this`而不是`void`，从而实现方法调用的链式操作。`Car`类的实现如下： ```java public class Car { private MarketingDescription _desc; public Car() { _desc = new MarketingDescriptionImpl(); } public static Car describedAs() { return new Car(); } public Car box() { _desc.setType("box"); return this; } public Car length(double length) { _desc.setLength(length); return this; } public Car type(Type type) { _desc.setType(type); return this; } public Car includes(Equipment equip) { _desc.setAttribute("equipment", equip.toString()); return this; } public Car lining(Lining lining) { _desc.setLining(lining); return this; } } ``` 这种方式实际上是一种表达式构建器（Expression Builder）的DSL模式，`Car`类隐藏了内部构建`MarketingDescription`对象的事实。要实现流畅接口，需要打破Java的一些传统规则，比如`Car`类不再是JavaBean。JavaBeans规范要求对象有默认构造函数，并且使用`getXXX()`和`setXXX()`方法，返回类型为`void`。但这些规则在某些情况下会损害代码的整体质量，我们应该根据实际需求明智地做出决策，而不是盲目遵循。 #### 3. 反对象（Anti-Objects） 有时候，我们应该质疑自己解决问题的固有倾向。在2006年的OOPSLA会议上有一篇名为“Collaborative Diffusion: Programming Anti-Objects”的论文指出，虽然对象和对象层次结构为大多数问题提供了出色的抽象机制，但这些抽象也会使某些问题变得更加复杂。反对象的思想是切换问题的前景和背景，解决更简单、不那么明显的问题。 以经典的吃豆人（PacMan）游戏为例，游戏需要解决幽灵如何在迷宫中追逐吃豆人的难题，也就是在迷宫中找到到移动目标的最短距离。由于当时的计算能力有限，开发者没有采用将智能赋予幽灵的“明显”解决方案，而是采用了反对象方法，将智能构建到迷宫本身。 迷宫中的每个单元格都有简单的规则，从左上角开始依次执行。每个单元格会记录“吃豆人气味”的值，当吃豆人在某个单元格时，该单元格的气味值最大；当吃豆人离开后，气味值逐渐降低直至消失。幽灵只需要嗅探气味，朝着气味更浓的单元格移动即可。 这个例子说明，我们不能陷入“传统”建模总是正确的陷阱，有时候换个角度思