final and inheritance

[Tomasz Cichecki]

What is marking a class as final useful for ? I came across this post on github: http://ocramius.github.io/blog/when-to-declare-classes-final/. Do you agree with the guideline ?

[Sebastian Gozin]

I just go for never final.

[Juan Manuel Gimeno Illa]

Joshua Boch in Effective Java says that classes not intended to be subclassed should be marked final. The idea is that an extensible by inheritance classs should be carefully constructed and documented (e.g. all uses of overridable methods in the class) so, if one does not intend for a class to be extended that way, one should prohibit it making it final (or defining its constrcutor private).

FWIW I rarelly do that.

JM

[anand raman]

if the intention is that the function will be never extended sure "go for final". However I havent been ale to identify such situations during the build out. Hence I dont use finals almost ever. 

anand

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

--

Phone +91 98809 37073
http://twitter.com/diduknow & http://semi-long-form.blogspot.com

[Ryan Schmitt]

The biggest problem with marking classes 'final' is that you cannot mock them using a tool like Mockito. I generally mark value types final (in fact, Lombok does it automatically: http://projectlombok.org/features/Value.html ), because otherwise there's no way to guarantee immutability (and there are other problems as well).

[Sebastian Gozin]

Even with value types I typically do not bother. While I agree immutability would be nice, languages like Java just fight you every step of the way I simply gave up.
I expect people to respect the immutability contract even though it is not enforced.
Not always possible but mostly works.

[Tomasz Cichecki]

While I do agree that the final gets in the way of testing tools I personally think that this is a problem for the tools to solve. Think about the debugger: it's hard to imagine someone released a debugger that's not capable debugging a final class or it was not able to peek or amend static values. Of course using final affects us as developers because when using the keyword we have to take into consideration the limitations it imposes. But I have the impression that not using final for the sake of not being to able to stub/mock is like using in the code if (debug) { } else { }. One might argue that the same goes for the access quanifiers i.e. private vs protected vs public and that the tests trump encapsulation but I think it's not the same case as tests actually help to discover what quantifiers you need to apply.

[Tomasz Cichecki]

The real problem with final I have is that the article describes the ideal situation where the author of a final class provides an interface so that we can supply our own implementation and that all the existing client code uses the abstract type. In the real world however I observe something quite different from that. The author doesn't care to provide the abstraction or the client programmers tend to use the concrate type. In fact it's worse than that: the author deliberately marks the class final and doesn't provide the interface in fact suggesting "if you want it differently provide your own" and than grins knowing that if I wanted even a small change I'd have to change and recompile vast parts of the system. Even as unobstractive change as decorating objects of a final class is impossible. So I usually consider final as a way to enforce certain coding style and sealing certain design decisions rather than a sign of someone carrying about the system architecture.

W dniu poniedziałek, 12 stycznia 2015 04:45:43 UTC+1 użytkownik Ryan Schmitt napisał:

[Caio Fernando Paes de Andrade]

I see final as defensive programming: harmful in code shared by a team, helpful in code exposed to the world.

Caio

Sent from my iPhone

--

[Robert C. Martin]

I never, ever, make a class final.  I can’t imagine a scenario where that would be useful.  I can only imagine it making life difficult for me and others.  

My guideline:  Don’t do Final unless you absolutely have to, and you’ve exhausted every other option.

[Ryan Schmitt]

You can't imagine a scenario where guaranteed immutability (which implies the final keyword) would be useful? Apparently the JDK authors could: for a number of reasons related to thread-safety, performance, caching, and--most interestingly--security, they made java.lang.String final.

http://stackoverflow.com/questions/2068804/why-is-string-class-declared-final-in-java

As this example shows, "immutability by best intentions," where the immutability of a data type is a mere convention that is in no way actually enforced, is very often simply not good enough, particularly for library authors. Does anyone really want to go back to the days of mutable strings? Does anyone want to live in a world where you have to make defensive deep copies of strings before using them as keys in hash maps, in case the string is actually a mutable subclass of java.lang.String?

[Indrit Selimi]

I don't agree. Coding should be as much as possible a "collaborative" activity not unilaterally enforcing doubtful policies.

I almost never user final classes.

[Tomasz Cichecki]

I think that Unclebob refers to everyday programming activities and crafting a string implementation just doesn't seem to be one of them but the link was very useful for me to get a bettter understanding where final might actually apply.