Decorator Pattern

The Decorator Pattern is used for adding additional functionality to a particular object as opposed to a class of objects. It is easy to add functionality to an entire class of objects by subclassing an object, but it is impossible to extend a single object this way. With the Decorator Pattern, you can add functionality to a single object and leave others like it unmodified.

Decorator, also known as a Wrapper, is an object that has an interface identical to an object that it contains. Any calls that the decorator gets, it relays to the object that it contains, and adds its own functionality along the way, either before or after the call. This gives you a lot of flexibility, since you can change what the decorator does at runtime, as opposed to having the change be static and determined at compile time by subclassing. Since a Decorator complies with the interface that the object that it contains, the Decorator is indistinguishable from the object that it contains. That is, a Decorator is a concrete instance of the abstract class, and thus is indistinguishable from any other concrete instance, including other decorators. This can be used to great advantage, as you can recursively nest decorators without any other objects being able to tell the difference, allowing a near infinite amount of customization.

It is a good idea to use a Decorator in a situation where you want to change the behaviour of an object repeatedly (by adding and subtracting functionality) during runtime.

Example :-A very nice example of decorators is Java's I/O stream implementation.

Difference between struts and springs

Question: Difference between Strust and Springs

Answer:Difference between struts and springs could be analysed from various facets.

(1) Purpose of each framework.
(2) Various feature offerings at framework level.
(3) The design & stuff.

Firstly, Struts is a sophisticated framework offering the easy 2 develop, structured view/presentation layer of the MVC applications. Advanced, robust and scalable view framework underpinning reuse and seperation of concerns to certain extent. Springs is a Lightweight Inversion of Control and Aspect Oriented Container Framework. Every work in the last sentence carry the true purpose of the Spring framework. It is just not a framework to integrate / plug in at the presentation layer. It is much more to that. It is adaptible and easy to run light weight applications, it provides a framework to integrate OR mapping, JDBC etc., Infact Struts can be used as the presentation tier in Spring.

Secondly, Struts features strictly associate with presentation stuff. It offers Tiles to bring in reuse at presentation level. It offers Modules allowing the application presentation to segregate into various modules giving more modularity there by allowing each module to have its own Custom/Default Request Processor. Spring provides Aspect Oriented programming, it also solves the seperation of concerns at a much bigger level. It allows the programmer to add the features (transactions, security, database connectivity components, logging components) etc., at the declaration level. Spring framework takes the responsibility of supplying the input parameters required for the method contracts at runtime reducing the coupling between various modules by a method called dependency injection / Inversion of Control.

Thirdly, Struts is developed with a Front Controller and dispatcher pattern. Where in all the requests go to the ActionServlet thereby routed to the module specific Request Processor which then loads the associated Form Beans, perform validations and then handovers the control to the appropriate Action class with the help of the action mapping specified in Struts-config.xml file. On the other hand, spring does not route the request in a specific way like this, rather it allows to you to design in your own way however in allowing to exploit the power of framework, it allows you to use the Aspect Oriented Programming and Inversion of Control in a great way with great deal of declarative programming with the XML. Commons framework can be integrated to leverage the validation in spring framework too. Morethan this, it provides all features like JDBC connectivity, OR Mapping etc., just to develop & run your applications on the top of this.


Another differences:
1. Struts is a web framework only, Struts can be compare with the SpringMVC. And SpringMVC is subset of the Spring framework. So we can say that Sturts can be seen as the subset of the spring framework in functionality point of view.
2. What Action class do in struts, Controller does in Spring. And action in Struts is a Abstract class but Controller in Spring is an interface, This is very good advantage of the spring.
3. Spring don�t have any action from, it bind the http form values directly into pojo. Instead of initializing the form bean spring directly initialize the domain object.
4. ActionForward in struts is replace with the ModelAndView in Spring. Model component contain the business object to be displayed via view component.
5. Unlike Struts Spring don�t provide any separate tag library.



More talk:
1.Struts implement MVC Design Patten where as Spring implements IOC Design Pattren and addreses AOP Cross cutting concerns.
2.Struts is heavy weight where as Spring is light weight framework.
3.Struts is tightly coupled Spring is loosely coupled.



Struts will be Generally used as a Front End Frame work.
Spring has spring webFlow for the same purpose, which is part of spring Framework.

The other major advatages of spring Framework is it handles

- Transaction management
- support for Messaging
- support and Integration with Other Frame works.
(Eg: Hibernate, Struts, Tapestry.. etc)

Struts Framework have some advantages
-Excellent support for Tag Library, which has wide industry acceptance.
-Easy to integare with other client side technologies.

It really a subjective matter, what for you want to use them.
both can be combindly used, to take best out of them,
or spring can alone can be used.




whenever develop applicatoion in two ways:
1.Programming through interface
2.Programming through class
Struts drawbacks:

1.better way is Programming through interfaces so that struts not support that(i.e all are predifined class.. Action,DiaspatchAction,SwitchAction)
2.This framework is tightcoupling.it is not separated layerwised
3.It is not Suuport to DependencyInjection
4.We have to hard code to use
applications like hibernate, jdbc, etc.

