Java Reference
In-Depth Information
Establishing a pattern
By itself, a problem is only a bug. We should already have processes and proce-
dures for identifying and fixing bugs. Indeed, many of my father's customers
had adequate measures for detecting and removing bad products from the
line. The problems with these reactive approaches are twofold. First, we will
never find all of the bugs. Second, if we do not fix the machinery or the pro-
cess, we will create more bugs! After we have established a pattern, we need to
elevate it from bug to antipattern.
1.4.3
Refactoring antipatterns
After we find a problem and establish a pattern, our strategy calls for refactor-
ing it to form a better solution and process. Here, we are overlapping the
realms of design patterns and antipattern. My intuition is that this combina-
tion is part of what is missing in the software quality industry. The combina-
tion of design patterns and antipatterns is practical and powerful. Poor
solutions can be identified through antipatterns and redesigned into more
proven and practical alternatives using design patterns. The process of contin-
ually improving code through restructuring for clarity or flexibility and the
elimination of redundant or unused code is called
refactoring.
Many experts advocate the rule “If it isn't broke, don't fix it
.”
In the realm
of software development, following this rule can be very expensive, especially
at the beginning of a program's life cycle. The average line of code will be
changed, modified, converted, and read many times over its lifetime. It is folly
to view a refactoring exercise as time wasted without considering the tremen-
dous savings over time. Instead, refactoring should be viewed as an investment
that will pay whenever code is maintained, converted, read, enhanced, or oth-
erwise modified. Therefore, refactoring is a cornerstone of this topic.
1.5
Why
Bitter Java
?
In the Java community, the study and promotion of design patterns, or blue-
prints for proven solutions, has become well established and robust. The same
is not true of the antipattern. As an architect and consultant, I have seen an
amazing sameness to the mistakes that our customers tend to make. While the
problem of the month may change slightly in a different domain or setting, the
patterns of poor design, culture, and even technology stay remarkably consis-
tent from one engagement to the next. I strongly believe that the study of anti-
patterns inherently changes the way we look at the software process. It keeps us
