• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Answer for Mock Exam 4, question 9 (Java OCA 8 Programmer I Study Guide)

 
Saad Benbouzid
Greenhorn
Posts: 20
Chrome IntelliJ IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Why is answer C correct ?
Shouldn't the method be named "public int getNumberWings() { return numberWings }" to be JavaBean compliant (camel-case form of the property name) ?

Thanks.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Saad Benbouzid wrote:Why is answer C correct ?
Shouldn't the method be named "public int getNumberWings() { return numberWings }" to be JavaBean compliant (camel-case form of the property name) ?

Because the name of the property name is completely unrelated with the name of the instance variable storing the value.

So the method also adheres to the JavaBeans naming conventionsSo the instance variable is a_b_c_1_2_3 and the property is count (and its accessor method getCount is compliant to the JavaBeans naming conventions).

Hope it helps!
Kind regards,
Roel
 
Vivek Chulani
Greenhorn
Posts: 6
Eclipse IDE Java Oracle
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The value being returned has no relation to the name of the getter method. The method getNumWings does follow camel-case form. Hope this helps.
 
Saad Benbouzid
Greenhorn
Posts: 20
Chrome IntelliJ IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for your answer Roel.

But nevertheless I find it strange, it's not what I've been taught about JavaBean's naming convention, that is to say :
- default or zero-argument constructor,
- implementation of the Serializable interface,
- public accessor and mutators methods.

I thought get() and set() methods have to follow the name of the corresponding properties. For example, your POJO strictly needs to follow this convention if it's involved into serialization and deserialization features, for example if you're using JAXB. If not reflection mechanisms won't work properly.

Serialization/Deserialization won't work for the "numberWings" property if you're exposing "getNumWings()" instead of "getNumberWings()". And it won't also work if you're not implementing simple pass-through getters, for instance "return new Integer(numberWings);" instead of "return numberWings;" regarding an "Integer numberWings" property.

I think that's also what's explained in the JavaBean spec : http://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/
See chapter 8.3 "Design Patterns for Properties".

I'm a bit lost then :/
 
Roel De Nijs
Sheriff
Posts: 10662
144
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
Saad Benbouzid wrote:I think that's also what's explained in the JavaBean spec : http://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/
See chapter 8.3 "Design Patterns for Properties".

No, in my opinion it isn't. That section doesn't mention anything about the actual name of instance variables, it's only about discovering properties based on the names of the accessor and mutator method, the return type of the accessor method and the parameter of the mutator method. Here is the quote from the document (on page 55): If we discover a matching pair of “get<PropertyName>” and “set<PropertyName>” methods that take and return the same type, then we regard these methods as defining a read-write property whose name will be “<propertyName>”. So it's all about the methods which are being inspected, not about the instance variables. This quote confirms that statement: By default, we use design patterns to locate properties by looking for methods of the form: (so the methods determine the name of the properties, not the instance variables).

Have a look at the JellyBean class at pages 44 and 45. It has an ourColor instance variable, but the property is color.

Hope it helps!
Kind regards,
Roel
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35279
384
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For what it's worth, I learned it wrong originally - just like you did!

It is good practice to have the method names match the instance variable. But it's not wrong.
 
Suresh Regmi
Greenhorn
Posts: 19
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel and Jeanne, if you look at the text book page number 206 table 4.5. It states, " 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". Then this saying is wrong. I had also found that answer was not right.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Suresh Regmi wrote:if you look at the text book page number 206 table 4.5. It states, " 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". Then this saying is wrong.

And could you elaborate a little bit about the reason(s) why you think this statement is wrong. For me that's a true statement!
 
Saad Benbouzid
Greenhorn
Posts: 20
Chrome IntelliJ IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel De Nijs wrote:
Suresh Regmi wrote:if you look at the text book page number 206 table 4.5. It states, " 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". Then this saying is wrong.

And could you elaborate a little bit about the reason(s) why you think this statement is wrong. For me that's a true statement!


@Roel: When he said it's wrong, I think Suresh was talking about the answer C of question 9 (my original question). Because according to that statement, supported by the "must" word, for me answer C has no right to be true, since it's clearly not following the naming convention Suresh just quoted from the book.
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 3817
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
C is correct and the statement from the book is also correct. You seem to be confusing "property" with instance variable. If your method is getNumWings, then the bean is said to have a property named numWings. The fact that it does not have numWings variable and that it has numberWings variable is irrelevant.

BTW, option A is correct as well. It is valid for a getter method for a boolean property to start with the name is or get. Both are valid.
 
