StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>The other answers seem to focused on explaining why immutability is good. It is very good and I use it whenever possible. <em>However, that is not your question</em>. I'll take your question point by point to try to make sure you're getting the answers and examples you need.</p> <blockquote> <p>I am unable to get what are the scenarios where we need an immutable class.</p> </blockquote> <p>"Need" is a relative term here. Immutable classes are a design pattern that, like any paradigm/pattern/tool, is there to make constructing software easier. Similarly, plenty of code was written before the OO paradigm came along, but count me among the programmers that <em>"need"</em> OO. Immutable classes, like OO, aren't strictly <em>needed</em>, but I going to act like I need them.</p> <blockquote> <p>Have you ever faced any such requirement?</p> </blockquote> <p>If you aren't looking at the objects in the problem domain with the right perspective, you may not see a <em>requirement</em> for an immutable object. It might be easy to think that a problem domain doesn't <em>require</em> any immutable classes if you're not familiar when to use them advantageously.</p> <p>I often use immutable classes where I think of a given object in my problem domain as <strong>a value or fixed instance</strong>. This notion is sometimes dependent on perspective or viewpoint, but ideally, it will be easy to switch into the right perspective to identify good candidate objects.</p> <p>You can get a better sense of where immutable objects are <em>really useful</em> (if not strictly necessary) by making sure you read up on various books/online articles to develop a good sense for how to think about immutable classes. One good article to get you started is <a href="http://www.ibm.com/developerworks/java/library/j-jtp02183.html" rel="noreferrer">Java theory and practice: To mutate or not to mutate?</a></p> <p>I'll try to give a couple of examples below of how one can see objects in different perspectives (mutable vs immutable) to clarify what I mean by perspective.</p> <blockquote> <p>... can you please give us any real example where we should use this pattern.</p> </blockquote> <p>Since you asked for real examples I'll give you some, but first lets start with some classic examples.</p> <p><strong>Classic Value Objects</strong></p> <p>Strings and integers and are often thought of as values. Therefore its not surprising to find that String class and the Integer wrapper class (as well as the other wrapper classes) are immutable in Java. A color is usually thought of as a value, thus the immutable Color class.</p> <p><strong>Counterexample</strong></p> <p>In contrast, a car is not usually thought of as a value object. Modeling a car usually means a creating a class that has changing state (odometer, speed, fuel level, etc). However, there are some domains where it car may be a value object. For example, a car (or specifically a car model) might be thought of as a value object in an app to look up the proper motor oil for a given vehicle.</p> <p><strong>Playing Cards</strong></p> <p>Ever write a playing card program? I did. I could have represented a playing card as a mutable object with a mutable suit and rank. A draw-poker hand could be 5 fixed instances where replacing the 5th card in my hand would mean mutating the 5th playing card instance into a new card by changing its suit and rank ivars.</p> <p>However, I tend to think of a playing card as an immutable object that has a fixed unchanging suit and rank once created. My draw poker hand would be 5 instances and replacing a card in my hand would involve discarding one of those instance and adding a new random instance to my hand.</p> <p><strong>Map Projection</strong></p> <p>One last example is when I worked on some map code where the map could display itself in various <a href="http://en.wikipedia.org/wiki/Map_projection" rel="noreferrer">projections</a>. The original code had the map use a fixed, but mutatable projection instance (like the mutable playing card above). Changing the map projection meant mutating the map's projection instance's ivars (projection type, center point, zoom, etc).</p> <p>However, I felt the design was simpler if I thought of a projection as an immutable value or fixed instance. Changing the map projection meant having the map reference a different projection instance rather than mutating the map's fixed projection instance. This also made it simpler to capture named projections such as <code>MERCATOR_WORLD_VIEW</code>.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload