Container pattern
|
|
In computer programming, the container pattern is one of design patterns in which objects are created to hold other objects. Queues, FIFOs/stacks, buffers, shopping carts, and caches all fit this description.
Breadth first recursion has an example of recursing through a network of objects to find them all, where a queue is used to hold unexplored paths. <math>Insert formula here<math> Iterator interface is an important part of all objects that act as containers in one way or another. It provides a consistent way to loop through that container's contents: any container should be functionally interchangeable with any other for the purposes of inspecting their contents. This employs the ideas of abstract root classes and abstract class.
Template class talks about generators for containers. Type safety breaks down when presented with generic, reusable containers that can hold any type of data. If a container only holds one specific type of data, we know any items retrieved from it are of the correct type, and no type errors can occur, but then we can't reuse that container. TemplateClass follows C++'s ideas of templates, and provides a generic implementation that can create instances tailored to specific data types to enforce safety. ObjectOriented purists will find this of interest.
Aggregation pattern and state vs class talk about other, more present, type issues that crop up when creating containers full of subclasses of a certain type. What if one subclass doesn't do something the superclass does? Model it as state. Null-methods are okay. Don't fork the inheritance to remove a feature. Similar to Introduce null object, but for methods.
Object oriented design heuristics, section 5.19, has an example of a basket that cores fruit. How could this possibly made general? Anything other than a fruit would need a //->core()// method that does nothing, requiring a base class implementing a stub //core()// to be inherited by all.
Extract a generic interface:
- Generalize - Rather than //core()//, why not //prepare()//? Oranges
could peel themselves, grapes devine themselves, and so forth. Method calls aren't instructions on how to do something but rather a request that an end be achieved. How it is done is best left to the object.
- Extract interface - Given a saner interface, make it optional.
Let the basket test //->can('prepare')//. If the item is capable of doing so, it may. If it isn't, no big deal. The magic basket prepares fruit. Not preparing non-fruit is okey. No one ever said just because it prepares fruit it has to blow up when presented with non-fruit. This is somewhat of a compromise - TypeSafety doesn't exist for things wishing to use the basket as a repository for all things fruit and no thing not fruit. Useful for avoiding interfacebloat
The article is originally from Perl Design Patterns Book.