关于java工厂模式
发布网友
发布时间：2022-04-22 03:44
共2个回答
热心网友
时间：2022-04-14 19:22
呵，我最近也在研究这个，文字一堆的概念性的东西我就不说了，看着就烦~我理解的工厂模式应该这样的：对于初学者来说，设计一个程序往往是边写代码边修正，缺乏一个环节：设计工厂模式我觉得应该是以设计为第一步的编程方法首先拿到一个项目后，先分析这个项目你准备写哪些类，分别实现哪些功能然后看看你的个各类中是否有功能相同或者功能类似的部分，将这些部分提取出来然后按照他们的层次设计不同的接口，最后为所有接口设计一个抽象类 举个例子，假设我们要描述一个人的特征，可以定义一个human类，并赋予它成员变量：age,sex,height,weight...等等等等。那么在描述这个人的时候，可以实例化这个human类，然后采用human.age=19; human.sex="男性";等等这类方法来描述这个对象。这样的描述不能说有错，但并不是工厂模式。假设有四个不同的人，先提取他们的共同特征，2男2女，都是人。那么可以这样描述他们：先定义一个顶层的抽象类：人类然后定义2个接口，分别对人类进行扩展性描述：男人，女人再定义2个接口，再对上面的类进行扩展性描述：年轻男人，年老男人，年轻女人，年老女人那么引用了年轻男人这个接口的类就直接被赋予了人类、性别、年龄这三个属性特征。也就是说，如果用前一种方式来描述一个人，它只是一个孤立的类，用工厂模式来描述一个人，它其实是一个树形结构。 表面上看起来，工厂模式写起来似乎更加的麻烦，其实它有它的优点所在：1、能体现你的几个类的层次结构，父子关系，引用关系。而不是为了引用代码就使用继承，为了多重继承就使用接口，我觉得这些都是错误的用法。2、假设需要你描述100个人，每个人都要用50个形容词来修饰他，那么第一种方法无疑是艰巨的任务。为了描述一个人的某个特征，你不得不去描述他们的49个特征，这样的工作要重复100次！但如果用工厂模式，你只需要建立好工厂模式的构架，选择就接近对象特征的那个类进行实例化就可以了！3、在维护方法，一旦程序需要扩展功能，第一种方法就只能不断的向human类添加成员变量，向滚雪球一样越滚越大，而你所有引用了human类的地方都必须修改，对于一个大的项目来说维护工作是致命的！而使用工厂模式，你可以随时在任意两个类中插入其他的类，只需要更改上下的引用而已，而你其他引用了这些类的地方则完全不受其影响！ 所以才说JAVA是一门设计的语言，以上只是我个人的理解，至于对不对，还在实践中~~
热心网友
时间：2022-04-14 20:40
工厂模式有以下几种形态:
简单工厂(Simple Factory)模式
工厂方法(Factory Method)模式,又称多形性工厂(Polymorphic Factory)模式
抽象工厂(Abstract Factory)模式,又称工具箱(Kit或Toolkit)模式
在简单工厂模式中,一个工厂类处于对产品类实例化调用的中心位置上,它决定那一个产品类应当被实例化, 如同一个交通*站在来往的车辆流中,决定放行那一个方向的车辆向那一个方向流动一样。
工厂方法模式是简单工厂模式的进一步抽象化和推广，工厂方法模式里不再只由一个工厂类决定那一个产品类应当被实例化,这个决定被交给子类去作。
工厂方法模式和简单工厂模式在定义上的不同是很明显的。工厂方法模式的核心是一个抽象工厂类,而不像简单工厂模式, 把核心放在一个实类上。工厂方法模式可以允许很多实的工厂类从抽象工厂类继承下来, 从而可以在实际上成为多个简单工厂模式的综合,从而推广了简单工厂模式。
反过来讲,简单工厂模式是由工厂方法模式退化而来。设想如果我们非常确定一个系统只需要一个实的工厂类, 那么就不妨把抽象工厂类合并到实的工厂类中去。而这样一来,我们就退化到简单工厂模式了。
抽象工厂模式是所有形态的工厂模式中最为抽象和最具广泛性的一种形态，抽象工厂模式是工厂方法模式的进一步扩广化和抽象化。如下图：
在抽象工厂模式中，抽象产品 (AbstractProct) 可能是一个或多个，从而构成一个或多个产品族(Proct Family)。 在只有一个产品族的情况下，抽象工厂模式实际上退化到工厂方法模式。
总结： 简单工厂模式是由一个具体的类去创建其他类的实例，父类是相同的，父类是具体的。
工厂方法模式是有一个抽象的父类定义公共接口，子类负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成。
抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无须指定他们具体的类。它针对的是有多个产品的等级结构。而工厂方法模式针对的是一个产品的等级结构。
