The first key idea is to keep everything extremely simple - simple to understand but also simple to use.
The second one is that only the functionality is important - not the implementation. Nevertheless efficiency is important but the user should not be disturbed by possible implementations.
So the design is strictly on functionality - it is important what one can do with one class. This is definitively not a linear approach. If we apply our approach on plants it will tell us what we can do with a plant - not all the relations between plants. So we have plants we can eat, plants to feed animals, plants we can use to make clothes, plants looking nice and so on. Grouping plants means mainly answering questions like: 'can I eat it?' or 'is this plant useful for the chemical industry?'
This does not mean that the linear approach is a bad one - we only use a different way which may be more useful for the programmer without too much interest into the "zoo" of data structuring.
We need some "things" to store and retrieve data in a convenient, efficient and safe way. We want the following functionality:
We call something we can store data in a CONTAINER_ and something we can remove data from at exactly one place a DISPENSER_. Contrary to this container which allows only to remove item after item (like a salt dispenser) we have other containers which allow us to browse through and to remove, extract and change elements randomly. We call these containers LIST_s if data are stored without key and TABLE_s if they are stored with key.
Note: we use underscore as a part of the name of every container of ours with the only target - to be simply polite - we didn't want to reserve - "to steal" - these popular names... |
To approach this target we finally distinguish 3 different types of containers we can read from (note that ARRAY and STRING are part of the Eiffel Kernel and will not be discussed here):
LIST_ | elements can be read without changing the list |
TABLE_ | the same as LIST_ but with keys |
DISPENSER_ | only one element can be read at the same time |
in terms of writing we distinguish two types:
CONTAINER_ | no keys |
KEYED_CONTAINER_ | elements are stored with keys |
To simplify the manipulation of the LIST_ and TABLE_ objects we introduce also two groups of expert classes: TABLE_ITERATOR_ and LIST_ITERATOR_. These iterators will be explained separately. They are not really necessary, i.e. it is possible to live without them. Despite of this fact they may be useful for special applications and the objective of this class library is to be useful. So we include these classes.