Posts filed under 'Patterns'
Dave Linthicum writes about why patterns can be key to SOA solutions. Being a patterns enthusiast and practitioner, I agree with what’s been said in spirit. But, having been through the process of identifying and documenting the enterprise Java patterns, I am cringing at one thought he expressed there of creating a database of SOA patterns. I am afraid that I don’t buy this approach entirely. Such a database is going to cause more problems than solve anything.
Patterns don’t live in isolation, they really create a network amongst them (of inter-relationships) that increases the value of the set of patterns as a whole. A single pattern itself, while useful, has limited applicability. Whereas with a set of patterns and relationships, you can start understanding the key pattern heuristics and eventually lead to a pattern language, which is the ultimate goal of any patterns practitioner. This was the hardest part of pattern discovery in our (me, Dan & John) enterprise patterns work, where you can see one such example of pattern relationships (and here) to help you better understand the community of patterns, rather than just a single pattern.
For an example of a patterns database, take a look at the Server Side patterns database, while commendable and has incredible participation, the patterns submitted there lack such a language of relationships and thereby exist at multiple levels of abstraction which do not inter-relate very well.
March 31st, 2006
I am deeply saddened to hear that John Vlissides passed away during thanksgiving after a long battle with an illness (see here and here). I had the pleasure and good fortune of meeting him once and only once at OOPSLA a couple of years ago. I now recall how I was struck by his modesty and friendliness. He was a great author, contributor and an overall very nice guy. He will greatly missed by the community.
Read anecdotes and memories and even share yours on WikiWikiWeb here (See http://c2.com/cgi/wiki?JohnVlissides).
GoF Patterns Software
November 28th, 2005
Let's say you have used a pattern many times in your implementations. And then
one day something new comes along and you no longer need to implement that old
pattern anymore. So what happens to that pattern? Does it get deprecated? I
have come across this question many times while talking to other developers.
For instance, this question of pattern deprecation is associated with some
patterns we documented in Core J2EE
Patterns. We first released these patterns in the 1st edition. And when
newer version of J2EE/EJB/Servlet specifications became available, these patterns
gained direct support in the underlying platform. The questions related to a
few of the J2EE patterns are:
- Did Intercepting Filter pattern get deprecated since Servlet version 2.3 specification introduced an new Filter component ?
- Is Composite Entity pattern no longer applicable since EJB 2.0 introduced local EJBs?
- Is Service Activator pattern deprecated since EJB version 2.0 introduced Message Driven Beans (MDB)?
IMO, patterns do not get deprecated. In these cases above, the patterns were absorbed and supported into the relevant specifications. This makes the platform better because it is providing built-in support for well known patterns. So as platforms mature, some platform patterns can get assimilated into the platform as a process of improvement.
This process however does not diminish the value of those patterns. Instead the forces around the patterns can change a bit leading to new solutions and strategies for implementing the pattern in the new platform. This is what happened to some patterns in Core J2EE Patterns. As J2EE evolved, the strategies we describe for these patterns also evolved. I look at this as a process of symbiosis and maturation between patterns and platforms.
YouRIt: Patterns Architecture J2EE Programming
April 18th, 2005
Question: Should I use Intercepting Filter or Front Controller?
Short answer is: use both. Intercepting Filter and Front Controller are typically used in combination. IMO, the real question is how to separate the concerns of each in my web application.
This is a common question I encounter.
Sometimes, when I need to implement a request/response handling functionality in the presentation tier,
choosing between processing in Intercepting Filter and Front Controller becomes a matter of preference. Both patterns offer a way to centralize control of request/response processing. However, there are some key differences in how you assign responsibilities to each.
- I use Intercepting Filter when I want loosely-coupled pre and post processors for request/response handling.
Intercepting Filters offer pluggability and configurability so that I can add/remove filters non-intrusively (declaratively). Filters are ideal if the operations they perform are well-encapsulated and discrete so that I can plug and play as I want.
- For all other common request processing, a Front Controller is the way to go for me. Front Controller avoids duplication of code in multiple views. Typically, once I implement a Front Controller, I pretty much want to leave it alone as much as possible. Over time, if I start seeing lots of conditional switching (if-then-else or case/switch) in my Front Controller, then I might refactor conditional logic using Intercepting Filters or delegate the conditional processing to helpers using the Command and Controller Strategy [see Front Controller pattern] implementing a Command [GoF] based services layer.
Bottomline: I want my Front Controllers to be straightforward, simple and easy to maintain, and my Intercepting Filters to be loosely-coupled, pluggable and stateless.
What do you think?
March 23rd, 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.
- 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.
- 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.
- 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
March 18th, 2005
I hear from other developers all the time about how they feel that design patterns are over-hyped and not really useful. For example, recently I was talking to an aquaintance Bob (not his real name), who works for a hugely well-known company.
We were talking about some programming stuff, and as it happens, soon wandered into the world of patterns.
Bob said to me that when he first read the GoF book, he felt that there was nothing new in it. He had already implemented those patterns and had reused them over and over in his designs. So, he said, “What is the big deal with patterns? I did not learn anything new!”
In my experience, this sentiment is pretty common among us developers. I, and my co-authors, received similar feedback during the early days of our work on Core J2EE Patterns. I said to him “Bob, it is great that you had implemented those patterns in the GoF book before it was published. But the very fact that you, me and others like us have repeatedly implemented them proves that those patterns are indeed patterns! And that's the whole point about patterns.”
Documenting recurring designs helps us to communicate with other developers. Patterns provide a great mechanism to document and share reusable problem/solution pairs. Patterns also provide a powerful design vocabulary so everyone on the team can talk the same talk and understand each other. This increases productivity and decreases noise and ambiguity in our design discussions. The benefit of such a vocabulary in design is often an overlooked benefit of using patterns in our day to day work.
In the GoF book, they talk about an Aha! experience - when one understands the patterns and gains new insights. I think the experience I have encountered from other developers is a bit different, one that I call the Duh! effect, as in “Duh! I knew that already.” As a pattern practitioner, when I hear the Duh! effect, I no longer have to prove that patterns are useful and that a pattern is a pattern.
Duh! = Game over!
March 17th, 2005
Martin Fowler (one of my favorite authors) has put together this nice survey of various pattern catalogs that have evolved in the recent years.
We collaborated with Martin when we were developing the Core J2EE Patterns book and were grateful for his comments and suggestions as he reviewed our work. We continue to work with him and others in the Pattern community.
Over the last year or so, many in the patterns community have been working together to create a pattern fabric to collaborate and bring together patterns related work by different people. Microsoft has recently put together a new community site called PatternShare for sharing and collaborating around patterns.
March 17th, 2005