Enthuware

I select "interface implementation" because i read this "Which of the following code reuse techniques are used to aggregate features from multiple classes?" and we can only insert from one class.

There is no implementation in an interface. So you can't aggregate functionality by implementing interface.
It is true that Java allows a class to extend only one class but this is an OO conceptual question and since you have to select two options, inheritance and composition are the right choices.
HTH,
Paul.

Aggregation means has-a relationship not is-a.So how inheritance is correct answer ?

Aggregation

Aggregation is a special case of association. A directional association between objects. When an object ‘has-a’ another object, then you have got an aggregation between them. Direction between them specified which object contains the other object. Aggregation is also called a “Has-a” relationship.

The word "aggregation" may have different meaning depending on the context it is used. In this case, the question is talking about "aggregating features", this does not limit the scope to "aggregation" as in "has-a".

As explained in the explanation, there are two way to aggregate features in your class - either inherit from another class or use composition/aggregation i.e. has-a.

You could say aggregation is a special case of composition (or vice versa). Both are has-a but in case of composition, the life cycle of the contained object is controlled by the container object. While in aggregation, the life cycles of both the objects are independent of each other.

ETS User wrote:I select "interface implementation" because i read this "Which of the following code reuse techniques are used to aggregate features from multiple classes?" and we can only insert from one class.

Totally agree with this. You can't aggregate features from multiple classes using inheritance. Seems to me, a complete neophyte, that using inheritance, you're not even aggregating, you're extending. Since when is inheritance also known as aggregation?
The example given notably doesn't show aggregation of features from multiple classes using inheritance. I'd welcome an example, but I doubt it's possible.

/scepticism off

Student wrote:

ETS User wrote: You can't aggregate features from multiple classes using inheritance.

Sorry, but you are wrong conceptually. This is a limitation only of the programming language. Not of OO in general. You might want to consult a book on OO to understand how features from multiple classes may be aggregated.

Again, "aggregating features" != aggregation.

Please read my previous response.

-Paul.

This seems to be a non-technical use of the term 'aggregation'. I hope the OCPJ doesn't ask questions with ambiguous terms like this. The meaning here seems to be 'combine', as in "are used to combine features from multiple classes".

In defense of inheritance being used to combine features from multiple classes, inheritance hierarchies can contain multiple levels, so a class can inherit features from more than one class up the hierarchy; that is, from its superclass, its superclass's superclass, etc.

telston wrote:This seems to be a non-technical use of the term 'aggregation'.

The question does not use the term aggregation. The question uses the phrase "aggregate features", which is very clear. There is no ambiguity here.

HTH,
Paul.

admin wrote: (extensing of no more than 1 class) is a limitation only of the programming language. Not of OO in general.

Are you sure it's possible to get a question not applicable to Java? As stated in exam description, the exam is verified against JavaSE 7.

Alexey, as per the objectives, it is possible.
I have updated the problem statement to make it clear that this is strictly from OO perspective. Hope there is no ambiguity now.

HTH,
Paul.

Can you explain to me why the
"Factory Pattern"
does not aggregate features from multiple classes?

In Factory pattern, the factory class merely instantiates another class and returns that object's reference. It does not make use of the object's methods/features and is not aware of those either. Therefore, it does not "aggregate" any feature form even one class, let alone multiple.

I agree with the OP

'multiple classes' is misleading

Oh yeah I can aggregate multiple features using interface implementation.
I'm getting all the static members.
Also, I can aggregate function signatures. I don't even need to implement them if the "implementing" class is abstract.
IOW option 5 is in fact correct. In my not so humble opinion

I do not buy that this question should be about OO in general, or otherwise transcend Java.
First, because neither question nor answers say anything in that direction. Also, I dimly recall that the live exam does not tell us what category a question falls into, so there's no hint coming from that direction (I may be wrong as my memory is dim).
Second, because Oracle's certification objectives do not contain anything about OO outside of the Java domain. Everything is interpreted within the Java context, including Design Patterns. (Okay, I may be wrong with this since I can't find an authoritative list of certification objectives - where does one find these?)

Detailed exam objectives are given here: https://education.oracle.com/pls/web_pr ... id:1Z0-809

Oh yeah I can aggregate multiple features using interface implementation.

Conceptually, interfaces do not contain implementation. So I do not agree that you can aggregate implementation using interfaces.
statics in an interface is an affront to OOP but yes, it can be argued that they can be aggregated by implementing multiple interface.

This does get complicated in Java 8, which allows interfaces to have default methods!

It says "aggregate features", not "aggregate implementations". A method is a feature, even one that exists just as a signature because it's abstract or from an interface.

No Java 8 for me currently, so default methods do not factor in here.
Though with that one, implementing multiple interfaces would indeed aggregate implementations as well.

Oh. Right. I see a potential source of disagreement.
"Implementing an interface" can mean two quite different things:
a) The "implements" keyword in the class header.
b) Implementing all functions of an interface.
I've been assuming that the "implement an interface" wording in the question means (a), because that's the technical term. If you've been thinking along the lines of (b), then I agree that the act of implementing a method is indeed no aggregation.

Still, since it's always (a) as well, I still think that implementing multiple interfaces does have an aggregating aspect to it. Callers will perceive the new class as aggregating the APIs present in the interfaces after all.
(I have to admit that I'm mostly looking at classes from the "what's their API" standpoint. I'm more library designer than coder after all, that's why I love OO in the first place.)

I think you have a valid point. Will update the problem statement.
thank you for your feedback! greatly appreciated.
Paul.

Nice to hear I'm helping

aggregate features from multiple classes
this seems to be pointing me to interfaces although interfaces are not classes
but that is why interfaces were made in the first place - to aggregate different functionality from multiple classes (in Java interfaces which mimic the classes)
into one class. I don't know why no one has pointed to interfaces.
Inheritance would mean that I can only aggregate features of a single class
as opposed to multiple classes as asked in the question. I think for inheritance to be the correct answer the question should be framed as
aggregate multiple features of class. Other wise Interface would seem the correct answer. A lot of subjective questions and this is one among them. I am hoping the real exam doesn't have such!
Edit:Actually now that I am revising it seems I am wrong. Even if you implement Interfaces you are providing your own functionality rather than using other class or to correctly say interface functionality. So the next best option to Inheritance would logically be Composition.