学习心得

软件开发的理解

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

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

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

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

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

面向对接：面向问题领域的对象编程；

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

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

非结构化的抽象；

结构化的程序设计；

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

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

函数式编程，比较适合数据编程；

反应式编程；

什么是面向对象编程

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

无状态对象：对象没有自己的数据；

一个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 有相关的，都和 内聚性 有关。

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

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

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

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

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

推荐书籍：

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

如果设计不敏捷，过程

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

好的程序员，特点：欢迎需求变更；

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