inheritance - Java 8 -- interfaces with default methods vs abstract classes -

inheritance - Java 8 -- interfaces with default methods vs abstract classes -

i'm trying come finish reply to:

"why/when utilize abstract class rather interface."

and looking verification/suggestions on following.

an reply is,

"to provide implementation of it. before concrete classes come in define specific types, abstract class, typically right below interface in inheritance hierarchy (as in many of examples in java apis) implements , pins downwards mutual aspects of construction interface defines.

another reason utilize abstract class there clear logical hierarchy among types. abstract class has utilize organize hierarchy while forcing, beingness abstract class rather concrete one, instantiation of objects on concrete classes downwards below in hierarchy defined , meaningful."

then, in context, comes q:

"since java 8, interfaces can define default method implementations. why wouldn't write default method(s) in interface instead of abstract class implements method(s)? "

the reply be:

" 1 reason is: interface methods public, field members constants (final & public). may wanna restrict access privileges of methods and/or create them operate on non-constant state.

another is: descendant class can phone call upon abstract class method(s) super, while can not on default interface methods. also, interface has no constructors invoked descendants.

the rest of reasons same in pre-java 8 above. "

other these above, why rather go abstract class interface have default interface methods since java 8?

please note: i've seen java 8 default methods vs. non-abstract methods in abstract classes , interface default methods vs abstract class in java 8 along other useful discussions. q rather why chose abstract class on interface other way round.

tia.

here reasons take abstract class on interface. ones list - private fields, etc., of major ones. these few more subtle ones

type clarity. can extend 1 class. makes clearer object how utilize it. the diamond problem. have implement of default methods in interface help avoid diamond problem. if interface collections, can huge pain since there billion of them. abstract class, overwrite need to in java 8, there lambda expressions, , old routine of passing around interface method implement has been usurped. still, when see interface default method, can interpreted in ways might not intend

here's oracle has on subject:

which should use, abstract classes or interfaces? consider using abstract classes if of these statements apply situation:

you want share code among several closely related classes. you expect classes extend abstract class have many mutual methods or fields, or require access modifiers other public (such protected , private). you want declare non-static or non-final fields. enables define methods can access , modify state of object belong.

in article, orace defends distinction between 2 type systems https://docs.oracle.com/javase/tutorial/java/iandi/abstract.html

edit clarify "diamond problem" bullet problem described here (and many other places) http://www.lambdafaq.org/what-about-the-diamond-problem/

the problem occurs when inherit 2 places declare same method, , have pick 1 when resolving function call. never issue in java 7-, since extend 1 class , interfaces had no methods.

the resolution tactic little complicated, here description of it: (from http://blog.loxal.net/2013/05/java-8-default-interface.html)

to address diamond problem there precedence in order implementation used: if class implements default / optional methods of interfaces, code can compiled , implementations of class used. otherwise compiler tries patch missing implementation(s) interface's default implementation. , if there multiple default implementations of method, diamond problem occurs , compiler rejects compilation. if class implements interface's default method, implementation of class used instead of interfaces's default implementation.

if stick abstract classes, never run problem. however, if object required implement 2 interfaces (because needs added lists expecting types, e.g.), and interfaces have conflicting method signatures, wind having redefine whole bunch of methods if means you're making super calls, sort of defeats point of inheritance-based dynamic dispatch. isn't deal-breaker, consider when structuring complex java project

inheritance interface abstract-class java-8