代码重构分享

平时很多人的代码

快速浏览30秒,能否读懂一个大概意思

代码重构分享_第1张图片

看下优化过后的代码(以下代码逻辑更加复杂)

代码重构分享_第2张图片代码重构分享_第3张图片

一个好的方法是什么样的?

  • 不超过20行

  • 方法见名知意(方法命名很重要)

  • 代码缩进不超过2个

  • 方法入参不超过3个

    反例:

        代码重构分享_第4张图片

  • 方法只干一件事

  • 方法的出参没有歧义(反例)

    代码重构分享_第5张图片
  • 方法内部的调用是属于同一级别的

    案例如第二个

平时写代码,应该遵循什么规范

  • 复用性

  • 易用性

  • 扩展性

设计规范有哪些

  • 单一原则

    方法单一,返回值单一,类单一,接口单一

  • 开闭原则

    动静分离

  • 里氏替换原则

    代码复用时可用到,用父类作为入参代码重构分享_第6张图片

    代码重构分享_第7张图片
  • 接口隔离,

    分层思想-> 三层架构

  • 迪米特法则

    最少知道原则

  • 合成复用原则

    尽量使用组合而非继承,因为java是单继承,另外,委托模式也就是组合 耦合度更低

在重构代码时,会遇到参数过多的问题,如何解决

  1. 封装到一个对象中,作为入参

  2. threadLocal

  3. 使用有状态的类(详见案例)

spring中单例对象如何引用一个原型对象

  1. context中获取

  2. @Bean

  3. @Lookup

@Lookup

方法返回值替换

  • 可以用在spring中有状态的类

  • 线程任务类中用到spring容器中的对象

三层架构的优缺点

  • 优点 容易掌握,容易形成规范,最差不会差到哪去,但是最好也好不到哪种,中庸之道

  • 不合理之处:

    违反面相对象设计的初衷 -> 每个类有自己的属性与行为

    贫血模型,bean只有属性, 没有行为,service只有行为,与公共属性,没有自己的行为 Service过度依赖于仓储层 职责之外,业务层应该更多的只关心业务而非具体实现 耦合度高,假如mq换了,service怎么办?接口隔离 面向数据库事务脚本的编程,面向过程的编程,而非面向对象

六边形架构

  • 入站与出站

  • 业务代码高内聚

你可能感兴趣的:(重构)