Index

Difference between Proxy, Decorator, Adaptor, and Bridge Patterns ?

Proxy, Decorator, Adapter, and Bridge are all variations on "wrapping" a class. But their uses are different.

• Proxy could be used when you want to lazy-instantiate an object, or hide the fact that you're calling a remote service, or control access to the object.
  See proxy pattern with details.
• Decorator is also called "Smart Proxy." This is used when you want to add functionality to an object, but not by extending that object's type. This allows you to do so at runtime.
• Adapter / Wrapper is used when you have an abstract interface, and you want to map that interface to another object which has similar functional role, but a different interface.
  In particular Decorator looks very close to Adapter but still there is basic difference:
  

  	Adapter / Wrapper	Decorator
  Composes "origin" class	True	True
  Modifies original interface	True	False
  Modifies behavior of interface	False	True
  Proxies method calls	True	True

   
  See Adapter pattern and Decorator Pattern with examples.
• Bridge is very similar to Adapter, but we call it Bridge when you define both the abstract interface and the underlying implementation. I.e. you're not adapting to some legacy or third-party code, you're the designer of all the code but you need to be able to swap out different implementations.
  See bridge pattern with example.
• Facade is a higher-level (read: simpler) interface to a subsystem of one or more classes. Think of Facade as a sort of container for other objects, as opposed to simply a wrapper. So you don't have to worry about so many things, just call the facade to do all the stuff.
  See Facade pattern with example.

MVC Pattern Basics

Definition
The Model-View-Controller (MVC) architectural pattern is used in software engineering to allow for the separation of three common features in GUI applications:

• the data access (typically via a database)
• the business logic (how the data will be used)
• user interaction (how the data and actions will be visually presented)

MVC pattern differenciates all the 3 aspects of application in 3 difft tiers.

Modal
It incorporates following point

•  Holds the business logic of the application.
•  holds data sent between different. tiers like JSP to servlet and handler classes.
• One of the goals of the model is to give a presentation which does not directly refer to any specific DBMS. 

View

• This represents the visible user interface, so handles presentation tier of the application.
• it knows enough about the data to create a coherent presentation, but does not actually do the work of presenting the data. Instead, it provides the ability to manipulate data outside the View through event handlers defined within. 
• handles presentation logic, client side validation.
• e.g. HTML, JSP

Controller

• handles the flow of the application
• Joins the Model with the View and is the heart of the business logic.
• It is the source of activity when an event occurs and defines the event handling actions which access data (from the Model) and are presented to the user (in the View).
• e.g. Servlets, Action Class in Struts, ActionServlet is using struts-config.xml as front controller to handle each request and redirect it to appropriate destination.

Advantages

•  Increases modularity of the application.
•  Increases Maintainability of the application, i.e.  the data presentation can be changed without any notion of how the data is obtained and conversely, the data access can be changed without any knowledge of how it is to be presented. 

Example
to be added soon

The optimized null check pattern

Data Access Object ( DAO ) Pattern

A data access object (DAO) is an object that provides an abstract interface to some type of database or persistence mechanism, providing some specific operations without exposing details of the database. It provides a mapping from application calls to the persistence layer.

A typical DAO implementation has the following components:

• A DAO interface
• A concrete class that implements the DAO interface
• Entities OR Data transfer objects (sometimes called value objects)

Seeing all the components with the Example

Entity

Order.java

public class Order{
    private int id;
    private String customerName;
    private Date date;
 
    public int getId() { return id; }
    public void setId(int id) { this.id = id; }
 
    public String getCustomerName() { return customerName; }
    public void setCustomerName(String customerName) {  

          this.customerName = customerName;  

    }
 
    public Date getDate() { return date; }
    public void setDate(Date date) { this.date = date;}
}

DAO interface
OrderDao.java
Get the interface for Create Retrieve Update and Delete operations.

//holds all CRUD behaviours
public interface OrderDao {
      void create(Order entity);
      Order findById(int id) throws OrderDontExistException;
      void update(Order entity);
      void delete(Order entity);      
}

DAO Implementation
OrderDaoImpl.java
This just takes the datasource object and stores all the queries related to Order object. I am just implementing finById method for simplicity.

public abstract class OrderDaoImpl implements OrderDao {
    
        DataSource ds;
    public OrderDaoImpl(DataSource ds_) {
        ds = ds_;
        
    }
 
