# 背景

最近因为工作需要,需要更多的思考“架构”

系统架构和人员架构类似,都是基于职责的分配,每个模块负责某个职责,协调组成系统

问题在架构下可能被规避、忽略、解决、拆解后解决

架构是对“层”友好的,分层往往可以处理掉复杂的问题,对运行的影响不大,对编写影响较大

学习设计模式,可能能从中体会到分层的技巧

参考资料:设计模式

# 原则

  1. 开闭原则:抽象约束、封装变化
  2. 里氏替换原则:子类能完全替换父类(没太多乱七八糟的问题)
  3. 依赖倒置原则:高层模块不应依赖底层模块,两者都应依赖抽象,也就是应面向接口编程
  4. 单一职责原则:一个类应该有且仅有一个引起它变化的原因
    这个有点坑,简单想一个函数应该是有单一职责的,但是对于类或者对象,要想只有一个修改途径怎么办?
    一种方法就是把字段及其GET、SET方法单独拿出来做一个接口/类,再把所有修改方法拿出来作为一个工具类
    也就是说如果有方法可能直接修改类的可获取的属性的话就要做成两个类,一个放属性,一个放方法,这么麻烦还干活吗!
  5. 接口隔离原则的定义:接口尽量小
  6. 迪米特法则:只与你的直接朋友交谈,不跟“陌生人”说话
  7. 合成复用原则:尽量先使用组合或者聚合等关联关系来实现,其次才考虑使用继承关系来实现

# GoF 的 23 种设计模式

范围\目的 创建型模式 结构型模式 行为型模式
类模式 工厂方法 (类)适配器 模板方法、解释器
范围\目的 创建型模式 结构型模式 行为型模式
对象模式 单例 代理 策略
原型 (对象)适配器 命令
抽象工厂 桥接 职责链
建造者 装饰 状态
外观 观察者
享元 中介者
组合 迭代器
访问者
备忘录

几个观点

  1. 设计模式的终极目标是只加代码,不改代码
  2. new 行为会破坏代码的稳定性,因此要让别人 new,集中 new

面向过程偏重行动顺序,面向对象偏重行为抽象,两者都需要数据结构抽象

两者的关系和组织流程与组织结构的关系挺像的