On 12/21/00 8:53 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> When the Struts Framework project <http://jakarta.apache.org/struts> first > started, we began with the "pure O-O" approach of interfaces for all of the > core abstractions. But, as we are approaching a 1.0 release (where you had > better get really serious about backwards compatibility -- I guess for Ant > that will happen at the 2.0 level :-) -- it became apparent how risky this > strategy is. Yep. One more round of tweaking with things and breaking things. Then compatibility gets laid in from there one out. > But then, it became obvious: if we left ActionForm as an interface, consider > what happens if in Struts 1.1 we want to add some new method signatures to > ActionForm for additional functionality. Yes, we can add new default methods > to the convenience base class, but the whole idea of an interface is that > we're granting *permission* to implement it completely your own way. Right. And if you are putting everything into an abstract base class that 99.9% of people are extending from -- that begs the question of "why the interface?". Interfaces are great for things that you really understand. Josh's collections are an example of that. However, if there's a damn good chance that you don't understand the whole problem domain, then you have to evaluate carefully. .duncan -- James Duncan Davidson [EMAIL PROTECTED] !try; do()
