Multiple Pimpl-classes using each other

Question

I have three classes that I expose to the user via pimpl. The Model is a data container that can be read from and written to a file. The Manipulator is an object that can load a Model, perform changes and return it as a new Model. The Consumer loads a Model and allows the user to things with it (read its properties, print it etc.).

class Model {
    Model(std::string &filename);
    void toFile(std::string &filename);
private:
    class ModelImpl;
    std::unique_ptr<ModelImpl> mImpl;
};

class Manipulator {
    Manipulator(Model &model);
    Model alterModel(...);
private:
    class ManipulatorImpl;
    std::unique_ptr<ManipulatorImpl> mImpl;
};

class Consumer {
    Consumer(Model &model);
    void loadModel(Model &model);
    void doSomething();
private:
    class ConsumerImpl;
    std::unique_ptr<ConsumerImpl> mImpl;
};

The reason for using pimpl is primarily to hide the internal data types used by the Model. The only types visible to the user should be Model, Manipulator and Consumer and standard c++ types.

The issue I am having here is in the implementations ConsumerImpl and ManipulatorImpl: in those classes I have to access the underlying data structures of the ModelImpl, but pimpl hides them:

Consumer::ConsumerImpl::loadModel(Model model) {
    auto someModelValue = model.mImpl->someInternalValue;
}

Obviously this does not work. How to solve this? Is pimpl the right solution here?

Edit: My colleague came up with this:

class Consumer {
    Consumer(Model &model);
    void loadModel(Model &model);
    void doSomething();
private:
    class ConsumerImpl;
    std::unique_ptr<ConsumerImpl> mImpl;
};

class Model {
    Model(std::string &filename);
    void toFile(std::string &filename);
private:
    void *getObjectPtr();
    class ModelImpl;
    std::unique_ptr<ModelImpl> mImpl;
    friend Consumer;
};

void *Model::Model::getObjectPtr() {
    return mImpl->getObjectPtr();
}



class Model::ModelImpl {
public:
//    [...]
    void *getObjectPtr();

private:
    SecretInternalType mData;
};

void *Model::ModelImpl::getObjectPtr() {
    return static_cast<void*>(&mData);
}


// Access the internal data of Model from Consumer:
void Consumer::ConsumerImpl::doSomething() {
    SecretInternalType* data = static_cast<SecretInternalType*>(mModel->getObjectPtr());
}

Basically the Model has a method that returns a void pointer to the (hidden) internal data. The consumer can get this pointer, cast it back to the correct type and access the data. To make this only accessable from the Consumer class, the method is private but friends with Consumer.

I implemented this approach and it works for me. Still I am curious what you think of it and if there are any problems.

Answer 1

The issue you are facing isn't really related to the Pimpl idiom - imagine you erase the pimpl related parts of your snippets, the problem stays the same as it's caused by the need to access the private representation of your Model (or ModelImpl) instance. This is how I would try to approach the situation:

• Define a list of operations that make sense for a Consumer instance to invoke on a Model instance. These should be part of Model's public interface. Do the same for the relationship between Model and Manipulator. If that clutters your Model interface too much, split it into two separate abstract classes, let a Model implementation inherit from both and Consumer/Maninpulator operate on the base class interface that's meant for them.
• Reconsider which parts of Model are worth hiding. If Model owns some container that needs to be accessed from a consumer, expose it (Effective STL, Item 2), read access via an appropriate method should be fine.
• If Consumer objects still need more information, their own role could be more than an ordinary consumer, so maybe some parts of their implementation should be implemented in another class or in the model?
• Introduce a(n) (abstract) class for data exchange between Model and Consumer. Pass this from Consumer to Model, let the Model choose which information to pas to the intermediate layer. But this already introduces a certain amount of complexity that might be quite unnecessary.

Whatever changes you apply to your design, you can still choose whether to use the Pimpl idiom with forwarding methods or not. And one last suggestion: don't declare one of the classes friend - this might be quite opinionated but your scenario doesn't suggest that such a strong coupling is necessary.