Hi Ken, -----Original Message-----
From: Ken Krugler <kkrugler_li...@transpac.com> Reply-To: "dev@tika.apache.org" <dev@tika.apache.org> Date: Tuesday, February 9, 2016 at 8:54 AM To: "dev@tika.apache.org" <dev@tika.apache.org> Subject: RE: Use of interface vs. abstract class >Hi Chris, > >> From: Mattmann, Chris A (3980) >> Sent: February 9, 2016 8:40:06am PST >> To: dev@tika.apache.org >> Cc: Trevor Claude Lewis; Ramirez, Paul M (398M) >> Subject: Re: Use of interface vs. abstract class >> >> Hey Ken, >> >> My general preference in these situations is to use an interface; >> then to provide an abstract base class, and encourage some limited >> method implementation and basic functionality to bubble up into >> the abstract base class that implements that interface. Then we >> can encourage non-API changes to the abstract base class; API (possibly >> but not guaranteed to be breaking) changes to the interface, and >> so forth. > >What's an example of a non-breaking change to the API that's defined by >an interface? Guess it depends on what you and I consider breaking. I’ll illustrate. Ex1: To me, this is “non breaking”, since C doesn’t have to do anything with the API change. public interface A{ public long X(); public String Y(); } public abstract class B implements A{ public long X(){ return 0L; } } public class C extends B{ public String Y(){ return “Y”; } } //UPDATE A and B public interface A{ public long X(); public String Y(); public int Z(); } public abstract class B implements A{ public long X(){ return 0L; } public int Z(){return 1;} } // C remains same. > >> So, TL;DR I would prefer interface + abstract base class, but maybe >> that’s just me. > >I'm curious why you prefer an interface (with the breakage issue) Again, depends on what you consider breaking. Based on my example above, I don’t consider that breaking (even if you had a class F that directly implemented A, you could always sub-interface M, and put “changes” there, and then suggest that classes that want to take advantage of the new interface methods explicitly use M instead of A. > plus the need for an abstract base class over just a base class. I guess just flexibility, indirection, and abstraction for me. > >What I see is people using interfaces when they're pretty certain that >(a) implementations will need to support multiple APIs, and (b) the >interface won't change. > >Neither seems the be the case for most of the APIs in Tika. Meh, to each their own, frankly. I am fine with either way to be honest, but my preference is what I suggested above. Just my pref, though. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++