• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Chapter 11 Java Class Design Review Questions question 14 (Sybex)

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chapter 11 Java Class Design Review Questions question 14
Answer in book is option B Plant.
But Plant getter methods are not final, so it is not immutable class.

Question 32 is also similar where answer is A -Flower and not Plant because it does not have final getter methods.

So, answer to the 14 th question should be option D - none
 
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the Ranch

Please provide more details of the question because many of us don't have that book. It is not necessary to mark methods final in order for a class to be immutable, but the class must be final or, like LocalDate have a private constructor and be only instantiable via a factory method. LocalDate is a final class, but because it has no accessible constructors it cannot be subclassed, so it would be immutable without being final.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mukta,
Welcome to CodeRanch!

That question is from our OCA/OCP Practice Tests book.

For #14, the class itself is final so you can't extend it. Which means you can't override the getters. In our OCP book, we list one of the criteria for immutable as "prevent methods from being overidden." The class being final covers that checkbox.
 
Mukta Pradhan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you!

What if methods are final but class is not final, is it a proper implementation of Immutable class?
 
Campbell Ritchie
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mukta Pradhan wrote:Thank you!

That's a pleasure

What if methods are final but class is not final, is it a proper implementation of Immutable class?

Work it out. Can you create a subclass with an additional field whose value can change?
 
Mukta Pradhan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If methods are final and class is not final then the class that inherits this cannot override the methods, and it will not have access to the private fields of parent class.
So, that should be okay.
 
Mukta Pradhan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The subclass can be mutable but the parent class will be immutable. I think...
 
Campbell Ritchie
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mukta Pradhan wrote:The subclass can be mutable . . . . . .

 
Campbell Ritchie
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Did you make hashCode() final? Just think what sort of trouble I can cause by overriding hashCode without overriding equals(). And what sort of trouble could I cause by overriding equals() to account for i? It is now impossible to maintain the general contract for equals() and the Liskov Substitution Principle.Now you can see that even a superclass reference can become mutable because the ”immutable“ class has been extended from.
 
Mukta Pradhan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The Immutable reference to a mutable subclass will not have access to the fields of mutable class in above example 'i'
Only after casting it to the mutable subclass it will have access to fields and methods and can change it.
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What do you think of this?

 
Mukta Pradhan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The SuperClass does not meet the properties of preventing methods from being overridden.
But, this class is currently immutable as we wont able to change its field s.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic