Composite pattern

TOC:

· Discussion

· UML

· Simple example… updating window display

· Simple example…drawing shapes

· Simple example…dir structure

· JTree examples

o A SUN tutorial

o Displaying corporate personnel structure as a tree

o Parse xml file to JTree

· Related to the last JTree example… SAXparsing an XML file to JTable view

· Maven chapter 4 yahoo weather display

In computer science, the composite pattern is a partitioning design pattern. Composite allows a group of objects to be treated in the same way as a single instance of an object. The intent of composite is to "compose" objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly.

Motivation

When dealing with tree-structured data, programmers often have to discriminate between a leaf-node and a branch. This makes code more complex, and therefore, error prone. The solution is an interface that allows treating complex and primitive objects uniformly. In object-oriented programming, a composite is an object (e.g., a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them. The operations you can perform on all the composite objects often have a least common denominator relationship. For example, if defining a system to portray grouped shapes on a screen, it would be useful to define resizing a group of shapes to have the same effect (in some sense) as resizing a single shape.

When to use

Composite can be used when clients should ignore the difference between compositions of objects and individual objects.^[1] If programmers find that they are using multiple objects in the same way, and often have nearly identical code to handle each of them, then composite is a good choice; it is less complex in this situation to treat primitives and composites as homogeneous.

Structure

Java developers need the Composite pattern because we often must manipulate composites exactly the same way we manipulate primitive objects. For example, graphic primitives such as lines or text must be drawn, moved, and resized. But we also want to perform the same operation on composites, such as drawings, that are composed of those primitives. Ideally, we'd like to perform operations on both primitive objects and composites in exactly the same manner, without distinguishing between the two. If we must distinguish between primitive objects and composites to perform the same operations on those two types of objects, our code would become more complex and more difficult to implement, maintain, and extend.

Composite pattern in UML.

Composite pattern in LePUS3.

Component

is the abstraction for all components, including composite ones
declares the interface for objects in the composition
implements default behavior for the interface common to all classes, as appropriate
declares an interface for accessing and managing its child components
(optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate

Leaf

represents leaf objects in the composition
implements all Component methods

Composite

represents a composite Component (component having children)
implements methods to manipulate children
implements all Component methods, generally by delegating them to its children

And another site with a composite example/discussion http://userpages.umbc.edu/~tarr/dp/lectures/Composite.pdf Discussion from that site omitted here. Their example shows how code to update window widgets (buttons, textareas, menus, and containers of other widgets) might apply this pattern:

First try:

public void update() {

if (buttons != null)

for (int k = 0; k < buttons.length; k++)

buttons[k].draw();

if (menus != null)

for (int k = 0; k < menus.length; k++)

menus[k].refresh();

// Other widgets handled similarly.

if (containers != null)

for (int k = 0; k < containers.length; k++ )

containers[k].updateWidgets();

}

...}

Second try:

public class Window {

Widget[] widgets;

WidgetContainer[] containers;

public void update() {

if (widgets != null)

for (int k = 0; k < widgets.length; k++)

widgets[k].update();

if (containers != null)

for (int k = 0; k < containers.length; k++ )

containers[k].updateWidgets();

}}

Then, using composite pattern:

public class Window {

Component[] components;

public void update() {

if (components != null)

for (int k = 0; k < components.length; k++)

components[k].update();

}}

A graphics class example in java, which looks sort of like it might work for our shape sorter, except that sufficient detail to implement the shape drawing strategy is omitted.

import java.util.List;

import java.util.ArrayList;

/** "Component" */

interface Graphic {

//Prints the graphic.

public void print();

}

/** "Composite" */

class CompositeGraphic implements Graphic {

//Collection of child graphics.

private List<Graphic> mChildGraphics = new ArrayList<Graphic>();

//Prints the graphic.

public void print() {

for (Graphic graphic : mChildGraphics) {

graphic.print();

}

//Adds the graphic to the composition.

public void add(Graphic graphic) {

mChildGraphics.add(graphic);

}

//Removes the graphic from the composition.

public void remove(Graphic graphic) {

mChildGraphics.remove(graphic);

}

/** "Leaf" */

class Ellipse implements Graphic {

//Prints the graphic.

public void print() {

System.out.println("Ellipse");

}

/** Client */

public class Program {

public static void main(String[] args) {

//Initialize four ellipses

Ellipse ellipse1 = new Ellipse();

Ellipse ellipse2 = new Ellipse();

Ellipse ellipse3 = new Ellipse();

Ellipse ellipse4 = new Ellipse();

//Initialize three composite graphics

CompositeGraphic graphic = new CompositeGraphic();

CompositeGraphic graphic1 = new CompositeGraphic();

CompositeGraphic graphic2 = new CompositeGraphic();

//Composes the graphics

graphic1.add(ellipse1);

graphic1.add(ellipse2);

graphic1.add(ellipse3);

graphic2.add(ellipse4);

graphic.add(graphic1);

graphic.add(graphic2);

//Prints the complete graphic (four times the string "Ellipse").

graphic.print();

}

(Output is just the list of leaf ellipses.) Exercise… modify the above to draw ellipses rather than write the word ellipse, for the leaf node elements.

A frequently used composite example is in examining/generating directory structure. Here’s an example of this:

import java.util.*;

// Define a "lowest common denominator"

interface AbstractFile

{

public void ls();

}

// File implements the "lowest common denominator"

class File implements AbstractFile

{

public File(String name)

{

m_name = name;

}

public void ls()

{

System.out.println(CompositeDemo.g_indent + m_name);

}

private String m_name;

}

// Directory implements the "lowest common denominator"

class Directory implements AbstractFile

{

public Directory(String name)

{

m_name = name;

}

public void add(Object obj)

{

m_files.add(obj);

}

public void ls()

{

System.out.println(CompositeDemo.g_indent + m_name);

CompositeDemo.g_indent.append(" ");

for (int i = 0; i < m_files.size(); ++i)

{

// Leverage the "lowest common denominator"

AbstractFile obj = (AbstractFile)m_files.get(i);

obj.ls();

}

CompositeDemo.g_indent.setLength(CompositeDemo.g_indent.length() - 3);

}

private String m_name;

private ArrayList m_files = new ArrayList();

}

public class CompositeDemo

{

public static StringBuffer g_indent = new StringBuffer();

public static void main(String[] args)

{

Directory one = new Directory("dir111"), two = new Directory("dir222"),

thr = new Directory("dir333");

File a = new File("a"), b = new File("b"), c = new File("c"), d = new

File("d"), e = new File("e");

one.add(a);

one.add(two);

one.add(b);

two.add(c);

two.add(d);

two.add(thr);

thr.add(e);

one.ls();

}

Output is not too impressive but shows the dir structure:

dir111

dir222

dir333