<SNIP> On Thu, 31 Mar 2005 05:55:27 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: >.... > So long as people follow our advice, and extend the base class, they > will be protected from changes to the API. If someone chooses to > implement the interface from scratch, then they will have some more > work to do. If they've setup a base class of their own, then there > shouldn't be so much to do. (At least not more than we would put into > our own base class.) </SNIP>
The idea of interfaces is not to appeal to the least common denominator and to do it all for people, but to allow people to create quality code. If the "bent" of the committers is to protect only those who extend the base class, then the whole point of using interfaces really is suspect isn't it? Do not think this is a critique of using interfaces. I am 100% for that. I think that good coding ideas should go into examples and not into the interface. <SNIP> > As to the number of members, I'm a DRY guy myself. If I see the same > 3++ lines appearing in more then one place, then into a convenience > method they go. (Heck, one line if its convoluted!) </SNIP> A great coding practice for clear and incisive implementations, but a bad idea in interfaces. This is the sort of implementation detail that really should not be in interfaces. <SNIP> > For something, like ActionContext, I'd suggest we start with any > convenience method know found in the Action class, and add whatever > other methods we can point to in the example applications or derive > from *actual* use cases in our own work. So long as an argument is not > hypothetical, but based on actual practice, then it's not an argument > :) </SNIP> Actual practice can be called "actual implementation" and is not appropriate for an interfaced based architecture. This is just a sideways return to the old and defective Struts, isn't it? <SNIP> > Adding more members might even encourage good practice. People will > tend to use the base class so they don't have to implement everything > themselves. If there were very few members, more people might start > rolling their own. </SNIP> What is the point of having interfaces if you are just going to clutter them so that people won't use them? This is, to my mind, a very strange suggestion. I have a lot of respect for your idea, Ted, but this treatment of interfaces seems to be anti-pattern-code to me. <SNIP> > We might want to take care to document which methods are used by the > framework and which methods are "optional." Nothing unusual in that. > Many of the larger Sun interfaces have "optional" methods, which, "if > implemented", should do this or that. We could just follow suit. If a > method is referenced by the stock framework, it's required, if not, > it's "optional". If someone doesn't use it in their applications, then > they don't have to implement it. </SNIP> I cannot think of "[m]any" or even "any" larger Sun interfaces that include utility methods. Which ones do you have in mind? I certainly would make sure that the required methods are not just the utility methods to a particular implementation and are really required by the logic of the interface. <SNIP> > If we identify one form the other, then we've done our job. And, if > you are using something like IDEA, it's not much of a challenge. IDEA > will gladly find the usages of a method throughout a given codebase :) </SNIP> Hopefully, Struts, other than the bastard-child Shale, will not become tool-bound. I know you are not suggesting this, Ted. But, I cannot see what the point in terms of good architecture is here. Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
