一、简单工厂模式:
将产品做一层抽象,用工厂去获得产品实例,通过给予工厂产品参数(枚举或字符串)来获得自己想要的实际产品。(让用户只专注于参数,不用考虑创建逻辑)
二、抽象工厂模式:
将产品做一层抽象,工厂也做一层抽象,用一个工厂生成器类,将参数(枚举或字符串)提供给工厂生成器来获得实际工厂,再给实际工厂提供参数(枚举或字符串)来获得实际产品。
三、建造者模式:
传统初始化对象的痛点:在对成员变量进行赋值的时候,该成员变量可能需要一定的前置操作,而要使用该对象的程序员必须自己手动完成这些前置操作后才能对该成员变量赋值。除此之外,根据对成员变量赋值顺序不同,所得到的对象的作用也会不同。
(让用户只专注于具体实现,而不纠结于繁杂的参数及细节)
建造者适用于总共的建造产品少,可是它们的细节差距非常多的情况。
...
越说越懵,直接举个例子:你是一个赛车手,名叫张弛,五年前因为开快车被吊销驾照,现在你要夺回一切。首先,你需要一辆赛车。作为一个只会开车的赛车仔,你自己并不知道赛车的哪个配件怎么样:一个S级OC发动机、锻造曲轴、锻造连杆、锻造活塞、轻量化气门、盖瑞特涡轮、考斯沃斯Omega、ICD Plus数据记录单元......(得了吧你读都读不顺怎么能自己拼出一辆车来呢),正确方式是:你得走到俱乐部,找到叶经理,告诉他,我要我以前开的那辆车,或者直接告诉他,我要林振东同款赛车,在这里你的知识量仅为车有两种实现。
叶经理皱皱眉头,说行,三天后来取。
然后叶经理找到专门做这个车的团队(丰田LZD团队)(除此之外,还有大众ZC团队,只是叶经理暂时不需要他们),团队能做的事都是:装发动机、装曲轴、装活塞、装涡轮......,叶经理告诉他们,我要定制一辆你们的车。
这些团队很懒,不布置任务,他们就不工作,因此叶经理来活了:给团队下达任务:做发动机装上、做曲轴装上、做活塞装上......
丰田团队的红衣少年们收到这个任务之后就开始将各个配件组合成一辆车了(S级OC发动机、锻造曲轴、锻造连杆、锻造活塞、轻量化气门、盖瑞特涡轮、考斯沃斯Omega、ICD Plus数据记录单元.....)。做完了,团队返回给叶经理这辆车。
最后叶经理给你这辆车,故事结束。
回想一下,你并没有告诉叶经理(Director)具体细节,你只说了要哪种实现,他就给你了。而所有的细节配件都是团队(Builder)完成的,这个团队可以是丰田(ToyotaBuilder),也可以是大众(VolkswagenBuilder)。他们帮你完成了一辆车(Toyota),这两个团队产出的车为什么不同?因为他们适用的配件不同。为什么你不自己拼出一辆车?因为细节太复杂,你把握不住,万一你在放座椅前先把车门装上了,那这车就做不下去了。
组成:
产品接口、产品具体实现类、建造器抽象类、建造器具体实现类、经理类
四、装饰器模式:
对某一接口的实现类进行装饰,被装饰类实现的是某一种接口,装饰类首先为一个抽象类,类内部有被装饰类的成员变量。装饰类提供相较其被装饰类更丰富、更多的功能。相较于代理模式,代理模式的代理类更像是一种为被代理的类提供其无需关心的必要拓展,而装饰模式更像是利用被装饰类的实例对外提供更丰富的功能。比如Java I/O中的BufferedReader提供了比Reader更强大的功能,是Reader的装饰类。而代理的目标并不是提供更强大的功能,而是对被代理的类做一些其本身并不需要完成的一些补充任务。
且一般情况下,用户不能直接使用被代理对象,只能通过代理类与被代理对象间接联系。而装饰者对于原来的类来说并不是必需的,你依然可以使用原来的类,它只是功能更少。
组成:
装饰器抽象类,装饰器具体实现类,被装饰接口,被装饰接口实现类。
五、适配器模式
当服务调用者调用方式与服务提供者提供的接口不一致时,可以使用适配器来适配两端。适配器模式有两种实现方式:一是适配器组合原来的服务提供者对象,二是适配器继承原来的服务提供者对象。类适配器用继承的方式实现,对象适配器用组合的方式实现。
简单来说,服务调用者使用适配器提供给它的接口,而不是原来的服务提供者提供的接口,适配器既可以通过继承原来的服务提供者来进行适配操作,也可以往自己内部添加一个服务提供者通过调用它来进行适配操作。至于什么时候用哪种?你自己适配的时候觉得哪种方便你就用哪种呗,你要用继承,那你就得重写对应方法,你要用组合,你就可以直接调用,你就算最后写的麻烦比别人多,那又怎么样呢?自己用哪个拿手就用哪种,何必去纠结。
组成:
适配器接口(你得让调用者用你提供的接口),适配器实现(你不能给个空壳子),服务提供者(本来就在解决这俩端的问题,它自己都不在那还解决啥),服务提供者接口(说到底就是这个接口不匹配的事)
(改日继续更)