Java Reference
In-Depth Information
service method into two pieces to allow us to separate initialization and valida-
tion from the main line processing. This is a Split Cleaner, but because the
intent of the command architecture is clear and the execute and init methods
can be in close proximity, the design is relatively safe. Nevertheless, we should
continue our refactoring to ensure that our connections are cleaned in the
event of an exception. We do this by moving the cleanup to a finally block:
public void execute ()
DataException {
} catch (Throwable theException) {
} finally {
In truth, we could be even more defensive. If result.close() or state-
ment.close() throw runtime exceptions, connection.close() doesn't get
called. Also, if there's a failure before the result set is built, result will be null.
You should test for a null result before closure.
Antipattern: Hardwired Connections
The previous examples dealt with tightly coupled connections that are likely to
be found entirely within our own walls. When we're sharing a business-to-
business connection, we should pay careful attention to the coupling between
systems. Different types of interfaces should have couplings of different
strengths. Object-oriented languages let us keep the coupling between objects
fairly loose. Direct access through an object's interface may be sufficient for
many purposes. For the boundary between the model and view, we should
loosen the coupling. In chapters 3 and 4, we did so through a command layer.
The layer between client and server should employ still looser coupling, which
we accomplish through the servlet API over HTTP over TCP/IP .
When you're dealing with two disparate systems that cut across organiza-
tional boundaries, you need to be especially careful when designing the inter-
faces. Experience has shown that loosely coupled systems are easier to maintain,
and many decisions that you make can affect the strength of the coupling
Search WWH ::

Custom Search