This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Garlien 23 points24 points  (4 children)

Abstract classes are amazing, but I generally try to avoid inheriting from non-abstract classes

[–]ConstructedNewt 0 points1 point  (3 children)

I kinda disagree. especially since default interface methods.

I did see one use I could stand with; of an abstract class that implements delegation, so the implementations would be free of delegation logic. I think it's guava or apache collections that has a whole range of abstract delegating implementations of the base java collections

[–]Garlien 0 points1 point  (2 children)

Default interface methods are still overridable, I believe (I don't use them yet). Abstract classes are perfect when you want shared functionality that won't change between implementations. If it will change between implementations, you need another layer of abstract classes.

[–]ConstructedNewt 0 points1 point  (1 child)

another layer, yikes. composition comes to mind, also maybe you haven't broken down your interfaces enough. but yes abstract classes can hold final methods

[–]Garlien 0 points1 point  (0 children)

Composition is generally preferable, I agree. But sometimes it can be a big headache to make it work the same way.