Shallow copy and deep copy in prototype patterns?

There are two types of cloning for prototype patterns. One is the shallow cloning which you have just read in the first question. In shallow copy only that object is cloned, any objects containing in that object is not cloned. For instance consider the figure ‘Deep cloning in action’ we have a customer class and we have an address class aggregated inside the customer class. ‘MemberWiseClone’ will only clone the customer class ‘ClsCustomer’ but not the ‘ClsAddress’ class. So we added the ‘MemberWiseClone’ function in the address class also. Now when we call the ‘getClone’ function we call the parent cloning function and also the child cloning function, which leads to cloning of the complete object. When the parent objects are cloned with their containing objects it’s called as deep cloning and when only the parent is clones its termed as shallow cloning.

Builder pattern in Java

Builder falls under the type of creational pattern category. Builder pattern helps us to separate the construction of a complex object from its representation so that the same construction process can create different representations. Builder pattern is useful when the construction of the object is very complex. The main objective is to separate the construction of objects and their representations. If we are able to separate the construction and representation, we can then get many representations from the same construction.

Figure: – Builder concept

To understand what we mean by construction and representation lets take the example of the below ‘Tea preparation’ sequence.

You can see from the figure ‘Tea preparation’ from the same preparation steps we can get three representation of tea’s (i.e. Tea with out sugar, tea with sugar / milk and tea with out milk).

Figure: – Tea preparation

Now let’s take a real time example in software world to see how builder can separate the complex creation and its representation. Consider we have application where we need the same report to be displayed in either ‘PDF’ or ‘EXCEL’ format. Figure ‘Request a report’ shows the series of steps to achieve the same. Depending on report type a new report is created, report type is set, headers and footers of the report are set and finally we get the report for display.

 

Figure: – Request a report

Now let’s take a different view of the problem as shown in figure ‘Different View’. The same flow defined in ‘Request a report’ is now analyzed in representations and common construction. The construction process is same for both the types of reports but they result in different representations.

Figure: – Different View

We will take the same report problem and try to solve the same using builder patterns. There are three main parts when you want to implement builder patterns.

• Builder: – Builder is responsible for defining the construction process for individual parts. Builder has those individual processes to initialize and configure the product.
• Director: – Director takes those individual processes from the builder and defines the sequence to build the product.
• Product: – Product is the final object which is produced from the builder and director coordination.

First let’s have a look at the builder class hierarchy. We have a abstract class called as ‘ReportBuilder’ from which custom builders like ‘ReportPDF’ builder and ‘ReportEXCEL’ builder will be built.

 

Figure: – Builder class hierarchy

Figure ‘Builder classes in actual code’ shows the methods of the classes. To generate report we need to first Create a new report, set the report type (to EXCEL or PDF) , set report headers , set the report footers and finally get the report. We have defined two custom builders one for ‘PDF’ (ReportPDF) and other for ‘EXCEL’ (ReportExcel). These two custom builders define there own process according to the report type.

Figure: – Builder classes in actual code

Now let’s understand how director will work. Class ‘clsDirector’ takes the builder and calls the individual method process in a sequential manner. So director is like a driver who takes all the individual processes and calls them in sequential manner to generate the final product, which is the report in this case. Figure ‘Director in action’ shows how the method ‘MakeReport’ calls the individual process to generate the report product by PDF or EXCEL.

The third component in the builder is the product which is nothing but the report class in this case.

 

Figure: – The report class

Now let’s take a top view of the builder project. Figure ‘Client,builder,director and product’ shows how they work to achieve the builder pattern. Client creates the object of the director class and passes the appropriate builder to initialize the product. Depending on the builder the product is initialized/created and finally sent to the client.

Figure: – Client, builder, director and product 

The output is something like this. We can see two report types displayed with their headers according to the builder.

Figure: – Final output of builder

 

 

Source -http://ashishkhandelwal.arkutil.com/?p=1076

Pin it

Singleton Pattern – Design Patterns in Java

The Singleton Pattern Ensure a class only has one instance, and provide a global point of access to it.For example ,if we need a connection to single database at one time  or when ever we are referring to to single application.properties file in struts application for showing application in one language at one time.Then we can need of singleton pattern or you can use it to create a connection pool. It’s not wise to create a new connection every time a program needs to write something to a database; instead, a connection or a set of connections that are already a pool can be instantiated using the Singleton pattern.

Need of Singleton Pattern

– Sometimes we want just a single instance of a class to exist in the system

– We need to have that one instance easily accessible

– And we want to ensure that additional instances of the class can not be created

Benefits of Pattern

– Controlled access to sole instance

– Permits a variable number of instances

How we can Implement singleton pattern

We will be using statis method to call the client to get a reference to the

single instance and we’ll use a private constructor

/* SingletonHolder is loaded on the first execution of Singleton.getInstance()
* or the first access to SingletonHolder.INSTANCE, not before.
*/

public class VinaySingleton {

private static VinaySingleton  VINAYINSTANCE ;

private VinaySingleton() {
}

public static VinaySingleton  getInstance() {
if(VINAYINSTANCE ==null){
VINAYINSTANCE = new VinaySingleton();
}

return VINAYINSTANCE;

}

We will be having private constructor which tells that no other outside classes can directly instantiate this class. The only way to get a reference to the VinaySingleton object is to make a call to the static method VinaySingleton.getInstance ().Similarly create Myconnection class and method as above


Even if client call the VinaySingleton.getInstance multiple time the multiple object will point to same reference.

package techartifact.pattern.singleton;
public class VinayClient {
public static void main(String[] args) {

 VinaySingleton i1 = VinaySingleton.getInstance();
 MyConnection i2 = MyConnection.getInstance();

 if (i1 == i2){
System.out.println("Both the object pointing to same reference");
 }else{
System.out.println("Objects are not equal");
}
 }
}