高质量代码

• 多实践、多思考是速度最快的学习路径。
• 多锻炼逻辑思维能力，主动思考，积极讨论，刻意训练。
• 基础知识转化为开发生产力。先学基础-设计模式，算法等，再读源码。
• 易扩展，易用，易维护
• 先发问： 如何分层、分模块？如何划分类？继承还是实现？单例还是静态工厂？怎么高内聚低耦合？
• 设计模式的引入降低可读性的问题？
• 代码质量高 - 避免bug频发，排查困难，补丁风暴。
• 组合模式：基金各种参数最大回撤、夏普等的计算提供给不同页面展示。
• 责任链模式：开市前各种初始化，收市后的各种状态变更的顺序执行。
• 策略模式：替换复杂的if else场景。
• 评判高质量维度：可扩展和可维护的关系？什么样的代码算是易扩展，易读？
• 可维护性 maintainnability ：不破坏原有设计，不引入bug的前提下快速修改或者添加代码。
• 可读性 readability ：最重要标准。code review 可以测试可读性。
• 可扩展性 extensibility ：应对变化的能力。预留扩展点。
• 灵活性 flexibility ：抽象比较全面。
• 简洁性 simplicity ：KISS原则，大道至简。
• 可复用性 reusability 高内聚、解耦、单一功能原则。DRY（Don’t Repeat Yourself）设计原则。
• 可测试行 testability
• 继承多态帮我们写出可复用代码；编程规范帮助我们写出易读代码；设计原则帮我们写出可复用、灵活、易读、易扩展、易维护的代码；设计模式帮我们写出易扩展代码；持续重构可以时刻保持可维护性。
• 面向对象：
  1. 四大特性-封装、抽象、继承、多态。
  2. 面向对象和面向过程编程的区别和联系。
  3. 对象对象分析OOA、面向对象设计OOD、面向对象编程OOP。
  4. 接口和抽象类的应用场景。
  5. 基于接口而非实现的设计思想
  6. 多组合少继承设计思想
  7. 面向过程的贫血模型和面向对象的充血模型。
• 设计原则：SOLID原则 – SRP单一职责/OCP开闭/LSP历史替换/ISP接口隔离/DIP依赖倒置原则。
• DRY原则、KISS原则、YAGNI原则、LOD法则。
• 设计模式：创建型、结构型、行为型、应用场景，解决可扩展性。
• 编程规范：
• 重构：不要过度设计，Why What When How，建立持续重构意识。
  

面向对象

• 面向对象编程是一种编程范式或编程风格，以类或对象作为组织代码的基本单元，四大特性作为基石。
• 面向对象编程语言是支持类或对象的语法机制去实现四大特性的编程语言。
• 四大特性解决什么问题？
  • 1. 封装Encapsulation 信息隐藏或者数据访问保护，外部调用仅能通过类提供的方式-函数来访问。降低使用者错误调用的概率，提高易用性。保护数据不被随意修改，提高可维护性。
  • 2. 抽象Abstraction函数就是一种抽象，并不局限于接口类和抽象类。基于接口，开闭原则，代码解耦思想。
  • 3. 继承Inheritance代码复用。is-a关系。有争议的特性，有人认为是反模式，go就完全摒弃继承。
  • 4. 多态Polymorphism继承加多态重写实现。duck-typing实现，Python只要两个类有相同的方法即可实现多态。提高可扩展性和复用性。设计原则，依赖倒置、里氏替换、策略模式、基于接口而非实现编程。
