设计原则6大原则解读--

父文章

   架构师之设计模式_个人渣记录仅为自己搜索用的博客-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. 原有代码行数越多越差

  改进: 具有前瞻性,把变化的地方提取出来.可配置.