Skip to main content
61 events
when toggle format what by license comment
S Aug 4, 2016 at 15:20 history notice added Thomas Owens Historical significance
S Aug 4, 2016 at 15:20 history locked Thomas Owens
Aug 4, 2016 at 15:20 history closed Thomas Owens Needs more focus
Apr 7, 2016 at 4:18 comment added andho @JimboJonny if implemented correctly yes. But in context of a Java Bean, any other object is able to manipulate the data the class is responsible for and allows invalidating the invariants of the object. This style is okay for Anemic Domains, but then they are just data structures. All setters are mutators but not all mutators are setters. If you implement mutators as command methods, the classes will become more descriptive and more appropriate to the essence of OOP. The problem is most of the time, the classes not having any behaviour/logic except setting and getting values.
Apr 2, 2016 at 20:03 comment added Jimbo Jonny @andho - ...that's 100% incorrect. Getters and setters are actually, literally, what makes encapsulation in OOP by abstracting away the internal changes to the external accessors/mutators (i.e. getters/setters). Read up on OOP: codebetter.com/raymondlewallen/2005/07/19/…
Apr 2, 2016 at 19:57 comment added Jimbo Jonny Immutable is best for 5% of stuff, mutable is best for 5% of stuff, and the other 90% of the time these objects aren't being used it ways where it matters either way. Therefore since mutable is default it takes that 90%. So 95% is mutable...which is about what most programmers do. Most people don't treat trends as religions...we just use them where they're useful.
Jan 10, 2016 at 14:50 comment added BornToCode @GrandmasterB - Could you please give some examples for situations where immutable are more appropriate ?
Sep 26, 2015 at 0:00 comment added Isaiah van der Elst Mutable objects aren't bad. The problem is that they are often abused and handled irresponsibly. It does irk me a little when I run across a method that returns a value and edits the mutable parameters with zero documentation. (what happened to the single responsibility principle).
Jan 29, 2015 at 4:54 comment added andho Just a bit related to Immutability. But getters and setters is a direct violation of Encapsulation which is the main principle of OOP. This takes the responsibility of the state of the data away from the Object/Class which pretty much defeats the purpose of OOP.
Dec 9, 2014 at 8:01 answer added Dr. Hans-Peter Störr timeline score: 1
Oct 21, 2014 at 7:20 review Close votes
Oct 29, 2014 at 3:03
Oct 21, 2014 at 7:00 history edited DarkWanderer
The question is related not only to Java
Jun 10, 2014 at 6:24 answer added yegor256 timeline score: 7
Mar 17, 2014 at 21:17 history protected Doc Brown
Jan 1, 2014 at 9:16 answer added Alexey timeline score: -1
Jan 1, 2014 at 6:21 answer added Jon timeline score: 0
Nov 5, 2013 at 15:09 comment added Dunk Of course if you design your objects to just be data-classes then I guess immutable is a "good-thing". However, good OO designs generally don't design their classes to just be data-classes. Thus, I really wonder about the types of designs coming out of people that make extensive use of immutable objects.
Nov 5, 2013 at 4:06 comment added Erik Reppen Immutable vs mutable is failure to recognize the real problem IMO which is an excess of objects mutating other objects.
Nov 5, 2013 at 2:57 answer added Jay timeline score: 5
Jul 10, 2013 at 4:44 answer added Michael Ozeryansky timeline score: 1
Sep 20, 2012 at 14:42 answer added MSalters timeline score: 4
Sep 20, 2012 at 9:13 comment added SK-logic What's the point in objects if everything is immutable? Use proper functional languages instead.
Sep 20, 2012 at 4:39 answer added Adam Gent timeline score: 5
S Aug 24, 2012 at 15:48 answer added supercat timeline score: 9
S Aug 24, 2012 at 15:48 history made wiki Post Made Community Wiki by supercat
Aug 17, 2012 at 16:55 answer added dan_waterworth timeline score: 4
Aug 17, 2012 at 16:13 answer added Giorgio timeline score: 1
Aug 17, 2012 at 15:13 comment added Paul @leftaroundabout I use Java because it works. It's not the latest fashion, but it works.
Aug 17, 2012 at 15:10 comment added Paul In iOS objective-C, array = [array arraywithobject:] performance sucks... So immutable for performance.
Aug 17, 2012 at 12:59 answer added Tulains Córdova timeline score: 1
Jun 11, 2012 at 16:45 history edited Arseni Mourzenko CC BY-SA 3.0
added definitions of im/mutable objects and links to their Wikipedia article
S Jun 11, 2012 at 16:45 history suggested ahsteele CC BY-SA 3.0
added definitions of im/mutable objects and links to their Wikipedia article
Jun 11, 2012 at 16:40 review Suggested edits
S Jun 11, 2012 at 16:45
Jun 11, 2012 at 7:02 vote accept Vinoth Kumar C M
Jun 8, 2012 at 14:34 comment added user4051 @GrandmasterB read "if" as "given that" and you don't need to be offended by the opening of the question ;-)
Jun 7, 2012 at 9:10 comment added leftaroundabout Why do people keep using the Java language at all, if it is on one hand ridiculously uncompromising about "good style" of pure OO but does very little to even encourage style decisions that would really be useful, such as not using mutable state?
Jun 7, 2012 at 3:40 comment added user16764 Why are immutable objects good?
Jun 7, 2012 at 2:08 answer added gutch timeline score: 12
Jun 7, 2012 at 0:46 answer added Bill K timeline score: 1
Jun 6, 2012 at 20:43 comment added GrandmasterB -1, immutable objects arent 'good'. Just more or less appropriate for specific situations. Anyone telling you one technique or another is objectively 'good' or 'bad' over another for all situations is selling you religion.
Jun 6, 2012 at 20:08 answer added haylem timeline score: 8
Jun 6, 2012 at 19:31 comment added iteratingself one reason: convenience
Jun 6, 2012 at 19:21 answer added Jerry Coffin timeline score: 13
Jun 6, 2012 at 18:28 comment added hugomg BTW - even if we ignore the whole mutability vs immutability issue, public getters and setters are a well known source of pain in OO design, since they tend to break encapsulation and invariants.
Jun 6, 2012 at 18:13 comment added ctrl-alt-delor Don't call them lazy. I am lazy. I make my classes immutable (usually), because it increases my chance of getting it right first time, and I can't be bothered with debugging. Yes busy is the word, very busy.
Jun 6, 2012 at 17:53 comment added Onorio Catenacci By the way, it's not "getters" and "setters" that make an object mutable or not. Public member variables can be modified without getters and setters--and that makes an object mutable.
Jun 6, 2012 at 15:13 answer added Onorio Catenacci timeline score: 130
Jun 6, 2012 at 14:44 answer added Ralf H timeline score: -2
Jun 6, 2012 at 14:41 comment added Binary Worrier @Joachim: I think it's fairly obvious that "lazy" was used in it's pejorative sense above :) Also, Immutable Objects (like Lambda Calculus, and OOP back in the day - yes I am that old) don't need to be new to suddenly become flavour of the month. I'm not arguing that they're a bad thing (they're not), or that they don't have their place (they obviously do), just go easy on folks because they haven't heard the latest Good Word and been converted as fervently oneself (not blaming you for the "lazy" comment, I know you tried to mitigate it).
Jun 6, 2012 at 14:19 answer added RalphChapin timeline score: 1
Jun 6, 2012 at 13:51 comment added Joachim Sauer @BinaryWorrier: immutable objects are hardly a "new thing". They might not have been used heavily for domain objects, but Java and C# had them from the very beginning. Also: "lazy" is not always a bad word, some kinds of "lazy" are an absolute advantage for a developer.
Jun 6, 2012 at 13:40 answer added smartcaveman timeline score: 49
Jun 6, 2012 at 13:33 answer added Paul Sanwald timeline score: 36
Jun 6, 2012 at 12:21 comment added Binary Worrier For every evangelical programmer/blogger there are 1000 avid blog readers that immediately re-invent themselves and adopt the latest techniques. For every one of those there are 10,000 programmers out there with their nose to the grind stone getting a days work done and getting product out the door. Those guys are using tried and trusted techniques that have worked for them for years. They wait until new techniques are widely adopted and show actual benefits before taking them up. Don't call them stupid, and they're anything but lazy, call them "busy" instead.
Jun 6, 2012 at 10:34 history tweeted twitter.com/#!/StackProgrammer/status/210318831955099648
Jun 6, 2012 at 9:48 vote accept Vinoth Kumar C M
Jun 6, 2012 at 15:54
Jun 6, 2012 at 7:58 comment added Joachim Sauer I think that, apart from legitimate reasons (as mentioned by Péter below), "lazy developer" is a more common reason than "stupid" developer". And before "stupid developer" there's also "uninformed developer".
Jun 6, 2012 at 7:55 answer added Florian Salihovic timeline score: 29
Jun 6, 2012 at 7:51 answer added Péter Török timeline score: 324
Jun 6, 2012 at 7:46 history edited yannis CC BY-SA 3.0
please don't add tags in titles, the more popular tag is automatically prepended, and your question would appear in search engines like "java - Java : ...". Also avoid spaces before punctuation marks...
Jun 6, 2012 at 7:44 history asked Vinoth Kumar C M CC BY-SA 3.0