Factory and Abstract Factory:

In factory we have to provide a FactoryClass that can construct different products. The product type that needs to be constructed is usually specified in the argument for the factory method, or a different method for each product can be specified pushing the responsibility onto the client modules to invoke the right product.

Suppose we have three products A,B and C. And lets have a factory class F. F can have either createProduct(argument) or createA(); createB(); createC() implementations.

One disadvantage with this approach is that it does not allow for extensibility. Every time we need to add a new product code we end up changing the code in Factory class. Lets say if there is new product D, then we’ll have to add a new method createD() or change the code for createProduct(). But, if we can have a class called product (assuming all A,B,C and D are of same type) and if we can classify A,B,C and D as Product, then by having a separate factory class for A, B or C will allow in future to just add any new factory class for a new product with out touching the existing code. So, it will be A, B, C, D, E…..

Allowing clients to specify their concrete factory class, allows to add new client code that uses new ProductFactory with minimal effort. For this to work we generally declare earlier ProductFactory as an Abstract class, as it really does not create any classes, and all Afactory, Bfactory…. As concrete factories.
Each concrete factory creates its product type and abstract factory refers to abstract product. I guess there is no need to say that this is AbstractFactory.

Sruts 2 for dummies
Sruts 2 for dummies

Requests:

Struts 2 uses OpenSymphony's WebWorks and XWorks frameworks. XWorks frameworks implements IOC (Inversion Of Control) framework, thus decoupling
command receivers from originators. Its an extension to the Command Pattern from Struts 1.x to additionally allow the Action objects to be independent of
the HTTPServletRequest/Response. It all looks rather complex initially but it is very trivial... Just following two tips would help.

1) When using command pattern instead of receivers requiring to implement interface with execute(param1, param2, ....), let them
implement just execute() without any arguments. Now send these arguments to the receiver via hashmap. in global visibility.

Receiver if interested in request parameters can request them using singleton object ActionContext.

2) Now if ActionContext is a singleton, how to chain ActionContext. For this the framework, uses concept similar to Stack.
Every ActionProxy (not exactly Action, to remove burden from us) saves its ActionContext (or caches locally) in a local variable before calling a next Action. At the end of the Action,
it restores its ActionContext. This is not tough, just ...

Save ActionContext;
try {
ActionInvocation.Action...
} catch () {}
Finally
{
restore ActionContext;
}


Two direct advantages of this IOC approach are:

1) Filters as per Aspect Oriented Programming (AOP) need not require to implement the delegation model where they dispatch the request using chain pattern.
Similary while receiving response.

2) Unit testing of the actions is simplified as they are independent of container related parameters.


Return Values from Actions.

Earlier in Struts 1.x all actions used to explicitly add results to request,session ( for pull model of Model 2 Architecture ) to allow view to access the return values or access to the model objects
But if there is no direct access to HTTPRequest for Action objects, how can they access them. Well they can still get them using the ActionContext right. Struts 2 also uses OGNL notation to allow to retrieve
responses or model objects using stack. As Actions are being executed in a chain pattern (like I said earlier the stack model), the responses will also be available in the stack model. The last action in the ActionChain
will save the objects at the bottom of the stack (or at the top ?). OGNL allows objects to be retrieved using a notation convenient to use in templates/views. such as top, indexed notation etc.