'. '


From APIDesign

Jump to: navigation, search
This is great, thanks for taking the time to write it ! I will study it and reply if I can think of anything constructive to contribute.

One thing that has tended to confuse me in the book is there are multiple reasons, as you point out, why interfaces might cause API writer's headaches, and I tend to mix them up. Are interfaces trouble because they are public and therefore become stars? That's an evolution problem. What bad things can happen when you use interfaces from an evolutionary standpoint again? Are they trouble because the API writer's intent is not clear? That's a communication problem. What are my other options again?

I almost want a list of things I have to be on guard against, then check each design option against them. I almost want a flowchart. I must be a programmer. -- 11:36, 21 April 2009 (UTC)bassy bassy good dog!

Thanks for your comment. As regards the checklist, I've just created APIAntiPatterns category. But it will take a while until it is filled.

There is nothing bad on using Java interfaces in certain situations. Their biggest advantage is ClearDefinitionOfVersion. Their biggest restriction is inability to evolve and add new methods into them. As such I don't recommend common use of interfaces for ClientAPI, but I use them a lot in ProviderAPI.

--JaroslavTulach 19:12, 24 April 2009 (UTC)

Personal tools