• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is this a Has-a ?

 
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi



Thanks
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Personally, I don't think it's a good idea to use the term "has-a" at the code- or design-level.

So a better question could be "is this composition?" Is it?
 
Costa lamona
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
http://faq.javaranch.com/view?AssociationVsAggregationVsComposition
http://forum.java.sun.com/thread.jspa?threadID=696709

Then

Composition can = Aggregation + singelton;

Composition also applies when
1- Clonning
2- constructing the "contained" object inside its containner

Some times Composition is just like private inheritance in c++

That what I understand about composition....so far!!
If that is not correct tell me please


forget about immutable things like Wrrapers and Strings, make it

class Test {
static A i;
public static void main(String [] args) {
Test.A = new A();
}
}

class A {
}

if I am right,
This is composition, not aggregation, because all Tests object are pointing to the same A object.

Then

SCJP book by K & B, page 164, q2,

answering by B is not correct too.

Who agree
------------------------------------------------------------
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mohammed EL-Adawi:
Composition can = Aggregation + singelton;



Be careful with the term "singleton". There is a design pattern that is called this way and has nothing to do with composition. The design pattern ensures that there is exactly one instance of a class. With composition there can be as many instances as you like, but every instance needs to have exactly one owner who responsible for its lifetime cycle.


Composition also applies when
1- Clonning
2- constructing the "contained" object inside its containner



Not sure what you are getting at here.


Some times Composition is just like private inheritance in c++



I'd rather say that private inheritance is one way to implement Composition in C++.


class Test {
static A i;
public static void main(String [] args) {
Test.A = new A();
}
}

class A {
}

if I am right,
This is composition, not aggregation, because all Tests object are pointing to the same A object.



I would rather say that *no* Test object is referencing an A object - the Test *class* is.

And all objects referencing the same A object would in fact be an indicator that it's *not* composition, because it wouldn't be clear which object is responsible for handling the lifetime of the A object.



SCJP book by K & B, page 164, q2,

answering by B is not correct too.



Don't have the book, so I can't comment. You might want to restate this part of the question in our SCJP forum, where people better know what is considered correct *in respect to the certification*.
 
Costa lamona
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I'd rather say that private inheritance is one way to implement Composition in C++.

With composition there can be as many instances as you like, but every instance needs to have exactly one owner who responsible for its lifetime cycle.



let's be clear, I am not sure about any thing I say in design paterns because I did not read any books about it so far, but those clarify it to me, so thanks, But....


I would rather say that *no* Test object is referencing an A object - the Test *class* is.

And all objects referencing the same A object would in fact be an indicator that it's *not* composition, because it wouldn't be clear which object is responsible for handling the lifetime of the A object.



those confusing me,

1- The A object is owned and referenced by Test class

2- the Test Object(s), can access that static reference, so
practically, Test Object(s) own the ref.

3- but because, it is only one A object, it is not composition.

If those three are right, I am no more confused or doubt, are they ?

and....

would you say
Test class aggregate A, but Test object is not?

so what it should be called "class aggregation" ?

Then

SCJP book by K & B, page 164, q2,
B- Has-a relationships always rely on instace variables.

is correct statment ? because no such thing like "class aggregation"
regardless of what Sun think.

Phew....Thanks for giving me alot of your time....
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1- The A object is owned and referenced by Test class

Yes, but you need to be very careful with the idea of "ownership" in this sort of context.

Java is a garbage-collecting language, without explicit destruction of objects. The creator of an object can be removed from the system without removing an object it has created, if another object contains a reference to the created object.

In the example above, an object of class A is created in a static (class) method of Test, and then (ignoring the typo where "i" is referred to as "A") referenced by a static (class) member variable of Test.

This is true, even if no objects of class Test are ever created.

However, objects of class Test, and any other classes or objects in the same package are free to change this relationship after the object is created and assigned.

To make a connnection between the created object of class A and another object, all that is needed is to assign it to a member variable of another object:



To remove the connection between Test and the created object of class A, all that is needed is something such as .

If it happens that the created object of class A is being referenced by another object when it is removed from Test, then it will remain in existence, but will be no longer anything to do with Test.

2- the Test Object(s), can access that static reference, so
practically, Test Object(s) own the ref.


No. Not really. Object instances of class Test are merely referencing the created object of class A, much like the instance of class Ugh which I mention above.

[/b]3- but because, it is only one A object, it is not composition.[/b]

Almost.

The number of A objects makes no difference. I would say that the key thing here is that it is not composition because the created object can outlive its creator.

True composition at this level is very rare in Java. Almost all objects can be passed around, regardless of where and when they were created.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mohammed EL-Adawi:
1- The A object is owned and referenced by Test class



