新建了两个类
//宝马320
public classBMW320 { publicBMW320(){ System.out.println("制造-->BMW320");} }
//宝马523
public class BMW523 {
public BMW523(){
System.out.println("制造-->BMW523");
}
}
客户端:
public classCustomer {public static voidmain(String[] args) {
BMW320 bmw320= newBMW320();
BMW523 bmw523= newBMW523();
}
}
结果:
另外一个例子:比如说, 客户需要买手机
public classIphone {
public voidiphone () {}
}
public classHuawei {
public voidhuawei () {}
}
客户端的调用示例如下:
Iphone phone1 = newIphone();
phone1.iphone();
Huawei phone2 = newHuawei();
phone2.huawei();
这样的方式非常原始,也很简单,但是代码的逻辑不清晰,暴露的内容过多。
解决的方案:
抽象逻辑,提供接口
为了减少方法调用的复杂度,也为了便于抽象跟代码管理,咱们额外提供一个接口:
public interfacePhone {
voidplay();
}
然后,将所有手机类都实现 Phone 接口,将暴露给客户端调用的逻辑都封装在 play 方法里。
public classIphone implements Phone {
@Override
public voidplay() {
System.out.println("给我一台Ipone");
}
}
public class Huawei implements Phone {
@Override
public void play() {
System.out.println("给我一台华为");
}
}
那么,客户端需要知道的调用 API 就减少到了两种:
Phone 接口的信息
Phone 接口有哪些实现类
调用的逻辑就变简单了:
Phone phone1 = newIphone();
phone1.play();
Phone phone2= newHuawei();
phone2.play();
客户需要知道怎么去创建一款车,客户和车就紧密耦合在一起了.为了降低耦合,就出现了工厂类,把创建宝马的操作细节都放到了工厂里面去,客户直接使用工厂的创建工厂方法,传入想要的宝马车型号就行了,而不必去知道创建的细节.这就是工业革命了:简单工厂模式
即我们建立一个工厂类方法来制造新的对象。如图:
产品类:
abstract classBMW {publicBMW(){
}
}public classBMW320 extends BMW {publicBMW320() {
System.out.println("制造-->BMW320");
}
}public classBMW523 extends BMW{publicBMW523(){
System.out.println("制造-->BMW523");
}
}
工厂类:
public classFactory {public BMW createBMW(inttype) {switch(type) {case 320:return newBMW320();case 523:return newBMW523();default:break;
}return null;
}
}
客户类:
public classCustomer {public static voidmain(String[] args) {
Factory factory= newFactory();
BMW bmw320= factory.createBMW(320);
BMW bmw523= factory.createBMW(523);
}
}
结果:和最原始的一样,不过中间有工厂类,客户可以通过工厂类,创建需要的车辆
简单工厂模式又称静态工厂方法模式。重命名上就可以看出这个模式一定很简单。它存在的目的很简单:定义一个用于创建对象的接口。
先来看看它的组成:
1 、工厂类角色:这是本模式的核心,含有一定的商业逻辑和判断逻辑,用来创建产品
2 、抽象产品角色:它一般是具体产品继承的父类或者实现的接口。
3、 具体产品角色:工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。
下面我们从开闭原则(对扩展开放;对修改封闭)上来分析下简单工厂模式。当客户不再满足现有的车型号的时候,想要一种速度快的新型车,只要这种车符合抽象产品制定的合同,那么只要通知工厂类知道就可以被客户使用了。所以对产品部分来说,它是符合开闭原则的;但是工厂部分好像不太理想,因为每增加一种新型车,都要在工厂类中增加相应的创建业务逻辑(createBMW(int type)方法需要新增case),这显然是违背开闭原则的。可想而知对于新产品的加入,工厂类是很被动的。对于这样的工厂类,我们称它为全能类或者上帝类。
我们举的例子是最简单的情况,而在实际应用中,很可能产品是一个多层次的树状结构。由于简单工厂模式中只有一个工厂类来对应这些产品,所以这可能会把我们的上帝累坏了,也累坏了我们这些程序员。
于是工厂方法模式作为救世主出现了。 工厂类定义成了接口,而每新增的车种类型,就增加该车种类型对应工厂类的实现,这样工厂的设计就可以扩展了,而不必去修改原来的代码。
2、 工厂方法模式
工厂方法模式去掉了简单工厂模式中工厂方法的静态属性,使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。
工厂方法模式组成:
1、抽象工厂角色: 这是工厂方法模式的核心,它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。
2、具体工厂角色:它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。
3、抽象产品角色:它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。
4、具体产品角色:具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。
工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说,这样便分担了对象承受的压力;而且这样使得结构变得灵活 起来——当有新的产品产生时,只要按照抽象产品角色、抽象工厂角色提供的合同来生成,那么就可以被客户使用,而不必去修改任何已有 的代码。可以看出工厂角色的结构也是符合开闭原则的!