出于某种原因，我们需要将外部的代码整合进我们的自己的项目中

Using Third-Party Code

第三方软件包和框架的提供者努力争取广泛的适用性，以便它们能够在许多环境中工作，并吸引广泛的受众。但对开发者来说，他们只想其interface提供他们想要的功能。这个矛盾关系会影响我们系统的边界

例如，我们的应用程序可能会建立一个Map并将其传递给其他人。我们的目的可能是让我们的Map的接收者都不删除Map中的任何东西。但Map的API提供了clear()方法，并且Map的任何使用者都有权力清除它

例子: 如果我们需要一个存储Sensor的Map

Map sensors = new HashMap(); 
                                
Sensor s = (Sensor)sensors.get(sensorId ); 

这段代码可以实现，但是不够clean，可以使用范型

Map<Sensor> sensors = new HashMap<Sensor>(); 
... 
Sensor s = sensors.get(sensorId); 

这样更简洁，但是没有解决这个map提供比我们期望得更多的方法的问题

最好的方法是包装一下

                                            
public class Sensors {  
    private Map sensors = new HashMap(); 
    
    public Sensor getById(String id) { 
        return (Sensor) sensors.get(id); 
    } 
    
    //snip 
} 

作者并不建议将Map的每一次使用都以这种形式封装起来。相反，作者建议你不要在你的系统中传递Map（或任何其他边界Interface）。如果你使用像Map这样的边界接口，请将其保留在使用该接口的类或类的近亲中。避免从公共API中返回它，或接受它作为参数。(因为他们提供了很多多余的API)

Exploring and Learning Boundaries

我们可以写一些tests来探索我们对第三方代码的理解。Jim Newkirk称这种测试为学习测试learning tests

Learning Tests Are Better Than Free

Using Code That Does Not Yet Exist

写一些从无到有的代码是另一种的边界，区分知道和不知道的代码

最好的做法是先定义一个interface提供给调用者，这样做的好处是我们可以很好的掌控新增的代码，并且很适合完成边界测试

Clean Boundaries

好的软件设计在改代码的时候不需要大量的工作。

我们需要拒绝让我们的代码了解过多的第三方包或者API，好的方式是用一个类写一遍自己需要的API，然后把第三方的实现封装起立。方便我们control我们的代码

就像包装Map一样，或者使用适配器来转换API成我们需要的API