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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



Reply via email to