The Golden Rule of API Design

From WikiContent

Revision as of 20:02, 6 July 2009 by Mfeathers (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

API design is tough, especially in the large. If you are designing an API which 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. You aren't going to be able to refactor your AI freely over time, so there are some decisions that you have to get right, because right or wrong you are going to have to live with their consequences for a long while. Above all, you have to protect the invariants of your API. 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 easist 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. That way, you won't have to worry about people sub-classing your classes and overriding various bits of behavior.

Personal tools