OCP Study Guide Java SE 8 Programmer II - Study Guide - Possible error/explanation needed (Sybex)

[John Schubert]

I'm currently reading the OCP Study Guide. Its a great book so far.
I'm reporting this issue as I've read the current errata and didn't see anything related.

In Chapter 2, Review questions, p101, question #18:

Which of the following statements about inheritance and object composition are correct? (Choose all that apply.)
...
E. Object composition requires a class variable to be declared public or accessible from a public method to be used by a class in a different package.
...

According to the answer (p.553) this option is correct because:

object composition has no notion of inheritance and variables must be exposed publically if they are to be used by other classes in different packages

I think this option is not correct as it is worded, since you can still access a protected variable trough multiple means from a class in a different package. Even from the composed instance. E.g.: through inheritance:

package cars;

public class Car {
	protected Wheel[] wheels;
	
	public Car(Wheel[] wheels){
		this.wheels = wheels;
	}

	//Nobody can access our wheels, can they?	
}



package electriccars;

public class ElectricCar extends Car {
	public ElectricCar(Wheel[] wheels){
		super(wheels);
	}

	public void punctureWheel(){
		wheels[0].puncture();//Bang
	}
}

Moreover, even if the variable were private or package default, you could still keep a reference to the variable in the subclass constructor and cache it for later use:

package cars;

public class Car {
	private Wheel[] wheels;
	
	public Car(Wheel[] wheels){
		this.wheels = wheels;
	}
}



package electriccars;

public class ElectricCar extends Car {
	private Wheel[] wheels2;
	public ElectricCar(Wheel[] wheels){
		super(wheels);
		wheels2 = wheels;
	}

	public void punctureWheel(){
		wheels2[0].puncture();//Bang
	}
}

Similarly you could also use a variable that has been passed to our composed class' constructor by keeping a reference to it:

package repairshop;

import cars;

public class Shop {
	public static void main(String[] args){
		Wheel[] wheels = new Wheel[]{new Wheel(), new Wheel(), new Wheel(), new Wheel()};
		Car car = new Car(wheels);
		wheels[0].puncture(); //Bang
	}
}

This last example might seem far-fetched but please be aware that in this chapter the reader has been conditioned to look for this kind of subtleties. For instance, we have seen similar problems with collections being passed in the constructor to "immutable" objects and still being mutable from references cached outside (question #7 options E and G); we have also seen "singletons" that were not such due to the object being public or thread-unsafe getInstance implementations (question #9 options D and F).


In my opinion, the problem with option E is that it is assumed that:

Composition and inheritance are exclusive (which they are not).

Every variable mentioned in the question is a "component" variable passed as a dependency to this class and not any other variable that the class or any of its superclasses might already have.

You need to access the "component" instances through the composed class.

You have no means to access the components from outside of the composed class' package.

So I find this option very ambiguous and context-lacking. It is frustrating because when it comes to what is possible or not, real questions in the exam are full of trickery and hacks to mislead the student!

[Jeanne Boyarsky]

I think you are reading into this. In your example where you store it in the constructor, it isn't referenced anywhere else in the class so it is effectively useless.

Also, keep in mind the real exam tells you how many answers are correct. So you know if you have to look into a question in that much depth (you typically don't)

[Paul Anilprem]

Composition requires having an instance of some class as a field of your class, instead of extending that class. Whether that field is public or private and whether there is a method that makes that field accessible to other classes or not is irrelevant.

[John Schubert]

Jeanne Boyarsky wrote:I think you are reading into this

Yes that might well be the case. All those previous questions about singletons and immutable objects required very careful thinking, so the student arrives at question #18 in a paranoid state.

[John Schubert]

Paul Anilprem wrote:Composition requires having an instance of some class as a field of your class, instead of extending that class. Whether that field is public or private and whether there is a method that makes that field accessible to other classes or not is irrelevant.

I don't think it is irrelevant. In fact I think its key to understand the question.

We are talking about accessing that field from a different package. That can be done in four different ways from that class:

1. declaring the field as public

2. declaring the field as protected (accessible only through inheritance)

3. providing a public getter

4. providing a protected getter (accessible only through inheritance)

There are other more exotic options such as caching the field before passing it to the class, and even reflection hacks. If we ignore those, the question implies only options 1 and 3 are to be taken into account. The other two are totally plausible and I get to see them in the field very often.
For me to ignore the possibility of having both composition and inheritance was a simplification that was somehow in contradiction with the strict mindset required for some of the previous questions. Perhaps a commentary explaining that the two approaches shouldn't be considered at the same time would help.

[Paul Anilprem]

May be my response wasn't too clear. Option E should be marked incorrect because composition does not require a class variable to be declared public or accessible from a public method to be used by a class in a different package. As I said before, composition just requires an instance variable of another class. Whether that variable is accessible to any other class is irrelevant (as far as composition is concerned).

The wording "class variable" makes it incorrect as well. It should be "instance variable". Class variable implies static, which has nothing to do with composition.

HTH,
Paul.