设计模式学习-工厂模式

在学习设计模式之前，首先了解一下多态。

1.多态

多态，顾名思义，就是多种形态，在面向对象编程里就是指接口的多种不同的实现方式，鸟会飞，飞机也会飞，超人也会飞，同样是飞，变现出的形态却是不一样的，在程序中的体现就是

public interface ifly{
public abstract void fly();
}
class plane implements ifly{

@Override
public void fly() {
System.out.print("plane fly");
}

}
class bird implements ifly{

@Override
public void fly() {
System.out.print("bird fly");
}

}

.....

那这样做的作用是什么呢?

首先，可以实现代码的复用，这里的复用并不是代码量的减少，而是结构的复用，子类不需要再去思考去添加新的功能调用，只需要去实现接口就可以了，如，超人还会“跑”，那我就去实现“跑”这个接口...在项目开发中，接口的开发往往比子类去实现花费的时间更多。

其次，封装性，这里的封装是指对方法的封装，由父类指针指向子类对象然后在调用父类的某一个方法时，不同的子类对象变现出来的行为是不同的，此时就隐藏的子类的具体实现。

总而言之，多态是程序的结构更清晰，降低耦合度，大大降低了程序的维护。

2.简单工厂

既然是工厂factory，那就会有产品product，在面向对象编程中，product就是对象，而factory就是去创建对象。

首先来看一个经典的例子，在数据库开发的时候，我们使用SQL Server作为数据库，然后设计了一个简单的类sqlDB,里面包含了很多数据库的一些基本操作，如连接、增删改查...系统完成后，感觉很不错，给客户之后，客户突然说，我们这边要改成oracle作为数据库，需要把原来的重新修改一下，拿回来之后，你把之前的sqlDB类慌忙改成oracleDB，里面的连接方法，增删改查、使用这个类的地方全部都要改，自己恨不得重新写一遍～好不容易调试完，过了几天又要改成access的...快要疯了吧！

对于这种情况，最简单的解决方法就是，我们可能用到的类sqlDB、oracleDB、accessDB全部写好，随便你改变需求，改哪个换哪个，这种方法虽然可以解决，但是如果客户

并不要修改，你岂不是做了无用功？？？对了，那就用刚刚说的接口，定义一个DB接口，包含connect、insert、delete一些抽象函数，sqlDB、oracleDB、accessDB去实现他们，需要那种数据库，我就去实现那种，结构也清晰，也没有累赘，这就是使用了多态，听上去好像很完美了，但是如果在这个系统中，很多地方都使用了数据库的交互，那我修改DB的时候还不是要按个去找new ..DB()...然后修改，那有没有更好的方法，自然就引入了简单工厂。

在这里，sqlDB、oracleDB、accessDB就是product，他们的接口是iproduct，factory需要做的就是去create他们：

class factory{

public static iproduct create(String type){

switch(type){

case "sql":

return new sqlDB;

case "oracle"

...

}

}

}

在使用的时候：

factory myDB = factory.create("sqlDB"); 

但是这样好像还是要去一个一个修改，和之前没什么区别啊，那如果把“sqlDB”改成去读一个配置文件，那样的话，每次只要去修改配置文件，然后添加相应的子类就可以了。

可是简单工厂只是把子类的new..DB()..操作推迟到了工厂类中，并没有什么变化，而且还增大了篇幅。。。

实际上，简单工厂是属于创建型模式，是把创建多态化，有什么好处呢？首先它屏蔽了子类的实例化方法，其次把创建对象和使用对象分割开，这样用户在使用的使用，不需要了解这个子类对象到底是怎么实现的，有哪些参数...优化了软件的结构。
在面向过程的编程中，一般是把底层的功能包装成一个函数，然后高层使用时去调用它，但是如果底层改变了，高层也会改变，往往是牵一发而动全身，这对软件的维护是很不里的，而在面向对象编程中，如果我们把一个类都当成一个个的包装好的函数，而我去使用它，它发生了变化，那么调用它的也会跟着变化，维护起来也很不方便，那怎么让维护的代价最小呢？简单工厂其实就做到了一点，它把对象的创建封装到了一个类中，如果类的构造函数发生了变化，只需要在这个类中修改，无需按个去找new ..DB()..

还有很多理解有偏差，希望随着深入学习，能有更准确的理解！