commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject Re: svn commit: r1649362 - /commons/proper/imaging/trunk/src/main/java/org/apache/commons/imaging/formats/png/scanlinefilters/
Date Sun, 04 Jan 2015 19:54:51 GMT
On 01/04/2015 08:27 PM, Benedikt Ritter wrote:
> 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?

I think changes like these should at least be discussed on the ml so
that developers who worked on it for a longer time can comment. The 1.0
release is actually quite critical, as it will most likely remain the
stable branch for quite some time.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message