composition in java

[william kane]

Am i right in my understanding when i say that a non static inner class to implement a composition in java?

[Lasse Koskela]

UML's composition does not have an "official" mapping to Java constructs. A composition can be implemented with regular, top-level classes as well.

[william kane]

Originally posted by Lasse Koskela:
UML's composition does not have an "official" mapping to Java constructs. A composition can be implemented with regular, top-level classes as well.

Hi lasse i did not mean that inner class is the official mapping but that it can be one sure shot way of implementing composition.
How can you bind the lifetimes of the whole and parts??? for top level classes please illustrate with an example.

[Lasse Koskela]

I didn't assume you meant that it would've been the official mapping.
Consider the following definitions for aggregation and composition

aggregation -- A whole/part hierarchy. An aggregate object includes (has-a) other objects, each of which is considered to be a part of (part-of) the aggregate object.
composition -- A composition is a form of aggregation where the whole cannot exist without having the parts.

The "rules" for composition can be fulfilled in Java using top-level classes simply by making sure that whenever the parent object (the composite) is destroyed (i.e. nobody has a reference to it), the child objects (the components) are also destroyed (i.e. nobody can't reference them either).
Here's a simple example of how to make sure nobody can use an engine without the car it's installed in:

// file: Car.java
package car;
public class Car {
    private Engine engine;
    public Car() {
        this.engine = new Engine();
    }
}
// file: Engine.java
package car;
public class Engine {
    protected Engine() {
        // instances of Engine cannot be created outside of this package
    }
}

[william kane]

Originally posted by Lasse Koskela:
I didn't assume you meant that it would've been the official mapping.
Consider the following definitions for aggregation and composition

// file: Car.java
package car;
public class Car {
    private Engine engine;
    public Car() {
        this.engine = new Engine();
    }
}
// file: Engine.java
package car;
public class Engine {
    protected Engine() {
        // instances of Engine cannot be created outside of this package
    }
}

Thanks Lasse wouldnt it be better if we define Engine as follows
class Engine {
Engine() {
// instances of Engine cannot be created outside of this package
}
Now i cannot create instances in the even if i extend the class outside the package.
But i still feel that non static inner class is a better way to bind the lifetimes of the whole and the parts

[Frank Carver]

What puzzles me is why you seem to want a way to limit your implementation so closely to your analysis. In particular, I'm worried that you are missing the difference between a class and an object.
In a composition relationship, a "whole" object cannot exist without a complete set of its "part" objects. You may, if you wish, strengthen this to add that these "part" objects cannot exist independent of the "whole" object. This, however, says nothing about the classes, or about any other objects which may happen to have the same class as the particular "part" objects we are concerned with.
It's perfectly reasonable for another area of the software to create other objects of the same class, and use them as it will. In fact, if you wish your software to be properly unit tested, it's vital!
I really can't see any advantage in artificially limiting the scope or visibility of the Engine class (as in the above examples), when what you actually need to do is to limit the scope or visibility of a particular Engine object.
Think about some of the standard API classes which everybody uses, such as String and HashMap. The classes are public and available for anyone to use, but we are all quite happy with marking a particular String or HashMap object as private in one of our classes, and using it in a pure composition relationship:

class Car
{
  private String vehicleIdentificationNumber;
  
  public car(Factory factory)
  {
    this.vehicleIdentificationNumber = factory.nextVIN();
  }
 
  // ...
 
  public String toString()
  {
    return "a Car, with VIN: '" + vehicleIdentificationNumber + "'");
  }
}

In the above example, the VIN string only ever exists as part of a Car object, all Car objects have one, and it disappears when the Car object is lost. So, by definition, it is a composition relationship. But String is a public class!

[Ilja Preuss]

Mhh, you are all using a different definition for Composition than I am used to. To me, composition means that the "whole" is responsible for both creating and destroying the "part".
Obviously, inner classes don't enforce this - if it has a public constructor, anyone can create new instances of it.
Additionally, Composition also allows for passing the responsibility around - as Frank said, it's more a property of object relationships than of class relationships. The following is a valid class diagram:

+---+         +---+
| A |<#>------| D |
+---+         |   |
              |   |
+---+         |   |
| C |<#>------|   |
+---+         +---+

[Jose Botella]

the "whole" is responsible for both creating and destroying the "part".

is this equivalent to say that the part cannot exist without the whole?

[william kane]

Originally posted by Frank Carver:
[QB]In a composition relationship, a "whole" object cannot exist without a complete set of its "part" objects.
QB]

Thanks frank that clears a lot of things for me.

[Ilja Preuss]

Originally posted by Jose Botella:

is this equivalent to say that the part cannot exist without the whole?

I'd say it is implied, but lifetime responsibility is stronger.
That is, if there is no "whole" there is noone able to create a "part". And when the "whole" gets destroyed, it is forced to either also destroy the part or pass it to another "whole".
On the other hand, "cannot exist without the whole" doesn't say anything about who creates or destroys the "part".

[william kane]

Originally posted by Frank Carver:
What puzzles me is why you seem to want a way to limit your implementation so closely to your analysis.

On second thoughts I didnot get this Frank can you please throw some light on what you mean.
Ilja i did also get this passing of parts between wholes when whole is destroyed does it not run counter to "no parts w/o whole" thing???
Please explain
Thanks in advance

[Frank Carver]

Yes, that was a bit of an odd phrase. Sorry.
What I was trying to address is a tendency I often see in designers and architects to make a system more complicated than it needs to be. This usually happens because some of the "requirements" being worked on are specified (or inferred) as limitations rather than features, but can also happen with some types of feature requirements.
You can spot this kind of overcomplexity when you see external application constraints being coded into internal software structures. A classic example is use of the Singleton pattern when it simply isn't necessary.
Imagine you have analysed a problem scenario, and discovered that the corporation you are modelling has only one head office (for example). A common mistake is to take this as meaning that the assumption of a single head office must be built in to the underlying program structure, for example by using a Singleton. However, a much simpler solution is possible: model the head office with a regular class, then simply create one instance of it in the application. The solution is then smaller (no Singleton code and the associated decisions and documentation), much easier to test (you are free to create and examine one or more instances of the class during your unit tests) and more flexible (if the corporation amalgamates with another and suddenly has two head offices, you just create another instance).
I mentioned this because I was worried that you were in danger of falling in to the same trap. There seems no need to build the object-relationship limitations of your analysis into the class structure of your solution, and if you choose to do that you will almost inevitably end up making life much more difficult for yourself, for all the above reasons.
Did that make any more sense?
[ October 13, 2003: Message edited by: Frank Carver ]

[Ilja Preuss]

Originally posted by william kane:
Ilja i did also get this passing of parts between wholes when whole is destroyed does it not run counter to "no parts w/o whole" thing???

I don't think so - the "part" will still belong the exactly one "whole" all the time. It's just that which whole it belongs to might change.
Did that help?

[Stan James]

However, a much simpler solution is possible: model the head office with a regular class, then simply create one instance of it in the application.

Very cool point. I often ask if the system has to enforce certain things or allow them. Some times it's a matter of wanting to make your code honestly reflect the requirements. Some times it's a matter of protecting yourself from future mistakes, such as a second instance of Home Office might hopelessly confuse the application in a way that's very hard to detect and debug. But in short, I like the XP idea of the simplest thing that can possibly work. And the example of String and Hashmap is great!

[william kane]

Originally posted by Frank Carver:
I mentioned this because I was worried that you were in danger of falling in to the same trap. There seems no need to build the object-relationship limitations of your analysis into the class structure of your solution, and if you choose to do that you will almost inevitably end up making life much more difficult for yourself, for all the above reasons.
[ October 13, 2003: Message edited by: Frank Carver ]

Hey thanks frank i got what you are saying but that mystry of analysis to design always haunts me.Or to put it this way "What could be a design consideration that would ask for my modelling that object as a singleton??".
What i am trying to get at is what should i consider as a part of my design effort other than what has surfaced in my analysis?I know this is deviating from where we started but clarity on this will do me a world of good.
Thanks in advance

[Frank Carver]

Or to put it this way "What could be a design consideration that would ask for my modelling that object as a singleton??".
Tough question. I've seen lots of projects which have used Singleton, but I've never personally come across a situation where it was actually an advantage to have it!
An elegant, simple, solution is one which is capable of meeting all the current requirements. Adding extra complexity just to limit it to a solution which is only capable of meeting those requirements is at best pointless extra work, and at worst a mistake which will cost a lot of time and money to change later.
Lots of useful guidelines follow from this principle: don't make your own class if there is a system class which will do the job; don't build a "framework" until you have at least two applications which will use it; don't use a pattern just because it is in a pattern book, and so on.

[Ilja Preuss]

Originally posted by william kane:

What i am trying to get at is what should i consider as a part of my design effort other than what has surfaced in my analysis?

You should only consider those things as part of your design which help you build the solution to your problem. In the analysis you explored the structure of the problem. Going from there to the structure of the solution will probably always be a creative act - in fact, that's what software development mainly is about, in my opinion.