JDBC Design Patterns
Hi All,
I am new to patterns and have started understanding them using the Head First Series.
I would like to know what all design patterns are there in JDBC?
Can i say that JDBC uses a Facade design patterns as it hides the database specific details and provides us a interface which helps us to connect to a database. What other design patterns exist as part of the JDBC?
Request you to clarify my doubts.
Many thanks in advance
[467 byte] By [
minkeya] at [2007-11-26 13:58:55]
# 1
> Hi All,
> I am new to patterns and have started understanding
> them using the Head First Series.
>
> I would like to know what all design patterns are there in JDBC?
ResultSet is a cursor/Iterator. Might be a Proxy, too.
> Can i say that JDBC uses a Facade design patterns as
> it hides the database specific details and provides
> us a interface which helps us to connect to a
> database. What other design patterns exist as part of
> the JDBC?
Sure, sounds good.
>
> Request you to clarify my doubts.
>
> Many thanks in advance
What does having this information do for you?
%
# 2
> > What does having this information do for you?I would guess a good grade on the homework assignment.I am pretty sure I have seen the same question before.
# 3
Sounds like a question that a IT recruiter would want to ask a potential candidate.
# 4
Thanks to everyone for their responses so far.
However, let me clarify few things that this post is certainly not a part of any college assignment.
Moreover i am neither appearing for any job interviews nor doing any recruitments.
I would admit that my OO and patterns concepts are not too much to write about but i am
learning and want to apply my understanding of the patterns to the real technologies we work with.
My main intention to start this thread is to understand how experts tend to view any technology like JDBC
in terms of patterns. How can i view and understand these in terms of patterns and OO design.
I would really appreciate a good discussion on it rather than any spoon feeding.
A typical JDBC code will appear as follows:
try
{
/* Load the jdbc-odbc driver
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
// Open a connection to data source
con =DriverManager.getConnection("jdbc:odbc:DBName","","");
// Get a statement from the connection
Statement stmt = conn.createStatement() ;
// Execute the query
ResultSet rs = stmt.executeQuery( "select * from table_name" ) ;
}
1. Is it ok to look into each statement of the above code snippet in terms of Design Patterns.
2. How can one dissect each line of the code in terms of various design patterns?
3. Is it correct to conclude that java.sql package overall uses Abstract Factory Pattern.
As it uses lot of interfaces and implemetation is provided by the Vendors.
4. Consider a particular package like java.sql.Statement,java.sql.Blob,java.sql.Connection etc. is is correct to conclude that
its an example of a Factory Method Pattern as any client would instantiate. Here the client would be Statement object,
Creator is Connection Interface and createStatement() is the factory method.
5. I am not able to understand if a statement like Class.forName() should be viewed only in terms of a programming instruction or
any design pattern
6. Can "stmt.executeQuery()" can be viewed as A Strategy Pattern?
I would really welcome a good discussion on the above questions.
Thanks in Advance
# 5
Not everything is a pattern.
# 6
> I would really appreciate a good discussion on it
> rather than any spoon feeding.
> A typical JDBC code will appear as follows:
>
> try
>{
> /* Load the jdbc-odbc driver
>Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
>
>// Open a connection to data source
> con
> =DriverManager.getConnection("jdbc:odbc:DBName","","")
> ;
>
>// Get a statement from the connection
> Statement stmt = conn.createStatement() ;
>
>// Execute the query
> ResultSet rs = stmt.executeQuery( "select * from
> table_name" ) ;
>
>
> }
>
> 1. Is it ok to look into each statement of the above
> code snippet in terms of Design Patterns.
it's ok, yes. not necessarily appropriate or worthwhile, though
> 2. How can one dissect each line of the code in terms
> of various design patterns?
you can't. design patterns exist at a higher level of abstraction than code. 'in terms of' is also disconcertingly vague.
> 3. Is it correct to conclude that java.sql package
> overall uses Abstract Factory Pattern.
> As it uses lot of interfaces and implemetation is
> provided by the Vendors.
yep. that sounds fair enough. not very useful, though
> 4. Consider a particular package like
> java.sql.Statement,java.sql.Blob,java.sql.Connection
> etc. is is correct to conclude that
> its an example of a Factory Method Pattern as any
> client would instantiate. Here the client would be
> Statement object,
> Creator is Connection Interface and createStatement()
> is the factory method.
possibly. there's little value in trying to define everything as a "design pattern", though. rather than thinking "oh, they must be using PATTERN X here", think "if I were writing this code, I think PATTERN X would be appropriate". or, more usefully, "is there a pattern that solves this problem?". there isn't, necessarily
> 5. I am not able to understand if a statement like
> Class.forName() should be viewed only in terms of a
> programming instruction or
> any design pattern
it's a line of code, nothing more. stop trying to make everything into a pattern. until you realise where patterns are and aren't applicable, you'll never understand them
> 6. Can "stmt.executeQuery()" can be viewed as A
> Strategy Pattern?
nope. what makes you think that?
> I would really welcome a good discussion on the above
> questions.
does the discussion have to involve design patterns? you know, of course, that design patterns aren't magic beans, right? I know you've just discovered patterns, and are all excited by them, but seriously, they're only ideas, not Infallible Solutions To All Software Problems ™. the most common mistake people make using design patterns is to see them everywhere, and try to bend every problem to fit a particular pattern
for the record, nobody really views JDBC in terms of patterns. there's little value in viewing existing technologies in those terms, since the most you can "gain" is to have guessed what some other developer did, before.
# 7
georgemc,Thanks a lot for tips and guidance
# 8
> How can i view and understand
> these in terms of patterns and OO design.
You probably should have a look at an implementation of a JDBC driver, too.
> A typical JDBC code will appear as follows:
>
> try
>{
> /* Load the jdbc-odbc driver
>Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
This may be a Design Pattern, but not a classical GOF one. The code called here dynamically loads code at runtime. There are other languages that do similar things, like classic DLLs, so there is a chance to find a pattern. But you would have to look at the underlying implementation.
>
>// Open a connection to data source
> con
> =DriverManager.getConnection("jdbc:odbc:DBName","","")
> ;
This is a factory method and it may be backed by an Abstract Factory. You would need to look at the implementation to find it out.
>
>// Get a statement from the connection
> Statement stmt = conn.createStatement() ;
Abstract Factory.
>// Execute the query
> ResultSet rs = stmt.executeQuery( "select * from
> table_name" ) ;
Without knowledge of the implementation, one could only guess which patterns are involved here.
Typical JDBC drivers send the query string via network to a database, so it may use Proxy.
You could (if you really want) implement a JDBC driver that includes and works on an in-memory database, so there probably will be an Interpreter for the query string.
> 1. Is it ok to look into each statement of the above
> code snippet in terms of Design Patterns.
Would be better to look at the implementation, too.
> 3. Is it correct to conclude that java.sql package
> overall uses Abstract Factory Pattern.
Probably, but not necessarily.
> As it uses lot of interfaces and implemetation is
> provided by the Vendors.
That's not the point. It needs to include an interface that contains a factory method.
Statement stmt = conn.createStatement() ;
is an example.
>
> 6. Can "stmt.executeQuery()" can be viewed as A
> Strategy Pattern?
I see no context here. And with context i mean the Context of the Strategy pattern. It may be internally implemented as a Strategy, but not really worth talking about if we don't know the implementation.
So far it is only a method of an interface that is implemented by different drivers.
