Some interesting patterns for design and implementation (TOP 5)

In my last entry about patterns I explained the fundamental concepts of (in my opinion) the building blocks of every architecture with patterns. The feedback for the entry was great, so I describe here some implementation level / design patterns.

  1. Observer: you will even find the first implementation in JDK 1.0 (just scan the java.util. Package). Observer (together with command) is the foundation of every event distribution implementation. Also MVC is based on observer. The basic idea: you are interesting in a state of an object. In case the state changes, you will be notified (Pull or Push strategies are possible). In Java EE observer does not work properly (the latency...), so it is a good idea to use e.g. JMS topics for the event distribution.
  2. Strategy: a cool name for a simple approach. The idea: make algorithms replacable. The solution: hide them behind an interface and make them so replaceable (often with Factories or IoC/DI). It's often used, without knowing it.
  3. Template: provide a basic but, unchangeable, behavior (sequence of method invocations) in a superclass for all subclasses. The idea is used in the Servlet-API: the HttpServlet overrides the service method and dispatches to the doGet, doPost etc. methods. If you would like to build another webframework (:-)) you have to extend from the HttpServlet and override the doGet and doPost methods. Very often the template methods are abstract, in the HttpServlet they are concrete, but throw exceptions
  4. Visitor: is used for the harder problems. You would like to walk through a node graph. Is often used to copy an object graph, generic algorithms or cache replications e.g. in the framework the advertisements (=pointer to services) are replicated using walker algorithms from peer to peer. It is not very easy to implement (just think about cycle-recognition).
  5. Chain Of Responsibility: Similar to visitor. The nodes are able to deny the execution and also pass the control to the next node in the chain. This pattern is often is used together with decorator to implement simple AOP (see servlet filters or Spring's AOPs). You can also build a simple Rule Engine with CoR and Command. In this case the rules are executed and decide to pass the control to the next node or not. I built a simple rule engine, which read excel spreadsheets and generete the chain or rules (see my last entry about excel and "MDA")
If you already know decorator, you will find the other patterns like: wrapper, delegate or proxy no more so exciting. In real world it is not a big challenge to use all of the patterns, but the opposite is true. The architect/designer or developer should restrict the number of patterns and set constraints for the usage and the combination of patterns. Less is more...



Posted by babu_thaliyan on July 28, 2012 at 09:42 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments