Win a copy of Murach's Java Programming this week in the Beginning Java forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Again, the Encapsulation, plus Immutability  RSS feed

 
João Victor Gomes
Ranch Hand
Posts: 110
11
Eclipse IDE Java Netbeans IDE Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello everyone

Although there is already a topic discussing this mock exam question here, I would like to bring up this subject again.

I just finished the first mock exam of Sybex online tool (from the study guide by Jeanne and Scott), and there is something that let me thoughtful.
Well, apparently for encapsulation, the setter method isn't required. Ok, after I finished the test and thought about my mistake, I remembered the main definition of encapsulation: the instance variables can't be directly accessed. Without a setter doesn't mean that the variable won't be accessible anymore. But it is a little confusing, because I always consider encapsulation as a private instance variable with public getter/setter, because it is often used for this purpose.
The book keeps mentioning the public getter and setter for encapsulation, so when I face a question like this one, I let these rules exceptions escape from my control. What I understand now is, for encapsulation, a setter method isn't required, is that right?

The other issue is about immutability. The question says that letter F is right. But removing the setter method, we still need a constructor to initialize the instance variable. Or the default initialization is considered when talking about immutability? If the default initialization may be considered, is it true to say "All immutable classes are encapsulated, but not every encapsulated classes are immutable"? Since we don't need a setter method for encapsulation, all immutable classes are encapsulated.

Thanks again guys.



 
Liutauras Vilda
Marshal
Posts: 4252
255
BSD
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Question and provided answers and explanations are right.

João Victor Gomes wrote:... the instance variables can't be directly accessed.
What I understand now is, for encapsulation, a setter method isn't required, is that right?

That is right. Once instance variable is private, it cannot be accessed through object's reference variable directly and changed value for instance. For accessing variable you need to use public class's methods, getter or setter - one gives you a value, another let's you set a value.

Now, what is important about setter to know. With a setter you can control what value user can set. For instance 'age'. You might don't want nobody to let set value as -4. So in a setter method you can control that it never happens. Well encapsulated class never has its instance fields public.

Setter as you mentioned isn't mandatory. Setter lets mutate object's state. So, in order for the class to be immutable, setter shouldn't be provided. Assigning value once during object's instantiation isni't considered as mutability.

Object is immutable once he got state set (during objects creation, pressumably via its constructor) and it never change anymore. But that doesn't mean, that you cannot have multible objects with difference states. That means that particular object cannot mutate from its initial state.

 
João Victor Gomes
Ranch Hand
Posts: 110
11
Eclipse IDE Java Netbeans IDE Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Liutauras

So, I can assume that for immutability, the default value of an instance variable may be considered? Since in this question of the mock exam, the alternative F mentions making line 2 private and removing the setter method, but it doesn't mention creating a constructor to initialize the values. For immutability, I'm under no obligation to create a constructor with arguments?
 
Roel De Nijs
Sheriff
Posts: 11294
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:is it true to say "All immutable classes are encapsulated, but not every encapsulated classes are immutable"? Since we don't need a setter method for encapsulation, all immutable classes are encapsulated.

Definitely not!

This class is immutable, but is not encapsulated
 
João Victor Gomes
Ranch Hand
Posts: 110
11
Eclipse IDE 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:is it true to say "All immutable classes are encapsulated, but not every encapsulated classes are immutable"? Since we don't need a setter method for encapsulation, all immutable classes are encapsulated.

Definitely not!

This class is immutable, but is not encapsulated


Good point.

But can I consider a class without a contructor with arguments as immutable? I mean, the question says that making line 2 private and removing lines 6-8 would exhibit immutability, but there is no constructor with arguments to initialize the values.
Thus, I can assume that a class object can be immutable even without a constructor to initialize the values, since immutability means that an object of a class can't have its values changed, just initialized, and the values of an object (instance variables) will always be initialized (by the programmer, or by the JVM, with default values).
 
Roel De Nijs
Sheriff
Posts: 11294
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 can I consider a class without a contructor with arguments as immutable? I mean, the question says that making line 2 private and removing lines 6-8 would exhibit immutability, but there is no constructor with arguments to initialize the values.

If you make line 2 private and remove lines 6-8, you can't change the value of the (instance) variable height and the variable keeps its (default) value forever and ever. So yes, although not very useful, that's an immutable class.
 
Curse your sudden but inevitable betrayal! And this tiny ad too!
Thoughts on deprecation in Java
https://coderanch.com/t/683016/java/Deprecation-Java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!