不要轻易跨越边界
注：正文中的引用是直接引用作者的话，两条横线中间的段落的是我自己的观点，其他大约都可以算是笔记了。
在一个完整的系统开发过程中，我们一般不会所有的代码和细节实现都自己去完成，那么不可避免地要用到第三方类库、开源实现或者公司内部其他团队的子系统的实现。在这种时候，我们就要给自己负责的这部分定义「清晰的边界」，来让我们的软件更加健壮。本章将讨论一些对边界问题的处理的几个实践和技巧。
使用第三方代码
使用「第三方类库」总是会碰到这样一个问题，第三方包的提供者往往费尽心力要把接口设计得更加通用和普适，然而第三方包的使用者（往往是正在开发某个系统的我们）却只想要「我们要使用到的那部分功能」被开放出来，而对于不使用的功能我们并不想将之暴露给代码的其他部分。这就造成了第三方库和我们自己的代码间的边界问题。
这里拿Java基本类库中的java.util.Map来举例，这个类本身提供了很多方法（如列表7-1所示），对于Java基本类库来说这种强大而且灵活的Map是设计良好且很有必要的，但是如果我们的场景是我们使用Map存储手机上的传感器列表，此时我们并不希望接每个能拿到这个列表的人都能删除列表中的项——这可能会带来系统的不稳定，但是实际情况则刚好相反，拿到这个Map的人甚至可以使用一个clear()函数就可以清空整个列表，这就是代码中的边界问题：「第三方类库（这里是java.util.Map）的边界（它提供的接口）和我们代码中所需要的边界并不相同」。
//列表7-1 java.util.Map中的方法
• clear() void – Map
• containsKey(Object key) boolean – Map
• containsValue(Object value) boolean – Map
• entrySet() Set – Map
• equals(Object o) boolean – Map
• get(Object key) Object – Map
• getClass() Class<? extends Object> – Object
• hashCode() int – Map
• isEmpty() boolean – Map
• keySet() Set – Map
• notify() void – Object
• notifyAll() void – Object
• put(Object key, Object value) Object – Map
• putAll(Map t) void – Map
• remove(Object key) Object – Map
• size() int – Map
• toString() String – Object
• values() Collection – Map
• wait() void – Object
• wait(long timeout) void – Object
• wait(long timeout, int nanos) void – Object
要解决这个问题，只需要对这个容纳传感器的Map进行简单的面向对象封装。更理想的情况应该是，在你的代码中永远不要传递像Map这样边界十分「宽」的对象，它们永远应该被包裹在其他边界更「窄」的类中。
探索和学习边界
在项目中使用第三方的库可以加快开发进程，同时提供更多的功能。通常在准备把一个第三方库加入项目时，我们可能要花一段时间来查看它的文档，然后试着写一些代码来测试这个库是否能达到我们的要求，但是这样往往会发生这样的情况，当其中出现问题时，我们需要通过不断地调试「我们的项目中使用这个第三方库的相关代码」，来判断到底是我们的代码中的bug还是这个类库本身的bug。
与此不同，我们可以采用另外一种方法来对待第三方库，我们在拿到这个类库之后先写一整套的单元测试——这些单元测试涵盖了所有我们会用到的这个第三方库的功能——来验证这个库是否可以符合我们的要求，在此同时也学习了如何使用这个库。这个方法被称为学习测试（learning tests）。
学习log4j
比如我们想要使用Apache的log4j来作为我们的项目的日志系统，那么我们首先做的就是写一个单元测试，来测试它「是否可以」和「如何」在屏幕上打印一个字符串hello。那么我们通过查看它的文档和在搜索引擎中的检索问题，我们写出了代码7-2中的这样一个单元测试。
//代码7-2
public class LogTest {
private Logger logger;
@Before
public void initialize() {
logger = Logger.getLogger("logger");
logger.removeAllAppenders();
Logger.getRootLogger().removeAllAppenders();
}
@Test
public void basicLogger() {
BasicConfigurator.configure();
logger.info("basicLogger");
}
@Test
public void addAppenderWithStream() {
logger.addAppender(new ConsoleAppender(
new PatternLayout("%p %t %m%n"),
ConsoleAppender.SYSTEM_OUT));
logger.info("addAppenderWithStream");
}
@Test
public void addAppenderWithoutStream() {
logger.addAppender(new ConsoleAppender(
new PatternLayout("%p %t %m%n")));
logger.info("addAppenderWithoutStream");
}
}
写完这个测试，我们就已经知道怎么去使用log4j了，包括怎么去初始化和配置它，然后我们就可以按照学到的知识把log4j封装成一个我们自己的类，这样它的边界变成我们想要的样子。
「学习测试」还能带来更多的好处
我们通过以上的单元测试的编写学习了如何使用这个类库，同时也没有浪费时间，因为我们本来就要花时间去写测试代码，倒不如直接这样写成单元测试，既清晰又不会污染我们项目中的其他代码。
与此同时，学习测试还带来了其它更积极的作用，如果这个第三方类库的版本更新了，我们只要把我们的单元测试再跑一遍，就可以「其中我们要使用的这部分功能是否有了变化，是否仍然满足我们的需求」，如果单元测试直接通过，那么我们可以放心的升级新版本，否则我们也可以直接知道哪里出了问题，马上就可以在生产代码中做出修改，避免了产生毫无头绪的bug。
学习测试其实最根本的作用就是在第三方类库和我们的项目中间构建了一个边界，通过编写的单元测试就可以很清晰地测试这个边界是否有效。
我们经常为了避免产生bug而不愿意去升级项目中依赖的第三方库，甚至在这个过程中做出各种各样的妥协，让项目的维护和升级变得越来越难。如果使用这里的讲到的边界测试，升级第三方库也会变得十分容易。
使用未来的代码
使用边界可以带来另外一个好处就是，可以使用未来的代码。
我们经常碰到这样的场景，两个团队a和b合作开发一个项目，他们分别负责不同的模块，模块a依赖另外一个模块b，此时b的接口还完全没有定义，行为也完全可能有变化，但是b模块大致要做的事情是确定了的。那么a团队就可以在a模块中先自己设计一套简单的接口并作出简单的实现（可能返回的是假的数据），然后在这个基础之上a来写一个自己的适配器类c，来对所有这些接口进行包装。这样就定义好了a和b之间的边界，适配器类c就是连接a模块和b模块之间的桥梁，然后a就可以继续进行其他工作而不需要考虑b的开发进度了。
如果有一天b团队说它们的接口需要变化，那么a模块中要做出的修改也只局限在这个适配器类c中，其他的模块完全不受影响。
清晰的边界
关于边界问题有很多有趣的事情，变化就是其中之一。有时候我们的项目中不得不做出各种各样的改变，好的软件设计可以让项目以很小的代价来做出这种改变，而边界问题在这里起到了很重要的作用。
好的软件设计中应该有清晰的边界和在边界之间表示互相期许的单元测试。这样就防止了我们的代码知道太多的它依赖的第三方库的具体实现，所有边界之间的耦合可以轻松被控制在可接受的范围之内。
网友评论