软件设计原则与分层
@ 姜波 | 星期日,九月 12 日,2021 年 | 4 分钟阅读 | 更新于 星期日,九月 12 日,2021 年

软件设计原则

单一职责原则

  • 永远不应该有多于一个原因来改变某个类
  • 理解:对于一个类而言,应该仅有一个引起它变化的原因
  • 应用:如果一个类拥有了两种职责,那就可以将这个类分成两个类

开放封闭原则

  • 软件实体扩展应该是开放的,但对于修改应该是封闭的
  • 理解:对扩展开放,对修改封闭,可以去扩展类,但不要去修改类
  • 应用:当需求有改动,尽量用继承或组合的方式来扩展类的功能,而不是直接修改类的代码

里氏替换原则

  • 理解:父类一定能够被子类替换

最少知识原则

  • 只与你最直接的对象交流
  • 理解:低耦合,高内聚
  • 应用:做系统设计时,尽量减少依赖关系

接口隔离原则

  • 一个类与另一个类之间的依赖性,应该依赖于尽可能小的接口
  • 理解:不要对外暴露没有实际意义的接口,用户不应该依赖它不需要的接口
  • 应用:当需要对外暴露接口时,如果是非必要对外提供,尽量删除

依赖倒置原则

  • 高层模块不应该依赖于低层模块,它们应该依赖于抽象,抽象不应依赖于细节,细节应该依赖于抽象
  • 理解:应该面向接口编程,不应该面向实现类编程
  • 并不是说,所有的类都要有一个对应的接口,而是说,如果有接口,那就尽量使用接口来编程

补充设计原则

组合/聚合复用原则

  • 当要扩展类的功能时,优先考虑使用组合,而不是继承
  • 该原则在23种经典设计模式中频繁使用
  • 如:代理模式、装饰模式、适配器模式等

无环依赖原则

  • 当A模块依赖于B模块,B模块依赖于C模块,C模块依赖于A模块,此时将出现循环依赖
  • 在设计中避免该问题,可通过引入“中介者模式”解决

共同封装原则

  • 应该将易变的类放在同一个包里,将变化隔离出来
  • 该原则是“开放-封闭原则”的延生

共同重用原则

  • 如果重用了包中的一个类,那么也就相当于重用了包中的所有类,要尽可能减小包的大小

好莱坞原则

  • Don‘t call me, I’ll call you.
  • “控制反转”(或称为“依赖注入”)
  • 不需要主动创建对象,而是由容器帮我们来创建并管理这些对象

不重复原则

  • 不要让重复的代码到处都是,要让它们足够的重用,所以要尽可能地封装

保持简单与傻瓜

  • 保持系统界面简洁,功能实用,操作方便

高内聚与低耦合

  • 模块内部需要做到内聚度高,模块之间需要做到耦合度低

关注点分离

  • 将一个复杂的问题分离为多个简单的问题,然后逐个解决
  • 难点:如何进行分离

不需要它

  • 不要一开始就把系统设计得非常复杂,不要陷入“过度设计”的深渊
  • 让系统足够简单,而又不失扩展性

软件设计分层

系统级架构

  • 应用在整个系统内,如与后台服务如何通信,与第三方系统如何集成
  • 设计前端首要条件:了解前端系统与其他系统之间的关系
  • 关系包括:业务关系和协作机制
  • 设计后端:只需要规定与后台数据传递的机制
  • 包括:api设计规则,访问授权的一个开放标准(OAuth)跳转token的验证,数据传递cookie等
  • 前端与后端的关系考虑的主要因素是:前后端分离的架构设计
  • 前后端分离架构其实是如何实施技术决策,用户鉴权、API接口管理和设计、API文档管理、Mock的使用、BFF(服务于前端的后端,nodejs),是否需要服务端渲染等

微前端

  • 在一个系统内微前端是应用间的架构方案
  • 在多个应用之间,微前端则是一种系统间等架构方案
  • 微前端是将多个前端应用以某种形式结合在一起进行应用
  • 旨在解决单体应用在一个相对长的时间跨度下,由于参与的人员、团队的增多、变迁,从一个普通应用演变成一个巨石应用(Frontend Monolith)后,随之而来的应用不可维护的问题
  • 单实例:即同一时刻,只有一个子应用被展示,子应用具备一个完整的应用生命周期
  • 多实例:同一时刻可展示多个子应用
  • 单实例和多实例通常基于url的变化来做子应用的切换
  • 通常使用Web Components方案来做子应用封装,子应用更像是一个业务组件而不是应用

应用级架构

  • 应用级架构可以看作是系统级架构的细化
  • 单个应用与其他外部应用的关系,微服务架构下多个应用的协作,数据交换等
  • 脚手架
  • 模式库
  • 设计系统

模块级架构

  • 开始业务编码之前进行设计,称为迭代

代码级架构

  • 规范与原则

实操

  • 开发流程
  • 代码质量以及改善
  • 规范而非默契

注意

  • 在开发中,要注意可维护性
  • 简单的代码可维护性高;越是抽象代码越难维护

公众号

Image text

QQ

Image text

微信

Image text

微信打赏

Image text

社交链接