Composition in Java

Question

Say I have the following class:

public class BodyClass{

private LegClass myLeftLeg;
private LegClass myRightLeg;
private NoseClass myNose;

...

}

later on somewhere deep in a software program, I am going to have a solitary instance of myRightLeg.

Now, how come I won't know easily (or at all) which BodyClass object this rightleg pertains to, let alone which Class this instance variable is contained in? Why is it that in composition relationships, the information about the parent class is not automatically stored in the child objects, at runtime?

Couldn't there be a world whereby Java lazily-loaded each class variable with information about the parent class itself?

Why would this be bad? And wouldn't this be a fairly solid benefit?

I hear people say things like subclasses shouldn't know anything about their superclasses and instance variables shouldn't know anything about their parent classes, but frankly I don't see why not.

My question relates to this question:

How do you find all subclasses of a given class in Java?

You can always check the instance type using instanceOf operator — Juned Ahsan, Sep 22 '13 at 04:55
What's the bigger problem you're trying to solve? This smells like an [XY problem](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) to me. — Matt Ball, Sep 22 '13 at 04:58
hi Matt, I am using DB4o, and therein this problem arises. If I have a Model object and I can call store() on this object, this Model object might have another Model object as a instance variable. This is very common, especially in model class designs for relational database tables. But if I call store() on the instance variable object, how does DB4o know that this instance variable object was a child of a parent model object? I am not sure if it does, and it should. — Alexander Mills, Sep 22 '13 at 16:45
@Juned I will know the type of the instance variable, but I will not know the type of the class in which it is contained. — Alexander Mills, Sep 22 '13 at 16:45

score 1 · Answer 1 · edited May 23 '17 at 10:28

Now, how come I won't know easily (or at all) which BodyClass object this rightleg pertains to, let alone which Class this instance variable is contained in?
...
Why is it that in composition relationships, the information about the parent class is not automatically stored in the child objects, at runtime?

Because the language specification does not include this requirement.

In Java, objects don't contain references to other objects unless they are explicitly given them, as fields, or implicitly given them, as inherited fields. That's it. If you want your objects to know which objects know about them, you'll have to program it yourself:

class LegClass {
    private BodyClass body;

    void setBody(BodyClass body) {
        this.body = body;
    }
}

class BodyClass {
    // snip...
    void setRightLeg(LegClass rightLeg) {
        this.myRightLeg = rightLeg;
        rightLeg.setBody(this);
    }
}

Note the tight coupling this introduces between the two classes. Tight coupling is generally not a good thing.

I don't see why this is especially useful, and such a "feature" veers towards violating some of the tenets of OOP (which Java espouses), such as Encapsulation and Single Responsibility. A field which knows about which instance(s) (remember, there's no reason it has to only be one!) reference it is generally a code smell.

Its delibrate on java part to implement it like that. If a class memebr varibale knows about which instance it belongs to, it will lead to very tight coupling. One main reason for using Composition is loose coupling. — Lokesh, Sep 22 '13 at 05:06
guys, other than performance issues, I see absolutely no reason why there should not be automatic information about the relationship between instance variables and their parent classes. It would help in many circumstances. I have run across this same problem before. Normally to solve the problem, I use a static hashtable instance variable in the parent class. — Alexander Mills, Sep 22 '13 at 16:48
see this problem: http://stackoverflow.com/questions/492184/how-do-you-find-all-subclasses-of-a-given-class-in-java — Alexander Mills, Sep 23 '13 at 18:47

score 1 · Answer 2 · answered May 28 '16 at 16:41

Lots of reasons, but I think I would narrow it down to 2 big ones:

1) Unlike real objects, Java objects can be in more than one place. You wouldn't necessarily call that a "composition relationship", but a "composition relationship" isn't a thing that exists in Java. In Java you have fields that have references to other objects, and and more than one field in more than one place can point to the same target object. So it doesn't make sense in many cases to even ask about the "owner" or "container"

2) You can arrange such back-references yourself, but it's usually a bad idea. The Leg class is where you put code that is about the leg. That code solves leg problems and shouldn't generally care whether or not there is even a body around. If you have whole-body problems that can only be solved if you know about the body AND the leg, then solve them in the body class. That's called the "separation of concerns", and it's the primary way we organize software so that we can understand it.

score 0 · Answer 3 · answered May 28 '16 at 16:28

Composition means HAS A Inheritance means IS A

Example: Car has a Engine and Car is a Automobile

In programming this is represented as:

class Engine {} // The engine class.

class Automobile{} // Automobile class which is parent to Car class.

// Car is an Automobile, so Car class extends Automobile class. class Car extends Automobile{

// Car has a Engine so, Car class has an instance of Engine class as its member. private Engine engine; }

Composition in Java

3 Answers3