2020/6/16 架构学习心得

作业2-学习心得

Date:  2020/6/16    V1.0

Author： Jessie

本周是架构师课程学习的第二周。本周对架构设计的基本原则进行案例+方法的梳理。

架构设计的原则

框架定义：

用来实现某一类应用的结构性的程序，是对某一类架构方案的可复用的设计与实现。

框架对架构师奠定了团队中的地位。

架构师的意义，做框架选型或自己设计框架。

框架和工具的区别：

l  框架调用应用程序代码，如：Junit

l  应用程序调用工具, 如：Log4j

程序设计的冲击（不好代码的表现）

l  僵硬： 不易增加、修改；

l  脆弱：

l  不可移植

软件设计的五大原则：

一、开闭原则（OCP）：Open/Closed Principle

l  对于扩展是开放的

l  对于更改是封闭的

l  不需要修改软件实体（类、模块、函数），就能实现功能的扩展。

关键：抽象，实现不修改而扩展。通过抽象实现多态。    

改造的方法：策略模式、适配器模式、观察者模式等

二、依赖倒置原则（DIP）：Dependency Inversion Principle

l  高层模块不能依赖低层模块，而是大家都依赖于于抽象。

l  抽象不能依赖实现，而是实现依赖抽象。

假如高层模块依赖低层模块，那么对低层改动过就会影响高层模块，这明显不合理——也会造成依赖的传递。高层业务规则应该独立于包括实现细节的低层模块，并用高层的策略去影响低层的细节实现。

依赖倒置的关键：面向接口的编程。不是调用，通过定义接口来实现。这个原则下高层模块就很容易被重用。

举例：

如下的高层依赖低层，



改造为：



传统的过程化程序设计的依赖关系结构，策略依赖于细节的；

面向对象的程序设计倒置了依赖关系的结构，使得细节和策略都依赖于抽象，并且由客户端程序拥有服务接口。

框架就是利用依赖倒置原则实现的一类软件。好莱坞原则“Don’t call me，I will call you.”程序不需要调用框架的功能，框架调用程序的实现。

三、Liskov替换原则（LSP）

子类型（subtype）必须能替换其基类型（base type）

l  子类一定拥有基类的整个接口

l  子类不能比父类更严格

需要在场景中看是否违反LSP。对于违反了LSP的改进：组合替代。

继承虽然比较容易，也有缺点，建议优先使用组合进行OOP的扩展。

三、单一职责原则（SRP）：Single Responsibility Principle

l  内聚性原则：一个类只能有一个引起它变化的原因。

     一个类尽量职责少、代码少；可以很多类，尽量将类拆小。维护性、复用性方便。

四、接口分离原则（ISP）：Interface Segregation Principle

l  不强迫客户程序依赖它们不需要的方法。

l  一个接口只能有一种原因才能促使类的变化。

      SRP：尽量把一个类拆开；如果拆不开，就用ISP接口隔离原则隔离。



推荐书籍



敏捷开发的经典。不同于其他的敏捷开发的过程，本书重点在讲程序设计。一个核心观点：敏捷的不是过程，而是设计。技术决定是否敏捷。

优秀的程序员：欢迎需求的变更。设计就是为了需求变更而设计。



思考帮助

当发现业务系统需求实现越来越慢，每改一个需求造成旧业务收到影响时，就需要审核重新审视目前系统中的设计，养成重构的习惯。

在业务和成本的要求下，不可能全部停下来重构。就需要开发人员有在新需求中带着做一小部分重构的习惯。

走敏捷开发流程，本质敏捷是基于架构的敏捷。如果架构不敏捷，那么就是做的越快，错的越多。

本周通过讲解架构设计的手段，尤其重点阐述依赖倒置原则，让我们重新思考哪些是面向过程的编程，哪些是面向对象的编程。

利用架构设计之美，拥抱需求的变化！