Which design pattern?

Question

Hello!

I am looking for a couple of patterns or design ideas for implementation in C++ that would allow the following.

1.

• pool of similar objects
• objects requested and relinquished by client
• pool grows when exhausted, does not shrink
• there will be multiple clients (one pool per client to avoid mutexing)

An Object Pool seems most appropriate.

2.

The objects obtained from the pool will be data processors that will be chained together dynamically. Each object will perform some operation that may or may not alter the data before passing the data on (or they may terminate the chain).

This requirement has me a little stuck. I was considering something along the lines of a modified Chain of Responsibility where the data will be passed to all.

However, I'm wary of simply plucking pattern from the air and assuming its the best approach so I'd appreciate some feedback, alternative ideas and draw on the experience of others!

Thanks,

Stuart.

Thanks for the feedback so far:

The objects perform decode/analysis/transformation of real-time data. The pool would contain objects various objects derived from the same base class.

A control plane will dynamically create and initialise the chain of objects and the objects according to external criteria.

Format of the data can be explicitly indicated/updated as it passed through the objects. However this is isolated and of little consequence as it known at chain creation.

The strategy pattern deserves some studying.

Answer 1

You need to give more details on how these object will be used. Do the interact?

You will also need a manager to manage the life-cycle of objects (creation, distribution). The manager is typically implemented as a singleton... Also consider a builder pattern to create objects.

Answer 2

You do seem to have identified the key patterns, except that I'm not sure how the "objects in the pool" differ among them (if they do) -- i.e., how does each object know to perform possibly different processing before handing the (possibly-modified) data on to the next object in the chain (or breaking the chain)? If the objects are in a pool then I guess they'd better be undifferentiated and undistinguishable -- so, do you need a Strategy pattern too, to make such identical objects perform different processing and logic...?

Answer 3

A pool of "similar" objects? The nature of pools is that when you request an item from a pool you don't know which one you are getting. So similar isn't enough, they need to be the same.

But then they are chained? So they are different? So when you get an object you in some way "configure" it. And that configuration can be undone so that the object can be returned to the pool?

So my first question is: why not just "new" the object when you want them and delete them when finished (or have them gc-ed)?

You don't say what drives you towards the idea of a pool. Is the cost of creating these objects very high? Patterns need context, you've not given enough information to let us comment on the appropriateness of a pool.

A thought: Pattern == Code, Code == bug. Less code == fewer bugs. Keep it simple if you can.

The chain of responsibility idea sounds plausible, but again you don't give enough inforamtion. Does the sequence of the "chain" matter? How is it determined? Does it change over time? Is it really a chain or more like a "net". Do all objects transform data? What are the implications of doing a transform, might that affect how prior items in the chain would think about the object?

It sounds like you've got some very flexible processing in mind. Are you building excessive flexibility? What requirement led to this "Chain" concept?