Showing posts with label Design Patterns. Show all posts

A Quick Reference to the Spring 3 DI Bean Configuration

Posted on 2011-10-07 by CB





Spring 3 DI (dependency injection) functionality which placed in "Spring Core" is very important for managing objects (or "beans") in enterprise applications.


Here is a quick reference for bean configuration of Spring DI:

Spring Bean Configurations 





You can get a bean in application by

manual:
ApplicationContext context = new ClassPathApplicationContext(new String[] {“application-context.xml”})
ViewManager viewManager = (ViewManager)context.getBean(“viewManager”);

annotation:
@Autowired
ViewManager viewManager;




Posted in , , | 1 Comment

Software Architecture Antipatterns : Swiss Army Knife Interface

Posted on 2011-08-15 by CB




Swiss Army Knife Interface is an interface class which has excessive number of method definitions. Architect/designer may design this interface to use for every need of the software, but this is a wrong approach and an antipattern. More than one interface must be designed using some design approaches.
Of course, "excessive number of methods" is a too general statement. Although most developer think that a handful number of methods (e.g. 8-10)  and some studies show that some magic numbers (7 plus/minus 2) are mostly enough, we can't say the maximum number of methods precisely. 

First of all, you must think that this interface will be implemented by a class and if the number of methods is excessive, there will be plenty of empty method bodies in implementor class. But this situation still can't determine the number of interfaces and number of methods in an interface.

The answer is hidden in the OOP SOLID rules. Single Responsibility ("S") rule of SOLID says that "every object should have a single responsibility", and Interface Segregation ("I") rule of SOLID says that "different types of functionalities should be placed in different interfaces". If an interface have more than one types of functionalities or defines more than one responsibilities, implemening that interface is meaningless because implementer class will not suit SOLID rules by implementing that interface. 

More than one Swiss Army Knife Interface may also exist in a software. This means more than one problem exist and must be solved. 

For another viewpoint, you can take a look at our another post about interface segregation principle:


Posted in , , , | 6 Comments

5 Implementations of Singleton Pattern

Posted on 2010-08-25 by CB




This article introduces singleton design pattern and its 5 implementation variations (with C#).

Problem
At most one instance of a class must be created in an application.
Solution
That class (singleton) is defined including its own instance, and the constructor must be private.
Implementations
1. Lazy initialization, non-thread safe: This is the classical version, bot it's not thread safe. If more than one thread attempts to access instance at the same time, more than one instance may be created.
public class Singleton {
    private static Singleton instance = null;
    public static Singleton Instance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
    private Singleton() {}
}

2. Non-lazy initialization, thread safe: This is the simplest thread safe version, but it does not support lazy initialization.
public class Singleton {
    private readonly static Singleton instance = new Singleton();
    public static Singleton Instance() {
        return instance;
    }
    private Singleton() {}
}

3. Lazy initialization, thread safe: This version supports both properties, but has  performance problems. Once a thread uses singleton instance, the others have to wait because of lock.
public class Singleton {
    private static Singleton instance = null;
    private static readonly object lockObj = new object();
    public static Singleton Instance() {
        lock (lockObj) {
            if (instance == null) {
                instance = new Singleton();
            }
            return instance;
        }
    }
    private Singleton() {}
}

4. Double-check locking: An improved version of the third solution. Two null controls prevent lock waits for most time, but not always. Also, it does not work properly for Java because of Java memory management approach.
public class Singleton {
    private static Singleton instance = null;
    private static object lockObj = new object();
    public static Singleton Instance() {
        if (instance == null) {
            lock (lockObj) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
    private Singleton() {}
}

5. Nested initialization: A nested class is used for lazy initialization. This version is also thread safe, but a bit complex. For most situations, solutions 2 or 4 will be suitable according to performance parameters.
public class Singleton {
    public static Singleton Instance() {
         return Nested.instance;
    }
    private Singleton() {}

    class Nested {
        static Nested() {}
        internal static readonly Singleton instance = new Singleton(); 
    }
}

Usage: 
public static void Main(string[] args)
{
    Singleton instance = Singleton.Instance();
}


Posted in , | 17 Comments