The Golden Rule of API Design
2015-05-04 07:45
441 查看
The Golden Rule of API Design
Michael FeathersAPi DESiGN iS TOUGH, PARTiCULARLY iN THE LARGE. If you are designing an API that is going to have hundreds or thousands of users, you have to think about how you might change it in the future and whether your changes might break client code. Beyond that, you have to think about how users of your API affect you. If one of your API classes uses one of its own methods internally, you have to remember that a user could subclass your class and override it, and that could be disastrous. You wouldn’t be able to change that method because some of your users have given it a different meaning. Your future internal implementation choices are at the mercy of your users.
API developers solve this problem in various ways, but the easiest way is to lock down the API. If you are working in Java, you might be tempted to make most of your classes and methods final. In C#, you might make your classes and methods sealed. Regardless of the language you are using, you might be tempted to present your API through a singleton or use static factory meth- ods to guard it from people who might override behavior and use your code in ways that may constrain your choices later. This all seems reasonable, but is it really?
Over the past decade, we’ve gradually realized that unit testing is an extremely important part of practice, but that lesson has not completely permeated the industry. The evidence is all around us. Take an arbitrary untested class that
70 97 Things Every Programmer Should Know

uses a third-party API and try to write unit tests for it. Most of the time, you’ll run into trouble. You’ll find that the code using the API is stuck to it like glue. There’s no way to impersonate the API classes so that you can sense your code’s interactions with them, or supply return values for testing.
Over time, this will get better, but only if we start to see testing as a real use case when we design APIs. Unfortunately, it’s a little bit more involved than just testing our code. That’s where the Golden Rule of API Design fits in: It’s not enough to write tests for an API you develop; you have to write unit tests for code that uses your API. When you follow this rule, you learn firsthand the hurdles that your users will have to overcome when they try to test their code independently.
There is no one way to make it easy for developers to test code that uses your API. static, final, and sealed are not inherently bad constructs. They can be useful at times. But it is important to be aware of the testing issue and, to do that, you have to experience it yourself. Once you have, you can approach it as you would any other design challenge.
相关文章推荐
- The Golden Rule of API Design
- 上周技术关注:The Rule of Method Design
- The Rule of Method Design
- The Rule of Method Design
- “API design is like sex: Make one mistake and support it for the rest of your life.”
- The Ruler To design Static Member of Class.
- Importance of Rack Design to the Crusher Work Efficiency
- The design and Implementation of a Log-Structured File System
- The number of method references in a .dex file cannot exceed 64k API 17
- mvn install Geoserver under ubuntu10.04 时遇到的错误:the API of the mojo scanner is not compatible with this plugin version. 的解决方法
- Practical API Design: Confessions of a Java Framework Architect
- Google has disabled use of the Maps API for this application
- UBIFS设计简介 - A Brief Introduce to the Design of UBIFS
- Principles of good RESTful API Design
- 《Design of Computer Programs》学习笔记(2 - 1)Back of the Envelope - Lesson 2
- Windows Embedded CE 6.0 Internals (4) The Mechanism of API
- The Art and Science of Level Design
- Improve the Design and Flexibility of Your Project with Extreme Programming Techniques(Reship)
- 【原创】The Design and Implementation of OO Model of Fetion Engine
- 干粮 -- 计算机程序设计艺术(The Art of Computer Design) - 1