eSoftHead, a Vietnam Software Outsourcing Company» Object Oriented and Design

Object caching using Spring, Ehcache

admin — Wed, 22 Apr 2009 21:56:37 +0000

Caching is quite important to boost the application performance. There are many cache libraries in Java world, both commercial and open source. You should choose the existing library instead creating your own library. I see some guys in my previous companies develop their own cache, and it is not good for their project. Instead of spending time on project business features, guy spent much time to create the perfect library and maintain it through the project life cycle. Another case is using the Map and its relative classes for caching, it makes the application could not scalable and it does not provide the flexible caching mechanism the cache should have. Of course, we need to create the cache library if there is no good one in the market, but it is not true. There are many good cache libraries in Java world, one of them is Ehcache (http://ehcache.sourceforge.net/). Ehcache is the excellent library provides to community with high quality, good documentation, simple use and wide adoption by other popular frameworks. It takes development team 5-10 minutes to set up the caching (of course, if you are fresher you must spend more time to understand the caching mechanism), so why you do not use such library instead of creating your own library?

In our application, we use Spring as IoC container, though set up the Ehcache manager is the easy task but we would like to use it with our Spring beans and exposed it as Osgi service. Spring modules is the good library help us easy in configuration. It provides the consistent abstraction caching to our application, hence we can use our cache facade with other caching libraries such as JBoss cache, JCS, OScache without chaging our application code. You could download the Spring Modules at https://springmodules.dev.java.net/.

Here are the following steps to configure Ehcache in Spring application

Configuring caching via ehcache.xml file

http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="ehcache.xsd">

Declarating Ehcache in Spring context


 
  classpath:ehcache.xml

Programmatic use

Using ehcache is so simple, a unit test to make the test whether configuration is set up correctly and take the simple put/get could explain all.

@RunWith(EngroupClassRunner.class)
@ContextConfiguration(locations = { "/META-INF/spring/cache-context.xml" })
public class CacheTest {
    @Autowired
    protected CacheProviderFacade cacheProviderFacade;

    @Test
    public void testCacheConfiguration() {
        Assert.assertNotNull(cacheProviderFacade);

        EhCacheCachingModel model = new EhCacheCachingModel();
        model.setCacheName("engroupCache");

        cacheProviderFacade.putInCache("a", model, new Integer(1));
        Integer fromCache = (Integer) cacheProviderFacade.getFromCache("a",
                model);
        Assert.assertEquals(new Integer(1), fromCache);
    }
}

Besides of using ehcache to create the session like variable in our application, we would like to use ehcache to cache SQL statement in iBatis and integrate with Terracotta to complete our distributing caching solution in our future project. I will keep the post on further caching usage in future posts. Keep reading!

Share and Enjoy:

Integration of Jackrabbit OCM and Spring (updated version)

admin — Thu, 26 Mar 2009 10:04:09 +0000

In the previous post Jackrabbit OCM and Spring, I have outlined the way of integrating between Jacckrabbit OCM (jackrabbit 1.5.0-snapshot) and Spring. The time flies help us have more JCR knowledge, jackrabbit api becomes more stable and our Engroup ECM implementation is changed. Instead of creating the total new JCR node types for our domain classes in the previous version, we extends our node types base on the standard JCR node types as nt:file, nt:folder. In addition, our unit test is re-written for simpleness and make higher coverage rate.
You can download our example in example zip file with note that this example is the cut-off version of Engroup ECM API that limits handling simple file, folder instances. Because Engroup runs on Osgi platform, and we already
packaged our libraries as Osgi bundles. To reduce our efforts in editing this cut-off version, we use our libraries
at http://engroup.sourceforge.net/maven2/ instead the libraries in standard maven repository. It will takes your time to download Engroup libraries at the first time.

Basic Jackrabbit OCM and Spring configuration

 
     
     
         
             
             
             
                 
             
         
     
     
     
         
             http://esofthead.com/engroup

Declaring annotation classes


    
        
            com.engroup.module.ecm.domain.Content
            com.engroup.module.ecm.domain.File
            com.engroup.module.ecm.domain.Folder
            com.engroup.module.ecm.domain.Resource

Transaction support

 
     
 
 
     
         
     
     
         
             PROPAGATION_REQUIRED
             PROPAGATION_REQUIRED,readonly

 
     
     
         
             com.engroup.module.ecm.service.FileSystemService
         
      
      
          
      
      
          
              PROPAGATION_REQUIRED

Custom JCR node types

Depends on your context, you could want to write custom JCR node types such as add description field into File class. Fairly easy to do so by declaring custom node types in custom_nodetypes_test.xml file:



    
        nt:base
    
    
  

 
     
         nt:hierarchyNode

Writing unit test

Unit test is our standard and it is time to write some test cases to test Engroup ECM API. We will use the Spring
Test Framework to test our spring bean. One more concern is choosing appropriate Jackrabbit Persistent Manager for
testing. Jackrabbit supports various Persistent Manager such as File System, Database, InMemory. In our product, we
use Database Persistent Manager, but for testing purpose the InMemory Persistent Manager is the good choice for fast
and cleaning data after running test. You could configure it in Jackrabbit configuration file


...Workspace section
    
        
    
...Version section

Write FileSystemService unit test:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "/ecm-context-test.xml" })
public class FileSystemServiceTest {
    @Autowired
    @Qualifier("proxy")
    protected FileSystemService fileSystemService;
...
}

