鱼的做法有很多,例如蒸、炖、炸等等。假设现在需要蒸一条鱼的,最直接的做法是创建SteamFish的实例,并执行其cook方法,代码如下:
SteamFish.java:
public class SteamFish {
public void cook() {
Log.d(MainActivity.TAG, "蒸鱼");
}
}
MainActivity.java
SteamFish steamFish = new SteamFish();
steamFish.cook();
运行结果如下:
蒸鱼
突然有一天,对蒸的鱼吃腻了,想试一下炖鱼,则需要修改代码,创建一个StewFish的实例,并执行其cook方法,代码如下:
StewFish.java
public class StewFish {
public void cook() {
Log.d(MainActivity.TAG, "炖鱼");
}
}
MainActivity.java
StewFish stewFish = new StewFish();
stewFish.cook();
运行结果如下:
炖鱼
通过上面代码可以看出,都是使用的“new”实例化一个具体的类,这里是针对于实现编程,而不是针对于接口编程,当修改烹饪鱼的方式时,就必须重新对客户端的代码进行检查和修改,通常这样修改过的代码很难维护和更新,并且很容易犯错。从技术层面上看,new一个具体的类确实是没有错的,但是当代码大量使用具体的类时,这相当于给自己找麻烦,因为一旦加入新的具体类,就必须修改代码,也就是说,代码并非“对修改关闭”,所以我们要“找出会变化的方面,把它们从不变的部分分离出来”。
现在对代码做一下优化,因为蒸鱼和炖鱼都实现了cook这个方法,此时把cook方法抽出来,统一用一个Fish的接口实现,下面需要定义一个Fish的接口,代码如下:
public interface Fish {
void cook();
}
分别让SteamFish和StewFish对Fish的接口进行实现,代码如下:
SteamFish.java
public class SteamFish implements Fish {
@Override
public void cook() {
Log.d(MainActivity.TAG, "蒸鱼");
}
}
StewFish.java
public class StewFish implements Fish {
@Override
public void cook() {
Log.d(MainActivity.TAG, "炖鱼");
}
}
此时客户端的需要声明一个cookFish的方法,代码修改如下:
MainActivity.java
private void cookFish(String type) {
Fish fish = null;
if (type.equals("steam")) {
fish = new SteamFish();
} else if (type.equals("stew")) {
fish = new StewFish();
}
if (fish != null) {
fish.cook();
}
}
当客户端调用cookFish(“steam”)时,运行结果如下:
蒸鱼
当客户端调用cookFish(“stem”)时,运行结果如下:
炖鱼
很明显,此时cookFish方法对修改也不是关闭的,但是现在我们已经知道了鱼的选择 (具体类的实例化)是改变的,烹饪的方法(cook方法)是不变的,下面进一步对代码进行封装。
现在将创建对象的代码已到cookFish之外,此时需要一个新的对象专门负责创建对象,我们称这个新的对象为“工厂”,下面创建一个CookFactory类,具体代码如下:
CookFishFactory.java
public class CookFishFactory {
public static Fish createFish(String type) {
Fish fish = null;
if (type.equals("steam")) {
fish = new SteamFish();
} else if (type.equals("stew")) {
fish = new StewFish();
}
return fish;
}
}
MainActivity.java
private void cookFish(String type) {
Fish fish = CookFishFactory.createFish(type);
if (fish != null) {
fish.cook();
}
}
到此,简单工厂模式已经创建完毕。
当有新的烹饪方式加入时,CookFishFactory也需要实现对新的烹饪方式进行支持,这里也违反了开闭原则,我们可以利用反射解决该问题,重新修改CookFishFactory里的createFish方法,具体代码如下:
CookFishFactory.java
public static Fish createFish(String type) {
try {
Class fish = Class.forName(type);
return (Fish) fish.newInstance();
} catch (ClassNotFoundException e) {
e.printStackTrace();
}catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
return null;
}
使用反射做到了多扩展开放,对修改关闭的原则,但是这里使用了类的全名,所以这里使用哪种方式,得权衡下利弊。
简单工厂模式属于类的创建型模式,又叫做静态工厂方法模式。通过专门定义一个类(CookFishFactory)来负责创建其他类(SteamFish、StewFish)的实例,被创建的实例通常都具有共同的父类。
工厂角色(CookFishFactory)
简单工厂模式的核心,它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用,创建所需的具体产品对象。
抽象角色(Fish)
简单工厂模式所创建的所有对象的父类,它负责描述所有实例共有的公共接口。
具体角色(SteamFish、StewFish)
简单工厂模式所创建的具体产品对象。
用户在需要创建对象时,可以直接去工厂类里创建自己所需要的实例,而不需要了解创建这些对象的细节。
由于工厂类集中处理了所有实例的创建逻辑,所以在“高内聚”方面做的不好,随着产品不断的增多,工厂类可能也要做出相应的修改,扩展性不是很好。
用法如下:
context.getSystemService(Context.POWER_SERVICE)
具体代码如下:
@Override
public Object getSystemService(String name) {
ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name);
return fetcher == null ? null : fetcher.getService(this);
}
SimpleFactory工程