*bringing this to a wider audience* Hi All,
today I've committed some changes, that should probably have been discussed before. There were a few abstract classes in [imaging], which had no logic at all. They just defined abstract methods. I've changed this and replaced these abstract classes with interfaces. Following my commits, Thomas has pointed out, that abstract classes without logic may in some cases make sense from an "evolving API" POV. My point here is, that a class can only extend one class, but can implement several interfaces. Since we're working on the 1.0 API, I would like to give others the opportunity to chime in on this. The respective commits are: http://svn.apache.org/r1649358 http://svn.apache.org/r1649360 http://svn.apache.org/r1649364 http://svn.apache.org/r1649366 http://svn.apache.org/r1649367 http://svn.apache.org/r1649362 Please let me know if you feel like any (or all) of this commits should better be reverted. Thanks! Benedikt 2015-01-04 20:54 GMT+01:00 Thomas Neidhart <thomas.neidh...@gmail.com>: > 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 > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