And add some test method:

@Test
public void testUpdateFileWithVersion() {
    Resource resource = new Resource();
    resource.setData(new ByteArrayInputStream("this is the content"
            .getBytes()));
    resource.setLastModified(Calendar.getInstance());
    resource.setMimeType("plain/text");
    File file = new File();
    file.setPath("/A");
    file.setResource(resource);
    fileSystemService.save(file);

    Resource resource2 = new Resource();
    resource2.setData(new ByteArrayInputStream("this is the content 2"
            .getBytes()));
    resource2.setLastModified(Calendar.getInstance());
    resource2.setMimeType("plain/x");
    file.setResource(resource2);
    fileSystemService.update(file);
    Collection versions = fileSystemService
            .getVersionHistory(ContentConstants.FILE_ROOT_PATH + "/A");
    Assert.assertEquals(2, versions.size());
    File latestFileVersion = fileSystemService.getFileByVersion(
            ContentConstants.FILE_ROOT_PATH + "/A", "1.0");
    Assert.assertEquals("plain/x", latestFileVersion.getResource()
            .getMimeType());
    fileSystemService.remove(file);
}

You could download the example, see more details how to integrate Jackrabbit OCM and Spring, run the test and provide your feedbacks if any.

Source code

Share and Enjoy:

Template architecture for software rapid development – part 1

admin — Tue, 12 Jun 2007 01:45:30 +0000

To inspire my two previous posts are 'MVC pattern: Controller is too big' and 'Template projects in software development'., the current post is written base on my deeper thinking how to create the re-usable artifacts in a software company. More ideas are completed after my study on Software Product Line and Software Factories. I will write two posts about the template architecture, the first post is the introduction about the needs and benefits of template architecture, the second post is my suggestion of building template architecture and how to manage it via knowledge management system.

First, we go to the common related technical problems

1. Lack high technical skilled resources

In the resource market, there are just rare high technical skilled resources who has experience of developing architecture, design for various kinds of project and technologies. In Software Company, the ratio of technical architectures resource also is less than the needs of organization.

2. Re-discovering and Re-inventing common solution domain

Solution domain is discovered or invented in other product is not distributed to related products in a product line. Organization takes a lot effort for re-create solution for problem that is solved before, the solution can catch the traps of previous ones or the quality is not good enough.

3. Monolithic Construction - No reusable components

Not only solution domain is not kept in all products in product line but reusable components across products, product lines are not defined. In addition, organization does not have strategy of defining the re-use level of component, what is reused and how it is re-used. The rigid architecture is also the reason cause all components in one product are heavily tight, that cause its components can not be used separately and it is hard to bring one component to other products except bring many related components (but they are not related business domain of new product) and perform tuning code for new products.

4. Inefficient of R&D activities

