Use of interface vs. abstract class

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Use of interface vs. abstract class

kkrugler
Hi all,

In general I see open source projects using abstract classes for extension points, as that provides for a migration path in the event of an API change, versus breaking any code that has implemented the interface.

I see some interfaces being used in Tika, e.g. Translator.

Does the ServiceLoader require that these be interfaces? I assume not, as isAssignableFrom() should work with either interfaces or abstract classes, right?

Asking because I'm looking at the language detector API for 2.x.

Thanks,

-- Ken



--------------------------
Ken Krugler
+1 530-210-6378
http://www.scaleunlimited.com
custom big data solutions & training
Hadoop, Cascading, Cassandra & Solr





Reply | Threaded
Open this post in threaded view
|

Re: Use of interface vs. abstract class

Mattmann, Chris A (3010)
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.

So, TL;DR I would prefer interface + abstract base class, but maybe
that’s just me.

Cheers,
Chris

CC/Trevor - FYI Trevor, please talk to Ken since he is working on
what I had assigned you to do as well - aka the LanguageIdentifier
refactor/interface.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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: [hidden email]
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++





-----Original Message-----
From: Ken Krugler <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Tuesday, February 9, 2016 at 8:34 AM
To: "[hidden email]" <[hidden email]>
Subject: Use of interface vs. abstract class

>Hi all,
>
>In general I see open source projects using abstract classes for
>extension points, as that provides for a migration path in the event of
>an API change, versus breaking any code that has implemented the
>interface.
>
>I see some interfaces being used in Tika, e.g. Translator.
>
>Does the ServiceLoader require that these be interfaces? I assume not, as
>isAssignableFrom() should work with either interfaces or abstract
>classes, right?
>
>Asking because I'm looking at the language detector API for 2.x.
>
>Thanks,
>
>-- Ken
>
>
>
>--------------------------
>Ken Krugler
>+1 530-210-6378
>http://www.scaleunlimited.com
>custom big data solutions & training
>Hadoop, Cascading, Cassandra & Solr
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Use of interface vs. abstract class

Bob Paulin-2
Also default methods in Java 8 might be what we're looking for in the cases
where we want this for backward compatibility:

https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html

- Bob

On Tue, Feb 9, 2016 at 10:40 AM, Mattmann, Chris A (3980) <
[hidden email]> wrote:

> 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.
>
> So, TL;DR I would prefer interface + abstract base class, but maybe
> that’s just me.
>
> Cheers,
> Chris
>
> CC/Trevor - FYI Trevor, please talk to Ken since he is working on
> what I had assigned you to do as well - aka the LanguageIdentifier
> refactor/interface.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 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: [hidden email]
> WWW:  http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
>
> -----Original Message-----
> From: Ken Krugler <[hidden email]>
> Reply-To: "[hidden email]" <[hidden email]>
> Date: Tuesday, February 9, 2016 at 8:34 AM
> To: "[hidden email]" <[hidden email]>
> Subject: Use of interface vs. abstract class
>
> >Hi all,
> >
> >In general I see open source projects using abstract classes for
> >extension points, as that provides for a migration path in the event of
> >an API change, versus breaking any code that has implemented the
> >interface.
> >
> >I see some interfaces being used in Tika, e.g. Translator.
> >
> >Does the ServiceLoader require that these be interfaces? I assume not, as
> >isAssignableFrom() should work with either interfaces or abstract
> >classes, right?
> >
> >Asking because I'm looking at the language detector API for 2.x.
> >
> >Thanks,
> >
> >-- Ken
> >
> >
> >
> >--------------------------
> >Ken Krugler
> >+1 530-210-6378
> >http://www.scaleunlimited.com
> >custom big data solutions & training
> >Hadoop, Cascading, Cassandra & Solr
> >
> >
> >
> >
> >
>
>
Reply | Threaded
Open this post in threaded view
|

RE: Use of interface vs. abstract class

kkrugler
In reply to this post by Mattmann, Chris A (3010)
Hi Chris,

> From: Mattmann, Chris A (3980)
> Sent: February 9, 2016 8:40:06am PST
> To: [hidden email]
> 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?

> 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) plus the need for an abstract base class over just a base class.

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.

Thanks,

-- Ken

> CC/Trevor - FYI Trevor, please talk to Ken since he is working on
> what I had assigned you to do as well - aka the LanguageIdentifier
> refactor/interface.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 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: [hidden email]
> WWW:  http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
>
> -----Original Message-----
> From: Ken Krugler <[hidden email]>
> Reply-To: "[hidden email]" <[hidden email]>
> Date: Tuesday, February 9, 2016 at 8:34 AM
> To: "[hidden email]" <[hidden email]>
> Subject: Use of interface vs. abstract class
>
>> Hi all,
>>
>> In general I see open source projects using abstract classes for
>> extension points, as that provides for a migration path in the event of
>> an API change, versus breaking any code that has implemented the
>> interface.
>>
>> I see some interfaces being used in Tika, e.g. Translator.
>>
>> Does the ServiceLoader require that these be interfaces? I assume not, as
>> isAssignableFrom() should work with either interfaces or abstract
>> classes, right?
>>
>> Asking because I'm looking at the language detector API for 2.x.
>>
>> Thanks,
>>
>> -- Ken
>>
>>
>>
>> --------------------------
>> Ken Krugler
>> +1 530-210-6378
>> http://www.scaleunlimited.com
>> custom big data solutions & training
>> Hadoop, Cascading, Cassandra & Solr
>>
>>
>>
>>
>>
>

--------------------------
Ken Krugler
+1 530-210-6378
http://www.scaleunlimited.com
custom big data solutions & training
Hadoop, Cascading, Cassandra & Solr







--------------------------
Ken Krugler
+1 530-210-6378
http://www.scaleunlimited.com
custom big data solutions & training
Hadoop, Cascading, Cassandra & Solr





Reply | Threaded
Open this post in threaded view
|

Re: Use of interface vs. abstract class

Mattmann, Chris A (3010)
Hi Ken,

-----Original Message-----

From: Ken Krugler <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Tuesday, February 9, 2016 at 8:54 AM
To: "[hidden email]" <[hidden email]>
Subject: RE: Use of interface vs. abstract class

>Hi Chris,
>
>> From: Mattmann, Chris A (3980)
>> Sent: February 9, 2016 8:40:06am PST
>> To: [hidden email]
>> 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: [hidden email]
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++