Timeline for Why is using 'final' on a class really so bad?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 7, 2022 at 16:31 | comment | added | usr | @KonradRudolph Java takes this non-final-by-default mistake to the extreme. Methods are virtual by default. This is dangerous design. I'm sure many compatibility issues are caused by the fact that API consumers override things that were not designed to be overridden. | |
| Dec 7, 2022 at 9:21 | history | edited | Konrad Rudolph | CC BY-SA 4.0 |
give more sources
|
| Dec 7, 2022 at 8:49 | history | edited | Konrad Rudolph | CC BY-SA 4.0 |
update dead link
|
| Dec 7, 2022 at 8:44 | comment | added | Konrad Rudolph | @Corrodias On the contrary, this is pretty settled: there is an extremely wide agreement amongst OOP experts that “final by default”/“make extensibility explicit” is, in fact, the right design decision, and that not doing so is a mistake. I am not aware of any OOP thought leader who disagrees (I’m sure there must be a few, but they’d be in the minority, by far). | |
| Dec 6, 2022 at 22:49 | comment | added | usr | Any language that makes classes non-final by default has made a mistake. C# made that mistake for example. | |
| Dec 6, 2022 at 17:09 | comment | added | Corrodias | @KonradRudolph Dynamically typed languages yet have a place, I'm sure. But that's an interesting perspective. I think making the case for less power being better is a vital aspect of explaining why "always final" is the better approach, because that's not a settled debate. Then again, I can't remember the last time I extended a foreign class, but I do remember the last time I had to use reflection to work around a bug. | |
| Dec 6, 2022 at 11:24 | comment | added | Konrad Rudolph | @Corrodias I don’t really know what improvement you want to see. Would replacing “documents” with “documents […] and enforces this limitation” be better? To be clear, limitations of power in programming languages are almost without exception a good thing. This is why we have a type system, after all. It’s the opposite (= permissiveness) which needs to justify its acceptability. | |
| Dec 6, 2022 at 9:25 | comment | added | Corrodias | The answer only claims that "final" is documentation, but it does more than document. It limits the power of other people and code using the class. If it's to provide a compelling case for "final", it ought to address why that limitation of power is acceptable, IMO. | |
| Apr 12, 2017 at 7:31 | history | edited | CommunityBot |
replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
|
|
| Aug 18, 2016 at 5:49 | comment | added | Alexander Malakhov | "Jon Skeet" link is dead. Probably it was moved to this SO question. | |
| Oct 5, 2011 at 22:00 | vote | accept | JW01 | ||
| Jul 17, 2011 at 17:47 | comment | added | Jonny Dee | I'm still not convinced that using 'final' more often has become a best practice. In my opinion, the 'final' should really be used only if performance requirements dictate it, or if you must assure consistency cannot be broken by subclasses. In all other cases necessary documentation should go into, well, the documentation (which needs to be written anyway), and not into the source code as keywords that enforce certain usage patterns. To me, that's kind of playing god. Using annotations whould be a better solution. One could add a '@final' annotation and the compiler could issue a warning. | |
| Jul 17, 2011 at 10:07 | comment | added | Konrad Rudolph |
@Jonny Most of the Java API is badly designed. Remember that the bulk of it is more than ten years old and many best practices have been developed in the meantime. But don’t take my word for it: the Java engineers themselves say so, first and foremost Josh Bloch who has written in detail about this, e.g. in Effective Java. Rest assured that if the Java API were developed today, it would look very different, and final would play a much bigger role.
|
|
| Jul 16, 2011 at 20:46 | comment | added | Jonny Dee | You can consider the Java API itself and how often you will find the usage of the 'final' keyword. In fact, it is not used very often. It is used in cases were performance might get bad due to the dynamic binding taking place when "virtual" methods are called (in Java all methods are virtual if they are not declared as 'final' or 'private'), or when introducing custom subclasses of a Java API class might arise consistency issues, such as subclassing 'java.lang.String'. A Java String is a value object per definition and must not change its value later on. A subclass could break this rule. | |
| Jul 14, 2011 at 16:18 | comment | added | JW01 | Well that puts a spanner in the works. This late arrival contradicts all the other answers. Now I do not know what to believe :o. (Unticked my accepted answer and hold off decision during re-trial) | |
| Jul 14, 2011 at 11:49 | comment | added | Spoike | 1+: Since it screws up mocking; consider creating interfaces or abstract classes for each "final" class. | |
| Jul 14, 2011 at 7:00 | history | answered | Konrad Rudolph | CC BY-SA 3.0 |