《设计模式之美》(一:杂谈)

  1. 抽象类与接口区别
  • 语法上:抽象类:有属性,可以有方法具体实现,子类必须实现父类的抽象方法 ;接口:接口只有方法定义,没有属性和方法实现
  • 场景上:抽象类:is-a的关系,解决代码重用问题;接口:has-a关系,为了和代码解耦,可以理解成一种协议
    2.基于接口编程而不是实现编程
ImageStore image = new PrivateImageStore() 这种代码如何避免
配置文件+反射/工程模式
  1. 为什么建议多用组合少用继承
  • 用组合、继承、委托可以替代继承(多态、代码复用、is-a)
  • 继承层级过深不利于理解和扩展性和维护性
  • vo、bo、Entity代码很多重复,可以用组合方式或者继承一个基类
  1. 业务上常用的基于贫血模式的MVC违反了OOP吗?
  • Repository+Service+Control这种数据和方法隔离的方式 典型的面向过程的编程方式,称为贫血模式:业务在Service,Bo只有数据没有业务
  • DDD(Domain Driven Design)领域驱动设计 充血模式:Domain 相当于贫血模式的Bo 不过同时包含业务和数据
  1. solid(单一责任制、开闭原则、里式替换原则、接口隔离原则、控制反转原则)
  • 里式替换:与多态相似,不同点在于里式替换不能改变父类的逻辑
  • 控制反转:控制指的是对程序流程控制,反转指的是本来由程序员控制整个流程,交给了程序去控制
依赖注入:编码技巧,不在类里面new方式去创建对象,而是在外面创建好,通过参数去传递
依赖注入框架
名词解释
Kiss原则:Keep it short And Simple 保持代码简单
YAGNI原则:You Ain't Gone Need it 不去编写不需要的代码 
DRY原则: Don't Repeat YouSelf 不要编写重复的代码
  1. 改善代码质量的建议
  • 命名
    • 长度:类名可以表达准确点,不简写,变量名可以简写点
    • 利用上下文简写变量名: 比如 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不要设计大而全,修改一处,依赖的全部要重新编译

你可能感兴趣的:(《设计模式之美》(一:杂谈))