Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: <54A98CC9.3060203@gmail.com>
References: <20150104170753.6342EAC003F@hades.apache.org>
	<54A97A55.6020705@gmail.com>
	<CAB917R+w90CX=7_qn=rNbdg=u1AS_wenu1iOtoWPeWKU_68b6g@mail.gmail.com>
	<54A98CC9.3060203@gmail.com>
Date: Sun, 4 Jan 2015 20:27:33 +0100
Message-ID: 
 <CAB917R+fbKBOqndW4C4v2aEEGKHJG8aQ63ubKO0pWeGm3eJ9Nw@mail.gmail.com>
Subject: Re: svn commit: r1649362 -
 /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/
From: Benedikt Ritter <britter@apache.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=047d7b5d348cc3fc47050bd890ca

--047d7b5d348cc3fc47050bd890ca
Content-Type: text/plain; charset=UTF-8

2015-01-04 19:56 GMT+01:00 Thomas Neidhart <thomas.neidhart@gmail.com>:

> On 01/04/2015 07:48 PM, Benedikt Ritter wrote:
> > Hello Thomas,
> >
> > 2015-01-04 18:37 GMT+01:00 Thomas Neidhart <thomas.neidhart@gmail.com>:
> >
> >> On 01/04/2015 06:07 PM, britter@apache.org wrote:
> >>> Author: britter
> >>> Date: Sun Jan  4 17:07:51 2015
> >>> New Revision: 1649362
> >>>
> >>> URL: http://svn.apache.org/r1649362
> >>> Log:
> >>> ScanlineFilter really is an interface
> >>
> >> there is usually a good reason to use an abstract class instead of an
> >> interface in case the type is public.
> >>
> >
> > Yes, if the abstract class has some logic, which subclasses can leverage.
> > This was not the case here.
> >
> >
> >>
> >> This makes it possible to extend the interface even in minor interfaces.
> >>
> >
> > I don't understand what you mean. Can you give an example?
>
> If you define a public interface that classes implement, you can not
> change the interface during minor releases as this would potentially
> break client code.
>
> Thus there are cases where it is better to use an abstract base class
> instead of an interface, especially if it is highly unlikely that
> implementing classes will extend or implement other types.
>
> In math we have several examples of this pattern, as it is much easier
> to add new features considering the release policy in commons.
>
> The pattern is more or less obsolete with java 8, as there you have the
> possibility of default methods in interfaces, but as long as the minimum
> required version is < java 8 you have to keep this in mind.
>
> >>
> >> Maybe this is not necessary in this case, but should be kept in mind
> >> when doing such changes.
> >>
> >
> > As long as an abstract class does not define logic, it doesn't make any
> > sense to define it as a class, rather than as an interface. Using
> > interfaces has an important advantage: you can only extend one class, but
> > can implement more than one interface. So we should really only define
> > abstract classes, if they have logic that justifies their existence.
>
> well it depends on your use-case imho. From a clean object-oriented POV,
> you are totally right, but you also have to consider the maintainability
> aspect.
>

I understand your point now. I've never thought about it this way and your
right from an "evolving API" POV. Since we're currently designing the 1.0
API, I'd like to leave it this way for now. Or would you rather like to see
this commit reverted?

Benedikt


>
> > Benedikt
> >
> > P.S.: Nice to know, that someone is reviewing my commits in [imaging] :-)
>
> Usually I am quiet but I read a lot ;-).
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

--047d7b5d348cc3fc47050bd890ca--