Re: API Design
Thad Smith
> http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
>
>
> Communications of the ACM rarely bring something practical.
> This is a good exception.
>
> It is a good article about API design, and the problems of bad APIs.
Agreed. I plan to distribute the link to others at work. It makes
explicit the policy-free vs. policy-rich trade-off, which is a useful
insight for me.
Good design of low-level functions has a multiplying effect on
application code.
Followups set to comp.programming.
--
Thad
William Ahern
> jacob navia wrote:
> > http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
> >
> >
> > Communications of the ACM rarely bring something practical.
> > This is a good exception.
> >
> > It is a good article about API design, and the problems of bad APIs.
> Agreed. I plan to distribute the link to others at work. It makes
A good API emerges from iteration. You really can't know how to make a new
API work for you until you've used it in various situations. Tweak, use,
tweak use. Sometimes after two or three iterations you have a really solid
design, sometimes you need more. A couple of the authors suggestions in that
paper reflect this dilemmea, with the vain suggestions about documentation
and separating the caller from implementor.
Iteration is extremely hard to accomplish in a commercial environment with
other engineers because re-writing code is usually frowned upon, especially
once others have begun using the interface. (Thus if you separate caller
from implementor you'll never get the opportunity to change the API; and
it's foolish to think the first try will be even remotely optimal.)
This is why C++, Java, and C# are so popular commercially. For one thing, if
you implement a canonical design pattern, no matter how unwieldy or
overkill, nobody will object. Second, these interfaces can just be papered
over with super/sub classing on an ad hoc basis. This is also why the claims
of improved modularity in these OOP languages are baseless, because in
practice cross-dependencies grow very quickly.
One strategy is to write mock-up software in, say, Perl. The standard forms
in Perl reduce to C code rather well, as long as you're not using too many
modules. And of course design iteration in Perl is much faster than in C.
The interesting thing about C and design patterns is that though you can
obviously implement a design pattern in C, it's very difficult to implement
it in a universal fashion. It will almost always be closely bound to the
particular context. And this, I propose, is good thing!
Ed Prochak
wrote:
> Thad Smith <ThadSm...@acm.org> wrote:
> > jacob navia wrote:
> > >http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
>
> > > Communications of the ACM rarely bring something practical.
> > > This is a good exception.
>
> > > It is a good article about API design, and the problems of bad APIs.
> > Agreed. I plan to distribute the link to others at work. It makes
>
> A good API emerges from iteration. You really can't know how to make a new
> API work for you until you've used it in various situations. Tweak, use,
> tweak use. Sometimes after two or three iterations you have a really solid
> design, sometimes you need more. A couple of the authors suggestions in that
> paper reflect this dilemmea, with the vain suggestions about documentation
> and separating the caller from implementor.
>
> Iteration is extremely hard to accomplish in a commercial environment with
> other engineers because re-writing code is usually frowned upon, especially
> once others have begun using the interface. (Thus if you separate caller
> from implementor you'll never get the opportunity to change the API; and
> it's foolish to think the first try will be even remotely optimal.)
The rule I try to follow is based somewhat on hardware development.:
throw away the prototype!
IOW, your first iteration is seldom optimal. As long as the project
manager understands that, you are okay.
Ed