Saad Benbouzid
Greenhorn
Posts: 20
Chrome IntelliJ IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Anilprem wrote:C is correct and the statement from the book is also correct. You seem to be confusing "property" with instance variable. If your method is getNumWings, then the bean is said to have a property named numWings. The fact that it does not have numWings variable and that it has numberWings variable is irrelevant.

BTW, option A is correct as well. It is valid for a getter method for a boolean property to start with the name is or get. Both are valid.


Hi Paul, thank you for your inputs.
Can you then please explain to Suresh and me what is, in this context, the difference between an instance variable and a property ?

I've read the glossary and some stackoverflows entries, but it's still unclear to me. Sometimes fields and properties are quoted interchangeably, and regarding the glossary a field is an instance variable :
http://docs.oracle.com/javase/tutorial/information/glossary.html

I'm a bit confused since I've always thought property and instance variable mean the same (and I'm actually preparing for the certification to wipe away my numerous a priori :p).
Can you please provide two snippets, as examples describing both a property and an instance variable (within the same class) .

Thanks.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Saad Benbouzid wrote:Can you then please explain to Suresh and me what is, in this context, the difference between an instance variable and a property ?

Have a look at this code snippetClass Example has an instance variable a_b_c_1_2_3 and a property count with an accessor method getCount (which is compliant to JavaBeans naming conventions).

Hope it helps!
Kind regards,
Roel
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 3817
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Saad Benbouzid wrote:
Paul Anilprem wrote:C is correct and the statement from the book is also correct. You seem to be confusing "property" with instance variable. If your method is getNumWings, then the bean is said to have a property named numWings. The fact that it does not have numWings variable and that it has numberWings variable is irrelevant.

BTW, option A is correct as well. It is valid for a getter method for a boolean property to start with the name is or get. Both are valid.


Hi Paul, thank you for your inputs.
Can you then please explain to Suresh and me what is, in this context, the difference between an instance variable and a property ?

I've read the glossary and some stackoverflows entries, but it's still unclear to me. Sometimes fields and properties are quoted interchangeably, and regarding the glossary a field is an instance variable :
http://docs.oracle.com/javase/tutorial/information/glossary.html

I'm a bit confused since I've always thought property and instance variable mean the same (and I'm actually preparing for the certification to wipe away my numerous a priori :p).
Can you please provide two snippets, as examples describing both a property and an instance variable (within the same class) .

Thanks.

It is simple really. Property is an abstract concept. Property is basically a "feature" of an object. An instance variable is a concrete programming language concept that is used to implement the concept of property. It is used interchangeably all over the place and that is the cause of confusion. But technically, they are two different things.
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 3817
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This question itself is a good example.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Anilprem wrote:BTW, option A is correct as well. It is valid for a getter method for a boolean property to start with the name is or get. Both are valid.

True! Already mentioned in this topic as an errata item and it's already on the official errata overview
 
Saad Benbouzid
Greenhorn
Posts: 20
Chrome IntelliJ IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Paul.

Too bad you didn't provide the concrete examples I asked for
However, for me the book must cover this statement with concrete examples, or straight delete this sentence. Suresh and I might not be the only ones wondering why C is still correct after this statement yet written in the official book.

(Page #206, table 4.5. : "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".)

IMHO, this statement either needs to :
- provide concrete examples, including what part of the class exactly is the aforesaid property
- tell us why accessors written like answer C are also right, despite the "must" keyword and what is stated unambiguously

Can Jeanne please bring her insights on this and conclude on this thread ?
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Saad Benbouzid wrote:Too bad you didn't provide the concrete examples I asked for

I already provided 2 times the same example, but for some reason you don't want to use it...

Saad Benbouzid wrote:However, for me the book must cover this statement with concrete examples, or straight delete this sentence. Suresh and I might not be the only ones wondering why C is still correct after this statement yet written in the official book.

There is nothing wrong with that statement, so there is also no reason to delete it.

Saad Benbouzid wrote:(Page #206, table 4.5. : "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".)

Yet another example of this statement: if a class X has a method getCount(), then class X has a property count. Because the method name has the prefix get, the 1st letter of the property is in uppercase (C) and it's followed by the rest of the property name (ount). That's all! Easy to understand, isn't it?

Hope it helps!
Kind regards,
Roel
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 3817
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Saad Benbouzid wrote:
Too bad you didn't provide the concrete examples I asked for
However, for me the book must cover this statement with concrete examples, or straight delete this sentence. Suresh and I might not be the only ones wondering why C is still correct after this statement yet written in the official book.

I agree with it partially. The sentence is correct but the book should make the difference between the two clear.

Example is already there. This question is a concrete example. Not sure why you want me to repeat it or why you don't consider it an example.
 
Saad Benbouzid
Greenhorn
Posts: 20
Chrome IntelliJ IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Paul: I wanted an example illustrating the assertion "[...], followed by the rest of the property name".
That is to say an example involving a property + an accessor (get) complying to the "4.5 statement" + an accessor (also starting with get) not complying to the "4.5 statement".

But as you told me there is no concrete and proper implementation in Java regarding "property", I asked what is the reason for this statement to remain as is in the book. At least the statement should say that it talks about "an abstract concept, which has no equivalent in Java, so just keep in mind that ... etc etc". And by "etc etc" I would expect, among others, the reasons why accessor and mutators can be written independently of the instance variable name returned. As you said, and as the exam expects it (making answer C correct).
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm starting to get the feeling I'm being ignored here!

Saad Benbouzid wrote:That is to say an example involving a property + an accessor (get) complying to the "4.5 statement" + an accessor (also starting with get) not complying to the "4.5 statement".

getNumWings is an accessor method which complies to the "4.5 statement" and getnumWings does not (although it starts with get as well!
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 3817
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Saad Benbouzid wrote:
But as you told me there is no concrete and proper implementation in Java regarding "property"

I did not say that and there indeed is. If you have a non-private method named getXxx, you have a property named xxx. Conversely, if you want to implement a property named xxx, provide a non private method getXxx. That's it. How you implement this method is your call. There may not even be an instance variable. You could return a computed value.
 
Saad Benbouzid
Greenhorn
Posts: 20
Chrome IntelliJ IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know Roel, and I agree.

But then what's the meaning of this : "followed by the rest of the property name".

What is the rest of the property name ?

Following your answer, all these four forms are correct answers, and alll these four forms follow the "4.5 statement", right ?



Then if I understand you correctly and if we agree so far, why is the "4.5 statement" not just saying :
The method name must have a prefix of set/get/is, followed by a letter in uppercase, [eventually] followed by an alphanumeric chain of characters.


instead of :
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.


What is this "property name" mishmash, and why is this "property name" even mentioned if, as you state, field/instance-variable/property name has nothing to do with the accessor/mutator method name to be JavaBean compliant ?



 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 3817
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel De Nijs wrote:I'm starting to get the feeling I'm being ignored here!

Saad Benbouzid wrote:That is to say an example involving a property + an accessor (get) complying to the "4.5 statement" + an accessor (also starting with get) not complying to the "4.5 statement".

getNumWings is an accessor method which complies to the "4.5 statement" and getnumWings does not (although it starts with get as well!


Certainly not by me
 
Saad Benbouzid
Greenhorn
Posts: 20
Chrome IntelliJ IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Anilprem wrote:If you have a non-private method named getXxx, you have a property named xxx


That's it Paul, praise the lawd I finally got my answer ! My confusion was right here Paul, I see the light now.
Thank you all of you and sorry for my insistence.
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 3817
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Saad Benbouzid wrote:
But then what's the meaning of this : "followed by the rest of the property name".

As a designer of your application, you have to decide what property your class should have. It is that name. Again, nothing to do with variable name.
 
Saad Benbouzid
Greenhorn
Posts: 20
Chrome IntelliJ IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Awesome answer, Paul, in due form ! Thank you again.

 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Saad Benbouzid wrote:Following your answer, all these four forms are correct answers, and alll these four forms follow the "4.5 statement", right ?

Correct! And thus you have four properties: numWings, numberWings, foo, and bar.

Saad Benbouzid wrote:Then if I understand you correctly and if we agree so far, why is the "4.5 statement" not just saying :
The method name must have a prefix of set/get/is, followed by a letter in uppercase, [eventually] followed by an alphanumeric chain of characters.


instead of :
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.

Because the property name is not limited to alphanumeric characters, you can have properties like color1, result2, and many more

Hope it helps!
Kind regards,
Roel
 
Saad Benbouzid
Greenhorn
Posts: 20
Chrome IntelliJ IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel De Nijs wrote:Because the property name is not limited to alphanumeric characters, you can have properties like color1, result2, and many more

color1 and result2 are actually of alphanumeric form Roel

But nevermind, I got my answer. Thanks again to you and Paul.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Saad Benbouzid wrote:
Roel De Nijs wrote:Because the property name is not limited to alphanumeric characters, you can have properties like color1, result2, and many more

color1 and result2 are actually of alphanumeric form Roel

Doh, you are right! Let's create another property priceIn$ quickly so no one notices this rookie mistake
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic