陀螺愣了愣，久久盯着招财，仿佛看到了当年自己刚学习编程的样子，对一切充满好奇，对代码又有点洁癖，欣慰地说道：“说得好啊，那我们尝试利用反射继续优化一下吧。”
客户端的代码优化如下
“到此SimpleCatFoodFactoryV2就符合了开闭原则，但是这里利用反射的一个基本原则是所有对象的构造方法必须保持一致，如果对象创建的过程比较复杂而且各有特点，那么优化到这一步或许并不是最好的选择，记住优化的原则——合适就好”，陀螺补充道。
招财对陀螺的这一番优化和解说佩服不已，心想实习遇到这么个好老板好师傅，平时还能试吃自己最爱的猫粮，这简直就是在天堂啊。
猫粮公司的扩张日子一天天过去，公司在陀螺的运营下经营有成，计划在全国各地建立分公司。为了保证服务质量，陀螺希望各个分公司能够使用他们经过时间考验的代码。
但是不同的分公司需要根据当地特色生产不同口味的产品，比如山东生产「葱香猫粮」、「大酱猫粮」，湖南生产「辣子猫粮」、「剁椒猫粮」...
招财心想，这不简单嘛！继续利用SimpleCatFoodFactoryV2，让各个公司的新款猫粮继承CatFood不就可以了嘛！
但是转念一想，随着每个分公司的产品链的丰富，获取产品的创建过程会有差异，那么SimpleCatFoodFactoryV2的职责会变得越来越多，像一个万能的类，不方便维护。
招财想到可以为每个分公司创建独立的简单工厂，然后将具体的简单工厂对象绑定到PaoMaChang对象中，顾客下单的时候只要指定对应的分公司的工厂和口味就可以进行下单了。
PaoMaChangV3重构如下
将工厂本身也做了个抽象，创建ICatFoodFactory接口
各分公司的工厂代码
各种口味的猫粮代码如下
产品类对应的UML图为
顾客下单「湖南分公司」的「剁椒猫粮」的代码就变成了这样
到此，招财重构完了代码，经过细心检查系统终于上线了，各地分公司使用这套系统有条不紊地开展起自己的业务，形势一片大好！
之后的某一天，招财接到陀螺的电话，让他火速前往陀螺的办公室，招财一路战战兢兢，一直在想是不是自己的代码出了问题。来到办公室，陀螺招呼招财来到他旁边坐着，指着满屏的代码说道：“别害怕，你的代码到目前为止没有出什么bug。你为每一个分公司单独创建自己的简单工厂，又把简单工厂对象作为参数注入到了PaoMaChang类中，能看得出来你最近没少在代码上下功夫。只是我在审查各分公司代码的时候发现一个潜在的隐患。”说罢，打开了某分公司的代码给招财看。
招才看到，湖南分公司的技术人员在order()方法中擅自添加了一个pack()打包的方法，陀螺继续说道：“先不管这个逻辑加的对不对，光是分公司能够改动我们的核心代码这一点就是有风险的，你需要想个办法，既能让每个分公司自由创建产品，又能保证我们的核心功能不被改变，核心逻辑只能由我们来定。”
“确实是个问题，目前各个分公司的下单逻辑都是自己定义的，我们需要提供一个真正的“框架”，让他们按照我们的标准来进行业务逻辑。”
“没错！”，陀螺欣慰地看着招财。
“既然如此，我可以把我们的PaoMaChangV3改成抽象的，命名为PaoMaChangV4吧，让各个子公司继承这个类，然后为order()添加final关键字，禁止子类进行覆写，这样他们便只能用我们的下单逻辑了”，招财一遍思考一边说。
“那你打算怎么让子公司能自由控制各种产品呢？”，陀螺问道。