As programmers, we often complain that we have to do things quickly instead of doing them properly. But there are times when we do have to dot every i and cross every t. When those times come, it's the programmer's dream, and we should be ready for it.
What I've tried to show here is the "right" way to do thingsrealizing, of course, that there is no one right way.
You'll notice I've talked more about interface than implementation. That's because in this kind of situation, interface is everything.
The external interface for a library is all that a user of that library will ever really see. It should be complete, intuitive, and flexible.
On the other hand, we can't really go without discussing implementation. For one thing, it is never separated from the interface as much as we would like; if I'm writing the code, I have to tie the interface to the internals.
For another thing, it's essential to make the code maintainable. In an ideal world, we would write it once, release it, and that would be that. This is not an ideal world. There will be periodic bug fixes and enhancements, no matter how small the code is. Six months from now, someone will have to read this code and modify it. Do that person a favor, especially since it may be you.
That's it for now. In the second article of this series, we'll talk about typecasts, operator overloading, I/O stacking, and more.