Pattern Hatching

John Vlissides

Mentioned 10

Design patterns, which express relationships between recurring problems and proven solutions, have become immensely popular in the world of software development. More and more software developers are recognizing the supreme usefulness of design patterns and how they ease the design and delivery of software applications. This book builds upon the information presented in the seminal work in this field, Design Patterns: Elements of Reusable Object-Oriented Software, and gives software professionals the information they need to recognize and write their own patterns. Pattern Hatching, written by one of the co-authors of Design Patterns, truly helps the software professional apply one of the most popular concepts in software development.

More on Amazon.com

Mentioned in questions and answers.

From Wikipedia :

The idea was that once completed, the implementation of a class could only be modified to correct errors; new or changed features would require that a different class be created. That class could reuse coding from the original class through inheritance

From what I understand, The Visitor pattern is a powerful technique to traverse similar but different objects that implement the same Interface by the use of double dispatch. In one of my Java examples, I created a composite set of objects that form a tree structure, and each specific implementation of those objects implement the visitable interface. The visitor interface has a method for each of the visitable objects, and the concrete visitor implements what to do for each of those cases.

The thing I'm trying to get my head around is the fact that if I were to add a new implementation to the composite structure that also implements visitable, then I need to reopen the visitor interface and add that case to it, also forcing me to modify each implementation of visitor.

