对于训练有素的小偷来说，背后会有一个比较强大的小偷培训机构，或者说小偷公司，运营这小偷的日常工作。就想牛群，冯巩“小偷公司”里面有很多部门一样。
当然在之前的简单工厂中有了，将具体的偷什么的动作（Operation）发配给子类去做了，但是在小偷公司的高层发现，这样做也不是一个办法，所有的逻辑都定义在
工厂方法中，那如果我要增加一个偷车的动作，那就要去对现行的工厂方法去做修改。当然这是违背了“开发-闭合原则”的。对扩展开放，对修改闭合。
那好我就重新在分配中层管理员，负责专项的偷盗功能。比如我要偷自行车，那我就专门指派一个训练偷自行车的管理人员。专门负责生产专项偷盗技术的。这叫术业有专攻嘛
那好。就对每一个偷盗技术做一个专项工厂。这就是工厂方法模式了。直接来看类图吧：
每个类的代码就不贴了这里只给出客户端的实现代码：
package DesignPattern.FactoryMethodPattern.StealCompany;
public class StealCompanyTest {
/** * * * * @param args */public static void main(String[] args) {
// TODO Auto-generated method stub IStealCompanyFactory StealOperFactory = new StealWalletFactory();StealOperation StealOper = StealOperFactory.CreateStealOperation();
StealOper.Steal();
}
}
这里通过具体的偷盗的工厂产生的一个对象，然后一个IStealCompanyFactory的接口的变量指向该对象。然后通过调用该对象实现了IStealCompanyFactory的方法，
CreateStealOperation来产生一个StealOperation具体的对象。然后调用重写了StealOperation中的Steal的方法。
输出结果：
我是偷钱包的！OH,BABY!
总结：
工厂方法模式还会避免不了选择，因为如果我要偷钱包，就实例化偷钱包的工厂，然后让偷抢包的工厂去生产偷钱包的操作。但是它把简单工厂中的内部逻辑移动到了客户端代码
进行。如果我要偷手机，我只要在客户端加入偷手机的内容就可以了。如果，我要加入偷车的操作，那么我只需要新建一个实现了IStealCompanyFactory接口的偷车的具体工厂类，
然后新建一个重写了StealOperation中Steal方法的偷车的类。这样的话不会对任何现有的代码做任何修改。当然也就很好的遵循了“开放--闭合原则”对修改闭合，对扩展开放。
工厂方法模式简直是这个原则的奶妈啊！一手养大的！
最后给出工厂方法的经典UML类图：
