会用JOIN,却不懂编程的“程序员”(4)

1.1. 前言

前面的文章让我们的程序能轻松的应对业务的变更了。这本该是一件皆大欢喜的事。但是,本系列文章的目的不仅仅在于此,而且还没有满足哪些要少些代码的程序员的要求。

1.2. 请不要来虚

“装饰器模式”想必这对程序员来说并不陌生。基本上问每一个程序员,他们都能回答的头头是道。而且有写面试官肯定在面试的时候回问(这个框架用了什么模式啊。用装饰器有什么好处啊)。

我想说的是,你知道装饰器那么多。你在你的项目中使用了这种模式么(除了使用框架给你分装的)?我想有大半的程序员没有在自己的项目中编写装饰器来使用吧。所以还是恳求,知道就用上吧。

1.3. 目的

本篇文章的目的是使用装饰器来方便和简化我们开发,让我们的业务方法变简单。

1.4. 实现程序

我们使用三个装饰器方法来完成我们的目标:

装饰器方法名 用途
join_order 和订单信息进行合并(无论什么数据只要有user_id做关联)
join_order_good 和订单商品信息进行合并(无论什么数据只要有order_id做关联)
join_coupon 和券信息进行合并(无论什么数据只要有order_id做关联)

 

第一步、获取用户信息和获取订单信息进行程序拼凑后返回结果(在装饰器join_order方法中实现)。

第二步、获取订单商品信息并且并和“第一步”获得的结果进行拼凑并返回结果(在装饰器join_order_good方法中实现)。

第三步、获取订单券信息并且和“第二步”获得的结果进行拼凑并返回结果(在装饰器join_coupon方法中实现)。

输出结果:

源代码:use_decorator

现在来看上面的业务方法get_order_detail现在是不是变的简单了?它总共还不到10行代码。较劲的肯定会说你别忽悠我了,你那只是业务代码少了,但是你每增加一个需求你都要添加一个相关的装饰器(如果需求说需要展示订单的门店信息我们就需要创建一个类似join_store的装饰器方法并在业务方法上使用@join_store来实现),你只是把工作量放在了编写装饰器上面,本质上并没有改变。我只能说哎,竟然被你发现了。

我们继续回避代码量这个话题,看看我们代码应变需求的能力。如果需求说我们不需要展示券的信息了。这时我们只需要在get_order_detail方法上将@join_coupon给删除了就好了。这真是太方便了。但是需要增加业务的话可能就需要再次编写一个装饰器(如果是相同条件的就不用了)。

下一篇文章我们就来满足你真正的代码少扩展好的装饰器。

 

昵称:HH
QQ:275258836
ttlsa群交流沟通(QQ群②:6690706 QQ群③:168085569 QQ群④:415230207(新) 微信公众号:ttlsacom)

感觉本文内容不错,读后有收获?

逛逛衣服店,鼓励作者写出更好文章。

HH

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: