API设计黄金法则

The Golden Rule of API Design

API设计很难,尤其是大型的设计。如果你正在为成百上千的用户设计一款API,你不得不思考未来你可能作出何种改变,以及这些改变是否会给客户的代码造成破坏。除此之外,你不得不考虑这些API的用户会如何影响你。如果你的API类中有一个类会调用它自己的内部方法,你就不得不推荐用户可以通过继承一个子类并重写此方法,但这可能会成为灾难。你无法改变这个方法,因为用户已经给它赋予了不同的含义。你在之后的内部实现也将受到用户的支配。

API开发者有很多方法解决这个问题,但最简单的方式就是锁定API。如果你用Java实现,可能会在会让很多类和方法加上final。在C#中,你可能会让类和方法加上sealed。不管你用什么语言,你可能都想通过单一模式或静态工厂方法来展示你的API,从而可以保护它们不让他人有覆盖的行为,同时在使用你的代码时,能够限制住它们的选择。这看似全部的原因,但,是真的吗?

过去的十年里,我们逐渐认识到了单元测试是非常重要的一个环节,但这一教训并没有完全渗透到整个行业。其迹象充斥在我们周围。让一个未经测试的类随意用于第三方API,并尝试为它写单元测试。大部分时间,你都会掉坑里。你会发现这些代码所使用的API像是用胶水粘起来的一样。没有办法模拟这些API类,你只能通过“感觉”来和他们交流,或者提供返回值进行测试。

随着时间的推移,这都会变好,但只有在我们设计API时,才开始将测试视为真实用例。不幸的是,它比仅仅测试一下代码要复杂一些。那就是API设计黄金法则仅为你开发的API写测试是不够的;你不得不为使用了你的API的代码写单元测试。当你这么做了,你就能掌握用户在测试他们的代码时不得不面对的困难

没有办法让开发者在测试使用你API的代码时变得容易。staticfinalsealed本身并不是坏的结构。有时它们很有用。但更重要的是意识到测试问题,然后解决,你必须亲身经历。一旦你拥有(这种经验),你就可以像其他设计挑战一样解决它。

0%