闲谈设计模式

Intro

设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。

了解这些前辈们总结出来的经验有助于帮助你写出来更优秀的代码，帮助你写出可扩展、可读、可维护的高质量代码。

在极客时间里推出了数据结构和设计模式的王争说了一句话，如果说“数据结构与算法之美”是教你写出高效的代码，那设计模式就是教你写出高质量的代码。

为什么要学习设计模式

1. 提升自己代码质量，告别写被人吐槽的烂代码
2. 提高复杂代码的设计和开发能力，设计出扩展性良好，可维护性更强，可复用性更好的代码
3. 让读源码、学框架事半功倍，学会设计模式，在看框架源码的时候会更好的理解框架中的一些功能设计
4. 为你的职场发展做铺垫，提升自己 code review 能力，把控团队代码质量

设计模式设计原则

设计原则是指导我们代码设计的一些经验总结，对于每一种设计原则，我们需要掌握它的设计初衷，能解决哪些编程问题，有哪些应用场景。只有这样，我们才能在项目中灵活恰当地应用这些原则。

• 单一职责原则

  对于一个类而言，应该仅有一个引起它变化的原因

  如果一个类承担的职责过多，就等于把这些职责耦合再一起，一个职责的变化可能会削弱或者抑制这个类完全其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。

• 开放-封闭原则

  开放-封闭原则是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。

  对于扩展开放，对于更改封闭

• 依赖倒转原则

  • 高层模块不应该依赖低层模式，两个都应该依赖抽象。
  • 抽象不应该依赖细节，细节应该依赖于抽象。基于接口编程。

• 里氏代换原则

  子类型必须能够替换掉它们的父类型

• 接口隔离原则

  使用多个隔离的接口,比使用单个接口好，建立最小的接口

  一个接口只负责一个功能

• 迪米特法则

  如果两个类不必彼此通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法，可以通过第三者转发这个调用。

  类的结构设计上，每一个类都应当尽量降低成员的访问权限

  类之间的耦合越弱，越有利于复用，一个处在弱耦合的类别修改，不会对有关系的类造成波及

Overview 概览

【DesignPatterns】 项目是用 C# 写的一些设计模式的示例，基于 .netcore 3.1，大部分示例来自《大话设计模式》

设计模式大体上可分为三类：

• 创建型模式（Create）

  1. 简单工厂（SimpleFactory）
  2. 抽象工厂（AbstractFactory）
  3. 工厂方法（FactoryMethod）
  4. 建造者模式（Builder）
  5. 原型模式（Prototype）
  6. 单例模式（Singleton）

• 结构型模式（Structure）

  1. 适配器模式（Adapter）
  2. 桥接模式（Bridge）
  3. 组合模式（Composite）
  4. 装饰(者/器)模式（Decorator）
  5. 外观/门面模式（Facade）
  6. 享元模式（Flyweight）
  7. 代理模式（Proxy）

• 行为型模式（Behavior）

  1. 观察者模式（Observer）
  2. 模板方法（TemplateMethod）
  3. 命令模式（Command）
  4. 状态模式（State）
  5. 职责链模式（Chain of Responsibility）
  6. 解释器模式（Interpreter）
  7. 中介者模式（Mediator）
  8. 访问者模式（Visitor）
  9. 备忘录模式（Memento）
  10. 迭代器模式（Iterator）
  11. 策略模式（Strategy）

More

我们上面提到的设计原则有六个，现在有的文章说是有七个，多出来的一个原则是 “组合由于继承”，主要是强调多用组合而非继承，因为继承可能会引入很多不必要的东西，而且很多语言的设计是不允许多继承的，C# 就是单继承的语言，一个类只能有一个父类。

继承主要有三个作用：表示 is-a 关系，支持多态特性，代码复用。而这三个作用都可以通过组合、接口、委托三个技术手段来达成。除此之外，利用组合还能解决层次过深、过复杂的继承关系影响代码可维护性的问题，所以很多情况下组合是比继承更好一些的。

王争在设计模式专栏中总结了一些设计模式和设计原则的一些知识点，分享一下，可以作为学习设计模式的参考：

image

Reference

• https://github.com/WeihanLi/DesignPatterns