为了跟别人的有所区别,我这里直接就用接口来实现抽象工厂了,毕竟接口也是一个抽象类么。我想尝试用不一样的角度来介绍抽象工厂。
抽象工厂,怎么说呢,我觉得它是一个把代码工业化的模式,对于实现流水线式的功能的程序会更适合一点,但是灵活性不够,不适用于一些小程序。
以下沿用了机器人的例子。
首先要提出一个叫做“系列”的概念来区分跟“类型”区分。
什么叫系列呢? 就是指一个或者多个类型,它们的类型不同,但是他们拥有相同的属性和功能方法,典型的例子就是几种实现了相同的几个接口的类。那么它们就属于一个系列。
比如这里的机器人除了实现Speak打招呼功能,还额外实现了Clean打扫功能。如果Girlfriend也只会Speak和Clean,那么可以说Girlfriend和机器人是属于一个系列的。 8)
但是,Girlfriend事实上还能做一些啪啪啪的事情 :evil: ,所以这时候它们就不是一个系列的了。
用抽象工厂的好处,就是能很方便的管理同一系列的类别,如果其中一种类别出问题不能用了,可以很方便的就换成另外一种同系列类别,下面就用机器人类来举例:
机器人系列都拥有一下两种功能:Speak和Clean
功能模块接口Speaker:
功能模块接口Cleaner:
工作者(或许机器人或许是人类)的生成工厂接口:
机器人A的生成工厂,实现或者说继承了“工作者”生成工厂类
实现类,或者说是应用代码:
从上面这么多代码看起来,抽象工厂其实实现起来很麻烦,如果有一天机器人系列又多了一种跳舞功能,那么很多地方都要重写。
但是它的好处就在于,当RobotA这种类型的机器人停产的时候,你可以很方便的在应用代码里用同系列的new RobotBFactory()替换掉就可以了,其他的什么都不需要改。
所以我认为抽象工厂更加适合于那种功能模块已经非常成熟,基本上不需要太多修改,但是会随时替换掉实现这些功能模块的类的那种情况。
比如说数据库链接,所有的JDBC其实功能模块几乎一样,只不过种类不同,有些是SQL-Server,有些是MySQL,那么这时候用抽象工厂来写就比较方便了。
抽象工厂,怎么说呢,我觉得它是一个把代码工业化的模式,对于实现流水线式的功能的程序会更适合一点,但是灵活性不够,不适用于一些小程序。
以下沿用了机器人的例子。
首先要提出一个叫做“系列”的概念来区分跟“类型”区分。
什么叫系列呢? 就是指一个或者多个类型,它们的类型不同,但是他们拥有相同的属性和功能方法,典型的例子就是几种实现了相同的几个接口的类。那么它们就属于一个系列。
比如这里的机器人除了实现Speak打招呼功能,还额外实现了Clean打扫功能。如果Girlfriend也只会Speak和Clean,那么可以说Girlfriend和机器人是属于一个系列的。 8)
但是,Girlfriend事实上还能做一些啪啪啪的事情 :evil: ,所以这时候它们就不是一个系列的了。
用抽象工厂的好处,就是能很方便的管理同一系列的类别,如果其中一种类别出问题不能用了,可以很方便的就换成另外一种同系列类别,下面就用机器人类来举例:
机器人系列都拥有一下两种功能:Speak和Clean
功能模块接口Speaker:
package com.iteye.bolide74.impl;
public interface ISpeaker {
public void Speak(String msg);
}
功能模块接口Cleaner:
package com.iteye.bolide74.impl;
public interface ICleaner {
public void Clean();
}
工作者(或许机器人或许是人类)的生成工厂接口:
package com.iteye.bolide74.impl;
public interface IWorkerFactory {
public ICleaner getCleaner();
public ISpeaker getSpeaker();
}
机器人A的生成工厂,实现或者说继承了“工作者”生成工厂类
package com.iteye.bolide74.action;
import com.iteye.bolide74.impl.ICleaner;
import com.iteye.bolide74.impl.ISpeaker;
import com.iteye.bolide74.impl.IWorkerFactory;
public class RobotAFactory implements IWorkerFactory {
@Override
public ICleaner getCleaner() {
return new RobotCleaner();
}
@Override
public ISpeaker getSpeaker() {
return new RobotSpeaker();
}
}
实现类,或者说是应用代码:
package com.iteye.bolide74.tester;
import com.iteye.bolide74.action.RobotAFactory;
import com.iteye.bolide74.impl.ICleaner;
import com.iteye.bolide74.impl.ISpeaker;
import com.iteye.bolide74.impl.IWorkerFactory;
public class Tester {
public static void main(String[] args) {
IWorkerFactory workFactory=new RobotAFactory();
ICleaner cleaner=workFactory.getCleaner();
ISpeaker speaker=workFactory.getSpeaker();
cleaner.Clean();
speaker.Speak("hello,world!");
}
}
从上面这么多代码看起来,抽象工厂其实实现起来很麻烦,如果有一天机器人系列又多了一种跳舞功能,那么很多地方都要重写。
但是它的好处就在于,当RobotA这种类型的机器人停产的时候,你可以很方便的在应用代码里用同系列的new RobotBFactory()替换掉就可以了,其他的什么都不需要改。
所以我认为抽象工厂更加适合于那种功能模块已经非常成熟,基本上不需要太多修改,但是会随时替换掉实现这些功能模块的类的那种情况。
比如说数据库链接,所有的JDBC其实功能模块几乎一样,只不过种类不同,有些是SQL-Server,有些是MySQL,那么这时候用抽象工厂来写就比较方便了。