Reviewers
From APIDesign
Contents |
Reviewers
Reviews and comments of pre-published versions of the book have been provided by many good reviewers and hopefully helped me eliminate trivial mistakes. I could not address all the comments, that would mean quite a big rewrite of the whole book. I may do it when I write another one, still I believe that the reviewers helped me a lot to make the book a better book.
Theory and Justifications
Please read the part and provide your comments here by Apr 3, 2008. Sections prefixed with 
are already processed. If you modify a section marked as , let User:JaroslavTulach know as I have already processed them and I might overlook your comments.
-
Prologue - Yet Another Design Book?
- Theory and Justification
- The Art of Building Modern Software
- The Motivation to Create an API
- Determining What Makes a Good API
- How to Check the Quality of an API
- Ever Changing Targets
Practical Design
Dear Reviewers Thanks for your comments to Part 1, now you have a chance to review something real, something that contains a lot examples and also a lot of claims that need to be validated or invalidated.
Keep in mind that grammar changes are not something that I will apply. That is task for my publisher. More than them I am interested in your insight in various technologies that I refer to, but I am not real expert in. If anyone feels there is something about XML, bytecode manipulation, etc. that I do not interpret correctly, please make a note.
Another thing that I'd like you to verify is how easy it is to work with Sources. Are they connected well with the text of the book? Do you know what to do with them? Can you run them, study the sources, debug them? Is there any aspect that they miss and that should be improved? It is especially important to identify things that need to be done before publishing the book, those others can simply be improved later.
Finish your review by Apr 14, 2008 please. Little delay is ok, but the sooner the better:
- Do Not Expose More Than You Want
- Code Against Interfaces, Not Implementations
- Use Modular Architecture
- Separate APIs for Client APIs and Support APIs
- Keep Testability In Mind
- Cooperating with Other APIs
- Runtime Aspects of APIs
- Declarative Programming
Daily Life and the Future
Dear Reviewers.
Thanks for your comments to Part 2. I'll start to process them now. Meanwhile I can offer you Part 3. I am looking forward to your comments. Please provide them by April 23, 2008. Btw. do not forget to get latest Sources.
