Software Architecture & Engineering
55 篇笔记
- 4.1 函数式选项模式historical
1. 定义 - 创建由默认值的对象,同时可以灵活地修改属性 - 我们可能需要为Option的字段指定默认值 - Option的字段成员可能会发生变更 2. Golang 2.1. 要创建的对象 2.2. 测试 3. 参考 - Go语言设计模式之函数式选项模式 \ 李文周的博客
- 4.2 接口型函数historical
1. 接口型函数是什么 一个实现了接口的函数类型,简称为接口型函数 2. 为什么需要接口型函数 既能够将普通的函数类型(需类型转换)作为参数,也可以将结构体作为参数,使用更为灵活,可读性也更好,这就是接口型函数的价值。 3. 实现 4. 参考 - Go 接口型函数的使用场景 \ 极客兔兔
- 4.3 事件溯源模式historical
1. 什么是事件溯源 基于事件的一种软件架构模式 系统的CUD事件进行持久化 2. 为什么需要事件溯源 传统的CRUD存在一些问题 1. 直接操作数据库,而数据库性能比较低 2. 为了防止并发问题需要引入锁、事务等,引发性能上的损失 3. 因为数据存储中通常保存的是数据最终的状态,所以为了追踪数据变
- 4.4 发布订阅模式historical
1. 发布订阅模式是什么 - 有三个角色:发布者、事件中心、订阅者 - 订阅者需要向事件中心订阅指定的事件 - 发布者向事件中心发布指定事件内容 - 事件中心通知订阅者 - 订阅者收到消息 2. 为什么需要发布订阅模式 - 解耦 - 发布者只关注生产数据,不关心订阅者怎么消费 - 订阅者只关注消费数
- 4.5 生产者消费者模式historical
1. 生产者/消费者模式是什么 - 有三个角色:生产者、消费者、队列 - 生产者生产完数据丢入队列,消费者从队列取出数据消费 2. 为什么需要生产者/消费者模式 - 解耦 - 生产者只关注生产数据,不关心消费者怎么消费 - 消费者只关注消费数据,不关心生产者怎么生产 - 异步 3. 生产者/消费者模
- 5.1 开闭原则historical
1. 什么是开闭原则 对扩展开放,对修改关闭 2. 为什么需要开闭原则 降低维护带来的新风险 3. 开闭原则实现 新需求修改代码的时候看下会不会修改到原有的代码,有的话需要重构:通过接口或者抽象类定义抽象层,将可变因素封装在具体实现类中 继承:里氏替换原则.md 组合/聚合:合成复用原则.md 4.
- 5.2 里氏替换原则historical
1. 什么是里氏替换原则 不要破坏继承体系,子类重写方法功能发生改变,不应该影响父类方法的含义 开闭原则在继承中的体现 2. 为什么需要里氏替换原则 通过继承提高软件复用能力 3. 里氏替换原则实现 子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法 子类中可以增加自己特有的方法 4. 参考 -
- 5.3 依赖倒置原则historical
1. 什么是依赖倒置原则 高层不应该依赖低层 要面向接口编程,不要面向实现编程。 2. 为什么需要依赖倒置原则 提高可扩展性 3. 依赖倒置原则实现 每个类尽量提供接口或抽象类,或者两者都具备。 变量的声明类型尽量是接口或者是抽象类。 任何类都不应该从具体类派生而应该从抽象类派生。 使用继承时尽量遵
- 5.4 单一职责原则historical
1. 什么是单一职责原则 一个类只干一件事,实现类要单一 2. 为什么需要单一职责原则 提高代码的可读性 3. 单一职责原则实现 需要设计人员发现类的不同职责并将其分离,再封装到不同的类或模块中 4. 参考 - 单一职责原则——面向对象设计原则
- 5.5 接口隔离原则historical
1. 什么是接口隔离原则 一个接口只干一件事,接口要精简单一 2. 为什么需要接口隔离原则 提高代码的可读性 解耦 3. 接口隔离原则实现 接口尽量小,一个接口只服务于一个子模块或业务逻辑。 为依赖接口的类定制服务。只提供调用者需要的方法,屏蔽不需要的方法。 4. 参考 - 接口隔离原则——面向对象