谈谈几种典型的反模式

设计模式作为一个概念被提出来已经很久了,而我们耳熟能详的设计模式有GOF的设计模式,J2EE应用架构的的设计模式.也有从UML角度阐释的类的设计模式.
下面我想介绍一下几种典型的反模式.

• 具形类依赖

• 容器依赖

• 实例注册

• 构造器中很多参数

• 传播依赖

• 容器例证

• 单例

1具形类依赖:

顾名思义,如果一个类需要另外一个类的支持,及一个类内需要生命另外一个类的引用,如下代码所示:

public class UserService {
    private final UserDAO userDAO;

    public UserService(UserDAO userDAO) {
        this.userDAO = userDAO;
    }
}

public class userDAO {
}

        通过类名我们就可以猜到,UserService 可能是个处理业务逻辑的bean,而userDAO是完成数据存取的类.
就以上代码这种实现,在UserService中,数据存取操作将依赖于特定的数据存取类UserDAO.
        而在做系统设计中,我们往往会把Service层和DAO层分开.及service并不需要了解DAO的具体实现.
因此,可能DAO层用JDBC实现,也可能会用hibernate或JDO实现.假如需要的话,如果系统在不同的数据访问层切换时,上面代码的设计方式将带来严重问题,因为我们必须修改业务代码层,因为业务代码层依赖于具体的DAO实现.所以,以上代码应由以下实现:

public class UserService {
    private final IUserDAO userDAO;

    public UserService(IUserDAO userDAO) {
        this.userDAO = userDAO;
    }
}

public interface IUserDAO{
}

    这样,UserService类只依赖于一个完成了数据存取功能的接口.当系统需要在不同的数据存取层切换时,
我们只需要更改IOC容器配置(如果采用了IOC容器的话),或者修改UserService构建控制类即可,而不必修改业务
代码(service)层.

2容器依赖
      
       假设有这样一个例子,一个类依赖于容器,类BImpl的实现依赖于A的实例.在容器中声明了依赖.就像下面的代码一样:

public interface A {
}

public class AImpl implements A {
}

public class BImpl implements B {
    private final A a;

    BImpl(PicoContainer pico) {
        a = (A) pico.getComponentInstanceOfType(A.class);
        
        /*
        alternatively:
        a = (A) pico.getComponentInstance("a");
        */
    }
}
    也可以用以下代码实现:
MutablePicoContainer pico = new DefaultPicoContainer();
pico.registerComponentImplementation("a", AImpl.class);
pico.registerComponentImplementation("b", BImpl.class);
pico.registerComponentInstance(pico);

...
B b = (B) pico.getComponentInstance("b");


但这是个反模式.原因有:
1,它引入了从BImpl到容器的不必要的依赖
2,如果没有容器,BImpl很难测试
3,BImpl假定A已经被注册了.而实际上A是null.
简单而优雅的做法是这样:
public class BImpl implements B {
    private final A a;

    BImpl(A a) {
        this.a = a;
    }
}
容器会发现BImpl 需要一个A,并传给它A的实现.

3构造器中很多参数

    如果在一个类的构造器中,有太多的参数,很可能是这个类被设计成处理很多工作,包含了很多
依赖关系,当一个类需要完成过多性质不同的工作的时候,它就应该被拆分成不同小类以分别完成
相应不同的逻辑功能.这也是OO的思想的体现之一.即不应该存在过大的类.
    也许，你需要考虑把这些参数包装成一个类。会给你带来很多好处。

4单例


    在四人帮的设计模式中,关于单例模式有详细的介绍.但似乎单例模式一直就是个争议性的模式.甚至有人曾
提出singleton is evil的观点.
    在企业应用中,单例经常会造成很糟糕的解决方案.