Question

Let’s say I have a class that represents a printing job: CPrintingJob. It knows nothing of the document being printed, just the job state – whether the job was queued, rejected, carried on etc.

The idea is an object of this class is instantiated whenever some printing needs to be done, then passed to the printing module along with other data, then the job’s creator checks its state to see how printing is going.

Suppose CPrintingJob inherits two interfaces:

class IPrintingJob // this one is to check the job state
{
    virtual TState GetState() const = 0;
    // ... some other state-inquiring methods

    class ICallback // job's owner is notified of state changes via this one
    {
        virtual void OnStateChange( const IPrintingJob& Job ) = 0; 
    };
};

and

class IPrintingJobControl // this one is for printing module to update the state
{
    virtual void SetState( const TState& NewState ) = 0;
    // ... some other state-changing methods
};

Problem is, the class that creates a CPrintingJob object shouldn’t have access to the IPrintingJobControl, but the printing module CPrintingJob is being passed to must be able to change its state and, therefore, have access to that interface.

I suppose this is exactly the case where friends should be used but I have always avoided them as an inherently flawed mechanic and consequently have no idea of how to use them properly.

So, how do I do it properly?

Answer 1

Use a factory and have the factory return an instance of IPrintingJob (best wrapped inside a smart_ptr). e.g.:

 struct PrintingFactory {
   static auto create() -> std::unique_ptr<IPrintingJob> {
     return std::unique_ptr<IPrintingJob>(new CPrintingJob());//as there is currently no std::make_unique..
   }
 }

Once you have to use the JobControl you can simply cast the pointer via std::dynamic_pointer_cast.