为什么要学习设计模式？可以在项目设计研发是有理有据，游刃有余，吹牛有依据
所有的设计模式离不开面向对象基础，面向对象是根，设计原则是树干，设计模式是树枝嫩叶；
面向对象
封装、继承、多态、抽象 ， 也有称面向对象三大特性（封装、继承、多态）
看似面向对象，实际面向过程
- 滥用getter、setter方法；
- 滥用全局变量、全局方法；
- 常见的constants类的定义，更好的设计是不是单独地设计常量类，而是哪个类用到了某个常量就在这类中定义；
- util工具类，只包含静态方法的类，彻彻底底的面向过程思想；
- 定义数据和方法分离的类，数据定义在一个类中，方法定义在另一个类中；
接口、抽象类
这俩是面向对象永恒的话题，定义和区别自行百度吧，一堆；
存在的意义，抽象类是为了代码的复用，接口是为了解耦；
从类继承层次上来看，抽象类是一种自下而上的设计思路，先有子类的代码重复，再有抽象成上层的父类；而接口相反，是一种自上而下的设计思路，先有设计接口，再考虑具体的实现；
基于接口而非实现编程
- 函数的命名不能暴露任务实现细节
- 封装具体的实现细节
- 为实现类定义抽象的接口
多用组合少用继承
继承主要有3个作用：
- is-a关系
- 支持多态特性
- 代码复用 组合、接口、委托可以完全替换掉继承；
贫血模型（MVC）、充血模型（DDD）
什么是贫血模型？
贫血模型，只包含数据，不包含业务逻辑的类，就是存pojo，典型的面向过程风格；
spring mvc 架构就是典型的贫血模型mvc ，重service，轻BO（business object）；
什么是充血模型？
数据和对应的业务逻辑被封装到同一个类，典型的面向对象风格；
领域驱动(DDD) 就是典型的充血模型，也分三层架构，但是区别在于service 层，包含service类和domain类，domain相比于BO类即包含数据也包含业务逻辑；
为什么贫血的mvc还在盛行？我们服务都是贫血mvc模型呢？
系统业务开发比较简单，简单的CRUD操作 充血模型的实现比贫血有一定难度 思维固化，习惯了贫血mvc思维，转型有成本；
什么场景应考虑DDD开发模式？
适合复杂的系统开发，具体看领域驱动的书吧
