Programming + Errors: 2011

Wednesday, December 21, 2011

Composite Pattern - Java Example

Composite can be used when clients should ignore the difference between compositions of objects and individual objects. 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

Composite pattern in UML.

Component

is the abstraction for all components, including composite ones
declares the interface for objects in the composition
(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

Composite pattern in LePUS3.

Variation

As it is described in Design Patterns, the pattern also involves including the child-manipulation methods in the main Component interface, not just the Composite subclass. More recent descriptions sometimes omit these methods.

Example

The following example, written in Java, implements a graphic class, which can be either an ellipse or a composition of several graphics. Every graphic can be printed. In algebraic form,

Graphic = ellipse | GraphicList
       GraphicList = empty | Graphic GraphicList

It could be extended to implement several other shapes (rectangle, etc.) and methods (translate, etc.).

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();
    }
}

Tuesday, December 20, 2011

Composite Pattern

Motivation

There are times when a program needs to manipulate a tree data structure and it is necessary to treat both Branches as well as Leaf Nodes uniformly. Consider for example a program that manipulates a file system. A file system is a tree structure that contains Branches which are Folders as well as Leaf nodes which are Files. Note that a folder object usually contains one or more file or folder objects and thus is a complex object where a file is a simple object. Note also that since files and folders have many operations and attributes in common, such as moving and copying a file or a folder, listing file or folder attributes such as file name and size, it would be easier and more convenient to treat both file and folder objects uniformly by defining a File System Resource Interface.

Intent

The intent of this pattern is to compose objects into tree structures to represent part-whole hierarchies.
Composite lets clients treat individual objects and compositions of objects uniformly.

Implementation

The figure below shows a UML class diagram for the Composite Pattern:
Composite Pattern Implementation - UML Class Diagram

Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn�t matter if the node is a composite or a leaf.

Applicability & Examples

The composite pattern applies when there is a part-whole hierarchy of objects and a client needs to deal with objects uniformly regardless of the fact that an object might be a leaf or a branch.

Example - Graphics Drawing Editor.

In graphics editors a shape can be basic or complex. An example of a simple shape is a line, where a complex shape is a rectangle which is made of four line objects. Since shapes have many operations in common such as rendering the shape to screen, and since shapes follow a part-whole hierarchy, composite pattern can be used to enable the program to deal with all shapes uniformly.
In the example we can see the following actors:

Shape (Component) - Shape is the abstraction for Lines, Rectangles (leafs) and and ComplexShapes (composites).
Line, Rectangle (Leafs) - objects that have no children. They implement services described by the Shape interface.
ComplexShape (Composite) - A Composite stores child Shapes in addition to implementing methods defined by the Shape interface.
GraphicsEditor (Client) - The GraphicsEditor manipulates Shapes in the hierarchy.

Alternative Implementation: Note that in the previous example there were times when we have avoided dealing with composite objects through the Shape interface and we have specifically dealt with them as composites (when using the method addToShape()). To avoid such situations and to further increase uniformity one can add methods to add, remove, as well as get child components to the Shape interface. The UML diagram below shows it:
Composite Pattern Alternative Implementation - UML Class Diagram

Composite Pattern Alternative Implementation - UML Class Diagram

Source: Click here to see java source code

Specific problems and implementation

Graphics Editors use composite pattern to implement complex and simple graphics as previously explained.
File System implementations use the composite design pattern as described previously.

Consequences

The composite pattern defines class hierarchies consisting of primitive objects and composite objects. Primitive objects can be composed into more complex objects, which in turn can be composed.
Clients treat primitive and composite objects uniformly through a component interface which makes client code simple.
Adding new components can be easy and client code does not need to be changed since client deals with the new components through the component interface.

Related Patterns

Decorator Pattern - Decorator is often used with Composite. When decorators and composites are used together, they will usually have a common parent class. So decorators will have to support the Component interface with operations like Add, Remove, and GetChild.

Known Uses

File System Implementation as discussed previously.

Composite Design Pattern

Add caption

Ignoring Inheritance with @XmlTransient

In previous articles I have covered how to map inheritance relationships in JAXB and EclipseLink MOXy. In this example I will describe how to remove an inheritance relationship in JAXB by leveraging @XmlTransient at the type level.

Java Model

Base

In this example we want all of our domain objects to have an id property. We will accomplish this by having all of our domain objects extend the same base class (Base). Since this base class is not relevant to the domain model we will tell JAXB to ignore it by marking it @XmlTransient.

package blog.inheritance.xmltransient;
 
import javax.xml.bind.annotation.XmlTransient;
 
@XmlTransient
public abstract class Base {
 
    private int id;
 
    public int getId() {
        return id;
    }
 
    public void setId(int id) {
        this.id = id;
    }
 
}

Customer

Since the parent class has been marked @XmlTransient the id property will be treated as part of the child classes. In the Customer class we will demonstrate this by including the id property in the propOrder specified on @XmlType.

package blog.inheritance.xmltransient;
 
import java.util.List;
 
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;
 
@XmlRootElement
@XmlType(propOrder={"id", "name", "address", "phoneNumbers"})
public class Customer extends Base {
 
    private String name;
    private Address address;
    private List<PhoneNumber> phoneNumbers;
 
    public String getName() {
        return name;
    }
 
    public void setName(String name) {
        this.name = name;
    }
 
    public Address getAddress() {
        return address;
    }
 
    public void setAddress(Address address) {
        this.address = address;
    }
 
    @XmlElement(name="phone-number")
    public List<PhoneNumber> getPhoneNumbers() {
        return phoneNumbers;
    }
 
    public void setPhoneNumbers(List<PhoneNumber> phoneNumbers) {
        this.phoneNumbers = phoneNumbers;
    }
 
}

