ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Did somebody say Shut up and Write? :)
Date Fri, 29 Dec 2000 12:31:32 GMT
At 08:53  21/12/00 -0800, Craig R. McClanahan wrote:
>Interestingly, that has been my own experience as well.
>If ActionForm is a subclassable base class (as it is now), however, the only
>people that get screwed by additions are those who happened to have
>the same method signatures that you are trying to add.  You still need to
>this into account, but at least the population of affected users is likely
to be
>much smaller than the "everybody" crowd affected by changes to fundamental

Yes it is well documented that use of interfaces in this manner is very
very bad. This is why components are generally abstracted via

Foo (interface) + AbstractFoo (abstract class) + DefaultFoo (concrete class)

(AbstractFoo is often ommitted if Foo is simple and has small easily
understandable contract). This way you satisfy both crowds. For 99% of
users will extend Abstract (or Default) implementations and just rewrite
parts they need to rewrite ;) However for those futzes who want to
reimplement everything then they can do it that way aswell.

Ironically the main reason most design people encourage the use of
interfaces is NOT to allow for easy extention etc but because it encourages
good seperation of concerns and design. This only is true if the "work"
interface is noticably smaller than the "implementation" interface. ie if
all methods are public and overidable then work==implementation and thus
there is no need for an interface abstraction. However if some
"implementation" interfaces are potentially wider than "work" interface
then it becomes a balance act that is mostly in favour of making separate
java interfaces.

(BTW by "implementation" interface I mean all non-private, final or
non-public methods - presumably there is also no member variables
accessbile either).

If you want to know more there is an interesting paper by the a very smart
guy on it. He is very widely known for algorithms (especially concurrency
algos) in java. He has also written a book about java concurrency I believe
.... thou I forget his name atm - I can find it if anyone wants ;)

>For everyone else (and this tends to be a very large majority), the change is
>transparent, as long as the default behavior of the new functionality remains
>same as what you had before.

Use of AbstractFoo/DefaultFoo will make this problem go away except for
rare freaks ... but they gonna break it anyways usually ;)

>As a result, I've grown to prefer base classes that can be subclassed, rather
>interfaces, to expose the functionality key components.  I still like
>to define optional behaviors that might be implemented by a large variety of
>object types, but tend not to like them as much for the key architectural

It can be acceptable if you have complete control over code base and can
maintain quality control easily. Programmers are much less likely to
produce highly coupled code if they have to cast from interface to
implementations to use extra functionality and as long as interfaces are
defined at appropriate level they can generally be extended appropriately.



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message