前端设计模式之设计原则和哲学(二)

1,538 阅读4分钟
  • 设计原则和模式都不难理解,它们是“讲道理”的,是理性的
  • 感性和理性永远是一对矛盾。感性喜欢宣传“多快好省”,但理性就需要思考如何具体实现,以及低成本的运作和维护(全流程)
  • 俗话说“书生误国”,文科生喜欢夸夸其谈,说理想,说结果,但从不考虑如何实现,以及如何监控、运维
  • 设计原则,设计模式,乃至整个软件工程,都是基于纯理性的思考

五大设计原则

S O L I D 五大设计原则

  • S 单一职责原则
  • O 开放封闭原则
  • L 李氏置换原则
  • I 接口独立原则
  • D 依赖导致原则

单一职责原则

  • 一个程序只做好一件事,如果功能过于复杂就拆分开,每个部分保持独立

开放封闭原则 —— 最重要

  • 对修改封闭,对扩展开放,这是软件设计的终极目标
  • 即要设计一种机制,当需求发生变化时,根据这种机制扩展代码,而不是修改原有的代码

里氏置换原则

  • 子类能覆盖父类,父类能出现的地方子类就能出现 —— 前端应用较少

接口隔离原则

  • 保持接口的单一独立,避免出现“胖接口”
  • 类似于单一职责原则,只不过前者说的比较统一,后者是单独对接口的规定
  • JS 中没有接口,因此体现较少

依赖倒置原则

  • 面向接口编程,依赖于抽象而不依赖于具体
  • 写代码时用到具体类时,不与具体类交互,而与具体类的上层接口交互
function fn(p: Student) {} // 依赖具体的类
function fn(p: IPerson) {} // 依赖接口

举例说明

  • 以常见的 Promise 来解释一下前两个原则
function loadImg(src: string) {
  const promise = new Promise<HTMLImageElement>((resolve, reject) => {
    const img = document.createElement("img");
    img.onload = () => {
      resolve(img);
    };
    img.onerror = () => {
      reject("图片加载失败");
    };
    img.src = src;
  });
  return promise;
}

const src = "xxx";

const result = loadImg(src);
result
  .then((img: HTMLImageElement) => {
    console.log("img.width", img.width);
    return img;
  })
  .then((img: HTMLImageElement) => {
    console.log("img.height", img.height);
  })
  .catch(err => {
    console.log(err);
  });
  • 单一职责原则:每个then中的逻辑只做好一件事,如果要做多个就用多个then
  • 开放封闭原则:如果这个需求要修改,那去扩展then即可,现有的逻辑不用修改,即对扩展开放、对修改封闭

这里引申两点:

  • 其实 S 和 O 是相符现成的,相互依赖

  • 开放封闭原则的好处不止于此,从整个软件开发流程看,减少现有逻辑的更改,也会减少测试的成本

UNIX Linux 设计哲学

  • 大型复杂的系统,才能体现出设计的价值

  • 操作系统是这个世界上最复杂的系统之一,他的设计思路值得我们学习

  • 通俗来说,设计(仅指编程设计)就是按照哪一种思路或者标准来实现功能

  • 同样的功能,不同的设计思想都能用不同的方式来实现

  • 前期效果可能一样,但是随着产品功能的增加和扩展,设计的作用才会慢慢的显示出来

原则:

  1. 小即是美(简单也是美)
  2. 让每个程序只做好一件事(单一职责)
  3. 快速建立原型
  4. 舍弃高效率而取可移植性和扩展性
  5. 采用纯文本来存储数据(前端应该采用规范易懂的数据格式存储数据)
  6. 充分利用软件的杠杆效应(软件复用)
  7. 使用 shell 脚本来提高杠杆效应和可移植性
  8. 避免强制性的用户界面
  9. 让每个程序都称为过滤器
  10. 十条小准则
    1. 允许用户定制环境(考虑多环境,扩展性)
    2. 尽量使操作系统内核小而轻量化
    3. 使用小写字母并尽量简短
    4. 保护树木
    5. 沉默是金
    6. 并行思考
    7. 各部分之和大于整体
    8. 寻求 90% 的解决方案
    9. 更坏就是更好
    10. 层次化思考

23 种设计模式

  • 1995 年,四位前辈出版《设计模式:可复用面向对象软件的基础》,总结了23种设计模式,沿用至今

“设计”和“模式”两个词应该分开读,先有设计,后有模式。

  • 设计:设计原则,设计思想
  • 模式:前辈总结出来的固定的套路

为何需要设计?—— 因为软件规模变大,甚至是一个系统集群,需求需要先设计,后开发,否则就乱掉

为何需要模式?—— 可套用前人经验,降低设计和沟通的成本

随着时代发展,目前前端最常用的设计模式,就以下几个:

  • 工厂模式
  • 单例模式
  • 原型模式
  • 装饰器模式
  • 代理模式
  • 观察者模式
  • 迭代器模式