设计模式之禅

最新推荐文章于 2021-02-07 15:25:59 发布

原创最新推荐文章于 2021-02-07 15:25:59 发布 · 650 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#设计模式 #生产者消费者 #工厂模式 #模版模式 #装饰者模式

java 专栏收录该内容

16 篇文章

订阅专栏

代码，是写给人看的，是写给机器运行的

这句话不知道是在哪里看到的，当时似懂非懂。后来细细品味了一番，觉得还是有道理的。
回想在做项目的时候，我们所写的代码确实能够做到后半部分，写给机器运行是个必备的条件。然而，前半部分呢，代码是写给人看的这一点很容易被忽略吧。每每想起以前接受别人的项目，甚至是自己以前写的项目，看到那些仙风道骨一般的代码，都要花不少时间来整理代码间错综复杂的关系，从交叉引用中去剥离，从基类设计中去回归等等，这样一来效率实在是太低。
究其原因，还是我们缺少对一种合理的规范的遵循，这种规范不仅是代码规范，还有设计层面上的规范，而这种规范的一个重要部分就是设计模式。设计模式能够帮助我们组织类和对象以解决某种特定场景下的问题，并且建立弹性的代码设计，可维护、可变化。（知乎上回答问题，都要问是什么，为什么，我们先来了解一下设计模式是什么，再了解为什么要运用设计模式，以及为什么在特殊情境下会有颠覆设计的说法）

设计模式概述

很多人都了解过设计模式，也知道大名鼎鼎的（GOF）总结的23种模式。这23中设计模式都是面向对象（OO）的，但是还有其他非OO的设计模式，比如生产者——消费者模式等等。下面会对生产者、消费者模式进行讲解，此外会把重心放在GOF的23中模式的解析上。

非面向对象的设计模式

生产者——消费者模式

说起生产者——消费者模式，想必大家都会想到高中生物学的案例。生物学中讲的生产者——消费者呈现了一种此消彼长的关系，从而维持了动态平衡，在计算机科学中则是表示资源的合理利用率，呈现的是数据的流转使用率。生产者负责生产数据，消费者负责消费数据，生产的数据多了，消费者消费来不及，供大于求，数据就堆积了；消费者需要的数据多了，生产者生产来不及，求大于供，数据就稀缺了。那么，有没有一种合理的方式使得生产者生产的数据够用且效率比较高。于是，我们加入了缓冲区，让生产的数据放入缓冲区中，当需要时消费者就能够从缓冲区中获取数据。
加入缓冲区的做法是有一些优点的：

支持并发
考虑让消费者直接向生产者获取数据，消费者要等待生产者将数据传递出来返回，在等待的这段时间内，消费者是阻塞的，什么事情都没做，纯粹在等待。而加入缓冲区解耦以后，双方各自独立，不需要互相等待。
灵活调配
生产者将数据放入缓冲区，消费者消费速度慢了，就可以把生产者生产的速度也调慢；当消费者消费速度快了，就可以把消费者的速度也调快。

面向对象的设计模式

装饰者模式

装饰者模式是保持主体不做改变的条件下，为主体添加额外的组件来装饰主体，换句话说，就是把原来写在主体里面作为装饰的代码抽出来放在装饰类中，这样在装饰变更的情况下，就可以只变更装饰类的代码，不用去改变主体的代码。用委托来实现。
其中：装饰者和被装饰对象需要拥有相同的超类型。装饰者可以在所委托被装饰者的行为之前或者之后，加上自己的行为，已达到特定的目的。

注意点
利用装饰者模式，常常造成设计中有大量的小类，数量众多。但是，如过你已经了解了装饰者的工作原理，以后当使用别人的大量装饰的api时，就可以很容易地辨别出他们的装饰者类是如何组织的，以方便用包装方式取得想要的行为。

继承和接口并非万能

继承并不能非常笼统的解决面向对象的问题，因为子类的行为可能是父类没有的，或者是不需要父类提供的。接口也是不能解决问题，没法让子类实现代码复用。在设计模式中，需要把会变化的部分取出并封装起来，一遍可以改动或扩充此部分，而不会影响不需要变化的其他部分。即系统中的某部分改变不会影响其他部分。

策略模式

定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

工厂模式

创建对象的代码放在哪里，是解耦的关键，因为所谓的耦合，就是产生了直接依赖，如果把这些直接依赖转移到工厂类中，就可保证原有类的纯粹。这种做法就是依赖倒置原则：依赖抽象，不依赖具体类。底层组件和高层组建都依赖共同的抽象。（派生对象来源于一个抽象：接口或抽象类）。工厂模式适用于类需要改变的时候，去思考实例化的代码该放在哪里的情况。抽象工厂模式可以定义多个接口来对应多个产品族，工厂方法模式只定义一个产品族单个接口。