单例模式不用说，重点关注实现方式，原型模式也不想多说。重点关注的是工厂模式、抽象工厂和建造者模式。这些设计模式，实现起来其实都不难，关键是要从场景需求入手，理解其适合出现的场景。当然，这些设计模式的目的，就是让我们在创建和使用对象的时候更加简洁方便。
1、工厂模式：当你明确有那么一些类要在同一个场景使用，他们的属性和行为都有相同的结构，使用是只需要知道父类而无须了解子类本身类型时，就可以使用工厂模式。实现流程一般就是，定义一套接口，让所有子类继承该接口，然后定义一个工厂类，接受不同参数来创建不同子类。在外面使用时，工厂所创建的所有对象，都只暴露了其实现的接口。
例如我们去饭店吃饭，点的各种菜都是被吃：
（1）我们抽象出一个接口叫做菜，它的表现就是被吃
（2）然后定义各种菜实例，来继承‘菜’接口，并实现‘被吃’这个方法。比如苦瓜被吃时，打印‘好苦’，豆腐打印‘好软’
（3）然后找到厨师这个工厂，让它帮我们生产，生产过程就写到厨师类中，厨师接到‘菜名’参数，返回具体的菜的实例
（4）最后我们开始闭着眼吃，对于每种菜，我只需要知道它是菜，知道它可以吃，而不必知道是苦瓜还是豆腐。所以创建的时候，传入菜名返回菜，然后到吃的时候，才知道好软、好苦。这里的重点时，我在完成吃饭这个动作时，只需要跟厨师说，然后做吃的动作，不需要自己管各种菜怎么做。
ShapeFactory shapeFactory = new ShapeFactory();
Shape shape1 = shapeFactory.getShape("CIRCLE");
2、抽象工厂：当你明确有那么一些类要在同一个场景使用，他们依照属性和行为可以分为几个类簇，使用时只需要知道他是属于哪个类簇而无需知道自己本身类型时，就可以使用抽象工厂模式。实现流程上，相对工厂模式，就是在工厂之上加一个层级，叫工厂的工厂（就是抽象工厂），这个层级是可以不断扩展的。在外面使用时，工厂所创建的所有对象，都只暴露了其所属类簇。
例如我们去饭店吃饭，要点菜和饮料，菜的表现是被吃，饮料是被喝：
（1）定义两种接口‘菜’、‘饮料’，分别是被吃和被喝
（2）定义各种菜和饮料的实力，实现‘被吃’、‘被喝’方法
（3）找到厨师这个生产菜的工厂，和服务员这个提供饮料的工厂，传入参数，返回菜和饮料实例
（4）最后找一个人给我喂饭的人，我点了喝的他就找服务员送来，点了吃的就找厨师做，我只找他，不再找厨师或服务员
（5）最后我们开始闭上眼睛吃。我说‘酒’，喂饭的人（抽象工厂）就找到服务员（生成饮料工厂），告诉他要酒（传入参数返回酒），然后拿着一个瓶子就‘喝’，说‘好酒！’。我说豆腐，喂饭的人就找到厨师，做好豆腐，夹一筷子喂我嘴里，我说‘好吃’。这里的重点是我在完成吃豆腐、喝酒这些不同任务时，只需要跟喂饭者交流，然后做吃和喝的动作，不管那些东西怎么来，且传参简单。
AbstractFactory shapeFactory = FactoryProducer.getFactory("SHAPE");
Shape shape1 = shapeFactory.getShape("CIRCLE");
3、建造者模式：当你明确有那么一些类要在同一个场景使用，他们要相互组合成各种不同的整体才能完成任务。使用时，我们只需要这些整体，而不需要知道这里组成部分。
例如我们在家里点餐，店里提供几种固定的套餐：
（1）定义两种接口‘菜’、‘饮料’，分别是被吃和被喝
（2）定义各种菜和饮料的实力，实现‘被吃’、‘被喝’方法
（3）店家配置各种套餐，如啤酒烤鸭套餐
（4）点餐时，我只需要告诉店家，要那种套餐，就完成了点餐任务，不需要知道各种部分怎么生产、配套
MealBuilder mealBuilder = new MealBuilder();
Meal vegMeal = mealBuilder.prepareVegMeal();
4、区别和优缺点：
（1）工厂模式和抽象工厂在使用时，只需一句代码里传入一个参数就能创建好一个对象，而建造者模式通常需要多句代码和多个参数才能创建好一个对象。
（2）事实上，在需求经常变动的项目中，工厂模式和抽象工厂模式的应用机会很有限，因为二者都是基于继承实现的，当需求变动需要改接口时，各个子类都要改动，改起来应该是很蛋疼的。所以工厂模式和抽象工厂模式的应用环境要求比较苛刻，就是需求稳定且子类的属性和行为都规范统一，因此在使用前要慎重考虑。而建造者模式是基于继承和组合配合实现，扩展性和应用场景适应性方面就要好得多。
网友评论