到这里我们实现了客户要求的两种类型商店的算法的需求，但是作为一种好的设计架构，还应该考虑到后面的需求变革，如果客户现在又增加了C类型商店和D类型商店，它们的算法要求又不一样，这个时候我们就需要进行C，D类型商店的创建，并继承Ishop接口，实现里面的方法，同时还得继续修改工厂类在switc中增加case进行捕捉创建相应的商店对象，一旦出现这样的情况，是不利于程序的扩展性和项目后期的维护性的。
优点：
简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。通过它，外界可以从直接创建具体产品对 象的尴尬局面中摆脱出来。
外界与具体类隔离开来，偶合性低。
明确区分了各自的职责和权力，有利于整个软件体系结构的优化。
缺点：
工厂类集中了所有实例的创建逻辑，容易违反GRASPR的高内聚的责任分配原则
虽然简单工厂模式能够适应一定的变化，但是它所能解决的问题是远远有限的。它所能创建的类只能是事先教考虑到的，如果需要添加新的类，则就需要改变工厂类了。
出现的上诉情况，应该如何解决，值得思考，将在下一个工厂方法模式中得到很好的解决。