One sort-of-related thing I forgot to mention in the parent post.
Suppose
you're looking at a pile of library code and trying to decide "which part is the
API, the interface"? The question you should ask yourself is "which parts can I
change, without possibly breaking somebody else's program that is using my
library?" In the java.io.File.exists() example, maybe one day Oracle will
decide to re-write the implementation of that method, to use a better technique.
But to make sure old programs still work, they can't change the interface
(the API), they can only change the private implementation parts. They
can't change the name of the method to "fileExists" (they could add a new
method called fileExists, but they can't remove the old "exists" method, because
removing "exists" would break any program that was using it). They can't change
the signature of the method (the return type, or the parameter list), for
the same reason: it would break existing programs. That's why you hear phrases
like "extending the API" ... because adding new things to the API is usually
safe, but other kinds of changes (removing or changing things) are not
safe.
This is why designing good APIs is so important, especially if lots of
programmers are going to be using your library to get things done. The better
the API, the easier they will find it to use your library correctly. And if you
make bad design choices in the API, you will probably be stuck with them
forever, and the programmers who have to use your library will either constantly
pay that price, or just give up and not use your code at all! [ Reply to This | Parent | # ]
|