面向对象,是编程的基础之一.
以下是很干很干的干货
begin...........
目前主流的编程范式 有三种:
1) 面向过程
2) 面向对象
3) 函数式编程
面向对象这种编程风格是其中最为主流的
因为其适合处理复杂的现实逻辑
目前市面上大部分的编程语言都是支持面向对象特性的。(封装,抽象,继承,多态)
是很多设计模式的 编码实现基础
封装:
被称之为信息隐藏,or 数据访问保护。类通过暴露有限的访问接口，让外部通过类暴露的方式来访问与操作内部数据与信息。它需要编程语言提供 权限访问控制语法来支持
在java中 eg： private 、default、protected 、 public
其用意在于
- 保护数据不被随意修改，导致业务出现问题，
- 仅仅暴露有限且有必要的接口，提高类的易用性，他人不关心类内部实现
抽象
抽象皆旨在隐藏函数or 功能的具体实现， 让使用者值需要关系当前类有哪些功能， 当前函数有什么功能。不用去关注他的实现，抽象可以通过 接口 or 抽象类来实现，
抽象的意义在于
- 修改实现无需改变功能定义
- 是处理复杂系统的有效手段，可以过滤掉不必要关系的实现。（毕竟，你不想发个http 请求还要关系7层网络通讯协议之间如何通讯，并为之编写通讯的代码）
继承
继承用来表示类之间的 is-a 关系（就是你），主要用于解决代码复用的问题分为两种模式： 单继承 与 多继承，
-
单继承
表示一个子类只继承一个父类，但是一个父类被多个子类继承
-
多继承
表示一个子类可以继承多个父类
为了实现这个特性，编程语言需要提供特殊的语法支持。
多态
指子类可以替换父类，在实际的代码运行过程中，调用子类的函数实现。多态这种特性也需要编程语言提供特使的语法机制来实现。
eg： 继承、接口、duck-typing。
多态可以提高代码的扩展性与复用性，是很多设计模式，设计原则，编程技巧的代码实现基础。
面向对象 VS 面向过程
面向对象相较于面向过程的优势主要有三个
- 对于大规模负载程序的开发，程序的处理流程并非单一的一条主线，而是错综负载的网状结构。面向对象编程比起面向过程编程更能够因对复杂类型的程序开发
- 面向对象编程拥有更加丰富的特性（封装，继承，抽象，多态）。利用这些特性可以使得代码更加易扩展，易维护，易复用。
- 面向对象更加符合人类的思维直观，更加人性化，高级。（虽然我不这么认为，也没有感受到这一点）
但是无论是面向对象风格编程还是面向过程风格编程，需要注意的是没有绝对的银弹，只有更加的适合。只能说如今的软件开发业务流程都已经复杂到了面向过程风格无法满足的地步， 所以才会有面向对象
但是请注意
面向对象编程语言写出来的代码不一定是 面向对象编程风格的
同理
面向过程编程语言，也可以写出面向对象编程风格的代码
面向对象分析,设计,编程
面向对象分析（OOA）、面向对象设计（OOD）、面向对象编程（OOP）。是面向对象开发的三个基本环节。
面向对象分析（OOA）：得出要做什么？
面向对象设计（OOD）：得出怎么做？
面向对象编程（OOP）：按照设计翻译成代码的过程。
与程序员的思考框架中的：
where are we now？（我们在哪里？）
where are we going？（我们要去哪？）
how can we get there？（我们怎么做？）
面向对象中差了一个 where are we now (我们目前在哪)？
而思考框架中 少了个 OOP
言归正传
面向对象分析, 就是 我在需求分析环节中 使用面向对象分析方式, 得出一个粗糙、粗粒度的基础方案,然后慢慢优化，一步一步迭代，从第一版的粗粒度中选出一块进行拆分，其中可以通过visio等画图工具进行辅助，免得分析后面忘了前面。（但是相较于面向对象分析方式，我更加热衷与用户故事的分析方式，把自己变成一个用户，将当前功能的使用方式，操作步骤一步一步的record下来。最后得出所有步骤之后在进行步骤拆分，然后思考每一步该如何实现。）
将面向对象分析转化为面向对象设计的时候可能会有些抽象，那么给出四个思考点，以思考点入手：
-
划分职责
根据需求分析，把涉及的功能点一个一个罗列出来，看那些功能点相近，操作同样的属性，可否归为同一个类
-
定义类以及其属性和方法
我们识别出需求描述中的动词，作为候选函数的名称，在进一步过滤筛选出真正的函数，把功能点中的名词作为候选属性，同样过滤。
-
定义类与类之间的交互关系
UML 统一建模芋圆中定义了流中类之间的关系。分别是：泛化、实现、关联、聚合、组合、依赖。从现实编程的角度保留其中的四个关系： 泛化、实现、组合、依赖。
-
将类组装其阿里并提供执行入口
我们需要将所有的类、功能组装在一起，提供一个执行入口，可以是一个api接口也就是一个函数，也可以使main（）函数
面向对象设计就是 把合适的代码放到合适的类中，至于如何划分可以根据划分标准“高内聚，低耦合”、单一职责、对扩展开放对修改关闭等设计原则，与思想。 目的是尽量保证 代码的可复用、易读、易扩展、易维护。
面向对象编程 就是 使用面向对象编程语言提供的语法特性 把设计翻译成代码，且尽量要保证我们的目的 可复用、易读、易扩展、易维护。
接口vs抽象类
抽象类不允许被实例化，只能被继承。它可以包含属性和方法，方法既可以包含代码实现，也可以是无实现，也可以是抽象方法。子类继承抽象类必须实现抽象类中所有的抽象方法。
接口不能包含属性（Java可以定义静态常量），只能声明方法，方法中不能包含代码实现（Java8之后可以有默认实现）。类在实现接口的时候必须实现接口中声明的所有方法。
抽象类是对成员变量以及方法的抽象，是一种is -a 关系，是为了解决代码复用的问题
接口仅仅是对方法（功能）的抽象，是一种 has-a的关系，表示具有某一组行为特性，是为了解决解耦问题
什么时候该用抽象类？ 什么时候该用接口？ 实际上，判断标准很简单：表示is-a 关系并且为了解决代码复用问题，就使用抽象类；如果表示 has-a关系，并且是为了解决抽象而非代码复用问题，那么就使用接口。
基于接口而非实现编程
应用这条原则，可以将业务概念与实现想分离，封装不稳定的实现，暴露稳定的接口，上游系统基于约定准则（接口）而非实现编程，不依赖不稳定的细节，如此当实现发生变化之后，上游系统代码基本不需要改动，以此来降低耦合性，提高扩展性。
当前准则被称之为 “基于抽象而非实现编程”， “基于约定规则而非实现编程”（个人认为与springBoot框架的约定大于配置理念有异曲同工之妙）。毕竟软件开发中最大的挑战就是需求的变化，导致实现的变化
多用组合少用继承
为什么不推荐是使用继承？
继承是面向对象的四大特性之一，用来表示类之间的is-a关系，可以解决代码复用问题，虽然有诸多作用但是当类的继承层次过深， 那就是挖深坑埋自己了。在这种情况下我们应该少用，乃至不用继承。
组合先比继承有哪些优势？
继承主要有三个作用： 表示 is-a 关系，支持多态特性，代码复用。而这三个作用都可以通过 组合、接口、委托三个技术手段来达成。除此之外，组合还可以解决层次过深，过复杂的继承关系影响代码维护的问题。
如何判断该使用继承or组合？
尽管业界鼓励多用组合少用继承，但是组合并非完美，继承也不是一无是处。还是要实际场合实际分析
贫血模型 VS 充血模型
我们平时所做的WEB 项目开发，大多数都是基于 贫血模型的MVC三层架构，也就是传统开发模式，之所以被称之为传统是因为：相对于充血模型的 DDD 开发模式而言的。
基于贫血模性的传统开发模式，是典型的面向过程编程风格。
相反基于充血模型的DDD开发模式，是典型的面向对象编程风格
不过，DDD并非银弹，对于业务不复杂的系统来说。基于贫血模型的三层架构完全够用，而且快速，简单，易上手。 基于充血模型的 DDD 反倒显得繁复，无法发挥作用。 但是在业务复杂的系统来说，基于充血模型的DDD开发模式，因为前期在设计上投入更多时间和经历，来提高代码的复用和可维护性，所以比贫血模型更有优势。
基于充血模型的DDD 开发模式与基于贫血模型的传统开发模式相比， Controller层和Repository层代码基本相同，这是因为 Repository层的 Entity声明周期有限，Controller层面的VO只是单纯作为一种DTO。两部分业务逻辑都不复杂，业务逻辑主要在Service。
Service在充血模型下负责与 Repository层和Controller打交道，和组织跨领域模型的业务代码，幂等事务等工作。至于其中的业务逻辑移动到 Domain的领域模型之中，让Service依赖Domain 来实现业务。
Service在贫血模型下负责与 Repository层和Controller打交道。和处理与实现所有的业务逻辑。
(感谢 前 Google工程师王争在极客时间开设的设计模式之美专栏, 以上内容多数来自其专栏并以其为基础加入了一些个人总结。算作是学习笔记)
