No, you're wrong (in my opinion). For the simple reason
that however long to spend trying to think out the API,
you'll never come up with all of the requirements - and
new requirements will always emerge as soon as you think
you've finished tying them down.
APIs will always change. Your best bet is to design an
API that is flexible enough to accept the changes without
breaking existing code. Perl is particularly good at this
as it's easy to add new parameters to a function and set
up defaults for ones that aren't passed. This is even easier
if you use hashes to simulate named parameters.
--
<http://www.dave.org.uk>
"Perl makes the fun jobs fun
and the boring jobs bearable" - me
| [reply] |
I suppose it depends. "Thoroughly" and "Ever" are pretty strong words. After all, you can spend so much time designing and planning that your project sponsors get tired of seeing no progress. (I know this from experience.) Similarly, if you're not willing to change your API, then you prevent it from evolving and improving.
Instead, I think it's wiser to pick the most common operations, design them orthogonally, and then let the API grow organically as needed. If you start with 20% that you'll need 80% of the time, you've got something you can base continued progess on.
It's hard to be more specific without details, but let's assume you're building a custom API for handling a database, one that matches your local standards and idioms. Given that, you then know the basic operations: create, alter, insert, delete, select, update, and so on. Implement those quickly and then produce a simple front-end for testing and evaluation. Let people see that and start providing input. You'll start getting immediate feedback and they'll see appreciable progress.
You have to use care and common sense, of course. After all, you don't want to reinvent the wheel (as in there are a lot of existing database API's available that already handle those atomic operations) nor do you want to short-sheet those using your API.
Inflexibility leads to brittleness and breakage (as it does in real life). If you do not allow yourself to back-track, re-design, improve, update, maintain, and so on, then how will you ever improve quality, performance, and flexibility?
--f
| [reply] |
Part of the problem was that I was in a cranky mood and was like "why did i take the time to design this interace when all of the sudden you introduce new requirements... and they don't make sense!" Just frustration... I was just doing sanity checking... (and, of course, I'm insane...)
----
Zak
| [reply] |
Been there; got the scars. :-}
Dancing requirements are one reason why I try to follow the MVC (model, view, controller) philosophy, as well as (more recently) designing for orthogonality. If you work on little pieces, they can be reassembled as needed; you also stay focused on what's important...getting the job done and staying flexible enough to stay employed.
Allow me to suggest The Pragmatic Programmer as something to take your mind away from the real-world aggravations, as well as providing some solid ideas for living effectively in an agravating development world. Indeed, it can help make that world less troublesome.
--f
| [reply] |
On the conceptual level, yes. A good number of API's don't actually start as API's. Once they work into that larger scheme of maintainability, they need to be carefully thought out according to the current methods and procedures that they need to fit right now. In doing that initial evaluation, you also need to look at how they are going to evolve as best you can.
Right now I deal with this since we have our own authentication services for our labs and I have to maintain a legacy "API," if you will. Half of the code is well structured. The other half is spaghetti. Let's just say that there are a lot of programmers here who enjoy global variables. A lot of global variables...
Firm evaluation of the API needs to accomplish the task at hand, as well as be open for expansion. I enjoy C++'s expansionability as well as Java and Perl's. It just depends on the task at hand. I'm pulling a lot more things into Perl because of code handling (plus management has finally smiled on Perl for development and is questioning our evil proprietary WinBatch crap), and because of general love of the language. | [reply] |