父文章
架构师之设计模式_个人渣记录仅为自己搜索用的博客-CSDN博客
原则: 对修改封闭,对扩展开放,高内聚,低耦合:
比赛虚拟队伍组织:
0. 建了个群. 保证沟通渠道.
1. 第一次开会, 明确目标:每个人都理解这些设计原则. 下周二来,然后定期跟踪. 承诺和压力
2. 第二次达成一致,对各个细节点.见如下问题. 每个人领取两个原则.原则模板,和框架.
3. 最后一次,各自讨论对方的,然后修改
4. 上场,演练口号,梦想,目标等. 咨询每个人是否已经看过.
补充: 分模块分层(facade或内聚业务隔离变化), 分层封装(降低变量数).
门面模式
1.职责单一 类/域
结合工作经验: 不同的维度: 架构师,小组leader,模块负责人.
一个比较简单的判断标准是, 1.边界不要新增新的依赖,代码相关逻辑不要引入新的业务概念( 例如 本来不依赖银行系统,本来代码不需要判断 "1类户","二类户" ) 2.按流程划分系统后. 每个系统负责独立的流程. (例如 签约 和入金分开, 虽然有缺点,即技术人员无法理解全貌 ,故 需要 维护 概念图. 边界,模型,控制类. )
方法: A. 按业务流分. 出现了多种业务时,才需要拆分. 1.水平切分(更难,最后review下模块的存在是为了隔离变化.) 2.垂直切分. 3.支撑切分. (这种变化一个层面是多个系统比如多个支付方式,另外一个层面的内部业务的变化,比如费用)
B. 按表分: 1.将一些表的业务剥离出去.如果够稳定就剥离走. 2.将表拆分后将对应的业务剥离走.
C. 但变量名比较长时,复杂,出现多个层次/名词时.就可以封装拆封了. 例如 付款方名称,收款方名称. 其实都叫名称,抽象为一个账户类.
一旦切分完之后,下层要关注是否还需要和最上层沟通.( 分润模块不需要直接调用订单获取费用,分析各种费用类型. 业务隔离,技术栈和繁琐的费用类型隔离. 系统的作用屏蔽技术栈和业务变化. 虽然包含了两种业务,但是屏蔽了变化)
同一类的职责还是一个职责. 一个类一个方法,一个功能.
按流程角度来职责,按垂直领域去单一. 最终到不可拆原则.
接口隔离是方法(面向的是业务方),职责单一是目的
2.里氏替换(用的少)
子类替换父类,而不是子类替换子类. 做法: 所有父类的方法都是final.
3.依赖倒置.
结合业务知识: 把业务类型和支付类型变成类,接口化. 同时也引入了开闭原则.
抽象不能依赖具体. 对于java来说接口不可能依赖具体.
抽象类的方法必须是抽象的,通用的. 抽象具体是相对的.
怎么对倒置进行理解: 倒置 原来是直接依赖实现的,一开始就知道调什么,现在不知道依赖的是什么倒过来了.(现在服务端的接口都是通过autowired注入,一开始都是明确的,不属于依赖隔离)
怎么对抽象进行理解: 商务单,普通单. 你可以抽象为订单,也可以将发单动作抽象为一个接口. 更加符合单一原则.
难点是什么? 关键是要把共用的部分给抽象出来.
blog.csdn.net/mariofei/article/details/23778661
难点: 具体是对应着物, 抽象对应着行为业务功能.
将具体的东西抽象出行为. 所有的都是service.
http://www.uml.org.cn/sjms/201211023.asp#3
实现一个很大的问题是 实现的依赖的实现也可以被上层看到.
4. 接口隔离原则 - 方法粒度
没有关系的接口合并在一起,形成一个臃肿的大接口,这是对接口的污染。
导致客户端依赖它不需要的接口;
接口方法实现可能在一个类里,但接口要拆分在不同的接口里.
但是从单一职责的角度不应该同时依赖多个类,应该有组装成组合组装.
难点: 隔离是相对调用者来说的. 接口隔离本身是方法,目的是为了对外面最小可见.
接口隔离原则跟之前的单一职责原则很相似,其实不然。其一,单一职责原则原注重的是职责,关注类整体能力,内部和外部依赖边界;而接口隔离原则注重外部对接口依赖的隔离,关注方法。其二,单一职责原则主要是约束类,其次才是接口和方法,它针对的是程序中的实现和细节;而接口隔离原则主要约束接口接口,主要针对抽象,针对程序整体框架的构建
接口隔离: 接口的含义是文件,然后dubbo jar可以切成多隔.
接口最小化,分开.不然实现类就要多实现.
使用多个专门的接口比使用单一的总接口要好.
不动实现,接口拆分.
举例: 支付,先根据职责单元拆分成 微信支付,支付宝支付. 然后再拆成n个接口.
虚线是依赖, 三角形是剪头.
5.迪米特法则 ( 最少知道原则,减少对内部的了解. 自己补充:隔离变化原则.)
定义:一个对象应该对其他对象保持最少的了解。
方法: 1. 单一职责 能尽量避免这个.
2. 和直接朋友,不要越层调用.
3. 降低对外和整体的依赖度. 而不是个体之间的.
举例: 快递员.
网状拓扑,变成星型拓扑. 银行清算系统.
为什么可以直接找对方: 每个功能不一样, 有些service可以直接调用.
6. 开闭原则:
对扩展开发,对修改封闭.
工程经验: 将type字段变成type接口.降低对内部的变化. 应对新的业务场景. 而不是采用门面模式,没有依赖导致.
评估方法: 1. 因变化导致变动行数越少
2. 因为变化导致变动代码行/原有代码行的比率.
3. 原有代码行数越多越差
改进: 具有前瞻性,把变化的地方提取出来.可配置.