CODEWITHSUNDEEP
c++design-patternsfactory
Jonathan H
Jonathan H

Reputation: 7953

Correct pattern to configure objects built by Factory

I've had this problem tickling me for the past weeks; my current implementation works, but I'm curious to know if there is a "good way" to do this. I'm new to design patterns, so this might be a stupid question.

Put simply, you have:

My problem is this; specific kernels implementations may define their own set of parameters, which differ from one kernel to another. Foo uses kernels to do some processing, but this processing ultimately depends on these parameters, and I don't know how to configure those in a nice way.

I don't want to go for an abstract factory, and configure the concrete factory before building, because this seems wrong to me; it's not the factory that has parameters, it's the kernel.

But on the other hand, even if I set the kernel pointer in Foo as public, I can't access the parameters of the underlying kernel since they're not part of the prototype's interface... I'm sure other people had this problem before, maybe there's a simple solution I don't see. :S

Thanks in advance!

NOTE: In my current implementation, there is no kernel Factory. I put the kernel concrete type as a template of Foo, and set the kernel as a public member, which allows me to configure the kernel after the declaration, and before to start the processing.

Upvotes: 0

Views: 184

Answers (2)

n. m. could be an AI
n. m. could be an AI

Reputation: 119877

If a piece of code knows what concrete kind of kernel it works with, it should have a pointer to that specific concrete kernel type. If it doesn't, it cannot access its specific parameters (but can possibly access all parameters in a generic way as suggested by @Jaywalker).

Your current implementation seems to go the first route, which is perfectly OK.

I have very limited info about your design, but it looks like you have several concrete kernel types, a separate builder for each type, and a separate configurator for each type. Packing all the builders into a Factory is problematic, as there's no clean and elegant way to forward concrete kernel types to their respective configurators (without things like *_cast<> or double dispatch). There are at least two ways to solve this and still have a Factory:

  1. Bundle each builder with its respective configurator, and pack all the bundles into a Factory that churns out configured kernels.
  2. Bundle each kernel with its configurator and make a Factory producing these bundles (this way a kernel may be configured any number of times during its life cycle).

Upvotes: 1

Jaywalker
Jaywalker

Reputation: 3119

Anything which is not part of the prototype interface will not be available in Foo, as you have said. It simply doesn't make sense to use the factory pattern if Foo knows the specifics of each kernel implementation.

In some limited circumstances, adding something like following getters and setters in the prototype interface could get your work done:

virtual bool setParameter (const string &key, const string &value) = 0;
virtual string getParameter (const string &key) = 0;

Upvotes: 1

Related Questions