Hi,
Well, I answered incorrectly too, but I read it again @fabbbb and it says "without breaking existing code". Without this you could consider "Make sum = 200 and make all fields (radiusA, radiusB, and sum) private." to be true. Encapsulation is not always something that you can add later on while ensuring it will not break existing code.
Regards,
Guillaume
About Question enthuware.ocajp.i.v7.2.997 :
Moderator: admin
-
- Posts: 3
- Joined: Sat Jan 16, 2016 1:20 pm
- Contact:
-
- Posts: 5
- Joined: Tue Feb 06, 2018 2:41 am
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.997 :
"breaking existing code" statement is really a subjective matter and I really hope I don't get one of "these" questions.
I consider breaking existing code as in making whatever's using the method not compile, and there are such answers...
This particular matter is breaking the business logic and you assume that everybody's on the same boat with the change.
com.sun. package was always a subject for change and nobody called it code breaking.
why isn't setRadius2 an answer then? only new users would be aware of it and old users would have to rewrite their code... or use the old one, that's not "breaking their existing code".
It's a very ambiguous question if it's really just a matter of encapsulation.
I consider breaking existing code as in making whatever's using the method not compile, and there are such answers...
This particular matter is breaking the business logic and you assume that everybody's on the same boat with the change.
com.sun. package was always a subject for change and nobody called it code breaking.
why isn't setRadius2 an answer then? only new users would be aware of it and old users would have to rewrite their code... or use the old one, that's not "breaking their existing code".
It's a very ambiguous question if it's really just a matter of encapsulation.
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.997 :
No, it is not ambiguous at all. "Breaking existing code" quite clearly implies that other existing code either fails compilation or fails to work as expected at runtime.igor.simecki wrote:"breaking existing code" statement is really a subjective matter and I really hope I don't get one of "these" questions.
I consider breaking existing code as in making whatever's using the method not compile, and there are such answers...
This particular matter is breaking the business logic and you assume that everybody's on the same boat with the change.
com.sun. package was always a subject for change and nobody called it code breaking.
why isn't setRadius2 an answer then? only new users would be aware of it and old users would have to rewrite their code... or use the old one, that's not "breaking their existing code".
It's a very ambiguous question if it's really just a matter of encapsulation.
Encapsulation requires data fields to be private. If you make radiusA, radiusB, and sum private, existing code that is using these variables will fail to compile.
setRadius2 is not a valid option because that doesn't make this class well encasulated because the radiusA, radiusB, and sum will still remain public.
Classes of com.sun package cannot be accused of breaking other people's code because this package was not part of the public API of Java library. No one was supposed to use it in the first place. Further, breaking is not only about code of other people, it is also about code in the same package. In the given question, if you make the variables private, code is the same package will also break.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
Who is online
Users browsing this forum: No registered users and 98 guests