换个角度看设计模式

·  阅读 83

1. 引言

学习模式的时候,会不会这种想法,不就是接口,抽象类,属性组合这些基本语法吗?为啥搞这么复杂?

模式并不会改变编程语言的基础,我们是不是可以换个角度,从编程语言提供的基础能力来审视下。(本文使用JAVA语法展示,其他语言可能略有不同)

VS对比

  • 设计模式是通过场景,然后解释场景的解决方案。
  • 我们要做的是倒过来,先看语言有几种解决方案,合适的场景再选用方案的排列组合。

2. 类的组合

2.1 通过属性组合

面向对象的语言(比如JAVA)的类可以有属性与方法;属性可以是接口,也可以是类,属性提供是组合能力,来看下属性的威力,通过属性我们可以把职责委托出去。

来看下图,处于中央位置的服务类,把不同的功能点委托给ABCDE来处理,自身协调调度ABCDE就可以:

委托与封装变化.png

这样做的几点思考:

  • 变换点得到了分离,一个变化点发生变化,只需要改少数类的代码:比如服务A包装了业务A的变化,如果业务A发生变化,那么只需要修改服务类A就可以。
  • 服务类并不太关心ABCDE是类还是接口,委托出去了就可以。
  • 委托选用类,还是接口没有那么重要(很多人认为很重要),代码是可以改的,如果需要不同实现,必然会改成接口;相反如果永远只有一种实现,干嘛一定要出现一个接口?!

2.2 类持有接口

QA:为什么要讨论类持有接口,而不是类持有类呢?

因为模式都是处理复杂问题的,所以模式的设计基本都是持有接口(可以各种变换),持有类的场景上图就够说明了。持有类依然是一个强大的武器,简单并不意味弱小

来看下下图,具体类通过接口分离出一个变化点,接口有不同的实现。

类持有接口.png

  • 策略模式就是把策略(变化点)委托出去,可以有不同的策略实现。
  • Build模式就是把对象创建过程(变换点)委托出去。

2. 类的继承

继承提供了一种复用机制,同时也提供了封装变化的机制,变化封装不如组合彻底。

继承.png

这种不彻底封装有个好处,最少只要两个类,就可以完成复用和扩展(如果采用组合,至少要2个类+一个接口)。

比如模板方法模式,就利用了这种简化的特质:具体类里写框架代码,调用了抽象的方法,每个子类实现抽象方法。

补充知识1:JAVA提供的匿名类和Lamda表达式,可以让模板方法这种继承写起来更简单。

补充知识2:JAVA的接口已经开始支持Default方法实现,抽象父类也可以是接口,在某些场景,接口和抽象类是可以替换的。

模板方法可参考:模板方法设计模式与生活的关系

3.同时使用继承+组合

其实就是桥梁模式了,通过继承和组合分别暴露一个变化点,可以同时支持两个维度的独立变化。

桥梁模式.png

分类:
后端
分类:
后端
收藏成功!
已添加到「」, 点击更改