views:

67

answers:

1

I have the following design request for a visual editing tool written in C++:

  • be able to define a template object (assign image, edit default rotation/scale, edit default property values)
  • be able to place instances of template object in view
  • be able to make changes to template object (eg different image, change rotation, scale, property values) with all instances using the new values immediately or after clicking "Apply"
  • Exception: if rotation, scale or any property value has been modified (overridden) at the instance, it should no longer take that value from its template!

What are good design choices for implementing such a template-instance relationship in C++ with the additional condition of instances being able to override template values? Is there a design pattern for that?

I came up with a few ideas but none strike me as the way to go. For example, I could have a TemplateObject class and a TemplateObjectInstance class. Through a 1-to-many relationship they "know" each other and for example, instances could check if a property is overridden locally (entry in TemplateObjectInstance's properties dictionary exists) and if not, tries to get the value from its parenting TemplateObject properties dictionary instead. Is that a solution that would work well enough?

Note: this question is not about C++ Templates.

+2  A: 

I don't see why this needs to be complicated. Unless there are additional constraints you're not letting us know about...

class RealItem;

class TemplateItem 
{
    //data members
public:
    //set properties and such
    RealItem MakeRealItem() const; //Generates a RealItem from this template.
};

class RealItem
{
    //etc...
};
Billy ONeal
The third bullet point requires that changes to the template are propagated to the real instances, so you'll also need an observer mechanism.
Mike Seymour
@Mike: Okay, a map of properties in `RealItem`, and a pointer back to `TemplateItem` when/if those items are not found in the instance map. No need for an observer pattern here -- instances can just get the value from the template when needed.
Billy ONeal
@Billy: You also need notification that the template has changed, so the objects know to redraw themselves. Which brings you back to an observer pattern.
Mike Seymour
@Mike: Okay, but that's a UI concern -- it has little to do with how you design how the classes internally operate. The notification to update the UI should be completely separate from the data structures in any case.
Billy ONeal
@Billy: If it's acceptable to force an update of the entire view when any object changes, then fine; implement the objects as pure data structures, and implement the notification separately. An observer pattern allows finer control of what needs updating, while still decoupling the model from the view.
Mike Seymour
thanks for that conversation, very helpful because I've been going through the same thoughts ... :)
GamingHorror
btw, there was one constraint I didn't mention but I think it doesn't really matter. It's whether I can re-use the image of the Template object while allowing instances to rotate, scale, etc their individual images. But that's not an issue as I found out.
GamingHorror