Preface Rarely does one get entertained by reading software manuals, though Knuth’s The TeXbook is one notable exception. Rarer still is getting pleasure from reading guidelines for writing software. Imagine my surprise when I found myself reading and actually liking Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries by Cwalina and Abrams. The book was seriously fun and educational at the same time. It was hard to put down. »
Preface In the previous post I talked about the importance of good design when making a published API. I ended by giving four ‘C’s of a good API: complete, compact, consistent and clear. Here I elaborate on them one by one.
Complete An API design is complete if it allows customers to write client code that supports all use cases allowed by the business. This is a dynamic situation. With time the business may change their policy and allow new use cases against the same domain objects. »
Use-case Driven API Design In the previous post, I discussed the qualities of a good public API design. Knowing where we want to go does not automatically tell us how to get there. Today I wanted to travel from Detroit to Chicago so I got in the car and opened Google Maps on my phone. It told me exactly how to get where I wanted to go. But before 1800 Chicago was much harder to find; there were no roads, no maps, no directions. »