On Feb. 5, 2003, I gave a talk at XPSTL about code duplication in Java. The presentation is available for download here, as well as the plain text of it. If you download the presentation, you’ll find the code snippets inside. The samples did not come along for the (very rough) plain text export below.
Attacking Code Duplication in Java
Oasis Digital Solutions Inc.
Feb. 5, 2003
Once and Only Once
z OAOO is shorthand for the principle that each idea should be expressed exactly once in the source code.
z A tenet of XP
z Predates XP, a good design principle
z Not specific to OO development
“So, duplication sucks. The more rabidly a person hates duplication, the more I trust their opinions on managing information. A programmer, upon noticing some redundancy, should be thrown into a panic, begin hyperventilating, and stammer something about “¡El diablo! !El diablo está en mi software!”.”
Why Not Duplicate?
z Duplication is not just inconvenient.
z OAOO is not an “architecture astronaut” nitpick.
z Duplication is a clear sign of bad information management and complexity management.
z Building large systems consists significantly of complexity management and dependency management.
z OAOO makes systems easier to change.
z OAOO holds back entropy.
z I admit – I follow that quote. I use hatred of duplication as a barometer of design skill.
How Do We Achieve OAOO?
z Usually by refactoring code that contains duplication.
z Usually, a little bit at a time.
z However, when doing or evaluating up-front design, OAOO is a excellent criteria to apply.
z Sometimes it’s obvious
z Other times it’s subtle
z Kent Beck is known for being able to see extremely subtle duplication, refactoring the code to make it clear duplication, then removing it.
Examples and Techniques
z Trivial duplication can be removed with Extract Method, adding a variable, etc.
z Some duplication is harder to address – we’ll look at examples and techniques for attacking it.
z These slides outline the ideas, we’ll do a few examples “live” in the presentation.
Tools to Achieve OAOO
z Anonymous Inner Classes
z Create a class hierarchy
z Command Pattern
z Replace Case with Polymorphism
y Code Generation
y Dynamic Proxies
y Replace class hierarchy with runtime relationships
Fighting a try / finally
z (One solution on the next slide.)
z Simple try / finally example…
z multiple try / finally example…
Anonymous Inner Classes
z They’re not just for Swing listeners.
z They are Java’s version of code blocks (Smalltalk, Ruby).
Create a Class Hierarchy
z Raise the duplicated code to a base class.
z (Also the Template Method pattern)
z Base class has a doFoo() and abstract realFoo()
z Descendants have a realFoo()
z doFoo() wraps realFoo() with whatever code would have been duplicated.
“Heavy Lifting” to Achieve OAOO
z Replace class hierarchy with runtime object relationships
z Replace application code with code generation
z Dynamic Proxies
z Aspect Oriented Programming – makes it much easier to remove many kinds of duplication.
Replace Class Hierarchy…
z An extreme step, not in the XP sense
z Useful when a previous designed has created a great number of “glue” classes that don’t contain much information
z The essence of code generation is to have a specification, and set of rules for producing code.
z Example: the many support and utility classes, coded in a formulaic way, in a typical EJB application
z Example: O-R persistance code
z Example: GUI code
What about Generated Duplicated Code?
z This doesn’t bother me – I only care about duplication in the checked in code
z If it bothers you, nearly every problem that can be solved with code gen, can be solved with a dynamic mechanism instead.
z (Note – Don’t check in generated code. Please.)
Adding a Field
z As an example of large scale duplication issue… if you want to add a field to some entity in a typical J2EE application, how many places in the code/configuration do you need to touch?
Duplication in Legacy Systems
z Legacy systems often contain extensive duplication
z Can we find some in JBidWatch?
z OAOO in software design, is closely related to normalization in DB schema design.
What About Tests?
z Sometimes I find that things are duplicated between test code and production code.
z I’m not comfortable with this…
z But sometimes getting rid of it seems to negate the point of the test.
z More examples, anyone?
z War stories?
z What additional / different tools does C# have to offer?
z Why do we see so much duplication in software?
z What about people who like duplication?
z These are some snapshots of the code we worked through during the presenation.
Starting Point – Parallel Loops
Anonymous Inner Class
AIC, with Template Method
z AICs are the Java syntax for blocks / closures.
z AICs are really ugly syntax compared to Smalltalk, Ruby, etc.
z OAOO techniques sometimes create code that non-expert Java developers find very hard to fathom.
z The syntax is a big pain for small examples, but OK in real apps.
Slides will be on my site: