所谓工厂模式

1.从ChannelFactory来看工厂模式：

一直以来，我都是对于工厂模式有着很大的困惑，虽然也看了网上的诸多文章，什么简单工厂啦，工厂方法啦，甚至抽象工厂方法啦，这里稍微记录一下这三个东西：

简单工厂：定义一个工厂类，根据传入的参数不同返回不同的实例，被创建的实例具有共同的父类或接口。

工厂方法：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。

抽象工厂：工厂方法的仅一步深化，在这个模式中的工厂类不单单可以创建一个对象，而是可以创建一组对象。这是和工厂方法最大的不同点。

以上这些我觉得都不重要，因为在我看来这些东西真的没啥卵用，我干嘛一定要用工厂方法呢，我好好的构造器用着也很好啊，我就喜欢用构造器new一个对象出来，我也没觉得你这个工厂方法优势在哪里啊。

直到，我看到了知乎上某大佬的一句话：“真正逼迫我们使用工厂方法的，是来源于这么一个事实：组合大于继承“

这话乍一看感觉挺没道理的，但仔细想来，假如我有这么个接口的实现类，里面有十几二十个属性，有八九个构造器方法，这个是不是一个很常见的类的形式，因为我们更希望以组合的形式来构造类。那么问题来了，我如果作为对这个类的调用方，想要构造，咋构造，里面错综复杂的逻辑和构造方法让我觉得很烦，我就想简单的搞一下就行，而且更讨厌的是，每一个调用方都要面对这些东西。所以工厂方法这个时候就体现价值出来了，调用方不用操心这个，交给工厂来做，就一个create方法，啥参数都不用给，我自己就给你实现好这个构造。

现在，假设有 十个调用方，那每个调用方只需要找到自己想要的那个factory就行了，然后简单的一个create，世界清净了，把对象创建和对象调用给解耦开，这个是我认为工厂模式最大的意义所在。

回到netty的这个工厂中来，这个更偷懒，它提供了一个反射实现工厂方法的实现类，把构造交给具体的各自实现就行。

publicclassReflectiveChannelFactoryimplementsChannelFactory{

​

privatefinalConstructorconstructor;

​

publicReflectiveChannelFactory(Classclazz) {

ObjectUtil.checkNotNull(clazz,"clazz");

try{

this.constructor=clazz.getConstructor();

}catch(NoSuchMethodExceptione) {

thrownewIllegalArgumentException("Class "+StringUtil.simpleClassName(clazz)+

" does not have a public non-arg constructor",e);

       }

   }

​

@Override

publicTnewChannel() {

try{

returnconstructor.newInstance();

}catch(Throwablet) {

thrownewChannelException("Unable to create Channel from class "+constructor.getDeclaringClass(),t);

       }

   }

}

所以，大部分情况下，只需要传一个具体实现类的channel，就生产出这个类来了。