一周两个设计模式—设计模式之外观模式(第四周)
【摘要】 业务场景上回书说道天庭万年单身汪小犬使用装饰器模式完美解决了添加咖啡种类和咖啡属性的问题顺便有大赚了一笔自己赚了20两黄金。PS:二郎神赚了5880!整体系统运行了几年没有任何问题(人间一年天上一日)。可是随着业务的扩张又遇到了新的问题。这不今天小犬正在和玉兔愉快玩耍,天王的小公子哪吒踩着风火轮火急火燎得来了。“小犬,系统又有新需求了。由于市场太好,人们经常一点就是好几杯不同种类的咖啡,所...
业务场景
上回书说道天庭万年单身汪小犬使用装饰器模式完美解决了添加咖啡种类和咖啡属性的问题顺便有大赚了一笔自己赚了20两黄金。PS:二郎神
赚了5880!整体系统运行了几年没有任何问题(人间一年天上一日)。可是随着业务的扩张又遇到了新的问题。这不今天小犬正在和玉兔愉快
玩耍,天王的小公子哪吒踩着风火轮火急火燎得来了。
“小犬,系统又有新需求了。由于市场太好,人们经常一点就是好几杯不同种类的咖啡,所以经过大佬的决定推出套餐服务,咱们的系统就得升级了,
限时1天完事,否则直接推出南天门。对了,通过套餐订的比单独订购的便宜且不能同时出现价格,当然套餐是提前编辑好的”
小犬一听就急了,赶紧扔下玉兔去搬砖了。
问题分析
这个其实就是多杯咖啡的绑定,至于如何绑定客户并不关心,他们关心的就是喝到想喝的咖啡,至于顺序、制作流程什么的都不关心,小犬
慢慢的在心里有了一个想法。(其实不是很合适,但是选模型选错了只能硬着头皮讲了)
首先生成A、B、C三种套餐
class ComboA {
fun make(){
var coffee = ShortBlack() as Coffee
coffee = Sugur(coffee)
coffee.price = coffee.cost()
Log.v("套餐A=======","描述:${coffee.description}======价格${coffee.price}元")
}
}
class ComboB {
fun make(){
var coffee = ShortBlack() as Coffee
coffee = BigCup(coffee)
coffee.price = coffee.cost()
Log.v("套餐A=======","描述:${coffee.description}======价格${coffee.price}元")
}
}
class ComboC {
fun make(){
var coffee = ShortBlack() as Coffee
coffee = Sugur(coffee)
coffee.price = coffee.cost()
coffee = BigCup(coffee)
coffee.price = coffee.cost()
Log.v("套餐A=======","描述:${coffee.description}======价格${coffee.price}元")
}
}
然后通过一个中间类来管理这个,这样代码中就可以直接调用这个类来实现了,收工。
class AppearCombo {
var comboA = ComboA()
var comboB = ComboB()
var comboC = ComboC()
fun comboA() {
comboA.make()
}
fun comboB() {
comboB.make()
}
fun comboC() {
comboC.make()
}
}
这就是外观者模式也就是门面模式的实现方式
定义:
门面模式是对象的结构模式,外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口,使得子系统更易于使用。
优点:
● 松散耦合
门面模式松散了客户端与子系统的耦合关系,让子系统内部的模块能更容易扩展和维护。
● 简单易用
门面模式让子系统更加易用,客户端不再需要了解子系统内部的实现,也不需要跟众多子系统内部的模块进行交互,只需要跟门面类交互就可以了。
● 更好的划分访问层次
通过合理使用Facade,可以帮助我们更好地划分访问的层次。有些方法是对系统外的,有些方法是系统内部使用的。把需要暴露给外部的功能集中到门面中
,这样既方便客户端使用,也很好地隐藏了内部的细节
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)