API设计很难，尤其是大型的设计。如果你正在为成百上千的用户设计一款API，你不得不思考未来你可能作出何种改变，以及这些改变是否会给客户的代码造成破坏。除此之外，你不得不考虑这些API的用户会如何影响你。如果你的API类中有一个类会调用它自己的内部方法，你就不得不推荐用户可以通过继承一个子类并重写此方法，但这可能会成为灾难。你无法改变这个方法，因为用户已经给它赋予了不同的含义。你在之后的内部实现也将受到用户的支配。
API开发者有很多方法解决这个问题，但最简单的方式就是锁定API。如果你用Java实现，可能会在会让很多类和方法加上final。在C#中，你可能会让类和方法加上sealed。不管你用什么语言，你可能都想通过单一模式或静态工厂方法来展示你的API，从而可以保护它们不让他人有覆盖的行为，同时在使用你的代码时，能够限制住它们的选择。这看似全部的原因，但，是真的吗？
过去的十年里，我们逐渐认识到了单元测试是非常重要的一个环节，但这一教训并没有完全渗透到整个行业。其迹象充斥在我们周围。让一个未经测试的类随意用于第三方API，并尝试为它写单元测试。大部分时间，你都会掉坑里。你会发现这些代码所使用的API像是用胶水粘起来的一样。没有办法模拟这些API类，你只能通过“感觉”来和他们交流，或者提供返回值进行测试。
随着时间的推移，这都会变好，但只有在我们设计API时，才开始将测试视为真实用例。不幸的是，它比仅仅测试一下代码要复杂一些。那就是API设计黄金法则：仅为你开发的API写测试是不够的；你不得不为使用了你的API的代码写单元测试。当你这么做了，你就能掌握用户在测试他们的代码时不得不面对的困难。
没有办法让开发者在测试使用你API的代码时变得容易。static、final和sealed本身并不是坏的结构。有时它们很有用。但更重要的是意识到测试问题，然后解决，你必须亲身经历。一旦你拥有(这种经验)，你就可以像其他设计挑战一样解决它。