It *is* referenced by the Test class. As Frank showed, that doesn't meant that the Test class has full responsibility for its lifetime. With other words, just because it references it doesn't mean that it owns it.


2- the Test Object(s), can access that static reference, so
practically, Test Object(s) own the ref.



Not at all. An object can be referenced by as many other objects at the same time as you like, but only one can "own" it at a time.


3- but because, it is only one A object, it is not composition.



I'm sorry for not being more clear - this seems to be kind of hard to get across...

One A object cannot be owned by an arbitrary number of objects at the same time, by definition. That's why there cannot be a composition relationship between the one A object and all Test objects. Does that make sense?

would you say
Test class aggregate A, but Test object is not?



If I remember correctly, an Association (as well as Association and Composition) relationship *always* exists between classes. An Association between class Test and class A would mean that *objects* of class Test can have *links* (instances of Associations) to objects of class A. (Complicated, eh? But that's how UML defines it, and it's actually somewhat consistent, once you understand it - which I don't claim to fully do...)

In a more OO language like Smalltalk, I'd say that your code can be interpreted as an Association relationship between the meta-class of Test (which the class Test is an instance of) and the class A. Don't know how to apply that to Java, where classes aren't true objects...

Whether it's an *Aggregation* would depend on whether cyclic dependencies are allowed.


SCJP book by K & B, page 164, q2,
B- Has-a relationships always rely on instace variables.

is correct statment ? because no such thing like "class aggregation"
regardless of what Sun think.



There is nothing in the concept of the "has-a" relationship that requires instance variables to be used. As you sayed, in C++ you could use private inheritance. I currently can't come up with an alternative in Java, though.

Notice, though, that that instance variable doesn't have to be a direct reference to the object. For example, it could alternatively just remember the objects id (UML even has a notation for this, if I remember correctly).


Phew....Thanks for giving me alot of your time....



You're welcome - this is a quite interesting discussion. And I'm sorry that the above is so complicated, perhaps overly so. But it's the best I currently was able to come up with. Hope it helps...
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Carver:
Yes, but you need to be very careful with the idea of "ownership" in this sort of context.

Java is a garbage-collecting language, without explicit destruction of objects. The creator of an object can be removed from the system without removing an object it has created, if another object contains a reference to the created object.



Yes. I think it's in "UML for Java Programmers" where Robert C. Martin explains that in a gc'ed language the responsibility of the owner changes from "creating and destroying" to "creating and keeping alive".


True composition at this level is very rare in Java. Almost all objects can be passed around, regardless of where and when they were created.



I'm not sure what exactly you mean by "at this level".

To me, composition is not about what you can enforce, but about what you intent. Even if objects are passed around, when an object is created be another object, and that other object has the responsibility of keeping it alive as long as it's needed (and other references are just shorter lived), it's composition.

With other words, to me the term "composition" is mainly helpful in communicating how the objects are intended to be used.
 
Frank Carver
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure what exactly you mean by "at this level".

I admit that was not very clear.

Mainly I was intending to avoid the confusion which can come with objects which only "live" during the context of a single method, and never get assigned to an object field.

With other words, to me the term "composition" is mainly helpful in communicating how the objects are intended to be used.

I can see that. Personally I don't often find that this is something particularly valuable to communicate.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Carver:

I can see that. Personally I don't often find that this is something particularly valuable to communicate.



Me neither.
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Carver:
Personally I don't often find that this is something particularly valuable to communicate.



In non-GC languages it is useful as it identifies the whole as being responsible for releasing the parts (for their resources). By extension this can become important in a GC language when the part objects hold "real" releasable resources like network sockets, file handles, etc. - garbage collection because of the lack of predictability and certainty is not suitable for releasing these kind of resources.
[ October 31, 2006: Message edited by: Peer Reynders ]
 
author
Posts: 9050
21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Guys,

I agree that if you're discussing something from K&B, it should probably be in the SCJP forum. The reason for this is that the SCJP exam covers a lot of topics on a fairly basic level. For instance, the exam covers, IS-A, HAS-A, coupling, and cohesion. These are all interesting and deep topics, and we, [BOLD]by design[/BOLD], don't cover them completely! If we provided a complete coverage for every topic mentioned in the SCJP objectives, we'd have a 3000 page book

We mention several times in the book that our coverage is NOT complete! It's intended to be focused on the exam, not to be the final word on any advanced topic. What we attempt to do in the book is provide a solid foundation for the topics, and get you to understand about 115% of what you'll need to know for the exam. We believe that a technical book should be focused - for instance, we don't believe that there is a single Java book out there that can be "all things Java" for everyone :roll:

hth,

Bert
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic