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

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

Moderator: admin

Post Reply
The_Nick

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

Post by The_Nick »

Hi,
Why the answer
Write another method setRadius2(int r) and set radiusB accordingly in this method.
should not be a valid answer? by doing that and then replacing sum with 200 it should have done the trick.



The_Nick

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

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

Post by admin »

Because in that case other people can still call setRadius, which will set radiusB to 100 - radiusA.
If you like our products and services, please help us by posting your review here.

kashyapa
Posts: 23
Joined: Thu May 08, 2014 5:27 am
Contact:

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

Post by kashyapa »

Could someone tell me, why the programmer cannot accomplish this goal by simply changing the sum to 200?

The explanation dos not make sense about it.

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

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

Post by admin »

kashyapa wrote:Could someone tell me, why the programmer cannot accomplish this goal by simply changing the sum to 200?

The explanation dos not make sense about it.
Please post exact code that you want to write. Please go through the explanation once more. It is correct and explains the issue.
If you like our products and services, please help us by posting your review here.

kashyapa
Posts: 23
Joined: Thu May 08, 2014 5:27 am
Contact:

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

Post by kashyapa »

Ok,

'sum' variable has public access, which means some other class may rely on the vale of this variable. so if we simply change the value of 'sum' from 100 to 200, it may cause subtle bugs on other classes.

am i missing something? :)

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

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

Post by admin »

You got it!
If you like our products and services, please help us by posting your review here.

Marthinus
Posts: 7
Joined: Tue Jul 22, 2014 5:07 am
Contact:

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

Post by Marthinus »

Even if the code was written with proper encapsulation principles in mind and you change the value of the private variable sum to 200 it would change the behaviour of the code and introduce a bug into legacy code.

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

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

Post by admin »

Marthinus wrote:Even if the code was written with proper encapsulation principles in mind and you change the value of the private variable sum to 200 it would change the behaviour of the code and introduce a bug into legacy code.
The point is to prevent users (and not the owner of the class) from messing with the behavior of the class and impact other users.
If you like our products and services, please help us by posting your review here.

fabbbb
Posts: 3
Joined: Wed Aug 27, 2014 10:26 am
Contact:

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

Post by fabbbb »

Make sum = 200 and make all fields (radiusA, radiusB, and sum) private.
The question does not mention that other classes access any of the fields. Under that circumstance I'd say this could be a correct answer.

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

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

Post by admin »

fabbbb wrote:
Make sum = 200 and make all fields (radiusA, radiusB, and sum) private.
The question does not mention that other classes access any of the fields. Under that circumstance I'd say this could be a correct answer.
Once the class is released, it cannot be known who uses what. public members become part of the public API and cannot be changed because that may break other people's code. That is the point of this question.
For example, Java API has several such methods which have been deprecated since 1.1 (http://docs.oracle.com/javase/7/docs/ap ... -list.html ) but they have to carry them even now.
If you like our products and services, please help us by posting your review here.

GuillaumeBailly
Posts: 3
Joined: Sat Jan 16, 2016 1:20 pm
Contact:

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

Post by GuillaumeBailly »

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

igor.simecki
Posts: 5
Joined: Tue Feb 06, 2018 2:41 am
Contact:

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

Post by igor.simecki »

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

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

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

Post by admin »

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

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 48 guests