This page contains an archived post to the Java Answers Forum made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Posted by Jay on January 23, 2002 at 5:14 PM
A few things.
- My proposal is not a factory.
- Chin's snippet is a perfect implementation of Abstract Factory
- Since my proposal is not a factory, it does not have to behave like a factory. And besides, the
system wont mind if we borrowed a few ideas?!
Now lets see, we made a perfect factory. But what did we actually do? We brought database design into
Java code! I mean, I dont want to know any database entities. Why should I have a class that represents
a table? I'll tell why not:
- When migrating to a different database, the factory assumes that the database design is not changed.
In fact, most of the time, clients already have a database for a long time, with their own design that
they fear changing their design to suit your application because there are a million other applications
already running with that database. But you have a 30MB of factory assuming your own design. What do you
do? Well, call the programmers, sit down, rewrite!
Or worse yet, the application is glued to the factory! You change the factory, the whole application is
But please bear in mind that this is in case of generic product using specific database.
Whereas in the other case, there is a definite signature (interface) what your application needs, just
implement it, and the application runs. I ask-you answer scenario. No more no less.
- You do not know where the data comes from. It could be a file, database(I mean like Oracle), a
socket stream. A streamed source already has a protocol, which it acknowledges, like XML. In that case
you are not even expected to implement a factory.
P.S Good job Chin & Matt.