Timeline for Object oriented immutability: final classes or final methods
Current License: CC BY-SA 3.0
12 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Feb 14, 2019 at 14:47 | answer | added | Ted Hopp | timeline score: -1 | |
Apr 11, 2018 at 12:29 | history | tweeted | twitter.com/StackSoftEng/status/984045893518348288 | ||
Apr 11, 2018 at 8:09 | answer | added | Nitesh Kumar Thakur | timeline score: -1 | |
Dec 13, 2017 at 18:04 | comment | added | cdeszaq |
One more point to make is that inherited methods (like those from Object such as hashCode , equals , and toString also need to be made final if the class itself is not made final .
|
|
Oct 15, 2013 at 13:39 | comment | added | nablex | @PieterB it is not meant as a comment on finality in general, it is meant as a comment on finality with regards to immutability. In that respect they are very much related if guarantees are to be made by the class designer. | |
Oct 15, 2013 at 13:38 | comment | added | Shivan Dragon | @PieterB docs.scala-lang.org/style/… | |
Oct 15, 2013 at 12:29 | comment | added | Pieter B | You're throwing two different concepts togethers that are only loosely related. | |
Oct 15, 2013 at 12:23 | answer | added | gnat | timeline score: 9 | |
Oct 15, 2013 at 11:59 | history | edited | nablex | CC BY-SA 3.0 |
clarification
|
Oct 15, 2013 at 11:47 | comment | added | Shivan Dragon | Well, one reason would be readability and brevity. If your example class had in fact multiple private values with multiple "getters", without the class-level "final" you'd have to copy paste it on the declaration of each method. Also, if you intended to make the class immutable (rather than just making some of its methods final), its easier to convey that through one word at the very top, rather than multiple instances of that word peppered around in the class body. | |
Oct 15, 2013 at 11:44 | answer | added | ftr | timeline score: 8 | |
Oct 15, 2013 at 11:22 | history | asked | nablex | CC BY-SA 3.0 |