Nowadays, there are many methodologies, toolkits, frameworks that help development members can increase their productivity and organization can deliver the better quality product with competitive cost. Normally, the cost for R&D occupies 2-3% operation cost of organization and it is not much cost to have the outstanding result especially in small-medium size company. In any company, focusing on some specific technologies and tools is the wise approach to strengthen organization knowledge instead of assigning limited number of resources to research many tools, frameworks

Long time ago, software organizations realize that some components can be re-used across projects and they define the process that promote re-usability of software artifacts, they are documentation, architecture, module, components or API library. However, lacking the good process also the criteria, guidelines, strategy for creating reusable artifacts take many companies effort without the valuable result. By categorizing projects into separated product lines that helps software company can limit the number of product lines they are developing also define the better strategy for reuse. The reusability is not limited in API library, component etc but the group of products that share the similar business domain or architecture, technology. Product lines is the rather new terminology and there are only few resources about it, recently Software Factories term are raised many times and it has different meaning to Product Line though it is derived from Product Line. However both of them promote the reusability of software artifacts.

Product lines introduction

According to [9], Software product lines represent a significant departure from software reuse schemes in which attempts are made to make assets as general as possible without the context provided by an architecture and a scope definition, and from opportunistic reuse schemes in which low-payoff assets are scavenged adhoc from a reuse repository.

Product lines pay off because the investment in the core assets is allocated across the entire family of products. The core assets provide a production capability that allows rapid construction of high-quality products.

Build a product line is a complicated task. In general, it takes a long time for building a set of related products especially it is true for outsource company that usually not control what products they will receive in future. Though maintain the business modeling across the products in one product line is difficult but the task that maintain the architecture also the reusable components in one product line is simpler. One template architecture is applied for one product line that is distinguished to others by architecture, technology also the domain knowledge. One template architecture consists:

Architecture design:

Software patterns: Integration patterns, design patterns, infrastructure patterns.
Object Oriented Principles: Open-Closed principles, Liskov principles, etc

Domain knowledge(s): Healthcare, eLearning, Telecom, etc

Technology and Platforms:

Operating system: Windows, Linux, …
Platform: Java, .NET, etc and its version platform.

Re-usable components:

Common API: validation, logging, caching etc
Domain API: HL7 (Healthcare), Barcode, EDI etc

Development workspace:

Tools: are used to build product base on template architecture. That includes development tool, build tool and deploy tool.
Guidelines: document guides people how to build product base on template architecture. It includes using common patterns, object oriented principles also usage of common and domain API. In addition, it also guides the usage of tools or practices of implementing on specific problem domain.
Samples: it guides development in practice via samples for basic problem that can serve to solve harder domain problem.

There are two things need to be considered, they are domain knowledge (that belong to business area) and technical artifacts like architecture, components (that belongs to technical area). One architecture that fit with one domain also it depends on deployment model. Two template architectures can reuse the same artifacts, such as two healthcare applications on window and web environment can share the components like HL7, EDI etc but they can have different software patterns for separated deployment model.

Benefits of template architecture

1. Increase productivity

The easiest thing we can see that productivity is increased, the cost is decreased. Development team members do not need to create or implementation from scratch, but they develop base on an existing TA that have guidelines, best practices also expert can support them use the TA.

2. Predictable result, higher quality

Due to TA is built by experienced technical geeks, also it is contributed by many real practices from previous projects, the feasible of solution or architecture are proven that make any solution base on TA is predictable and it has good quality

3. Re-use of skills, resources

Lack of high technical resources also they are many frameworks, toolkits, etc that has the same functionalities cause R&D is difficult to define what area they should focus in. By fixing with one solution for one kind of problem that cause organization gather all efforts for this problem instead of dispersing its effort. Members also learn the best tools, best practices of solution and have deep knowledge on it instead that they know many functional areas but only introduction level.

4. Competitive advantage

It is obvious that if one organization can provide the good solution to client, deliver the high quality product and the cost is competitive, that company has competitive advantage compare with its opponent.

5. Resource allocation

By simple usage of Template Architecture also it contains guidelines, practices. That free some experienced technical geeks outside project development. Team members can develop application base on Template Architecture, which are very easier to detect any violations to architecture and implementation. The experienced technical geeks can be assigned to more important tasks such as mentor technical activities, building other template architecture.

Reference

[1], Nguyen Phuc Hai – Template projects in Software Development, http://www.haiphucnguyen.net/blog/?p=36

[2], Nguyen Phuc Hai – MVC Pattern: Controller is too big, http://www.haiphucnguyen.net/blog/?p=42

[3], Software Factories – http://www.softwarefactories.com/

[4], Edward Bakker – Factories 201, http://www.edwardbakker.nl/

[5], Spring Framework, http://www.springframework.org

[6], Spring Modules, https://springmodules.dev.java.net/

[7], Enterprise Library 3.0 – April 2007, Documentation

[8], Jezz Santos - Factories’ ABC, http://blogs.msdn.com/jezzsa/archive/2006/08/09/sfxjargon.aspx

[9], Software Engineering Institute – Software Product Lines, http://www.sei.cmu.edu/productlines/

[10], Gunther Lenz and Christoph Wienands - Practical Software Factories in .NET

[11], Jack Greenfield, Keith Short et al – Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools

Share and Enjoy:

MVC pattern: Controller is too big!

admin — Fri, 04 May 2007 01:35:31 +0000

All software engineers know the MVC pattern also it is applied in various projects from standalone to web or distributed application. However, while many Software Engineers have different view on Controller layer and many cases it is not managed well because the Controller layer must do many things and it is too big for maintenance! I just copy the definition of MVC pattern here from Wikipedia (http://en.wikipedia.org/wiki/Model-view-controller)

Model: The domain-specific representation of the information on which the application operates. It is a common misconception that the model is another name for the domain layer. Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes and shipping charges for shopping cart items).; Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.
View: Renders the model into a form suitable for interaction, typically a user interface element.
Controller: Processes and responds to events, typically user actions, may invoke changes on the model.

Model and View is easily understand and be maintainable. However, when the TA define the architecture of some specific project, the Controller layer tends to become more complex when the project's size is increased. Base on the standard application, the controller will do:

Binding the data from view layer to entity objects.
Format data.
Validate the constraints (data constraints, application constraints and business constraints)
Manage variables scope
Manage the transactions
Execute business logics
Call data access layer and save model to persistent place (database for example).

Many tasks are handled in the typical MVC pattern architecture while view and model layer is rather simple and understandable. That is the root cause make some project apply the MVC pattern but still cause the bad quality on architecture. Let's dive in some specific code with me on typical Controller class:

public void execute (...args) {

//Binding parameters from view to entity model

//Format data if any

Date d = DateFormater.format (str);

...

//Validate the constraints

Validator.validator (entity);

// Manage transactions

Transaction.begin();

...

processBusinessRules() {

...

dao.save(entity);

}

...

Transaction.end();

}

The code should be cleaner if we separate the execute methods into several smaller ones. However, the Controller class has many reasons for change. If you need to change the validation rules, you will modify the Controller class. If you need to change the business rule, you also need to modify the Controller class etc. So for each responsibility of Controller layer must do, the architecture should divide it into separate classes, each class only has one reason to change that means each class has only one responsibility.

Base on the above advise, I will have the following interface for each responsibility define above:

IValidator: responsible for validation
ITransactionManager: responsible for transaction management
IService: responsible for specific processing business service
IDao: responsible for saving entity model to persistent storage.
...

Next, the Controller class will combine all classes (instead methods as above example) in one place, so I have the interface IController that makes the Controller layer has tigh coupling with View layer. For specific Controller class, I generalize the overall business processing base on the template method:

class ControllerTemplate implements IController {

IValidator validator;

IService service;

...

public void execute(...args) {

binding.bind(args);

validator.validator(entity);

formater.format(entity)

transaction.begin();

businessHandle();

transaction.end();

}

//need to be overidde

protected void businessHandle();

}

It should be better, if I only need to change the way of binding data, I only modify the Binding class and I do not care about the change will break the rest. The design looks more better and easily maintainable. It could be cause better to make the above class Validator, Formatter, Controller, Service object etc are independent by using some IoC container such as Spring, IoC, Guice ...We have the similar approach in Spring MVC but I do not see the similar approach in standalone application. Forgive me, I do not follow standalone application trends for rather long time , but applying Spring or Guice framework you can make the same thing easily in standalone environment.

