本文目录索引

• 1，使用简单工厂模式的优点是什么？
• 2，工厂模式，简单工厂模式，抽象工厂模式 三者有什么区别
• 3，谁能通俗说一下什么是工厂模式吗
• 4，java中的工厂模式是什么，请举例说明
• 5，工厂模式的好处是什么？
• 6，为什么要使用工厂模式?

1，使用简单工厂模式的优点是什么？

简单工厂模式的优点: 1、工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品； 2、简单工厂模式通过这种做法实现了对责任的分割，它提供了专门的工厂类用于创建对象。 3、客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以减少使用者的记忆量。 4、通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。 扩展资料: 简单工厂模式的缺点: 1、由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。 2、使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度。 3、系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。 4、简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。 参考资料来源:百度百科-简单工厂模式

2，工厂模式，简单工厂模式，抽象工厂模式 三者有什么区别

工厂模式的好处就在于将工厂和产品之间的耦合降低，将具体产品的构造过程放在了具体工厂类里面。在以后扩展产品的时候方便很多，只需要添加一个工厂类，一个产品类，就能方便的添加产品，而不需要修改原有的代码。而在简单工厂中，如果要增加一个产品，则需要修改工厂类，增加if/else分支，或者增加一个case分支，工厂模式符合软件开发中的OCP原则（open close principle），对扩展开放，对修改关闭。
抽象工厂模式：这个模式我总是感觉和builder模式非常相似。
工厂方法模式提供的是对一个产品的等级模式，，而抽象工厂方法提供的是对多个产品的等级模式，注意，这里的多个具体产品之间是相互耦合的，也就是说这里的抽象工厂提供的产品之间是存在某种联系的。
有人做如下的比较：
工厂方法模式：一个抽象产品类，可以派生出多个具体产品类。
一个抽象工厂类，可以派生出多个具体工厂类。
每个具体工厂类只能创建一个具体产品类的实例。
抽象工厂模式：多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。
一个抽象工厂类，可以派生出多个具体工厂类。
每个具体工厂类可以创建多个具体产品类的实例。
区别：工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。
工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。
下面是一个形象的比喻：
无论是简单工厂模式、工厂模式还是抽象工厂模式，它们本质上都是将不变的部分提取出来，将可变的部分留作接口，以达到最大程度上的复用。拿一个生产水杯（cup）的工厂举例：起初，不用工厂模式，我必须在生产水杯之前知道水杯的材料和形状等水杯的所有特征才能生产，这就是我们的new Cup();这个Cup必须是具体的。厂主发现同一形状的被子，只是材料不同,如一个是玻璃(glass)的，一个是瓷(china)的,但是确要两条生产线，显然有资源浪费的嫌疑。现在厂主生产杯子时先不让生产线知道我要产的是玻璃的还是瓷的，而是让它在不知道具体材料的情况下先做它能做的，等到它把模具做好，只需要向其中填充玻璃原料或者瓷原料就可以造出同一形状的具体杯子了。但是很可惜，java并不能new一个抽象的Cup，所以就有了简单工厂模式。原来是Cup cup=new Cup;现在是SimpleCupFactory.createCup(String cupName),根据cup的名字生产Cup,而createCup返回的是一个实现了 Cup接口或抽象类的具体Cup。简单抽象工厂模式有一个问题，就是当我现在想生产一个同样形状的铁杯时，工厂里并没有定义相应的处理流程，只能更改createCup方法，这就不合理了。我现在只是想生产铁杯，你只要在最后的时候把玻璃原料换成铁的不就行了吗，干嘛还要更改整条生产线呢？于是就有了工厂模式。原来生产线在生产模具的时候还要考虑是为玻璃杯生产的模具还是为铁杯生产的模具，现在它不用管了。CupFactory.createCup()创建Cup.CupFactory是接口或抽象类。实现它的具体子类会创建符合Cup接口的具体Cup。那么现在厂主想要生产水壶(kettle)，用工厂模式就不得不再造一条水壶生产线，能不能在水杯生产线同时生产水壶呢？这就是抽象工厂模式。

