EnforcingProperUsage

From APIDesign

Revision as of 04:45, 14 June 2015 by JaroslavTulach (Talk | contribs)
Jump to: navigation, search

API design is about communication between the API designer and its API users. Good API can be recognized by quality of the communication between the designer and the users. Does the vision of proper API usage (in header of the designer) recreates properly in heads of the users? If not, your API is probably suffering from a poor clarity. Do you users hack around your API - e.g. use things clearly stated as not being part of the API? Can you prevent them to do so? Those are question this essay is about to analyze.

Contents

Striving for Clarity

If an API reaches clarity - e.g. everything in the API has a single meaning - then there is no reason to enforce anything - users either use something (method, class) or not. However, as everything (method, class) in the API has a single meaning, if they use it, they have to (or at least chances are very high) use it correctly. That is the reason why it is important to follow the API design patterns for Clarity and focus on ClarityOfAccessModifiers, ClarityOfTypes and separate API from a service provider interfaces.

Trying to Hack

The problem TBD.

Preventing the Hacking

Engineering solution

Legal solution

Personal tools
buy