Re: Enum, switch, and a null
Daniel Pitts wrote :
On Sep 10, 4:42 pm, Wojtek <nowh...@a.com> wrote:
Lew wrote :
Wojtek wrote:
switch (Database.getDBType())
{
case MS_SQL:
sql = new SQL_Microsoft( setAutoCommit );
break;
}
return sql;
Another approach is to instantiate a Map <DBType, SQL> to retrieve the
desired SQL (or a Class<? extends SQL>), instantiated from a descriptor or
other resource.
SQL sql = dbMap.get( Database.getDBType() );
So then the get would return an already instantiated class? What about
threading? Would not all threads then get the same instance?
This is part of a Web app. Lots of threads...
Or is dbMap created for each use. That means I would be creating an
extra object (the map), plus an extra object for each DB engine, but
only using one of the engines for the life of the app.
--
Wojtek :-)
Hey, use Hibernate, that'll solve all your problems! :-)
If you change your DBType enum to be an interface or class with the a
method:
abstract SQL getSQLInstance(TransactionCommit setAutoCommit);
class MS_SQL_DBType implements DBType {
public SQL getSQLInstance(TransactionCommit setAutoCommit)
return new SQL_Microsoft( setAutoCommit );
}
}
class MySQL_DBType implements DBType {
public SQL getSQLInstance(TransactionCommit setAutoCommit)
return new SQL_MySSQL( setAutoCommit );
}
}
etc... and so forth.
Add a method to your DBType interface for every switch statement you
currently have.
Does that approach make sense now?
Each use case has a SQL/SQL_Microsoft pair. So for updating a simple
helper table such as StreetType (Street, Avenue, etc) I have the
methods getRow(), saveRow(), and newRow().
This has default visibility (package level) and is only used within
that package.
SQL and SQL_Microsoft are specific to the package they are in. There is
NOT a huge monolithic class with 100's of methods to handle each
possible use case. Each SQL_XX only has the methods required for its
own use case. The login example is the entirety of those classes. No
other methods.
I am not convinced. Each example given seems to assume that there is
one and only one SQL_Microsoft class in the entire system. There is
not. A partial package tree would look like:
app.uc.streetType
Servlet
Command
SQL
SQL_Microsoft
app.uc.stateProvince
Servlet
Command
SQL
SQL_Microsoft
app.uc.person.login
Servlet
Command
SQL
SQL_Microsoft
app.uc.person.edit
Servlet
Command
SQL
SQL_Microsoft
and so on. If in the future, the PHB's decide we need other engines
supported, then it might look like:
app.uc.streetType
Servlet
Command
SQL
SQL_Microsoft
SQL_MySQL
SQL_Oracle
SQL_Paradox
--
Wojtek :-)