Two of the biggest
benefits of OO design are maintainability (code that is easy to update) and
reusbaility (components that are easy to reuse). Many OO design choices help
both, but in most companies, one is more important than the other. If you're a
job shop churning out 5 new projects a month, reusability is more important than
if you are a product company that will only ever build and maintain one web
application.
For instance, loose
coupling and a small number of dependencies are important for
maintainability but even more so for reusability (who wants to have to drag 20
objects across just to reuse an AddressService or AuthenticationService?!). So,
what happens when maintainability and reusability collide?
For instance, I'm
considering pulling all of my SQL into a base class or seperately called object.
However I implement this it will decrease reusability as I'm adding a relatively
tightly coupled object dependency to all of my services. On the flip side, if I
want to wrap transactions around queries, add metadata to all queries
(lastupdateddate, etc.) or make any other universal change, I only have to
change one set of queries which is then wrapped by all of the entity specific
methods which simply pass the necessary parameters to the underlying
method.
And so to the
questions:
- Is anyone else
thinking about distinguishing between patterns that primarily improve
maintainability vs. reusability (I know that most of the time they improve
both)
- Any good
for/against arguments to having just a SINGLE DAO rather than one per entity,
with the service methods just parameterizing and calling the single DAO
(assuming sufficient flexibility can be programmed into the system in a
performant manner).
Any thoughts much
appreciated!
Best
Wishes,
Peter
Peter
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
