• Post Reply Bookmark Topic Watch Topic
  • New Topic

Opinion about getter method and Errata OCA Online Exam (Sybex)  RSS feed

 
Ranch Hand
Posts: 115
11
Eclipse IDE Hibernate Java Netbeans IDE Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, how are you guys?

I just took the Chapter 4 exam few hours ago (from the book oca java se 8 Study Guide, by Jeanne and Scott), and I think there is some errors in two questions.

The first one is in question 9. It says that the correct answers are C and E. To be honest, I just chose the letter A because the books says it is right. I always use the getters for booleans as boolean isVariableName(). But the book says that using get is right, and the question says that it is wrong. What do you guys think about it?
Another error in this question, I don't think the letter C is correct, since it says the following:

But it should start with get and then the name of the variable, like this:

And the result says that letter C is right. Or am I being too annoying?
This problem appears both in the book and in the online test.

Here is the images of the question 9:




Now, the other problem is in question 19. The result says that A and G are correct. First of all, letter G has a brace missing. The question says "Which of these classes compile and use a default constructor". So I thought it was a tricky answer, since the missing brace would give a compiler error. I saw that an errata is already defined to this error, but for the book, not for the site (at least I didn't find it).
Well, as you see, I chose letter A and D. In letter D, the constructor is defined, but it looks like a default constructor. A default constructor is only defined by the compiler, I can't consider a predefined constructor to be a default constructor, right? I can't make mistakes like this.


But I'm not that sad, because I made a score of 26/29 in this Chapter Exam. The other error was a total lack of attention.

Thanks again!
 
João Victor Gomes
Ranch Hand
Posts: 115
11
Eclipse IDE Hibernate Java Netbeans IDE Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As you might see, I lost a precious time. Those are questions to be answered in a few seconds, but I got distracted by the issues that I mentioned before.
 
Sheriff
Posts: 11338
177
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

João Victor Gomes wrote:But it should start with get and then the name of the variable, like this:


Definitely not! This question/confusion has already appeared several times in this forum In this topic and this one you'll find a detailed explanation (and discussion) about this question. Definitely worth reading! In short: there's no requirement about the instance variable itself, so the name of the property is defined by its getter/setter methods (and often it's exactly the same as the instance variable but that's not a requirement). So this code snippet correctly defines a property count

João Victor Gomes wrote:In letter D, the constructor is defined, but it looks like a default constructor. A default constructor is only defined by the compiler, I can't consider a predefined constructor to be a default constructor, right? I can't make mistakes like this.


In answer D a no-arg constructor is defined. And the distinction between both can sometimes be very confusing. Back in the days when I was preparing for my first Java certification exam(s), I also had some difficulties with this distinction. In short: Every default constructor is a no-arg constructor, but not every no-arg constructor is a default constructor. Only a class which does not define any constructors will have a default constructor. If a class defines at least one constructor, it will not have a default constructor (but it can have a no-arg constructor, like in answer D).

Hope it helps!
Kind regards,
Roel
 
João Victor Gomes
Ranch Hand
Posts: 115
11
Eclipse IDE Hibernate Java Netbeans IDE Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Roel, thanks for the answer.
I should have searched those topics before, but I was so tired that I forgot to. Sorry.
Great information is provided by those topics. I've always used set/get followed by the instance variable name, and isVariableName() for boolean accessor (I will talk about this in a minute).
I wasn't paying attention to something important. The book says "The method name must have a prefix of set/get/is, followed by the first letter of the property in uppercase, followed by the rest of the property name". I've switched the "property name" by "instance variable name". That's why I was thinking that the question was wrong. And, of course, as I said, I always used the is/get/set followed by the instance variable name. So this collaborated with my mistake.

But I still have two questions.
First question: In one of the topics that you recommended to me, Paul Anilprem said this about the getters and setters. I know he is not talking about encapsulation, but now I have some doubts. Considering the encapsulation concepts, a getter or setter can be non-private? Not just public?

Second question: So, the use of get to a boolean accessor is ok, right? I always used is. So, if I see a question in the real exam with the following code:


I can choose it as a right answer without thinking twice, right?

And, finally, the questions of the Chapter 4 Online Exam that I've mentioned still need to be fixed. Question 9 doesn't consider letter A as right. Alternative G of question 19 has a brace missing.

Thank you very much Roel.
 
João Victor Gomes
Ranch Hand
Posts: 115
11
Eclipse IDE Hibernate Java Netbeans IDE Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Roel De Nijs wrote:
[...] Every default constructor is a no-arg constructor, but not every no-arg constructor is a default constructor. Only a class which does not define any constructors will have a default constructor. If a class defines at least one constructor, it will not have a default constructor (but it can have a no-arg constructor, like in answer D).



That's it. I remembered now that the OCA & OCP Java SE 7 by Kathy and Bert did explain this rule, and I forgot.
I'll never miss it again.
 
Roel De Nijs
Sheriff
Posts: 11338
177
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

João Victor Gomes wrote:And, of course, as I said, I always used the is/get/set followed by the instance variable name.


That's a very common practice! But you could have a property without an instance variable because it's a computed value.

João Victor Gomes wrote:a getter or setter can be non-private? Not just public?


Of course!

João Victor Gomes wrote:I can choose it as a right answer without thinking twice, right?


Yes, you can! For a boolean both prefixes get and is are allowed.

João Victor Gomes wrote:And, finally, the questions of the Chapter 4 Online Exam that I've mentioned still need to be fixed. Question 9 doesn't consider letter A as right. Alternative G of question 19 has a brace missing.


Both are listed on the official errata overview and are already reported here and here. And the online question bank is just a copy of the questions in the book, so an error occuring in the book is almost guaranteed to occur online as well. In the online version there might be some additional errata due to the process of converting a text book question into an online one.
 
João Victor Gomes
Ranch Hand
Posts: 115
11
Eclipse IDE Hibernate Java Netbeans IDE Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I thought that for encapsulation concepts, the getters and setters should be public. I'm glad that I asked about it.

Thanks for the clarification.
 
Roel De Nijs
Sheriff
Posts: 11338
177
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

João Victor Gomes wrote:Well, I thought that for encapsulation concepts, the getters and setters should be public. I'm glad that I asked about it.


Encapsulation is nothing more than hiding the internal state (and implementation details). In its most common form instance variables are marked private and the accessor & mutator methods (often getters and setters) are marked public. But altough it's a must requirement to have private instance variables (so they are certainly hidden for the outside world), the accessor & mutator methods can have default or protected access. That only adds some more restrictions to the classes that can access these methods. But for a well-encapsulated class it's not required that all methods are accessible to all classes in the Java universe. A well-encapsulated class must fulfill two requirements: (1) its internal state (variables) is hidden and (2) all interaction is performed through methods.
 
João Victor Gomes
Ranch Hand
Posts: 115
11
Eclipse IDE Hibernate Java Netbeans IDE Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Roel De Nijs wrote:

João Victor Gomes wrote:Well, I thought that for encapsulation concepts, the getters and setters should be public. I'm glad that I asked about it.


Encapsulation is nothing more than hiding the internal state (and implementation details). In its most common form instance variables are marked private and the accessor & mutator methods (often getters and setters) are marked public. But altough it's a must requirement to have private instance variables (so they are certainly hidden for the outside world), the accessor & mutator methods can have default or protected access. That only adds some more restrictions to the classes that can access these methods. But for a well-encapsulated class it's not required that all methods are accessible to all classes in the Java universe. A well-encapsulated class must fulfill two requirements: (1) its internal state (variables) is hidden and (2) all interaction is performed through methods.



I got that.

Maybe the book should be more specific about it. For example, page 205, last paragraph says "For encapsulation, remember that data (an instance variable) is private and getters/setters are public". And also, page 217 says "Look for private instance variables and public getters and setters when identifying encapsulation".
Maybe that's because the exam just requires us to know about the public access of the methods, expecting that we know about the default and protected access modifiers. Or maybe that's because the public are more common.
But as you brought up the subject, both default and protected access modifiers still make the getters and setters visible, but for a more restricted group of classes. And it really makes sense, since, as you said, the main reason of using encapsulation is to prevent an instance variable of being accessed directly, so a method is necessary to handle this access.
Considering the definition above, it is easy to know that getters and setters may have public, default or protected access modifiers.
To be honest, the book mentions this, with other words. I just got confused because of those two examples that I mentioned in the beginning of this post, because one of them was placed in the final considerations of the chapter.

Thanks again for this nice discussion!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!