SPRING:
overcome the above problems Spring will be introduced
Spring Application develop through Interface
It suport DI.
It is layerwise designed.
It is loosecoupling
Spring suport MVC and Other MVC
Spring Application allways flow DesginPatterns
Spring support to POJO'S AND POJI(i.e it is not api dependent)
spring without hard coding in application as spring supports
classes hibernate, jdbc, and many more. This is very little
to say about spring. There are many features to be known.

Are You a Software Architect?

http://www.infoq.com/articles/brown-are-you-a-software-architect;jsessionid=1F983BDB0E1FEBDAC2C9A36C9D822EDA

Maven Phases

Maven Phases
Although hardly a comprehensive list, these are the most common default lifecycle phases executed.
 validate: validate the project is correct and all necessary information is available
 compile: compile the source code of the project
 test: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
 package: take the compiled code and package it in its distributable format, such as a JAR.
 integration-test: process and deploy the package if necessary into an environment where integration tests can be run
 verify: run any checks to verify the package is valid and meets quality criteria
 install: install the package into the local repository, for use as a dependency in other projects locally
 deploy: done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
There are two other Maven lifecycles of note beyond the default list above. They are
 clean: cleans up artifacts created by prior builds
 site: generates site documentation for this project
if we execute the compile phase, the phases that actually get executed are:
1. validate
2. generate-sources
3. process-sources
4. generate-resources
5. process-resources
6. compile

Chain of Responsibility

Chain of Responsibility is a popular technique for organizing the execution of complex processing flows. It is not difficult if you want to write it yourself but Commons Chain has already implemented this pattern for you.

Commons Chain models a computation as a series of "commands" that can be combined into a "chain". The API for a command consists of a single method (execute()), which is passed a "context" parameter containing the dynamic state of the computation, and whose return value is a boolean that determines whether or not processing for the current chain has been completed (true), or whether processing should be delegated to the next command in the chain (false).

E.g., first I create my custom context to be passed around my flows.

import org.apache.commons.chain.impl.ContextBase;

public class MyContext extends ContextBase {
  private String name;
  private String email;

  public String getName() {
      return name;
  }

  public void setName(String name) {
      this.name = name;
  }

  public String getEmail() {
      return email;
  }

  public void setEmail(String email) {
      this.email = email;
  }
}

Then I created my processes, each one as a command.

import org.apache.commons.chain.Command;
import org.apache.commons.chain.Context;

public class Command1 implements Command {

  public boolean execute(Context context) throws Exception {
      System.out.println("First command");
      MyContext myContext = (MyContext)context;
      myContext.setName("twit88");
      return false;
  }
}

import org.apache.commons.chain.Command;
import org.apache.commons.chain.Context;

public class Command2 implements Command {

  public boolean execute(Context context) throws Exception {
      System.out.println("Second command");
      MyContext myContext = (MyContext)context;
      myContext.setEmail("admin@twit88.com");
      return false;
  }
}

import org.apache.commons.chain.Command;
import org.apache.commons.chain.Context;

public class Command3 implements Command {

  public boolean execute(Context context) throws Exception {
      System.out.println("Third command");
      MyContext myContext = (MyContext)context;
      System.out.println("name: " + myContext.getName());
      System.out.println("email: " + myContext.getEmail());
      return false;
  }
}

I defined the sequence of processing in a configuration file.

<catalog>

<!-- Single command "chains"
       from CatalogBaseTestCase -->
<command   name="MyFirstCommand"
      className="Command1"/>
<command   name="MySecondCommand"
      className="Command2"/>
<command   name="MySecondCommand"
      className="Command3"/>

<!-- Chains with nested commands -->

<chain     name="MyFlow">
  <command   id="1"
      className="Command1"/>
  <command   id="2"
      className="Command2"/>
  <command   id="3"
      className="Command3"/>
</chain>

</catalog>

Then I can test it.

import org.apache.commons.chain.Catalog;
import org.apache.commons.chain.Command;
import org.apache.commons.chain.Context;
import org.apache.commons.chain.config.ConfigParser;
import org.apache.commons.chain.impl.CatalogFactoryBase;

public class TestChain {

  private static final String CONFIG_FILE = "/chain.xml";
  private ConfigParser parser;
  private Catalog catalog;

  public TestChain() {
      parser = new ConfigParser();
  }

  public Catalog getCatalog() throws Exception {
      if (catalog == null) {
          parser.parse(
            this.getClass().getResource(CONFIG_FILE));

      }
      catalog = CatalogFactoryBase.getInstance().getCatalog();
      return catalog;
  }

  public static void main(String[] args) throws Exception {
      TestChain chain = new TestChain();
      Catalog catalog = chain.getCatalog();
      Command command = catalog.getCommand("MyFlow");
      Context ctx = new MyContext();
      command.execute(ctx);
  }

}

The output

First command
Second command
Third command
name: twit88
email: admin@twit88.com

Courtsey:
http://twit88.com/blog/2008/03/17/design-pattern-design-a-simple-workflow-using-chain-of-responsibility-pattern/