Java Reference
In-Depth Information
CHAPTER 3
Exploring Presentation Tier
Design Patterns
S
ometime back I joined a team that was developing a product named eInsure for the
insurance industry. The goal was to develop a comprehensive online e-business solution
encompassing all the major insurance processes such as underwriting, claims manage-
ment, accounting, customer relationship, re-insurance, and so on. By the time I joined,
this application already had a few major releases and was being used in production by
two clients. But the development team found it highly cumbersome and effort-intensive
to handle any new requirement, enhancement, or change request. This would always
lead to unnecessarily long develop-test-fix-release-maintain (DTFRM) cycles. So, I
started to investigate and soon made some critical observations about the application.
The main reason for the problem was the source code. The application was huge
with nearly 350 JSPs, 30-odd session beans, 600+ POJO helpers, 300+ tables, and an equal
number of entity beans. The bulk of the existing source code was generated by a tool that
helped convert the legacy product written in Oracle PL/SQL to Java EE. The generated
source was based on the enterprise Java component model, but deep down it had funda-
mental design flaws and bad smells. Code smells generally indicate that something has
gone wrong somewhere in your application code. The term was popularized by Kent
Beck and Martin Fowler in the topic
Refactoring: Improving the Design of Existing Code
(Addison-Wesley, 1999). The data structures used in eInsure mimicked the PL/SQL tables
and arrays. As a result, the developers had to first grasp the behavior of legacy code and
data structures. As the new code was being added in the same legacy style, there was no
scope of any improvement.
The lack of design and OO skills in the eInsure team (most of the team members
themselves were making a transition to acquire Java EE technology skills along with the
product) added to the woes. There was absolutely no design directive or code documen-
tation. A good software application should have different configuration parameters to
control its runtime behavior without having to modify any code. These configuration
parameters are generally stored in XML or properties file external to the application.
41
