2. What is a Design
Pattern?
“Each pattern describes a problem which
occurs over and over again in our
environment and then describes the core of
the solution to that problem, in such a way
that you can use this solution a million
times over, without ever doing it the same
way twice.”
- Christopher Alexander
3.
4. The Patterns Backlash
• Copy/paste
• Design by template
• Cookbook / recipe approach
“The Design Patterns solution is to turn the
programmer into a fancy macro processor”
- M. J. Dominus, “Design Patterns” Aren't
5. The Patterns Backlash
• Design patterns aren’t patterns
• Just workaround for missing language
features
“At code level, most design patterns are
code smells.”
- Stuart Halloway
6. The Patterns Backlash
• Overuse
“Beginning developers never met a pattern
or an object they didn’t like. Encouraging
them to experiment with patterns is like
throwing gasoline on a fire.”
- Jeff Atwood, Coding Horror
14. Classic Singleton
public final class Singleton {
private static Singleton INSTANCE =
new Singleton();
private Singleton() {}
15. Classic Singleton
public final class Singleton {
private static Singleton INSTANCE =
new Singleton();
private Singleton() {}
public static Singleton instance() {
16. Classic Singleton
public final class Singleton {
private static Singleton INSTANCE =
new Singleton();
private Singleton() {}
public static Singleton instance() {
return INSTANCE;
17. Classic Singleton
public final class Singleton {
private static Singleton INSTANCE =
new Singleton();
private Singleton() {}
public static Singleton instance() {
return INSTANCE;
}
18. Classic Singleton
public final class Singleton {
private static Singleton INSTANCE =
new Singleton();
private Singleton() {}
public static Singleton instance() {
return INSTANCE;
}
public Object read() {
19. Classic Singleton
public final class Singleton {
private static Singleton INSTANCE =
new Singleton();
private Singleton() {}
public static Singleton instance() {
return INSTANCE;
}
public Object read() {
// nasty database call
20. Classic Singleton
public final class Singleton {
private static Singleton INSTANCE =
new Singleton();
private Singleton() {}
public static Singleton instance() {
return INSTANCE;
}
public Object read() {
// nasty database call
}
21. Classic Singleton
public final class Singleton {
private static Singleton INSTANCE =
new Singleton();
private Singleton() {}
public static Singleton instance() {
return INSTANCE;
}
public Object read() {
// nasty database call
}
}
22. Things go horribly wrong
public class Victim {
public void something() {
Object foo = Singleton.instance().read();
// etc...
}
}
23. Things go horribly wrong
public class Victim {
public void something() {
Object foo = Singleton.instance().read();
// etc...
}
}
public class TestVictim {
public void testSomething() {
// Holy crap, how do I
// mock the db call in Singleton?
}
}
25. Interfaces to the rescue
public interface Singleton {
Object read();
}
public class SingletonImpl
implements Singleton {
public Object read() {
// nasty database call
return null;
}
}
26. Dependency injection,
you’re my hero!
public class Victim {
private final Singleton singleton;
public Victim(Singleton singleton) {
this.singleton = singleton;
}
public void something() {
Object foo = singleton.read();
// etc...
}
}
27. Now we can test
public class TestVictim {
public void testSomething() {
Singleton s = new MockSingleton();
Victim victim = new Victim(s);
victim.something();
// assertions
}
}
28. Push construction up
public class Component {
private final Victim victim;
public Component() {
victim = new Victim(
new SingletonImpl() );
}
}
31. What have we learned?
• Interfaces and dependency injection
• Reduce hidden coupling
• Allow testability
• Allow subclassing
• Make construction and use flexible
• If need only one, control by configuration
• Guice
• Spring
40. What have we learned?
• Prefer composition to inheritance
• Allows greater reuse
• Communicates intent better
• Easier to understand and maintain
• More robust as it evolves
• Inheritance is a very strong form of coupling
• Especially in a single-inheritance language
51. Visitor Types
• “Collector” visitor - accumulate state
• “Finder” visitor - search and return
• “Event” visitor - stateless, fire events
• “Transform” visitor - modify while walking
• “Validation” visitor - validate and report
52. Visitor abort
public class FindVisitor
implements ConcreteVisitor {
private final int seek;
private Node match;
public FindVisitor(int seek) {
this.seek = seek;
}
public Node getMatch() {
return this.match;
}
public void visit(ConcreteNode1 n) {
if( this.match == null &&
n.getValue() == seek) {
this.match = n;
53. Exceptions
public class ComputeVisitor
implements ConcreteVisitor {
public void visit(ConcreteNode1 n) {
try {
// blah blah
} catch(BadException e) {
// what now?
}
}
}
54. What have we learned?
• Expression problem is tough
• Abstract base classes help plan for evolution
• Generics add precision and flexibility by
revealing hidden coupling