Example of Reflexive composition relation.

Hi ppl,
i just was having a talk with my prof regarding the various types of relation ship between Objects such as aggregation,association composition and their practical examples.
we became stuck for an example of reflexive composition ..
can anybody help out with a practical example of the same
just curious ..!!!

Reflexive composition is (as far as I know) used in a class diagram when one object refers to one or more other objects of the same type.
We might design a tree in which each Node holds a reference to a "parent" Node object and zero or more "child" Node objects.
We might design a list in which each Element object holds a reference to the "next" Element object.
We might design a system model in which each Person object holds a reference to a "next of kin" Person object.
And so on. Has that helped?

Hi frank,
thanx for the input
Reflexive Composition
1> The paret object spawns the child
2> Only the parent object knows the existance of the child
3> No object Other than the Parent can access the child object
4> The scope of the child is a long as the parent is in scope as the child is completely encapsulated by the parent.

A example for a composition would be a Thread and process where the process has no existance outside the thread....
i would like a example of reflexive composition where the parent and child are basically from the same class..
The examples u have provided i think do not fulfill the encapsulation req though i may be wrong....

1> The parent object spawns the child
2> Only the parent object knows the existance of
the child 3> No object Other than the Parent can
access the child object 4> The scope of the child
is a long as the parent is in scope as the child
is completely encapsulated by the parent.
...
i would like a example of reflexive composition
where the parent and child are basically from the
same class..
Ah. I'd missed the nuances of the "composition"
part. Strangely enough I was actually working
with one of these a couple weeks ago, although
there was no UML to show that it was.
In the system I am working on, there are several
"entity" style objects which hold data loaded
from a database (each aggregating the results of
several distinct queries and stored procedure
calls, and providing methods to update the
database from changed information). The original
(horrible) code had a lot of member variables
such as:
String networkId;
String controllerId;
int activeInterfaces;
Interface[] interfaces;
It also had an identical list of variables
String local_networkId;
String local_controllerId;
int local_activeInterfaces;
Interface[] local_interfaces;
and some clumsy code to copy from one group to
another, initialise the two groups, etc.
The original intention was to separate the
original values (loaded from the database) from
the ones modified by the user, so that when the
object is sent back to the database, only changed
values need be updated.
After several irritating bugs due to mistakes and
misunderstandings in updating this code, we
refactored it so that each class in question had
just one list of member variables, but also had a
reference to another instance of the same class,
created in the constructor. This enabled the
"secondary" object to hold the initial database
values for reference, but not to "get in the way"
of the functioning of the "primary" object.
Making the two objects instances of the same
class ensured that they would always have exactly
the same list of member variables.
I'm not holding this up as a particularly good
design, but given the original state of the code
it is certainly an improvement, and helps prepare
the ground for refactoring to more intelligent
designs later.
Has that helped?

Sorry for the cramped format of that last post, I had to use a text-mode browser

//The class and its instance share a parent/child relationship
//The class itself is the parent and it contains a static variable 
//of the type Singleton itself which is private hence is 
//completely hidden from the client which forms its child

//The parent according to the said theory 
public class Singleton {
    //The child ...
    private static Singleton _oSingleton = null;
    //The constructor being private it cannot be accessed from anywhere but the class method 
    private Singleton() {
    }
    // The only method which can create the instance of the object for u.
private static void createSingleton(){
if(_oSingleton==null){
_oSingleton = new Singleton();
}
}
    // The method which is exposed to the client and which accesses the parent ie 
    // the Class method and the client is completely unaware of the child.
public static String getSomething(){
createSingleton();
return _oSingleton.doSomeThing();
}
    //The handshake method of the instance of object for the method exposed by the parent ie the class 
private String doSomeThing(){
return "";
}
}

[ July 08, 2003: Message edited by: Devesh H Rao ]