Share and Enjoy:

Validation with Bean Validation Framework

admin — Fri, 04 May 2007 01:34:11 +0000

Spring framework provide the nice approach of validation that separate with the main business with validation. There are 3 ways of validation supported by Spring framework, they are: Common Validator, Valang (Va-lidation Lang-uage) Validator and Bean Framework Validator. According to me, Bean Framework Validator is the best among these approaches because it is more flexible, more powerful (support more types of validation Domain Model Constraints, Business Rules and Application Constraints besides Data Constraints). Bean Validation Framework provide the way to enhance its capacity, however you rarely need to enhance because it provides enough data constraint validation in almost cases. Compare with Hibernate Annotation, Bean Framework Validation also gain my vote per its advantages. One more reason that I choose Bean Validation Framework in my project that it supports XML declaration instead using annotations (though it support annotation too) because my beans are generated automatically and the Netbeans can not know to data constraint base on database schema.

Using Bean Validation Framework is rather easy, you declare the validation in spring context file and that is. Here is the sample of my context file:

class="ows.security.controller.RegisterUserController">

value="ows.security.admin.domain.UserDTO" />

Note that the bean name configurationLoader has resource property that makes you define the validation file for bean, in my case I put it in the folder beanValidation under classpath property. Here is the content of userDTOValidation.xml

http://www.springmodules.org/validation/bean"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springmodules.org/validation/bean
http://www.springmodules.org/validation/bean/validation.xsd">

Remember you installed the spring modules before, and it is the only one reminder to use this nice framework

Share and Enjoy:

OO design principles

admin — Fri, 19 Jan 2007 18:37:12 +0000

For any evaluation of architecture, the natural question is raised whether the architecture is good and the common criteria to assess this quality is not common for all reviewers. You can have some:

- It seems that the coding standard are not followed well –> Wrong assessment due to quality of design is not related to coding standard.

- The performance of system is great –> The performance result is not the main factor of evaluating system performance, of course the bad quality can cause the impact to system performance.

- The architecture is designed very complicated and it is created by a “guru” guy –> the complicated is the signal of bad design, we have no design for prediction purpose and the fame of some one is not the main factor to decide the quality of design.

- The architecture applies many well-known pattern in practices –> You know that the patterns are applied correctly depends on the context of business scenario. No one pattern is right for all cases.

Well, after reading my arguments, you will ask me what are the criteria to assess the quality of architecture. I just can say “The architecture is designed with high quality if they are followed object oriented design principles”. Pattern is described is GoF books or any ones must be follow the design principles/practices. Any violate can cause the quality of design becomes bad. Here are the design principles that are described detail on Object Mentor

The Open/Closed Principle: Software entities (classes, modules, etc) should be open for extension, but closed for modification.
The Liskov Substitution Principle: Derived classes must be usable through the base class interface without the need for the user to know the difference.
The Dependency Inversion Principle: Details should depend upon abstractions. Abstractions should not depend upon details.
The Interface Segregation Principle: Many client specific interfaces are better than one general purpose interface/
The Reuse/Release Equivalency Principle: The granule of reuse is the same as the granule of release. Only components that are released through a tracking system can be effectively reused.
The Common Closure Principle: Classes that change together, belong together.
The Common Reuse Principle: CClasses that aren’t reused together should not be grouped together.
The Acyclic Dependencies Principle: The dependency structure for released components must be a directed acyclic graph. There can be no cycles.
The Stable Dependencies Principle: Dependencies between released categories must run in the direction of stability. The dependee must be more stable than the depender.
The Stable Abstractions Principle: The more stable a class category is, the more it must consist of abstract classes. A completely stable category should consist of nothing but abstract classes.

Share and Enjoy:

Do we need to use Dependency injection pattern?

admin — Mon, 25 Dec 2006 18:25:35 +0000

