第二篇:建造者模式
什么是建造者模式
建造者模式是一步一步创建一个复杂对象,允许用户不了解细节的情况下精细的控制对象的构造过程。使得复杂对象的构建与他的表示相分离,同样的构造过程可以创建不同的表示。
经典模式
在生活中我们经常买票,各种各样的票,我们这里要创建一个可以售卖多种票的程序。
首先是产品Product,他是一个抽象类,他有各种票都有的特征,以及票在购买当中会经历的状态,check,检测这张票的信息是否可靠(如生成时间,设备,渠道等),pay,对这张票进行支付,query,查询这张票的支付状态(如,金额是否一致等)
1 | package top.huyuxin.builder; |
现在这个程序出售两种票,一种火车票,一种汽车票
1 | package top.huyuxin.builder; |
1 | package top.huyuxin.builder; |
处理两种票的逻辑应该是一致的。
1 | package top.huyuxin.builder; |
但是细节肯定是不一致的,所以我们创建两个不同的Builder
1 | package top.huyuxin.builder; |
1 | package top.huyuxin.builder; |
当在完成票的生成到出票的过程,顺序应该是一定的,不能还没生成票就去支付,还没支付就去查询。所以需要一个指挥者(Director)来控制他们的进程
1 | package top.huyuxin.builder; |
这样我们就可以安心售票了
1 | package top.huyuxin.builder; |
结果:
1 | Ticket [ticketname=TrainTicket, isCheck=true, isPayed=true, isQuery=true] |
当我们的程序需要买别的票的时候,只需要再次继承抽象类Ticket,并创建处理对应票的Builder就可以了,在TicketProgram 里我们通过依赖注入的方式,使得即使有新的票出售只要逻辑一致,也能正常控制票的出售。
在经典的建造者模式当中Director的控制流程应该是可变的,创建多个不同的sellTicket()方法,通过调动builder的执行顺序产生不同的结果。这就是建造者模式。
填充模式
填充模式,你可能没听过,因为这是我自己起的名字。很多时候对象的构建伴随着很多很多参数的初始化,并且这些参数又不得不先初始化好,大量的setter和getter需要一个管理者来管理一波。比如刚刚的买票,买票可以但是现在的票都是实名制的,在购票前应先获取购票人信息。
于是就有了下面的代码:
1 | package top.huyuxin.builder; |
这使得原来逻辑清晰的Ticket类变得杂乱不堪,由于setter和getter过多可能在初始化的时候你可能漏了用户的sex或则age没有填上。
(翻不完的setter和getter)
于是我们创建一个对象信息的建造者,用来构建对象,在setter的时候我们return this这样使得可以链式调用,
1 | package top.huyuxin.builder; |
在Ticket类初始化的时候便写入的购票人信息
1 | package top.huyuxin.builder; |
在调用的时候也十分的清晰
1 | PersonInfo xiaoshuangInfo=new PersonInfo.Builder() |
结果:
1 | Ticket [ticketname=BusTicket, personInfo=PersonInfo [holdername=小双, sex=women, age=18, birthday=2000-01-01, address=旮旯], isCheck=true, isPayed=true, isQuery=true] |
通过使用这个填充参数的填充模式使得Ticket对象的构建与表示分离。在填充模式中没有指挥官(Director)但是用于对象的构建还是搓搓有余。