标签：window 使用场景 图片 http 这一 class 文本编辑 factory width
1.简单工厂模式
简单工厂模式不能说是一个设计模式，说它是一种编程习惯可能更恰当些。因为它至少不是Gof23种设计模式之一。但它在实际的编程中经常被用到，而且思想也非常简单，可以说是工厂方法模式的一个引导。
模式定义
简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
模式优缺点
工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品；简单工厂模式通过这种做法实现了对责任的分割，它提供了专门的工厂类用于创建对象。
客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以减少使用者的记忆量。
通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。
由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。
使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度。
系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。
简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。
模式适用环境
在以下情况下可以使用简单工厂模式：
工厂类负责创建的对象比较少：由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
客户端只知道传入工厂类的参数，对于如何创建对象不关心：客户端既不需要关心创建细节，甚至连类名都不需要记住，只需要知道类型所对应的参数。
Fruit：抽象产品
public interface Fruit { public void getFruit(); }
orange:具体产品角色
public class Orange implements Fruit{ @Override public void getFruit() { // TODO Auto-generated method stub System.out.println("获得橘子"); } }
apple:具体产品
public class Apple implements Fruit{ @Override public void getFruit() { // TODO Auto-generated method stub System.out.println("获得苹果"); } }
工厂类：
public class SimpleFactory { public static Fruit getFruit(String type) throws Exception{ if(type.equalsIgnoreCase("orange")){ return new Orange(); }else if(type.equals("apple")){ return new Apple(); }else{ return null; } } }
测试类：
public class MainClass { public static void main(String[] args) throws Exception { Fruit apple = SimpleFactory.getFruit("apple"); Fruit orange = SimpleFactory.getFruit("Orange"); apple.getFruit(); orange.getFruit(); } }
运行结果：
2.工厂方法模式：
工厂方法模式是简单工厂模式的一个延伸，它解决的仍然是软件设计中与创建对象有关的问题。它可以更好的处理客户的需求变化。在工厂方法模式中，父类负责定义创建对象的公共接口，而子类则负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成，即由子类来决定究竟应该实例化（创建）哪一个类。
工厂方式法模式（Factory Method），定义了一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到子类。
参与者
抽象产品角色（Product）：定义产品的接口
具体产品角色（ConcreteProduct） ：实现接口Product的具体产品类
抽象工厂角色（Creator） ：声明工厂方法（FactoryMethod），返回一个产品
真实的工厂（ConcreteCreator）：实现FactoryMethod工厂方法，由客户调用，返回一个产品的实例
Fruit：抽象产品
orange:具体产品角色
apple:具体产品
工厂类：FruitFactory
public interface FruitFactory { public Fruit getFruit(); }
真实工厂：AppleFactory
public class AppleFactory implements FruitFactory { @Override public Fruit getFruit() { // TODO Auto-generated method stub return new Apple(); } }
PearFactory:
public class PearFactory implements FruitFactory{ @Override public Fruit getFruit() { // TODO Auto-generated method stub return new Pear(); } }
测试：
public class MainClass { public static void main(String[] args) throws Exception { FruitFactory appleFactory= new AppleFactory(); Apple apple = (Apple) appleFactory.getFruit(); apple.getFruit(); FruitFactory pearFactory = new PearFactory(); Pear pear = (Pear) pearFactory.getFruit(); pear.getFruit(); } }
运行结果：
工厂方法模式的优点
在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户隐藏了哪种具体产品类将被实例化这一细节，用户只需要关心所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。
基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节则完全封装在具体工厂内部。工厂方法模式之所以又被称为多态工厂模式，是因为所有的具体工厂类都具有同一抽象父类。
使用工厂方法模式的另一个优点是在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就可以了。这样，系统的可扩展性也就变得非常好，完全符合“开闭原则”。
工厂方法模式的缺点
在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。
由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度。
3.抽象工厂模式
意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
主要解决：主要解决接口选择的问题。
何时使用：系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。
如何解决：在一个产品族里面，定义多个产品。每个具体的工厂负责一个产品族。抽象工厂的返回值为最高级抽象产品。
关键代码：在一个工厂里聚合多个同类产品（在同一个产品族中）。
抽象产品： public interface Fruit { public void getFruit(); } apple: public abstract class Apple implements Fruit{ public abstract void getFruit(); } orange: public abstract class Orange implements Fruit{ public abstract void getFruit(); } northapple: public class NorthApple extends Apple{ @Override public void getFruit() { // TODO Auto-generated method stub System.out.println("获得北方苹果"); } } southapple: public class SouthApple extends Apple { @Override public void getFruit() { // TODO Auto-generated method stub System.out.println("获得南方苹果"); } } northorange: public class NorthOrange extends Orange { @Override public void getFruit() { // TODO Auto-generated method stub System.out.println("获得北方橘子"); } } southorange: public class SouthOrange extends Orange { @Override public void getFruit() { // TODO Auto-generated method stub System.out.println("获得南方橘子"); } }
抽象工厂： public interface FruitFactory { public Fruit getApple(); public Fruit getOrange(); } //生产北方产品 public class NorthFactory implements FruitFactory{ @Override public Fruit getApple() { // TODO Auto-generated method stub return new NorthApple(); } @Override public Fruit getOrange() { // TODO Auto-generated method stub return new NorthOrange(); } } //生产南方产品 public class SouthFactory implements FruitFactory { @Override public Fruit getApple() { // TODO Auto-generated method stub return new SouthApple(); } @Override public Fruit getOrange() { // TODO Auto-generated method stub return new SouthOrange(); } }
测试： public static void main(String[] args) throws Exception { FruitFactory southFactory = new SouthFactory(); SouthApple apple= (SouthApple) southFactory.getApple(); apple.getFruit(); SouthOrange orange = (SouthOrange) southFactory.getOrange(); orange.getFruit(); FruitFactory northFactory = new NorthFactory(); NorthApple apple2 = (NorthApple) northFactory.getApple(); apple2.getFruit(); NorthOrange orange2 = (NorthOrange) northFactory.getOrange(); orange2.getFruit(); }
运行结果：
抽象工程模式的优点：
封装性，每个产品的实现类不是高层模块要关系的，要关心的是什么？是接口，是抽象，它不关心对象是如何创建出来，这由谁负责呢？工厂类，只要知道工厂类是谁，我就能创建出一个需要的对象，省时省力，优秀设计就应该如此。
产品族内的约束为非公开状态。例如生产男女比例的问题上，猜想女娲娘娘肯定有自己的打算，不能让女盛男衰，否则女性的优点不就体现不出来了吗？那在抽象工厂模式，就应该有这样的一个约束：每生产1个女性，就同时生产出1.2个男性，这样的生产过程对调用工厂类的高层模块来说是透明的，它不需要知道这个约束，我就是要一个黄色女性产品就可以了，具体的产品族内的约束是在工厂内实现的。
缺点：
抽象工厂模式的最大缺点就是产品族扩展非常困难，为什么这么说呢？我们以通用代码为例，如果要增加一个产品C，也就是说有产品家族由原来的2个，增加到3个，看看我们的程序有多大改动吧！抽象类AbstractCreator要增加一个方法createProductC()，然后，两个实现类都要修改，想想看，这在项目中的话，还这么让人活！严重违反了开闭原则，而且我们一直说明抽象类和接口是一个契约，改变契约，所有与契约有关系的代码都要修改，这段代码叫什么？叫“有毒代码”，——只要这段代码有关系，就可能产生侵害的危险！
使用场景：
抽象工厂模式的使用场景定义非常简单：一个对象族（或是一组没有任何关系的对象）都有相同的约束，则可以使用抽象工厂模式，什么意思呢？例如一个文本编辑器和一个图片处理器，都是软件实体，但是linux下的文本编辑器和WINDOWS下的文本编辑器虽然功能和界面都相同，但是代码实现是不同的，图片处理器也是类似情况，也就是具有了共同的约束条件：操作系统类型，于是我们可以使用抽象工厂模式，产生不同操作系统下的编辑器和图片处理器。
标签：window 使用场景 图片 http 这一 class 文本编辑 factory width
原文地址：https://www.cnblogs.com/menbo/p/9937207.html
