设计模式相关

DDD领域驱动：（理论上就是把OOP应用于业务模型  最近再看一本书：Eric Evans <<领域驱动设计>>）

DDD第一原则：将数据和操作结合

DDD第二原则：界限上下文 这是将“单一职责”应用于我们的领域模型

实现：

1、使用通用语言：类、方法、字段的命名 要符合业务，使用业务语言命名，之后再客户或者团队交流更加流畅

2、理解业务：例如做一个理财系统，要亲自去和卖理财产品的人聊聊或者买个理财产品，这样数据库中那些对你毫无意义的字段才变得有血有肉。

充血模型

传统的MVC比较违反充血模型或者说是面向对象编程。比如controller 、service、Repositor，正常service写一些跟sql相关的代码，可能我们的业务模型不是很复杂，所以看起来bo里就是简单的数据，没有任何的方法或操作，，如果是充血模型，我们需要将bo设计成Domain领域模型，将数据和功能面向对象编程

贫血模型

用起来比较简单，容易上手，设计起来比较简单，适合于业务较为简单的场景

常用的设计原则：

1、单一职责原则：

（一个类或者模块只负责一个功能，不要设计大而全的类，要设计细粒度小，功能单一的类。单一职责原则是说为了提高复用性、可读性和可维护）

如何判断类的职责是否单一：

 （1）类中代码行数过多

 （2）类依赖的其他类过多

 （3）私有方法过多

 （4）比较难给类起一个合适的名字

 （5）类中的大量方法都是集中操作类中的某几个属性

2、对扩展开放，修改关闭原则：

传参的时候将可以封装的参数封装为一个对象

3、里式替换原则（子类对象能够替换父类对象出现的任何地方）

几个常见的违反历史替换的例子：

（1）子类违背父类声明要实现的功能
（2）子类违背父类对输入输出、异常的约定

   比如：在父类中，某个函数约定：运行出错的时候返回 null；获取数据为空的时候返回空集合（empty collection）。而子类重载函数之后，实现变       了，运行出错返回异常（exception），获取不到数据返回 null。那子类的设计就违背里式替换原则。

4、接口隔离原则

常用的设计模式：

单例模式 （饿汉、懒汉、静态内部类、枚举）

工厂模式 

1、简单工厂（只要某个类去写一个静态方法创建一个对象，如果有资源类，可以用静态块初始化）

2、工厂方法（定义一个接口方法，不同的实现类去实现）

3、抽象工厂（定义一个接口，里面有不同的方法和工厂方法的抽象程度不一样）

建造者模式

正常创建对象你只需要用构造方法即可，但是如果你的参数够多，然后当有些参数非必传，那么就显得冗余，你会想到set方法，但是如果你想创建完对象不再修改它，那么就要用建造者模式了。

代理模式(RPC场景)

静态代理需要针对每个类都创建一个代理类，并且每个代理类中的代码都有点像模板式的“重复”代码，增加了维护成本和开发成本。

装饰器模式（FileInputStream，FileDataInputStream,FileBufferInputStream）

适配器模式

这个模式就是用来做适配的，它将不兼容的接口转换为可兼容的接口，让原本由于接口不兼容而不能一起工作的类可以一起工作

适配器模式可以看作一种“补偿模式”，用来补救设计上的缺陷。应用这种模式算是“无奈之举”。如果在设计初期，我们就能协调规避接口不兼容的问题，那这种模式就没有应用的机会了

门面模式(整合接口和接口之间的关系)

策略模式