While this is fine, since I would need to do this anyway (What good is adding to your visitables if the visitor can't understand them?) but on an academic level, wouldn't this be violating the Open Closed Principle? Isn't that one of the core reasons for Design Patterns anyway? Trying to show a decent reason for switching to this pattern instead of maintaining a switch statement to end all switch statements, but everyone argues that the code will be the same anyways, with a method for each case instead of a switch block, just broken up and harder to read.

John Vlissides, one of the GoF, wrote an excellent chapter on the subject in his Patterns Hatching book. He discusses the very concern that extending the hierarchy is incompatible with maintaining the visitor intact. His solution is a hybrid between a visitor and an enum-based (or a type-based) approach, where a visitor is provided with a visitOther method called by all classes outside the "base" hierarchy that the visitor understands out of the box. This method provides you an escape way to treat the classes added to the hierarchy after the visitor has been finalized.

abstract class Visitable {
    void accept(Visitor v);
}
class VisitableSubclassA extends Visitable  {
    void accept(Visitor v) {
        v.visitA(this);
    }
}
class VisitableSubclassB extends Visitable {
    void accept(Visitor v) {
        v.visitB(this);
    }
}
interface Visitor {
    // The "boilerplate" visitor
    void visitB(VisitableSubclassA a);
    void visitB(VisitableSubclassB b);
    // The "escape clause" for all other types
    void visitOther(Visitable other);
}

When you add this modification, your visitor is no longer in violation of the Open-Close Principle, because it is open to extension without the need to modify its source code.

I tried this hybrid method on several projects, and it worked reasonably fine. My main class hierarchy is defined in a separately compiled library which does not need to change. When I add new implementations of Visitable, I modify my Visitor implementations to expect these new classes in their visitOther methods. Since both the visitors and the extending classes are located in the same library, this approach works very well.

P.S. There is another article called Visitor Revisited discussing precisely that question. The author concludes that one can go back to an enum-based double dispatch, because the original Visitor Pattern does not present a significant improvement over the enum-based dispatch. I disagree with the author, because in cases when the bulk of your inheritance hierarchy is solid, and the users are expected to provide a few implementations here and there, a hybrid approach provides significant benefits in readability; there is no point in throwing out everything because of a couple of classes that we can fit into the hierarchy with relative ease.

From a bookish perspective, you might say that x design pattern is applicable in y scenario, but I want to dig a little deeper here. So here are my queries:

  1. When do you first decide that you'll use design patterns? Do all of you decide upon design patterns before coding?
  2. Are there any DPs that you apply after you're done coding (small refactorings)? Do you apply DP while maintaining code?
  3. What are the design patterns that are predominantly applied during design?
  4. What are the DPs that you apply while tweaking/refactoring code?
  5. Are there any hints in code (technical not functional stuff) that suggest that you should apply a DP (like too many ifs, double dispatch, multithreading)? If so, could you name the DPs and their catchpoints?
  6. Do you use any Micro-DPs that makes you feel good about the code you've written (even though others hate you for it :p)?

Edit:
I'd like to add that I read DPs through "Head First Design Patterns" and although it's one of the best books to understand the pattern. I don't think I've been able to transition the Pizza examples to real world scenarios.

I think this is one of the most influential books on DP but we can still have a book that may enumerate the various popular business scenarios that demand a particular pattern alongside that pattern. This knowledge is still implicit to a large extent I think. Such a book would be a very nice quick reference don't you think :))

Don't forget the book Design Patters, it may cover C++ but it doesn't matter, it's all patterns. Besides the book is very good.

And you don't learn patterns to implement them, that's the wrong way, you learn then so you can talk about code with other programmers. It's more a extension to your normal language then anything else. Use it in your code when needed, but not before :-)

Two good books which deal with the how and when (not) to use Design Patterns are:

When can a design pattern make your software worse?

I have seen a program where they used the facade pattern between the GUI and logic. They considered that no objects may be transported over this, so only primitive types were used which made it difficult to code.

A design pattern can make your software worse if you misuse it, applying it in a wrong situation. Common sense should be the perfect companion for a design pattern.

The misuse of patterns sometimes is associated with a lack of understanding of the forces associated with the problem and the pattern proposed solution to that problem. Also the intent of the pattern could be misunderstood leading to misuses.

To a better comprehension of patterns you also need to learn about the Anti pattern concept and read a lot more than the GOF book. One suggestion is to read Pattern Hatching to complement GOF's concepts.

For decades programmers have often spent time making software worse by applying practices they don't understand, rather than learning why that practice is good. The use of certain tools/keywords/frameworkes can make a programmer feel sophisticated, when they're just screwing things up. Some common examples:

  • Throwing in lots of try/catch/finally blocks can make a programmer feel like they have an error handling scheme, when they in fact don't.
  • Replacing sql with stored procedures can make programmers feel like they have a data access layer, that magically gives them efficiency, reuseability, encapsulation, etc.
  • Using classes makes many programmers believe they're engaging in object oriented programming.

This list could go on forever. This tendency has always been around and always will be, because we humans always look for shortcuts. We see this a lot with patterns now because patterns are currently popular. The root problem is the same: developers not having a respect for how complicated software development is, and thinking a blindly implemented pattern or practice is a substitute for learning and humility.

The solution: difficult to say. You can't go to wrong though handing a junior developer Code Complete or some such, to help them understand this is all about applying principles to particular situations, and that great developers keep it simple.

What is your perspective on downcasting? Is it ALWAYS wrong, or are there cases where it is acceptable, or even preferable or desired?

Is there some good measure/guideline we can give that tells us when downcasting is "evil", and when it's "ok"/"good"?

(I know a similar question exists, but that question spins out from a concrete case. I'd like to have it answered from a general design perspective.)

An example for "legal" downcasting is Java pre 5.0 where you had to downcast container elements to their concrete type when accessing them. It was unavoidable in that context. This also shows the other side of the question though: if you need to downcast a lot in a given situation, it starts to be evil, so it is better to find another solution without downcasting. That resulted in the introduction of generics in Java 5.

John Vlissides analyzes this issue (aka "Type Laundering") a lot in his excellent book Pattern Hatching (practically a sequel to Design Patterns).

Working with Java and Java frameworks I have started shuddering when I encounter Abstract Factory patterns. In my opinion this is the most abused design pattern. Not all frameworks abuse it but there are many. It doesn't fit all models and when almost 100% of the time you are going to be doing the same thing why abstract it?

Which design pattern in your opinion is the most abused design pattern? One where developer have used it but it doesn't fit the problem so well. A case of having a golden hammer and everything looking like a nail. So, which design pattern makes you shudder when you encounter it in the wild?

EDIT: Just thought about the Singleton. But that cropped up in the question of the most overused. I am asking for the most abused. (Or incorrectly used).

I'd agree with Singleton.

But because people generally implement it as straight GoF vanilla and don't think about how it should be destroyed.

Have a read of the interesting chapter "To Kill A Singleton" also available in John Vlissides's book "Pattern Hatching: Design Patterns Applied" (sanitised Amazon link)

Edit: Just found the article "To Kill A Singleton" article on line here.

HTH

cheers

I am trying to figure out why composite is better than a simple inheritance.

For example, lets say we want to implement a file system. So basically we need files and folders. We can use the composite pattern while File and Folder classes inherit the base interface and Folder class holds an interface type collection.

But it looks like (to me anyway) that simple inheritance can do the same thing. If File is the root class and Folder inherits from File, the Folder can hold collection of Files, end of story.

Am I missing something?

if File is the root class and Folder inherit File, the Folder can hold collection of Files

This is essentially the Composite pattern, even if you don't call it like that :-)

Except that in your variation, Folder will inherit file-specific functionality which it can't (or worse: shouldn't) use. So you end up complicating your implementation to ensure that e.g. clients can't append bytes to the "end" of your folder etc.

FYI, the sequel to the GoF book, Pattern Hatching, discusses the implementation of a file system using various patterns, including Composite. Highly recommended read.

is there any new design patterns available other than the patterns covered by GoF book and Head First Design Patterns? Have any one of you used your own design patterns in your projects? Please let me know. if possible give some UML Diagrams. Thanks in advance.

The "sequel" to the GoF book is Pattern Hatching by John Vlissides. It does not publish really new patterns, but variations of some included in the original GoF book. Its great value is rather in that it shows the thought and design process involved in applying the patterns.

Although this is not an answer to your question in the strict sense, there are also lots of other kinds of patterns relevant to our field:

I was asked this question recently -

How would you model a file system using UML? Keeping it simple - you have files and directories, directories can contain other directories or files. Bonus points: how would you add the ability to cater for symbolic links?

What classes, relationships, cardinality would there be? Any design patterns you would use?

Check out Pattern Hatching (the "sequel" to Design Patterns) - the first part of the book discusses this, with lots reasoning about the applicable design patterns, and implementation code samples. Although it is pre-UML (I am not sure if it contains any diagrams in fact), but the discussion of the design process is priceless.

Which is the best tutorial to understand java design patterns? I am not new to java programming, so basics of java need not be required.

you may find these useful :

(but the last two are a bit advanced)

Joshua bloch's book Effective Java is useful even thought its not about design patterns but it's a must read.

You must read Head First Design Pattern.

Though not specific to Java, I seriously recommend you to go for, Design Patterns by Gamma, et al (a.k.a. the Gang of Four, or simply, GoF)

If you are not new to programming you have probably already used a lot of them without realizing it. Design patterns are not language specific, try not to think of them as 'Java' patterns or 'Python' patterns etc. A really good book is Design Patterns: Elements of Reusable Object-Oriented Software.

Do not waste your time with this question. Follow up to: What is so bad about singletons?


Please feel free to bitch on Singleton.

Inappropriate usage of Singleton may cause lot of paint. What kind of problem do you experienced with singleton? What is common misuse of this pattern?


After some digging into Corey's answer I discovered some greate articles on this topic.

One basic problem with the original GoF design is the fact that the destructor isn't protected. Anyone with a reference to the singleton instance is free to destroy the singleton.

See John Vlissides update "To Kill A Singleton" in his book "Pattern Hatching" (Amazon link).

cheers,

Rob