《设计模式之美》（一：杂谈）

1. 抽象类与接口区别

• 语法上：抽象类：有属性，可以有方法具体实现，子类必须实现父类的抽象方法 ；接口：接口只有方法定义，没有属性和方法实现
• 场景上：抽象类：is-a的关系，解决代码重用问题；接口：has-a关系，为了和代码解耦，可以理解成一种协议
  2.基于接口编程而不是实现编程

ImageStore image = new PrivateImageStore() 这种代码如何避免
配置文件+反射/工程模式

3. 为什么建议多用组合少用继承

• 用组合、继承、委托可以替代继承（多态、代码复用、is-a）
• 继承层级过深不利于理解和扩展性和维护性
• vo、bo、Entity代码很多重复，可以用组合方式或者继承一个基类

4. 业务上常用的基于贫血模式的MVC违反了OOP吗？

• Repository+Service+Control这种数据和方法隔离的方式 典型的面向过程的编程方式，称为贫血模式：业务在Service，Bo只有数据没有业务
• DDD(Domain Driven Design)领域驱动设计 充血模式:Domain 相当于贫血模式的Bo 不过同时包含业务和数据

5. solid(单一责任制、开闭原则、里式替换原则、接口隔离原则、控制反转原则)

• 里式替换：与多态相似，不同点在于里式替换不能改变父类的逻辑
• 控制反转：控制指的是对程序流程控制，反转指的是本来由程序员控制整个流程，交给了程序去控制

依赖注入：编码技巧，不在类里面new方式去创建对象，而是在外面创建好，通过参数去传递
依赖注入框架
名词解释
Kiss原则：Keep it short And Simple 保持代码简单
YAGNI原则：You Ain't Gone Need it 不去编写不需要的代码 
DRY原则: Don't Repeat YouSelf 不要编写重复的代码

6. 改善代码质量的建议

• 命名
  • 长度：类名可以表达准确点，不简写，变量名可以简写点
  • 利用上下文简写变量名： 比如 Class User ---> name 而不用userName
  • 命名可读可搜索：比如插入数据 用的是insertXXX 就不要再用addXXX
  • 接口和抽象类命名 IUserService---->UserService 或 UserService----->UserServiceImpl 抽象类 AbstractConfiguration
• 注释

注释 why what how
维护注释也需要成本

• 代码风格
  • 代码行长度、类长度、函数长度 控制
  • 类成员排列(静态 public protected private)
  • import导入排列 (按字母顺序)
• 编码技巧
  • 排除复杂方法
  • 不要用参数控制程序执行
  • if else不要过多嵌套
  • 程序出错 返回：错误码、NUll值、空对象、异常对象(吞掉，打印日志；直接抛出，包装抛出)
  • 滥用get set 返回的集合(不可变)
  • Constant和Utils不要设计大而全，修改一处，依赖的全部要重新编译