voices in my head were screaming, “Memento!” Although I had never needed to
apply memento until that day, I knew it was a perfect match. The memento pattern
would let me commit to a save point that I could then roll back. So I set about
revising my knowledge of the memento pattern's implementation. I created my
Caretaker , r Memento and Originator classes, placed them in an internal package,
and implemented the database logic code that uses internal memento classes.
I was proud and coni dent about the code I delivered. Surprisingly (for me), the
company didn't want to continue with the interview process. Maybe it was looking
for someone who would use a simple stack to push and pull values, but the code
I delivered gave me coni dence in my knowledge of design patterns, even for the
patterns I don't use often.
After going back over the original question years later, I realized there were
performance constraints of using minimal objects and an O(log N) runtime
performance. My code was readable, clean, and maintainable, but it failed to
address the key points that the interviewer asked in the i rst place.
If knowing a pattern blinds you to making good decisions, design patterns do more
harm than good.
…AND THE UGLY
Design patterns and Java EE are old pals. However, this friendship did not always work out well. As
J2EE became more accepted in the corporate world and began addressing large projects, design patterns
came to the rescue. Many of the classical patterns from GoF found their place in J2EE applications.
Enterprise patterns followed soon after to address common problems in the J2EE platform.
J2EE gained popularity and drove many new concepts such as Service Orientated Architecture
(SOA) and Web Services. However, the complex structure of J2EE doomed many projects to fail.
J2EE beans relied on extending classes and needed a heavyweight container on which to run.
Because the beans rely on the container, the development process needed full‐blown heavyweight
servers to slow down the development and needed costly hardware to run on. Still, those enterprise
containers were slow, resulting in sluggish restarts and refreshes. Testing and unit testing was hard
to perform properly.
Besides, J2EE coni guration was heavy and relied on XML i les. Although separating the
coni guration and code seemed like a good idea, soon it turned out to be an XML hell. Heavy
coni guration was needed to create a simple bean.
As J2EE became the platform of the enterprise, consultants, architects, and vendors released
sophisticated guidelines that resulted in over‐complex, over‐architected, and overly layered
applications that were impossible to test and hard to develop (due to long restarts), debug, and