This week's book giveaways are in the Cloud and AI/ML forums. We're giving away four copies each of Cloud Native Patterns and Natural Language Processing and have the authors on-line! See this thread and this one for details.
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:
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:
Similarly you could also use a variable that has been passed to our composed class' constructor by keeping a reference to it:
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!
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.
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.
Enthuware Software Support
posted 2 years ago
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.