Whatever…

How I Use Patterns…

March 18th, 2005

If you are new to software patterns, you might be wondering how to use them. In any case, I would love to hear back from you on how you find patterns useful (or not) depending on your experience. Anyway, based on my experience, I see 3 broad categories of pattern usage.

1. Building a new system
   
   If you are developing a new system, patterns help you to layout the design blueprint for the system. You can design the system using well-known patterns and help your team understand your design rapidly by documenting and explaining your design with patterns. Assuming that the patterns you use are well understood by your team members, you spend very little or no time in explaining the nitty-gritty details that can be encapsulated by each pattern. If someone is not familiar with a pattern that you are using, you simply point them to the pattern documentation and they would quickly get up to speed on it. Patterns streamline the design communication within your team and help your team to focus on the design and implementation instead of arguing about the fine-grained implementation choices underneath. Once you agree upon the overall design and the choice of patterns, you then get on with choosing the right strategies for implementing the design. Remember, there is not one way to implement a pattern. Multiple implementations (or solutions) for a pattern are described as discrete implementation strategies you get to choose and implement after choosing the pattern.

2. Understanding an existing system
   
   If you begin working with an alien system, the first (and hardest) thing to do is to comprehend the system design and architecture. Patterns help you in understanding such systems. You can use your patterns experience to drill down, identify and decompose the system design into comprehensible pieces that can be mapped to well-known patterns. In my job as a consultant, this is what I do. I end up mapping the system back into patterns by investigating the code, design documentations (if I am lucky to find one) and talking to other developers who might have worked with or have some knowledge of system. This helps me to capture and share the design information of the system and to focus on those areas I don't understand well (i.e. those areas that do not easily map to well-known patterns). Understanding a system is essential to managing, maintaining, refactoring and enhancing it confidently and patterns can help you to get there.

3. Refactoring a system
   
   This depends on the above point on understanding a system. Once you understand a system and map the system back to well-known patterns, refactoring becomes easier. You can identify the impact of refactoring by looking at the patterns and their inter-connections. Refactoring may involve such activities as changing a pattern strategy (i.e. same pattern, different implementation), swapping patterns (replace one pattern with another), or introducing a new pattern. Patterns become the targets to which we refactor a system. So there too, patterns provide me a better way to improve my refactoring. In my experience as a consultant to many customers, this benefit of patterns alone has proven to be of great value to perform my job efficiently and with the highest quality.

Useful References

• Refactoring To Patterns by Joshua Kerievsky is an excellent resource on understanding how you can refactor using various patterns as targets.
• Refactoring by Martin Fowler is the original book on the subject that is a must read for all developers.
• Core J2EE Patterns contains 21 J2EE patterns and 14 J2EE design-level refactorings - discusses pattern-based refactoring.
• And you can't forget Design Patterns by GoF that started it all.

License - Published under

Entry Filed under: Patterns