Enthuware

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 .

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.

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.

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.

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!

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.

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.

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?

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.

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.

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.

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).

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?!

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.

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.

please read the response just above your post. It explains why calculateArea method should be private.