The whole concept of this design pattern lies in the fact that we can treat a composite object which consists of several other objects the same way as a leaf object. The client never knows that it is working on an object which has many other objects inside it.
Let us try to understand the composite pattern with an example. Here we have defined a class namely Shape, which is acting as the root of all the objects in the example. We have put all the basic functionalities of a graphical object in this class. These functions are Add (for adding a component), Remove (for removing a component), GetChild (for getting a pointer to a child), GetParentOfComponent (which will return the parent of a component) and Draw (to draw a component).
class Shape
{
public:
Shape(){}
virtual void Add(unsigned int id)
{
throw LeafClassTypeException();
};
virtual void Remove(unsigned int id){};
//leaf classes will not override it..however, it will be overridden by the composite class.
virtual Shape* GetChild(unsigned int id)
{
throw LeafClassTypeException();
};
//Using this reference the "Chain of Responsibility" can be implemented
virtual Shape* GetParentOfComponent()
{
return ParentOfComponent;
};
virtual void SetParentOfComponent(Shape* s)
{
ParentOfComponent = s;
}
virtual void Display(){};
virtual Shape* FindItem(unsigned int id); //implementation afterwards
virtual ~Shape(){};
protected:
Shape* ParentOfComponent;
unsigned int resource_id;
};
typedef map (unsigned int, Shape*, less(unsigned int)) theMap;
theMap Resource_Map;
theMap::iterator theIterator;
Shape* Shape::FindItem(unsigned int id)
{
theIterator = Resource_Map.begin();
while (theIterator != Resource_Map.end())
{
theIterator = Resource_Map.find(id);
Shape* s = (*theIterator).second;
theIterator++;
return s;
}
return NULL;
}
Now from the Shape class, we have derived other graphic classes, like Point, Line and Rectangle. Among these classes, class Point is working as an helper class to define classes like Line and Rectangle. We have deduced another class called Picture which is composed of these component classes.
class Point : public Shape
{
public:
Point():x_Coord(0),y_Coord(0){}
Point(int x, int y):x_Coord(x), y_Coord(y){}
Point(const Point& p)
{
x_Coord = p.x_Coord;
y_Coord = p.y_Coord;
}
Point& operator = (const Point& p)
{
x_Coord = p.x_Coord;
y_Coord = p.y_Coord;
return *this;
}
virtual void Display()
{
cout<<"X Coordinate is:"<
int X_COORD()
{
return x_Coord;
}
int Y_COORD()
{
return y_Coord;
}
virtual ~Point(){}
private:
int x_Coord;
int y_Coord;
};
class Line : public Shape
{
private:
Line(unsigned int id):begin(0,0),end(0,0)
{
resource_id = id;
Resource_Map.insert(theMap::value_type(resource_id,(Shape*)this));
}
Line(unsigned int id, Point a, Point b):begin(a),end(b)
{
resource_id = id;
Resource_Map.insert(theMap::value_type(resource_id,(Shape*)this));
}
public:
virtual void Display()
{
cout<<"Begining point is:";
begin.Display();
cout<<"End Point is:";
end.Display();
}
static Line* CreateLine(unsigned int id, Point a, Point b)
{
return new Line(id,a,b);
}
virtual ~Line(){}
private:
Point begin;
Point end;
};
class Rectangle : public Shape
{
private:
Rectangle(unsigned int id, Point& p, int width, int height)
{
top_left = p;
top_right = Point(p.X_COORD() + width, p.Y_COORD());
bottom_left = Point(p.X_COORD() , p.Y_COORD() + height);
bottom_right = Point(p.X_COORD() + width, p.Y_COORD() + height);
resource_id = id;
Resource_Map.insert(theMap::value_type(resource_id,(Shape*)this));
}
public:
static Rectangle* CreateRectange(unsigned int id, Point& p, int width, int height)
{
return new Rectangle(id, p, width, height);
}
virtual ~Rectangle(){}
virtual void Display()
{
cout<<"The four vertices are:"<
top_left.Display();
cout <<"Top Right :";
top_right.Display();
cout<<"Bottom Left :";
bottom_left.Display();
cout<<"Bottom Right :";
bottom_right.Display();
}
//Attributes
private:
Point top_left;
Point top_right;
Point bottom_left;
Point bottom_right;
};
The interesting point here is that, we have tried to implement the leaf classes, namely Line and Rectangle as final classes by making their constructors private and providing static member functions to create them.
The Picture class is composed of these leaf objects (Line and Rectangle).
class Picture : public Shape
{
public:
Picture(unsigned int id)
{
resource_id = id;
Resource_Map.insert(theMap::value_type(resource_id,(Shape*)this));
}
virtual void Display()
{
vector
while (p != Components.end())
{
(*p)->Display();
p++;
}
}
//Adds the component with the resource id equal to the passed parameter
virtual void Add (unsigned int id)
{
Shape* s = FindItem(id);
Components.push_back(s);
s->SetParentOfComponent(this);
}
//removes the component from the list with the resource_id equal to the parameter passed
virtual void Remove(unsigned int id)
{
Shape* s = FindItem(id);
vector
int pos = 0;
while (p != Components.end())
{
if(Components.at(pos) == s)
break;
pos++;
p++;
}
Components.erase(p);
s->SetParentOfComponent(NULL);
}
//will return the chile having the id equal to the passed value.
virtual Shape* GetChild (unsigned int id)
{
return FindItem(id);
}
virtual ~Picture()
{
vector
int pos = 0;
while (p != Components.end())
{
delete(Components.at(pos));
p++;
pos++;
}
Components.clear();
}
private:
vector
};
The Shape class is called as the Component class, the Line and Rectangle classes are called the Leaf classes and the Picture class is called the Composite class.
Another interesting part of the example is that here every component is identifiable through its resource id. Whenever we create an object (leaf or composite object), it creates a key pair of the id and the pointer to that object and pushes this key into a MAP, from which we can easily search for that component in later times through its resource id.
There are many issues to consider when implementing the composite pattern.
We have defined one function called GetParentOfComponent. This can be useful to traverse the whole hierarchy of parent-child relationship. We have to make sure that any child can have only a composite object as its parent. We have ensured it by defining an Exception class which will be thrown the moment we want to add a component to a leaf object. The exception class can be defined as follows:
class LeafClassTypeException
{
public:
void printerrormsg()
{
cout<<"This is a leaf class"<
}
};
It should be noted that the functions like Add and Remove have been defined in the root class. Although for leaf classes, it does not do any meaningful things except throwing an exception, but it gives us transparency, because we can treat all components uniformly.
If we define these functions at the composite class level, then it would give the safety, because any attempt to Add or Remove from the leaf classes would give compile time error, but we would loose the transparency. The composite and the leaf classes will have different interfaces in this case.
The main participants in this design pattern are
Component (Shape) : It basically works as an abstract class which provides a common interface which will be used by the client to treat different classes uniformly. The common functionalities (e.g. Display) have been defined here. Other functionalities like Add, Remove, etc have been put in this class to maximize the role of this interface. The default behavior for Add and Remove has been implemented in such a fashion that for a leaf class, these functions will throw exceptions.
Leaf (Line, Rectangle, etc) : It represents a leaf objects in the composition. Leaf objects cannot have any children.
Composite (Picture) : It stores child components.
Client: It manipulates the objects through the common interface exposed by the Component class.
0 comments:
Post a Comment