Re: Factory pattern and building object

opamail1-googlenews@xxxxxxxxx wrote: 
I am creating a FlowChart type GUI application which has several
diagram items.  I have a DiagramItemFactory which creates concrete
diagram item objects.  I call this factory to create diagram items at
runtime via drag and drop, insert or other. Then I serialize my diagram
to an XML file.  Everything is ok so far.


Sample C# code:
public class DiagramItemFactory
{

public DiagramItem CreateItem(DiagramItemType itemType)
{
    DiagramItem diagramItem = null;
    switch (itemType)
    {
        case DiagramItemType.Square:
	    Square square = new Square();  // square class
	    diagramItem = square;
            break;

        case DiagramItemType.Circle:
	    Circle cirlce = new Circle();  // circle class
	    diagramItem = square;
            break;
    }
    return diagramItem;
}
}

My problem is when I open the file a go through the diagram items
defined in the file, I want to the DiagramItemFactory again to create
the diagram items for the diagram, but the problem is that
the factory only creates the default diagram items and the file
also contains size, color, coordinate and other properties.

Is there another pattern I should be using for opening up the file
and rendering the flow chart diagram?

Thank You,

Opa


May be you should create a DiagramItemObjectState class
instances of which should store all the state data
for a given DiagramItem object.
You should then serialize the state object and  optionally
provide this state information to the factory to restore the
state of the newly created object.

I know its not very clear , so let me try to write some rough code -

DiagramItemObjectState
{
}
SquareObjectState extends DiagramItemObjectState
{
}

DiagramItemDescriptor
{
        /**
        * Can not be null ;
        **/
        DiagramItemType type ;
        /**
        *       May be null for newly created objects (or do something
        *       more elegant ).
        **/
        DiagramItemObjectState state ;

        get/setType() ;
        get/setState() ;
}
DiagramItem
{
        /**
        * This probably should not handle a null state !
        * [Question]: Should you allow this only for not yet
        * initialized objects ?
        **/
        void initializeFrom(DiagramItemObjectState newState)
        {
                setState(newState) ;
        }
        private void setState(DiagramItemObjectState newState) ;
        /**
        * Use this method to store the state of the DiagramItem object
        **/
        DiagramItemDescriptor getDescriptor()
        {
                return new DiagramItemDescriptor(getState(), getType());
        }
}

Add a method in your factory class -
public DiagramItem createItem(DiagramItemDescriptor desc)
{
        DiagramItem item = createDiagramItem(desc.getType()) ;
        item.initializeFrom(desc.getState()) ;
        return item ;
}
There are several decisions that you will have to make -
[*] Do you need two createItem methods ?
[*] Should the initializeFrom use a Descriptor  ?
[*] Is the name "descriptor" good ?

and so on .. but most of these will depend more on you and your application.

The key idea as far as I am concerned is that you should separate the state of the DescriptorItem object in another class and store the state in the objects of this new class.

If you change the type of your object by using a different factory,
the state object may not be compatible with this new type and "initializeFrom" may fail.

Another problem is that it introduces parallel hierarchies as well as doubles the number of classes in the set.
.