    public void create(Order entity) { //do something }
  
    public E findById(int id) throws OrderDontExistException { 
       String sqlFindById = "select * from ORDERS where id=?";    
       Connection con = getConnectionFromDataSource(ds);
      PreparedStatement ps= con.prepareStatement(sqlFindById);;
         ps.setInt(1, id);
      ResultSet rs = ps.execute(); 
      //process result set 
       Order order = rs.getString("Name");
        //... so on
       
        return order;   
        }

    public void update(Order entity) { //do something }

    public void delete(Order entity) { //do something }

}

Exception class

package authordao;



public class OrderDontExistException extends Exception {


    public OrderDontExistException() {

        // TODO Auto-generated constructor stub

    }


    public OrderDontExistException(String message) {

        super(message);

        // TODO Auto-generated constructor stub

    }


    public OrderDontExistException(Throwable cause) {

        super(cause);

        // TODO Auto-generated constructor stub

    }


    public DAOException(String message, Throwable cause) {

        super(message, cause);

        // TODO Auto-generated constructor stub

    }


}

Using the Dao

OrderDao dao = new OrderDaoImpl(ds);
Order order = dao.findById(id);
//Now do some business logic

Conclusion
As this article has shown, implementing the DAO pattern entails more than just writing low-level data access code. You can start building better DAOs today by choosing a transaction demarcation strategy that is appropriate for your application, by incorporating logging in your DAO classes, and by following a few simple guidelines for exception handling.

Exception transformer pattern

Checked exceptions are widespread in Java. Imagine the situation where you are calling numerous methods on a class (say for the sake of serving as an example: a service class) each of which throws a checked exception (say ServiceException).

class Service {

    static class ServiceException extends Exception {}

    void serviceMethod1() throws ServiceException {}
    void serviceMethod2() throws ServiceException {}

}

Client with repetitive error handling logic
Your class as a client now has to deal with this exception every time you call a service method and also for every different method you call.

public class Client {

    private Service service;

    void callServiceMethod1Normally() {
        try {
            service.serviceMethod1();
        } catch (ServiceException e) {
            throw new RuntimeException("calling service method 1 failed", e);
        }
    }

    void callServiceMethod2Normally() {
        try {
            service.serviceMethod2();
        } catch (ServiceException e) {
            throw new RuntimeException("calling service method 2 failed", e);
        }
    }

}

Exception transformer abstraction

However your exception handling strategy may be the same across your use of the service class only with a different message each time. Instead of repetitively duplicating your exception handling logic (try/catch) around every service call you can abstract this out as follows. The following class abstracts the logic out. Note that this class is only shown as a separate class for the purposes of incrementally describing the pattern. For best effect this class should ideally be contained within your client class as a static inner class.

public abstract class ExceptionTransformer {

    abstract void call() throws ServiceException;

    void transform(String message) {
        try {
            call();
        } catch (ServiceException e) {
            throw new RuntimeException(message, e);
        }
    }

}

New client using exception transformer

Now using the new exception transformer our exception handling logic is simplified to only the logic that differs between the client methods.

class ClientUsingExceptionTransformer {

    private Service service;

    void callServiceMethod1UsingTransformer() {
        new ExceptionTransformer() {
            @Override
            void call() throws ServiceException {
                service.serviceMethod1();
            }
        }.transform("calling service method 1 failed");
    }

    void callServiceMethod2UsingTransformer() {
        new ExceptionTransformer() {
            @Override
            void call() throws ServiceException {
                service.serviceMethod2();
            }
        }.transform("calling service method 2 failed");
    }

}

Variation

This pattern can be easily varied to suit your personal exception handling styles. Here’s another variation where different checked exceptions are thrown by different service methods and handled by only logging them this time.

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

class ClientWithVariations {

    static final Logger logger = LoggerFactory.getLogger(ClientWithVariations.class);

    static class Service {

        static class ServiceHungry extends Exception {}
        static class ServiceSleepy extends Exception {}

        void hungryMethod() throws ServiceHungry {}
        void sleepyMethod() throws ServiceSleepy {}

    }

    private Service service;

    void callHungryMethod() {
        new ExceptionTransformer() {
            @Override
            void call() throws Exception {
                service.hungryMethod();
            }
        }.transform("method was too hungry to respond :(");
    }

    void callSleepyMethod() {
        new ExceptionTransformer() {
            @Override
            void call() throws Exception {
                service.sleepyMethod();
            }
        }.transform("method was too sleepy to respond :(");
    }

    static abstract class ExceptionTransformer {

        abstract void call() throws Exception;

        void transform(String message) {
            try {
                call();
            } catch (Exception e) {
                logger.error(message, e);
            }
        }

    }

}

This pattern really shows its value most effectively when you have numerous methods using it and also when there are multiple checked exceptions to handle resulting in multiple catch blocks all over the place.
Do you have any exception handling API patterns of your own? I know Joshua Bloch has suggested a few in Effective Java of which one comes to mind – an exception throwing method can be transformed into a boolean via another method which just returns false in the catch block and true elsewhere that can be quite useful if you don’t want to pollute the rest of the code with knowledge of this handling logic. By the way, before anyone mentions this I’m not suggesting converting checked exceptions to runtime exceptions or suppressing them by logging them is always the right thing to do. Thanks for reading.
P.S. This pattern will be particularly nice with closures in Java 8. And the multicatch in Java 7 will certainly also help make code more concise.

Fine grained and coarse grained objects

Some differences between fine grained and coarse grained objects:

• If object composition is based on Object references (not one for one attribute) , then its Coarse grained . If object composition is based on attributes, then its fine-grained.
• If there is one table to one object mapping, then its fine grained. If there is one object to more than one table, then its coarse grained.
• If the object holds lot of information it is coarse grained. eg. Example: A single "Account" object holds the customer name, address, account balance, opening date, last change date, etc.
  
  Fine-grained: More objects each holding less data. Example: An Account object holds balance, a Customer object holds name and address, a AccountOpenings object holds opening date, etc. There are relationships defined between these objects.
   

Note:
May be I am wrong but what I was thinking, coarse object means a big object, that has much responsibility. For example, suppose we are designing a system and we have identified logical entities (business domain objects) (I am not sure, it is right term or not) and now we want to come up with java classes corresponding to those. So should we try to map one entity to one java class (coarse object) or try that one entity should include many classes (each one will be fine object). However if we have really big object, facade pattern do help by bringing infront the small object with which we have to deal with.