Your biggest competition is the user’s belief in the difficulty of solving the problem.
Misuse prevention: Thread safety, order of operations, types, null behaviorsDon’t show what they don’t need: Internal, hide on interfaces, veneer the APIHard Shell: Don’t trust any code around or above you.
Consistent with the framework and itself, then with likely customer experience.
Prefer to have the fewest assemblies you can, and their names are part of their interface.Use different names for valid combinations – like .NET 20 and .NET 40. Have a reason for the CUSTOMER that you broke apart
Your job is to hide the complexity of your domain from users, not show how smart you areQuality is tightly related to how well it blends into the enviornmentYour preferences aren’t their preferences – configuration, designer or code
Designing APIs for Others Real World Lessons About Commercial API Development
Typical Programming Goals Minimize maintenance cost & risk Extensible / refactorable to new requirements Easy to read the source code
Commercial API Goals Other people use your library and like it. Short First Reference -> First Wow Digestible, iterative discovery Easy Things are Easy, Hard Things are Possible
How Users Discover Code Samples Very narrow, taken literally IntelliSense Driven Discovery See that they probably can do what they want to.
Design Priorities Discovery through your fingers Where possible can’t be misused Don’t show what they don’t need Advanced features in advanced ways Hard Shell Designer->Compile->Runtime
Key Implementation Method Always outside in – terms, flow, exception types. Reads like the outline of a book Fewer, Flatter Sample Driven Development Samples are your test cases Digestible chunks of WHY Consistency