软件设计原则

单一职责原则

  • 永远不应该有多于一个原因来改变某个类。
  • 理解:对于一个类而言,应该仅有一个引起它变化的原因。

  • 应用:如果一个类拥有了两种职责,那就可以将这个类分成两个类。

    开放封闭原则

  • 软件实体扩展应该是开放的，但对于修改应该是封闭的。

  • 理解:对扩展开放,对修改封闭。可以去扩展类,但不要去修改类。

  • 应用:当需求有改动,尽量用继承或组合的方式来扩展类的功能,而不是直接修改类的代码。

    里氏替换原则

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

    最少知识原则

  • 只与你最直接的对象交流

  • 理解：低耦合，高内聚

  • 应用：做系统设计时，尽量减小依赖关系

    接口隔离原则

  • 一个类与另一个类之间的依赖性,应该依赖于尽可能小的接口。

  • 理解:不要对外暴露没有实际意义的接口。用户不应该依赖它不需要的接口

  • 应用:当需要对外暴露接口时,如果是非必要对外提供,尽量删除。

    依赖倒置原则

  • 高层模块不应该依赖于低层模块,它们应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

  • 理解:应该面向接口编程,不应该面向实现类编程。

  • 并不是说,所有的类都要有一个对应的接口,而是说,如果有接口那就尽量使用接口来编程吧。

    总结

  • 将以上六大原则的英文首字母拼在一起就是SOLID (稳定的)，所以也称之为SOLID原则。

  • 只有满足了这六大原则,才能设计出稳定的软件架构!

    补充设计原则

    组合/聚合复用原则

  • 当要扩展类的功能时,优先考虑使用组台,而不是继承。

  • 该原则在23种经典设计模式中频繁使用。

  • 如:代理模式、装饰模式、适配器模式等。

    无环依赖原则

  • 当A模块依赖于B模块,B模块依赖于C模块,C依赖于A模块此时将出现循环依赖。

  • 在设计中避免该问题,可通过引入“中介者模式”解决。

    共同封装原则

  • 应该将易变的类放在同一个包里,将变化隔离出来。

  • 该原则是”开放-封闭原则”的延生。

    共用重用原则

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

    好莱坞原则

  • “控制反转”( 或称为”依赖注入”)

  • 不需要主动创建对象,而是由容器帮我们来创建并管理这些对象。

    其他设计原则

    不要重复你自己

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

    保持它简单与傻瓜

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

    高内聚与低耦合

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

    关注点分离

    将一个复杂的问题分离为多个简单的问题,然后逐个解决。

  • 难点：如何进行分离

    你不需要它

  • 不要一开始就把系统设计得非常复杂,不要陷入“过度设计”的深渊。

  • 让系统足够简单,而又不失扩展性。

    软件设计分层

    image.png

    系统级架构

  • 应用在整个系统内,如与后台服务如何通信,与第三方系统如何集成。

  • 设计前端首要条件:了解前端系统与其他系统之间的关系。
  • 关系包括:业务关系和协作机制。
  • 设计后端:只需要规定与后台数据传递的机制。
  • 包括: api设计规则,访问授权的一个开放标准( OAuth )跳转token的验证,数据传递cookie等。
  • 前端与后端的关系考虑的主要因素是:前后端分离的架构设计。

  • 前后端分离架构其实是如何实施技术决策,用户鉴权、API接口管理和设计、API文档管理、Mock的使用、BFF(服务于前端的后端,nodejs) ,是否需要服务端渲染等。

    微前端

  • 在一个系统内微前端是应用间的架构方案。

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

  • 通常使用Web Components方案来做子应用封装,子应用更像是一个业务组件而不是应用。

    应用级架构

  • 应用级架构可以看作是系统级架构的细化。

  • 单个应用与其他外部应用的关系,微服务架构下多个应用的协作、数据交换等。

    应用级架构形式

  • 脚手架

  • 模式库

  • 设计系统

    模块级架构

    这部分内容是我们开始业务编码之前进行设计,我们称为迭代。

    代码级架构

  • 规范与原则

    实操

  • 开发流程

  • 代码质量以及改善
  • 规范而非默契

注：

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