Address

package blog.inheritance.xmltransient;
 
public class Address extends Base {
 
    private String street;
 
    public String getStreet() {
        return street;
    }
 
    public void setStreet(String street) {
        this.street = street;
    }
 
}

PhoneNumber

package blog.inheritance.xmltransient;
 
public class PhoneNumber extends Base {
 
    private String number;
 
    public String getNumber() {
        return number;
    }
 
    public void setNumber(String number) {
        this.number = number;
    }
 
}

Demo Code

Below is the demo code that can be used to run this example:

package blog.inheritance.xmltransient;
 
import java.io.File;
 
import javax.xml.bind.JAXBContext;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;
 
public class Demo {
 
    public static void main(String[] args) throws Exception {
        JAXBContext jc = JAXBContext.newInstance(Customer.class);
 
        Unmarshaller unmarshaller = jc.createUnmarshaller();
        Customer customer = (Customer) unmarshaller.unmarshal(new File("input.xml"));
 
        Marshaller marshaller = jc.createMarshaller();
        marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
        marshaller.marshal(customer, System.out);
    }
 
}

XML (input.xml)

In the XML you will notice that there are no inheritance indicators present. The properties of the base class are simply treated as properties of the respective subclasses:

<?xml version="1.0" encoding="UTF-8"?>
<customer>
   <id>12</id>
   <name>Jane Doe</name>
   <address>
      <id>34</id>
      <street>1 A Street</street>
   </address>
   <phone-number>
      <id>45</id>
      <number>555-1111</number>
   </phone-number>
   <phone-number>
      <id>67</id>
      <number>555-2222</number>
   </phone-number>
</customer>
 
http://blog.bdoughan.com/2011/06/ignoring-inheritance-with-xmltransient.html

JAXB - self-referential-objects-and-downcasting

You can solve the issue by marking the IdentifiableObject class with @XmlTransient: Nodes

package forum8257098;

import java.util.List;

import javax.xml.bind.annotation.*;

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Nodes {

    @XmlElement(name="node")
    private List<Node> nodes;

}

Node

package forum8257098;

import javax.xml.bind.annotation.*;

@XmlRootElement
public class Node extends IdentifiableObject {

    @XmlElement
    private Node parent;

    @XmlElement
    private String aField;

}

IdentifiableObject

package forum8257098;

import javax.xml.bind.annotation.*;

@XmlTransient
public class IdentifiableObject {

    @XmlID
    @XmlAttribute
    private String id;

    @XmlAttribute
    private String name;

}

Demo

package forum8257098;

import java.io.File;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.Marshaller;
import javax.xml.bind.Unmarshaller;

public class Demo {

    public static void main(String[] args) throws Exception {
        JAXBContext jc = JAXBContext.newInstance(Nodes.class);

        Unmarshaller unmarshaller = jc.createUnmarshaller();
        File xml = new File("src/forum8257098/input.xml");
        Nodes nodes = (Nodes) unmarshaller.unmarshal(xml);

        Marshaller marshaller = jc.createMarshaller();
        marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
        marshaller.marshal(nodes, System.out);
    }

}

Input/Output

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<nodes>
    <node name="Node 1" id="49ad1cb6-f6fe-47f9-a544-4a1c6337c4a5">
        <aField>This is Node 1</aField>
    </node>
    <node name="Node 2" id="0a1d1895-49e1-4079-abc1-749c304cc5a2">
        <parent name="Node 1" id="49ad1cb6-f6fe-47f9-a544-4a1c6337c4a5"/>
        <aField>This is Node 2</aField>
    </node>
</nodes>

For More Information

http://blog.bdoughan.com/2011/06/ignoring-inheritance-with-xmltransient.html

Sunday, December 18, 2011

JAXB & Collection Properties

In this post will examine the different options JAXB offers for representing collections in XML. We will look at the following annotations:

@XmlElement
@XmlElementWrapper
@XmlList
@XmlList and @XmlAttribute
@XmlList and @XmlValue

Java Model

For this example we will use the following model. We will apply different JAXB annotations to observe the effect it has on the XML representation.

import java.util.*;
import javax.xml.bind.annotation.*;
 
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Customer {
 
    private List<String> emailAddresses;
     
    public Customer() {
        emailAddresses = new ArrayList<String>();
    }
 
    public List<String> getEmailAddresses() {
        return emailAddresses;
    }
 
    public void setEmailAddresses(List<String> emailAddresses) {
        this.emailAddresses = emailAddresses;
    }
 
}

Demo Code

The following code will be used to convert the Customer object to XML. We will examine the impact of changing the metadata on the XML representation.

import javax.xml.bind.JAXBContext;
import javax.xml.bind.Marshaller;
 
public class Demo {
 
    public static void main(String[] args) throws Exception {
        JAXBContext jc = JAXBContext.newInstance(Customer.class);
 
        Customer customer = new Customer();
        customer.getEmailAddresses().add("janed@example.com");
        customer.getEmailAddresses().add("jdoe@example.org");
 
        Marshaller marshaller = jc.createMarshaller();
        marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
        marshaller.marshal(customer, System.out);
    }
}

Default

By default each item in the collection will be marshalled to an XML element.

<customer>
    <emailAddresses>janed@example.com</emailAddresses>
    <emailAddresses>jdoe@example.org</emailAddresses>
</customer>

@XmlElement

We can control the name of the XML element a collection item is marshalled to by using the @XmlElement annotation.

import java.util.*;
import javax.xml.bind.annotation.*;
 
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Customer {
 
    @XmlElement(name="email-address")
    private List<String> emailAddresses;
 
}