很多类工厂都是用反射(Assembly.Load())来创建一个对象的,反射如此的消耗效率,并且反射后还要类型转换又消耗性能,为什么不直接new 一个对象?
是为了降低耦合还是?大虾们指点..谢谢。在线等

解决方案 »

  1.   

    Assembly.Load(path)中的path是一般是写在Webconfig里的,这样就可以更改配置,而不改动程序来使用不同的类了。
    工厂不是就想实现这样的功能才用的么?
      

  2.   

    你要是new的话,如果改变的话就要改程序了,不能实现根据配置文件new
      

  3.   

    通过放射,可以在运行时获得.NET中每一个类型(包括类、结构、委托、接口和枚举等)的成员,包括方法、属性、事件,以及构造函数等。还可以获得每个成员的名称、限定符和参数等。有了反射,即可对每一个类型了如指掌。如果获得了构造函数的信息,即可直接创建对象,即使对象的类型在编译时还不知道。提高程序扩张性。
      

  4.   

         Assembly.Load()并没有使用反射。通过一个完整的类型命名来找到Load参数所指定的程序集,并在程序集中找到相应的类并创建其实例。影响性能的是他将特定类所在的程序集加载到了内存中。所以,从性能的角度来看,可以忽略不计。在这个模式中,工厂类是整个模式的关键所在。它包含必要的判断逻辑,能够根据外界给定的信息,决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例,而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。工厂模式的主要好处在于消除对象间的耦合。通过使用工厂方法而不是new关键字及具体类,你可以把所有实例化代码集中在一个位置。这可以大大简化更换所用的类或在运行期间动态选择所用的类的工作。在派生子类时它也提供了更大的灵活性。使用工厂模式,你可以先创建一个抽象的父类,然后在子类中创建工厂方法,从而把成员对象的实例化推迟到更专门化的子类中进行。
    所有这些好处都与面向对象设计的这两条原则有关:弱化对象间的耦合;防止代码的重复。在一个方法中进行类的实例化,可以消除重复性的代码。这是在用一个对接口的调用取代一个具体的实现。这些都有助于创建模块化的代码。
         不难发现,简单工厂模式的缺点也正体现在其工厂类上,由于工厂类集中了所有实例的创建逻辑,所以“高内聚”方面做的并不好。另外,当系统中的具体产品类不断增多时,可能会出现要求工厂类也要做相应的修改,扩展性并不很好。
      

  5.   

    设计有一定的缺陷,尽量是缓存工厂,工厂来new 这样在时间上可以节省很多,在空间上也不会太浪费
      

  6.   

    关于实例化对象,Java界已经大范围流行IoC 模式了
      

  7.   

    第一次反射然后放在Cache中~~~
      

  8.   

    只是为了不改工厂的代码,也就几行码,用个case语法也无可厚非。