XP would
say cross that bridge when you come to it -- build what you require now, not for
the future. The problem with anticipating the future requirements is that
you cannot predict what the requirement will be. OK so you might be forced to
make your Oracle-specific database application work on SQL Server. But maybe
that won't happen and you'll be forced to make a version for a hand-held PDA
that can only talk to the (Oracle) database every 20 minutes via a satellite
uplink. I mean, who knows what sales & marketing will promise the next
customer around the corner. That's what they do; make unrealisitic promises to
customers. It's our job to deliver the realistic part of whatever
that promise was/is.
My
current project which I inheritied has taught me a lot about these things. I
used to think I knew all about such things, but until I saw it in real
operation, I had no idea. This project is one big ANTI-PATTERN after another.
Even 9 months later I'm still finding out brand new gems of ugly anti-pattern as
I finally get to re-engineer the damn thing into a proper
architecture.
And one
of things I found was the single-implementing-class interface, whcih
appears to have been built for some future requirement that has never come. It
just makes things more complex where they do not require. Meanwhile spaghetti
code and point-solutions abound in areas where is a clear need to decent OO
design and abstraction.
Good
design can always be refactored to implement an interface if necessary later
on.
regs
scot.
____________________________________________________-----Original Message-----
From: James Stauffer [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 4 December 2002 06:05
To: JDJList
Subject: [jdjlist] Re: interface for only 1 classHow do you balance that will all of the times that an interface isn't necessary? Another aspect is that an interface usually makes it more complex. If there is no foreseeable need for an interface when should you use an interface and when shouldn't you?James Stauffer
-----Original Message-----
From: Greg Nudelman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 03, 2002 12:28 PM
To: JDJList
Subject: [jdjlist] Re: interface for only 1 classIt depends. Let's say you only expect to use Oracle DB in the foreseeble future. So you write your driver loading, and persistance all over the place, and create it only for the Oracle. But in 12 months, your business folks decide to try and sell the system to some customer, who just got to have SQL Server. If you wrote persistence as an interface, it is a snap, otherwise, some work and re-testing af the whole thing may be involved.Sounds funny, but this is a real-life example.Greg____________________________________________________-----Original Message-----
From: James Stauffer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 03, 2002 7:54 AM
To: JDJList
Subject: [jdjlist] interface for only 1 classIs it good to have an interface if there will only be one class to implement it in the foreseeable future? Does it add unnecessary complexity? It usually isn't much more complex but does that extra complexity add extra value? Agile programming seems to say "don't build it because you won't need it." What do you think?
James Stauffer
____________________________________________________
To change your JDJList options, please visit:
http://www.sys-con.com/java/list.cfm
Be respectful! Clean up your posts before replying
____________________________________________________
To change your JDJList options, please visit:
http://www.sys-con.com/java/list.cfm
Be respectful! Clean up your posts before replying
____________________________________________________ ____________________________________________________
To change your JDJList options, please visit:
http://www.sys-con.com/java/list.cfm
Be respectful! Clean up your posts before replying
____________________________________________________
To change your JDJList options, please visit:
http://www.sys-con.com/java/list.cfm
Be respectful! Clean up your posts before replying
____________________________________________________