3，谁能通俗说一下什么是工厂模式吗

假设有一个工厂是生产玩具的，你现在需要玩具，你就跟工厂说给我生产一个小熊，然后工厂就给了你一个小熊玩具，如果你说给我生产一个大象，工厂就给了你一个大象玩具，用代码来表示
class Factory{
public Toy getToys(String type){
if("xiaoxiong"){

return new XiaoXiong();
}else if("daxiang"){

return new Daxiang();

}

}

}

calss Toy{
}
class XiaoXiong extends Toy{
}

class Daxiang extends Toy{

}

void main(){
//先获取到工厂实例，也就是你现在有一个工厂了

Factory f = new Factory();

//让工厂生产一个小熊对象

XIaoXIong xiaoxiong = f.getToys("xiaoxiong");

}

这就是简单工厂模式，把你想要生产的实例对象告诉工厂，然后工厂给你返回一个实例对象

如果想知道更多看下面的
blog.csdn.net/lovelion/article/details/9300337

4，java中的工厂模式是什么，请举例说明

工厂模式就是在接口和子类之间加入了一个过渡端，通过此过渡端获得接口的实例化对象，这个过渡端也就是所谓的工厂类。这样以后如果再有程序子类要扩充，直接修改工厂类客户端就可以根据标记得到相应的实例，增加了程序的灵活性。eg:
interface Fruit{
public void eat() ;
}
class Apple implements Fruit{
public void eat(){
System.out.println("** $$$$$") ;
}
};
class Orange implements Fruit{
public void eat(){
System.out.println("** #####。") ;
}
};
class Factory{ // 定义工厂类
public static Fruit getInstance(String className){
Fruit f = null ;
if("apple".equals(className)){ // 判断
f = new Apple() ;
}
if("orange".equals(className)){ // 判断
f = new Orange() ;
}
return f ;
}
};
public class InterfaceCaseDemo{
public static void main(String args[]){
Fruit f = Factory.getInstance(null) ; // 实例化接口
f.eat() ;
}
};

5，工厂模式的好处是什么？

创建型设计模式有简单工厂模式，工厂方法模式和抽象工厂模式，工厂模式的好处需要对比获得。
简单工厂模式，工厂方法模式和抽象工厂模式都是属于创建型设计模式，这三种创建型模式都不需要知道具体类。我们掌握一种思想，就是在创建一个对象时，需要把容易发生变化的地方给封装起来，来控制变化（哪里变化，封装哪里），以适应客户的变动，项目的扩展。用这三种设计模式都可以实现.下面根据这三者之间的特点，优点，缺点，适用范围进行比较。
1. 特点
简单工厂模式：专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有 共同的父类。它又称为静态工厂方法模式。它的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。在这个模式中，工厂类是整个模式的关键所在。它包含必要的判断逻辑，能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例，而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。
工厂方法模式：工厂方法是粒度很小的设计模式，因为模式的表现只是一个抽象的方法。 提前定义用于创建对象的接口，让子类决定实例化具体的某一个类，即在工厂和产品中间增加接口，工厂不再负责产品的创建，由接口针对不同条件返回具体的类实例，由具体类实例去实现。工厂方法模式是简单工厂模式的衍生，解决了许多简单工厂模式的问题。首先完全实现‘开－闭 原则’，实现了可扩展。其次实现更复杂的层次结构，可以应用于产品结果复杂的场合。工厂方法模式是对简单工厂模式进行了抽象。有一个抽象的Factory类（可以是抽象类和接口），这个类将不在负责具体的产品生产，而是只制定一些规范，具体的生产工作由其子类去完成。在这个模式中，工厂类和产品类往往可以依次对应。即一个抽象工厂对应一个抽象产品，一个具体工厂对应一个具体产品，这个具体的工厂就负责生产对应的产品。
抽象工厂模式：抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一 种形态。抽象工厂模式是指当有多个抽象角色时，使用的一种工厂模式。抽象工厂模式可以向客户端提供一个接口，使客户端在不必指定产品的具体的情况下，创建多个产品族中的产品对象。它有多个抽象产品类，每个抽象产品类可以派生出多个具体产品类，一个抽象工厂类，可以派生出多个具体工厂类，每个具体工厂类可以创建多个具体产品类的实例。每一个模式都是针对一定问题的解决方案，工厂方法模式针对的是一个产品等级结构；而抽象工厂模式针对的是多个产品等级结果。
Go back
2. 优点
简单工厂模式：工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实 例，客户端可以免除直接创建产品对象的责任，而仅仅"消费"产品。简单工厂模式通过这种做法实现了对责任的分割。简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。通过它，外界可以从直接创建具体产品对象的尴尬局面中摆脱出来。外界与具体类隔离开来，偶合性低。明确区分了各自的职责和权力，有利于整个软件体系结构的优化。
工厂方法模式：工厂方法模式是为了克服简单工厂模式的缺点（主要是为了满足OCP）而 设计出来的。简单工厂模式的工厂类随着产品类的增加需要增加很多方法（或代码），而工厂方法模式每个具体工厂类只完成单一任务，代码简洁。工厂方法模式完全满足OCP，即它有非常良好的扩展性。
抽象工厂模式：抽象工厂模式主要在于应对“新系列”的需求变化。分离了具体的类，抽 象工厂模式帮助你控制一个应用创建的对象的类，因为一个工厂封装创建产品对象的责任和过程。它将客户和类的实现分离，客户通过他们的抽象接口操纵实例，产品的类名也在具体工厂的实现中被分离，它们不出现在客户代码中。它使得易于交换产品系列。一个具体工厂类在一个应用中仅出现一次——即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。它有利于产品的一致性。当一个系列的产品对象被设计成一起工作时，一个应用一次只能使用同一个系列中的对象，这一点很重要，而抽象工厂很容易实现这一点。抽象工厂模式有助于这样的团队的分工，降低了模块间的耦合性，提高了团队开发效率。
Go back
3. 缺点
简单工厂模式：当产品有复杂的多层等级结构时，工厂类只有自己，以不变应万变，就是模式的缺点。因为工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。系统扩展困难，一旦添加新产品就不得不修改工厂逻辑（如果要增加一个产品，则需要修改工厂类，增加if/else分支，或者增加一个case分支），有可能造成工厂逻辑过于复杂,违背了"开放--封闭"原则(OCP).另外，简单工厂模式通常使用静态工厂方法，这使得无法由子类继承，造成工厂角色无法形成基于继承的等级结构。
工厂方法模式：不易于维护，假如某个具体产品类需要进行一定的修改，很可能需要修改对应的工厂类。当同时需要修改多个产品类的时候，对工厂类的修改会变得相当麻烦（对号入座已经是个问题了）。
抽象工厂模式：抽象工厂模式在于难于应付“新对象”的需求变动。难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几乎确定了可以被创建的产品集合，支持新种类的产品就需要扩展该工厂接口，这将涉及抽象工厂类及其所有子类的改变。
Go back
4. 适用范围
简单工厂模式：工厂类负责创建的对象比较少，客户只知道传入了工厂类的参数，对 于始何创建对象（逻辑）不关心。
工厂方法模式：当一个类不知道它所必须创建对象的类或一个类希望由子类来指定它所创建的对象时，当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候，可以使用工厂方法。
抽象工厂模式：一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。这个系统有多于一个的产品族，而系统只消费其中某一产品族。同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。
其实，无论是简单工厂模式、工厂模式还是抽象工厂模式，它们本质上都是将不变的部分提取出来，将可变的部分留作接口，以达到最大程度上的复用。究竟用哪种设计模式更适合，这要根据具体的业务需求来决定。

6，为什么要使用工厂模式?

工厂这个模式它可以隐藏函数的具体实现，并且更加具有封装性，更加的面向对象，这些东西在基础的编写小程序上并体现不出什么优越性，但在一个大项目中，就显得很重要了，

打个比方就像你如果说只有两三本书，你不需要什么归类放着，但你如果有一个图书管那么多书的话，放书就要有一定的规章，章法，这样就好管理，变更，查找