About Question enthuware.ocajp.i.v7.2.877 :

Help and support on OCA OCP Java Programmer Certification Questions
1Z0-808, 1Z0-809, 1Z0-815, 1Z0-816, 1Z0-817

Moderator: admin

Post Reply
ETS User

About Question enthuware.ocajp.i.v7.2.877 :

Post by ETS User »

If the option "Make side and area fields private." is selected in this question , then the main method will not be able to set sq.area .
Thus the refactoring will break the main method .

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by admin »

Hi,
You are right but that is the whole point of this particular refactoring (to improve encapsulation). You don't want other classes to modify internal fields (specially, area field) of Square class. TestClass should rightly fail when it tries to access area field directly.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

Javanaut

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by Javanaut »

Is not the calculateArea() method in option 3 of the changed setSide() method bad cohesion? Seems like there is too much going on in this method. :roll:

ksnortum
Posts: 30
Joined: Fri Dec 07, 2012 6:09 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by ksnortum »

I would say the opposite. The Square class should do everything a Square needs to do. But regardless, this question is about encapsulation, not cohesion.

zippo1000
Posts: 2
Joined: Mon Jun 24, 2013 5:59 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by zippo1000 »

From my point of view, calling 'calculateArea' in the method 'setSide' is ok if there is a field 'area' that must not be inconsistent concerning the value of 'side'. But then one should use 'setSide' in the constructor, too, in order to avoid this inconsistency!

dalibo
Posts: 4
Joined: Fri Dec 27, 2013 3:39 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by dalibo »

calculateArea() being part of setSide(double d) - is about encapsulation, and helps to form this question, but obviously, at least to me, this is weird, why would i waste resource to calculate something if i don't need that calculation. I am setting side, i am not calculating area. This should be separated in my opinion.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by admin »

Yes, there is can be many ways to do things. However, in this case, you are storing area in a separate variable and that variable can be accessed independently. Therefore, in this case, it is correct to recompute it every time side it set.
If you did not have area field, then your approach would have been correct.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

fasty23
Posts: 37
Joined: Thu Feb 13, 2014 12:58 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by fasty23 »

I think as the question said "(in the same package but defined in different
source files)" so "D. Make the getArea method public." does not have point. and it could be run without this. and we made more restrict code in encapsulation. is it right?

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by admin »

Yes, as mentioned in the explanation there are multiple ways to do this. So yes, getArea need not be public if you just want it accessible to classes in that package. But the question doesn't mention that it has to be accessible ONLY from TestClass. In general, getters/setters should be public unless there is a reason not to make them public.
If you like our products and services, please help us by posting your review here.

JeramieH
Posts: 22
Joined: Wed Jan 08, 2014 11:24 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by JeramieH »

dalibo wrote:calculateArea() being part of setSide(double d) - is about encapsulation, and helps to form this question, but obviously, at least to me, this is weird, why would i waste resource to calculate something if i don't need that calculation. I am setting side, i am not calculating area. This should be separated in my opinion.
Highly dependent on how the data will be used. In most of my projects, the data is set/calculated once during initialization, and then read thousands of times during execution. To repeatedly recalculate the same result on thousands of getArea() calls, especially when nothing has changed since the previous call, would be terribly wasteful. Just depends on the read/write frequency ratio of your data, and the complexity of the calculated values.

That being said, setSide() could set a "dirty area" boolean flag that only triggers a single recalculation on the next getArea call (if any). Or even make area a Double object and set it null when it's dirty, forcing a recalculation on the next getArea() call.

Re: http://en.wikipedia.org/wiki/Memoization

This question is virtually identical to enthuware.ocajp.i.v7.2.876, except the correct answer over there takes a totally different track.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by admin »

JeramieH wrote:
This question is virtually identical to enthuware.ocajp.i.v7.2.876, except the correct answer over there takes a totally different track.
Yes, we wanted to show the multiple ways in which you can be asked these kinds of questions in the exam. I agree that the solutions are a bit subjective (and need based) but still, keeping complexities aside, you can apply basic OO rules to arrive at an answer. Even if you don't agree with the answer, but they make you think about the issues involved and that is the goal of this question.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

phogi.java
Posts: 3
Joined: Sun Oct 26, 2014 9:31 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by phogi.java »

My problem here is that I keep thinking that to successfully refactor Square, any current users should not be affected. Which means, I cannot make a public field private, because it will break any current users that are already using the class, such as TestClass which is directly using the area field (sq.area).

evaevaeva
Posts: 10
Joined: Fri Mar 06, 2020 5:18 am
Contact:

ERROR IN Question enthuware.ocajp.i.v7.2.877 :

Post by evaevaeva »

The 'right' answer says: "Add a calculateArea method:

private void calculateArea(){
this.area = this.side*this.side;
}
"
But shouldn't it be PUBLIC instead of PRIVATE?!! In other words: isn't this an error in the answer?!

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by admin »

No, why should it be public? This functionality is used only internally within the class. The existing class does not expose this functionality outside either.
If you like our products and services, please help us by posting your review here.

evaevaeva
Posts: 10
Joined: Fri Mar 06, 2020 5:18 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by evaevaeva »

It should be public because it says so everywhere: 1. Declare the variables of a class as private. 2. Provide public setter and getter methods to modify and view the variables values.
That's what I have been learning all the way, so please help me understand why here they use a private a.m. I mean, you could of course, but then don't ask about 'terms of encapsulation', because it's contradictory.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.877 :

Post by admin »

please read the response just above your post. It explains why calculateArea method should be private.
If you like our products and services, please help us by posting your review here.

Post Reply

Who is online

Users browsing this forum: No registered users and 34 guests