Dependency injection pattern becomes popular recent years. But what is the root cause of this event and do you really need to use this pattern in your work? I know this pattern when my friend introduce me the Pico container and the article written by Martin Fowler (you can read it here). In the first read, I am impressed with what Martin said and what I did immediately after that is trying the frameworks is discussed in his article. Two years later, it is time for me to write some notes about this pattern after several real practices of applying it to my work.
Let's go with me and the simple example that all you know as the common first program "Hello world". I will illustrate ideas via Java program languages but it is also applied for any OO languages, especially for .NET.

Example 1: Hello world program

public class Helloworld {
  public static void main(string[] args) {
    System.out.println(“Hello world”);
  }
}

This program is simple, right? And it does not represent any OO idea. But when the requirement changes that you need support the ‘Hello world’ program for multiple languages. The natural approach is separating class HelloWorld to separated classes.

Example 2: Re-writing 'Hello world' program
This program is very simple, right? And it does not represent any OO idea in source code. But when the requirement changes, it says that you need support the "Hello World" program for multiple languages. The natural approach is separating the class HelloWorld into separated classes.

public interface HelloWorld {
  public void sayHello();
} 
 
public class HelloworldEng implements Helloworld {
  public void sayHello() {
    System.out.println("Hello world");
  }
} 
 
public class TestProgram {
  public static void main(String[] args) {
    HelloWorld helloworld = new HelloWordEng();
    helloworld.sayHello();
  }
}

Such program is better than the original but if user want to change the 'Hello world' message to another language we must modify the source code of TestProgram.java. It is violated with 'Open Closed principle'. What should we do now?

In fact to reduce the coupling between TestProgram and HelloWorld classes, we have two approaches. One is using Abstract Factory pattern and one is using Dependency Injection framework. If we use the first approach, the program is written like this

public class TestProgram {
  public static void main(string[] args) {
    Helloworld hello = HelloWordFactory.createHelloInstance();
    hello.sayHello();
  }
}

public class HelloworldFactory {
  public Helloworld createHelloInstance() {
    //using reflection to load the Helloworld instance via
    //application property
    String className = System.getProperty("helloworld.instance");
    Class c = Class.forName(className);
    ..
  }
}

Using abstract factory method, whenever you need to change the implementation of Helloworld instance, you only need to modify the application property to the Helloworld implementation class name. This makes the TestProgram and Helloworld implementation are not relative and we do not violate the principle Open Closed.Now, let us return the second approach of using Dependency Injection (DI) pattern. We have 3 forms of DI, they are constructor, setter and interface. The example here using DI setter forms with Spring framework

Example 3: Using DI setter

public class HelloWorldService {
  private HelloWorld helloWorld;
 
  public void setHelloWorld(HelloWorld helloworldInst){
    this.helloWorld = helloworldInst;
  }
  public void sayHello() {
    this.helloWorld.sayHello();
  }
}

After that, write the spring configuration and we can use the HelloWorldService in our TestProgram

public class TestProgram {
  public static void main(string[] args) {
    BeanFactory factory = new XmlBeanFactory(
          new ClassPathResource("HelloServiceEx.xml"));
    HelloWorldService service = factory.getBean("helloworldBean");
    service.sayHello();
  }
}

Compare two approaches, we see that both of them achieve the same goal but DI framework like Spring has more advantages that it is not only the way of initializing the instance but more flexible and general when we set the pre-defined data for implementation instance. In simple application that only needs to care the way of initializing implementation instance, I suggest to use the Abstract Factory pattern but other cases using a DI framework is the prefer method. Using DI pattern can make us achieve the loose coupling among collaborating classes (the actor and implementation classes), it makes our program is more testable, debugable, flexible. It is all for a OO design.

Share and Enjoy:

Singleton, is it a false pattern ?

admin — Mon, 25 Dec 2006 18:21:48 +0000

Singleton is the first pattern I learned when I am a fresh programmer, it is impressed to me at that time due to it is easy to learn. Years by years, I have learned many variances of this pattern through how to apply lazy loading the static instance to the thread-safe of initializing the static instance by using the two main streams of implementation:

Method 1:

