2020/6/16 架构学习心得

发布于: 9 小时前

作业2-学习心得

Date:  2020/6/16    V1.0

Author: Jessie

 

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

架构设计的原则

框架定义:

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

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

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

框架和工具的区别:

l  框架调用应用程序代码,如:Junit

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

 

程序设计的冲击(不好代码的表现)

l  僵硬: 不易增加、修改;

l  脆弱:

l  不可移植

 

软件设计的五大原则:

一、开闭原则(OCP):Open/Closed Principle

对于扩展是开放的

对于更改是封闭的

不需要修改软件实体(类、模块、函数),就能实现功能的扩展。

 

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

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

 

二、依赖倒置原则(DIP):Dependency Inversion Principle

 

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

抽象不能依赖实现,而是实现依赖抽象

 

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

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

 

举例:

如下的高层依赖低层,

改造为:

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

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

框架就是利用依赖倒置原则实现的一类软件。好莱坞原则“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接口隔离原则隔离。

 

推荐书籍

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

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

思考帮助

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

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

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

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

利用架构设计之美,拥抱需求的变化!

 

发布于: 9 小时前 阅读数: 14
用户头像

还未添加个人签名 2018.08.21 加入

还未添加个人简介

评论

发布
暂无评论
2020/6/16 架构学习心得