On 01/04/2015 08:27 PM, Benedikt Ritter wrote: > 2015-01-04 19:56 GMT+01:00 Thomas Neidhart <thomas.neidh...@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.neidh...@gmail.com>: >>> >>>> On 01/04/2015 06:07 PM, brit...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