public class SingletonEx {
    private static SingletonEx impl = null;
    private  SingletonEx() {
        ...
    }
    public static SingletonEx getInstance() {
          //another implementation to prevent
          //thread-safe problem is making the
          //synchronized keywork before this statement
          if (impl == null) {
              impl = new SingletonEx(); //lazy loading static instance impl
          }
          return impl;
     }
}

Method 2:

public class SingletonEx {
    private static SingletonEx impl = new SingletonEx();
    private SingletonEx() {
        ....
    }
    public static SingletonEx getInstance() {
        return impl;
    }
}

Some developers guys critize the method 1 is not thread-safe, even if we make it is thread-safe, it takes cost whenever we call getInstances method. But we have some other guys say that we only use when we need so method 2 takes cost when the program init Singleton instance. Some smarter guys say that we use method 1 or method 2 depend on context, ok it sounds better than option1 or 2 but it is not enough, it has some reasons:

Method 1:

You need lazy loading, it is ok but it seems fail in your arguments . You do not save any time using lazy loading at all, when you need the instance at first, you must create the instance, if the cost of creating instance too much it will pact the response time of program to user, so why do you create it in some time before, moreover you need to care the thread-safe problem while creating instance,
Moreover, it is not a must in design pattern but singleton objects in most cases are called many times in your program (in my cases, this argument is all times). So creating it at first is a good choice for us.

Method 2:

As above arguments, you do not need to use lazy loading for singleton pattern and method 2 seems to be better, except you need consider the time of creating the singleton object, if the cost of creating is high you should consider loading it at the first of init program (warm up)

But, singleton pattern still be a dangerous pattern and is it really useful for architects. I think the answer is negative due to the following reasons:
1. It is not thread-safe in operation (most of developers care thread-safe while creating but not operating )
2. It does not abstract the implementation; it is harm when the singleton instance is not stable enough.
3. It makes the design not flexible, all are fixed with its implementation and it takes cost while refractoring.
4. It may lead the bottleneck on operations, and unexpected behaviors.

That makes me carefully when using singleton pattern, only when needed and think deeply its consequences when apply, some of experiences are:
1. Make only one singleton pattern in one place. That means you should not create many singleton objects in your design, but create one factory object (apply singleton pattern) and create singleton object through that object.
2. Only use operations in singleton object as read object (avoid thread safe problem). It is a good choice if we use it for cache mechanism.
3. Apply for stable classes that we make sure no change in future (of course, you do not know in future, but in current we must be sure it has no change) . Do you remember the impact when string class add more methods in java 1.4, what the hell of change impact.

Method 1:

You need lazy loading, it is ok but it seems fail in your arguments . You do not save any time using lazy loading at all, when you need the instance at first, you must create the instance, if the cost of creating instance too much it will pact the response time of program to user, so why do you create it in some time before, moreover you need to care the thread-safe problem while creating instance.

Moreover, it is not a must in design pattern but singleton objects in most cases are called many times in your program (in my cases, this argument is all times). So creating it at first is a good choice for us.

Method 2:

As above arguments, you do not need to use lazy loading for singleton pattern and method 2 seems to be better, except you need consider the time of creating the singleton object, if the cost of creating is high you should consider loading it at the first of init program (warm up) But, singleton pattern still be a dangerous pattern and is it really useful for architects. I think the answer is negative due to the following reasons:
1. It is not thread-safe in operation (most of developers care thread-safe while creating but not operating )
2. It does not abstract the implementation; it is harm when the singleton instance is not stable enough.
3. It makes the design not flexible, all are fixed with its implementation and it takes cost while refractoring.
4. It may lead the bottleneck on operations, and unexpected behaviors. That makes me carefully when using singleton pattern, only when needed and think deeply its consequences when apply, some of experiences are:

- Make only one singleton pattern in one place. That means you should not create many singleton objects in your design, but create one factory object (apply singleton pattern) and create singleton object through that object.
- Only use operations in singleton object as read object (avoid thread safe problem). It is a good choice if we use it for cache mechanism.
- Apply for stable classes that we make sure no change in future (of course, you do not know in future, but in current we must be sure it has no change) . Do you remember the impact when string class add more methods in java 1.4, what the hell of change impact.

Share and Enjoy: