Container pattern
In computer programming, 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.
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 containers contents: any container
should be functionally interchangable with any other for the
purposes of inspecting their contents. This employes 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
Referenced By
Design pattern (computer science) | Design pattern (computing) | Software design pattern | Software desisgn pattern | Software pattern
|
