Composition

As you progress in an object-oriented design, you will likely encounter objects

in the problem domain that contain other objects. In this situation you will be
drawn to modeling a similar arrangement in the design of your solution. In an ob
ject-oriented design of a Java program, the way in which you model objects that
contain other objects is with composition, the act of composing a class out of r
eferences to other objects. With composition, references to the constituent obje
cts become fields of the containing object.
For example, it might be useful if the coffee cup object of your program could c
ontain coffee. Coffee itself could be a distinct class, which your program could
instantiate. You would award coffee with a type if it exhibits behavior that is
important to your solution. Perhaps it will swirl one way or another when stirr
ed, keep track of a temperature that changes over time, or keep track of the pro
portions of coffee and any additives such as cream and sugar.
To use composition in Java, you use instance variables of one object to hold ref
erences to other objects. For the CoffeeCup example, you could create a field fo
r coffee within the definition of class CoffeeCup, as shown below: [bv: implemen
t the methods]
// In Source Packet in file inherit/ex1/CoffeeCup.java
class CoffeeCup {
private Coffee innerCoffee;
public void addCoffee(Coffee newCoffee) {
// no implementation yet
}
public Coffee releaseOneSip(int sipSize) {
// no implementation yet
// (need a return so it will compile)
return null;
}
public Coffee spillEntireContents() {
// no implementation yet
// (need a return so it will compile)
return null;
}
}
// In Source Packet in file inherit/ex1/Coffee.java
public class Coffee {
private int mlCoffee;
public void add(int amount) {
// No implementation yet
}
public int remove(int amount) {
// No implementation yet
// (return 0 so it will compile)
return 0;
}
public int removeAll() {

// No implementation yet
// (return 0 so it will compile)
return 0;
}
}
In the example above, the CoffeeCup class contains a reference to one other obje
ct, an object of type Coffee. Class Coffee is defined is a separate source file.
The relationship modeled by composition is often referred to as the "has-a" rela
tionship. In this case a CoffeeCup has Coffee. As you can see from this example,
the has-a relationship doesn't mean that the containing object must have a cons
tituent object at all times, but that the containing object may have a constitue
nt object at some time. Therefore the CoffeeCup may at some time contain Coffee,
but it need not contain Coffee all the time. (When a CoffeeCup object doesn't c
ontain Coffee, its innerCoffee field is null.) In addition, note that the object
contained can change throughout the course of the containing object's life.
[bv: need to add UML diagram for composition, and explain the difference between
composition and agregation and why I draw my diagrams like I do.]