Re: [OT] Request for comments on DAO pattern implementation

[Michael McGrady]

Not sure why, but I have never had the difficulty of maintenance being 
held up because of appropriate uses of interfaces.  I have had the 
opposite happen lots of times.  I am a stickler for the interface 
approach to most classes.  I am even thinking of foregoing entirely the 
use of the System classloader for "service" as opposed to "client" 
classes.  Without using interfaces, of course, that would make no 
sense.  I get a kick out of how you express this, Rick, and I think I 
know the nonsense you have seen.  It is sometimes almost comical.  
However, if used appropriately, an interface could never create a 
maintenance problem.  If a class can have differing implementations, 
then an interface is just a good idea, isn't it.  And, if the 
implementations can use other treatments of that interface, then base 
abstract classes, adapters, etc. seem to me to be just good plain sense 
and not over-architected. 

Where I think most "over-architecture" happens is when someone has a way 
too cool idea about how to implement a simple algorithm or to solve a 
simple problem.   One of the coolest little uses of interface/abstract 
class/etc. designs is in the commons upload facility, I think.  Sean 
Sullivan really outdid himself on that one.

Michael McGrady
Rick Reumann wrote:
Adam Hardy wrote the following on 10/9/2004 7:34 AM:
However I have never come across a situation where anybody has 
changed the implementation when doing an upgrade to their 
application. It sounds good, but IMHO, never happens. Would be 
interested to find out otherwise :)

All of my classes implement an AlwaysHaveJustBecauseIheardItsGood 
interface which extends BaseJustBecause Interface and each class 
extends from MomsKitchenSink witch extends from 
VeryAbstractAbstractnessCrazyness and of course I throw in an 
annoymous inner ConfuseTheNextDeveloperMore class.

Actually, coding to interfaces and extending classes is good and 
helpful, but I agree with Adam. It's actually sort of ironic... since 
one of the main reasons you often see applications "over designed" is 
so that they 'supposedly could easily adapt to future requirement 
changes, yet the irony is that future maintenance often becomes the 
major bottleneck which is often complicated by some wacky 
over-architected design scheme.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]