• 那些看似是面向对象，本质是面向过程的代码。
  • a. 滥用getter,setter方法。Collections.unmodifiableList()返回不可修改的集合容器。防止集合容器内部数据被修改。
  • b. 滥用全局变量和全局方法。各种Util类中的静态方法就是典型的面向过程例子。Constants类大而全的弊端，拖慢项目启动时间影响开发效率，复用性低，其他项目要用必须复制一份同样的过去，解决方案如下：
    • 1. 根据使用场景拆解为功能单一的类。
    • 2. 或者直接定义在类中。Util类也不要一棒子打死，不要涉及大而全的工具类就可以了。
  • c. 定义数据和方法分离的类。MVC三层结构就是典型的面向过程，数据和方法分离了。叫做基于贫血的开发模式。遗留问题，为什么不摒弃呢？
  • 抽象类和接口区别，不支持原生语法的编程语言怎么模拟？
    • 抽象类特性，只能被继承，不能new。子类必须实现所有抽象方法。is-a，自下而上
    • 接口不能包含属性-成员变量，接口不能包含代码实现，子类必须实现所有方法。has-a 协议contract
    • 抽象类解决代码复用，防止子类忘记重新实现主要方法，普通父类可以被实例化增加了被误用的风险。
      • ps：设置构造函数私有化可以暂时解决父类被实例化，父类定义空方法暂时可以解决忘记实现方法问题，但都不够优雅。
    • 接口侧重于解耦，基于接口而非实现编程。自上而下。java8后增加default关键字，接口中可以实现默认方法
  • c++怎么模拟接口，抽象类所有方法都定义为virtual = abstract，不要定义属性。普通类定义构造私有，所有方法抛出MethodUnSupportedException异常。
  • 如果要表示一种 is-a 的关系，并且是为了解决代码复用问题，我们就用抽象类；如果要表示一种 has-a 关系，并且是为了解决抽象而非代码复用问题，那我们就用接口。
  • 基于接口/抽象而非编程Program to an interface, not an implementation
    • 函数命名不能暴露实现细节
    • 封装具体实现细节，为实现类定义抽象的接口。
    • 根据系统的稳定程度设计接口。
    • 课后思考题思路：策略模式，封装一个调用ImageStore的公共类，持有接口引用，增加模式只修改公共类。
  • 组合优于继承
    • 层次复杂，组合和委托来解决代码复用问题。继承结构稳定可以使用继承，结构复杂要使用组合。
    • 组合时指在使用类中定义委托类为私有属性。

  MVC贫血模型违反OOP，基于充血模型DDD

  • 数据和业务逻辑分割就叫做贫血模型Anemic Domain Model。适合业务简单的项目。SQL驱动开发，复用性差。
  • 充血模型反过来，数据和业务在一个类。金融系统。
  • DDD如何解耦业务系统，划分业务模型，定义业务模型交互
  • DDD 轻service 重Domain，开发流程不一样。先理清所有业务-业务调研，定义领域模型所包含的属性和方法，设计可复用的业务中间层，新功能需求的开发都基于之前定义好的领域模型来完成。
  • 实战虚拟钱包 使用OOP DDD
  • 拆分成两个系统，虚拟钱包和三方支付系统。
  • 设计一个钱包账户的思路，提现和支付都没问题，支付设计一个交易类型：0-支付 1-被支付，不太好，保证一致性时比较复杂。
  • 设计两个钱包账户，出账钱包账户和入账钱包账户好一点，比较容易实现幂等。两阶段提交。
  • 虚拟钱包流水设计不涉及业务交易类型，只涉及加减操作，在上层服务钱包服务中再维护一条有交易类型的数据。这样数据一致性和对账等就可以单独在虚拟钱包服务站进行了。
  • 只把service层设计出DDD，service层只负责和Repository层交互，幂等，事务，发邮件都在service里做，具体业务逻辑让领域模型做，转账设计两个账户的操作不能放入领域模型，后期可以单独抽出来做成领域模型。
  • 接口鉴权功能实战
  • 从简单的诉求慢慢优化，参考oauth2
  • 从需求中提炼功能点，大项目要先进行模块划分。然后动词为方法，名词为属性，有些名词可作为方法参数。
  • 类与类直接的关系：
    • 泛化Generalization - 继承
    • 实现Realization - 接口实现
    • 聚合Aggregation - A包含B，B的生命周期不依赖A public A(B b) { this.b = b; }
    • 组合Composition - A包含B，B的生命周期依赖A public A() { this.b = new B(); }
    • 关联Association - 非常弱的关系，包含聚合和组合
    • 依赖Dependency - 是一种比关联关系更加弱的关系，包含关联关系。不管是 B 类对象是 A 类对象的成员变量，还是 A 类的方法使用 B 类对象作为参数或者返回值、局部变量，只要 B 类对象和 A 类对象有任何使用关系，我们都称它们有依赖关系。

