学习心得

发布于: 2020 年 06 月 17 日
学习心得

软件开发的理解

计算软件编程比计算机出现早的很多。

计算机是进行逻辑计算的。

计算机编程早于计算机,因此不限于计算机

 

机器语言:面向机器编程。

高级语言:按照人的思维逻辑进行编程。

面向对接:面向问题领域的对象编程;

 

编程语言是一种“抽象”机制,问题是对“谁”来抽象。

领域问题----分析、抽象----模型<---设计、抽象--->软件系统

 

非结构化的抽象

结构化的程序设计;

 

编程的核心要素:人 计算机 客观业务领域

 

编程的认知:面向对象是编程发展的终极形式;

 

函数式编程,比较适合数据编程;

反应式编程;

 

什么是面向对象编程

什么是对象------状态、行为、标识

 

无状态对象:对象没有自己的数据;

一个service没有数据。

对象本身的数据没有

 

一些对象没有行为(get 和 set不算)

 

主张:DDD 思路;

主张:面向对象编程,都是有状态有行为;

 

封装不是面向对象编程语言独有的;

继承也不是面向对象独有的;

 

OOP的三大特征

多态性:对象互换的魔法

 

多态不是面向对象独有的,因为有指向函数的指针

多态再C语言上也可以实现

使用指向函数的指针是非常危险的。

 

多态是核心

抽象、封装、继承、多态

 

面向对象编程不是使用面向对象的编程语言进行编程,而是利用多态特性进行编程

 

设计模式原则

框架VS 工具

 

框架调用应用程序代码

应用程序代码调用工具

 

架构师用框架保证架构的落地

架构师通过工具提高开发效率

 

例如:log4j只是工具;

 

抽象接口;由具体的类去继承这个接口,然后实现接口的方法。

switch case /if else 语句比较脆弱。

 

【OOD 原则1:开闭原则】

对于扩展是开放的

对与更改是封闭的

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

关键就是抽象。

 

1、BUTON 抽象成接口,press函数

2、策略模式

3、适配器模式

4、观察者模式

 

phone的代码:

phone是个组合类;

当需求变更的时候,当前的其它组件(dialer,button)都不需要修改;

指需要修改phone这个组装类。

 

【OOD 原则2:依赖倒置原则】

DIP

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

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

 

controller是高层模块;

service是底层模块;

 

service接口是为谁定义的;

service定义个register

 

controller 自己调用自己的方法,service来实现这个方法。

controller 来定义接口; controller按照业务场景来定义接口;

serivce来实现这个方法。

(A依赖B,正常B说了算,现在A说了算)

高层定义接口,高层自己调用,但是需要底层去实现。

 

框架的核心:

好莱坞贵州:

DONT CALL ME ,I'LL CALL U

倒转的层次依赖原则

 

都是一样的,框架定义好了规则;

JUNIT:你只需要写单元测试实现;

TOMCAT: 你只需要实现 SERVLET

Spring:你不用来调用我,我来调用你,你只需要实现就行了。

你不用再 servlet内去实现去调用 tomcat 和 spring的代码。

 

框架的思维:

我来控制调用规则,你只要写实现就行了。

 

OOD原则三: Liskov 替换原则(LSP)

使用基类的地方可以使用子类来代替。

能否继承,是看方法是否统一的,在场景中是否能替换?

 

从契约的角度来看LSP

从更广泛的意义看,子类的 契约 不能比基类 更 严格。

 

解决办法:

1、提取共性到基类

2、改成组合模式;

 

继承和组合;

继承比较容易,优先使用组合;

 

OOD原则四: 单一职责原则(SRP)

违反SRP的原则后果:

脆弱性:修改了一个时,另一个功能也会意外受损

不可移植性:计计算几何应用只需要使用计算面积的功能,却不得不包括GUI依赖;

强调的是这个类尽量少;

一个类的代码尽量在一屏内实现;

一个类大了,就要拆开了,拆的时候怎么拆?

哪些在一起,那些应该拆开。

多一些类没事,但是代码一坨一坨在一起,那么这个比较麻烦了。

区分类的方法:分清职责

 

OOD原则五: 接口分离原则(ISP)

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

ISP 和SRP 有相关的,都和 内聚性 有关。

链接和收发数据环节有内在的关系,可能必须要写在一个类中。

但是我们依然可以在接口分开,这样当“连接”的方法改变时,那些只关心收发数据的程序不受到影响。

避免大类,类多了不要紧(几十-几百个都可以),只要命名规范;如果代码臃肿都在一起,维护就比较麻烦。

优先考虑组合,组合不适合,再考虑继承。

 

/********************************/

推荐书籍:

《敏捷软件开发》: 敏捷的是设计,而不是过程。

如果设计不敏捷,过程

/********************************/

好的程序员,特点:欢迎需求变更;

因为,设计就是为了变更而设计的。

 

用户头像

蒜泥精英

关注

还未添加个人签名 2018.09.19 加入

还未添加个人简介

评论

发布
暂无评论
学习心得