Andrew Sutton wrote:
Developing concepts is not a top-down process, nor is it a "chicken and the egg" problem. One way to look at concepts is that they describe common features of related kinds of types, although there is a much more precise way of saying this. How do you know the commonalities of heaps and/or queues if you haven't implemented any?
It's always possible to guess, but why spend the time? The project is to implement data structures, not describe them.
Well, maybe I'm taking a non-standard development approach, but for me the design process goes something like this: - Research algorithm/structure - Determine required functionality - Design interface to reflect the relationship between the theory and the implementation If the previously established theory (which describes the structure) groups a set of structures into a concept and group of "models" (sure, they're still concepts themselves, but...) that all have a well defined set of commonalities, it's not much of an issue to determine what they are, is it? And doesn't a good design from the beginning make the development process easier as time progresses? You end up with a much more coherent library if you have a well-designed interface to which the implementation conforms rather than an implementation that has an interface slapped on top. And of course you can then define an interface later and adapt all the pre-existing structures to match it, but again - if you know at least approximately what the interface should look like, why not start with it in mind? It keeps the code much cleaner. I know that I can't say I've implemented all the heaps. Nor can I say that I know exactly line for line how I will do so. But I can say that I know approximately what functionality I want out of them, and this is what I am trying to reflect with the abstract base class. It is still a draft interface, and subject to change as I begin implementing the various structures and seeing how differences may help to make the library better. But I think it does need to exist from a design decision standpoint. Dan Larkin