设计原则理论 SOLID

   - **单一职责原则SRP**
      - A class or module should have a single reponsibility。
      - 将两个不相干的功能放到同一个类中，那就违反了单一职责原则
      - 根据业务需求判断是否拆分，有几个不成文的经验： 
         - 类中代码行数，函数属性过多
         - 类依赖其他类过多
         - 类的私有方法过多
         - 类起名字时比较难起一个合适的名字
         - 类中大量的方法都是集中操作类中的某几个属性
      - 有些场景不适合拆的太细，要考虑高内聚，比如Serializer类
    - **开闭原则Open Closed Principle**
      - 怎么判断修改的代码是扩展还是修改？
      - software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification。我们把它翻译成中文就是：软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”，增加新功能是尽量新增模块、类、方法代码，不要再原有代码基础上修改。
      - 大前提只要没有破坏原有代码和测试用例的运行就是合理的修改扩展。
      - 对于一些判断聚合类的修改思路：把参数封装成类，判断用handle类代替，这样新增功能是只用改参数类和新增handle类就可以了。
      - 为了尽量写出扩展性好的代码，我们要时刻具备扩展意识、抽象意识、封装意识。这些“潜意识”可能比任何开发技巧都重要。
      - 写代码前先思考怎么设计代码结构，事先预留好扩展点。
      - 最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态等）。
      - 也不要过度设计，对于短期内的变动设计扩展点是用到就ok了，另外如果ifelse不太多也不建议用策略模式增加代码的可读性难度。
   - **里氏替换LSP**
     - Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it / 子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。
     - 多态是一种语法，LSP是指导子类如何设计不会影响到父类的逻辑行为。
     - 拿父类的测试用例去跑子类的方法如果报错就违背了LSP原则。
     - “design by contract，按照协议来设计”
  - **接口隔离原则Interface Segregation Principle**
     - “Clients should not be forced to depend upon interfaces that they do not use。”客户端不应该被强迫依赖它不需要的接口
     - 部分接口只提供给部分调用者使用就要拆分开，单独提供服务，其他调用者不用强制依赖不需要的接口。
     - 单个api的函数接口层面，如果调用者只用到了接口中部分功能，那这个接口就违背了ISP，这也是和SRP的最大区别，SRP关注模块类接口设计，ISP只关注接口设计。
  - **依赖反转原则Dependency Inversion Principle**
     - DI 将所依赖的类对象通过构造函数传递进来
     - 控制反转 流程的控制权从程序员“反转”到了框架
     - 高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象。
  -  **KISS和YAGNI You Ain’t Gonna Need It原则**
     - Keep It Simple and Straightforward.尽量保持简单
     - 保持可读可维护。优化投入产出比，逻辑复杂度，实现难度。系统性能瓶颈代码，核心功能要用复杂的方法。
     - 不要使用同事不懂的技术，不要重复造轮子，不要过度优化。
     - code review 评判代码是否简单。
     - YAGNI不要提前引入不需要的依赖包，kiss如何做，yagni要不要做。
  - **DRY Don't Repeat Yourself 不要重复自己**
     - 实现逻辑重复，只要不违背语义重复，不要合并
     - 功能语义重复，合并
     - 代码执行重复，尽量减少IO执行。
     - 代码复用性，代码复用，DRY。
     - 提高复用性方法：
        - 减少代码耦合
        - 满足单一职责原则
        - 模块化
        - 业务与非业务逻辑分离
        - 通用代码下沉
        - 继承、多态、抽象、封装
        - 应用模板等设计模式
        - 泛型编程，复用意识
   - **迪米特法则LODLaw of Demeter最小知识法则，实现高内聚、松耦合**
      - 高内聚：相近的功能放到同一个类中。
      - 松耦合：类与类之间的依赖关系简单清晰。
      - Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.每个模块（unit）只应该了解那些与它关系密切的模块（units: only units “closely” related to the current unit）的有限知识（knowledge）。或者说，每个模块只和自己的朋友“说话”（talk），不和陌生人“说话”（talk）。
      - 不该有直接依赖关系的类之间，不要有依赖；减少依赖，使用工厂模式创建对象。
      - 有依赖关系的类之间，尽量只依赖必要的接口（也就是定义中的“有限知识”）。拆分多个功能单一的接口。
      - 基于最小接口而非最大实现编程

实战1，如何做需求分析和设计

1. 技术人员要具备产品思维，借鉴成功案例，用户故事线框图用户用例细化。
2. 选择模块分层，先从高内聚低耦合考虑。
3. 积分系统思路：单独抽离成一个服务，只做积分的操作。计算规则分散到各个业务层，有上下层高关系的服务尽量让下层服务来计算，不要重复计算，同层服务可以使用mq解耦，上下层服务建议同步调用。
   

实战2 非业务的通用模块怎么设计

1. 易用性
2. 性能
3. 扩展性，是针对使用者来说在不修改源码的情况下扩展新的功能
4. 容错性
5. 通用性
6. TDD（测试驱动开发）和 Prototype（最小原型）的思想，画模块拆分图释放脑容量