OOP设计和设计模式
面向对象设计 OOP
不是简单地把程序分成数据和处理方法，而是把程序分成许多"对象"的基本单位，用这些对象的相互作用进行叙述。
很容易把对象误认为是数据的捆绑，但与其如此，更应视为执行一个角色的method和数据的捆绑。
面向对象的三大特性：
- 封装
隐藏对象的属性和实现细节，仅对外提供公共访问方式，将变化隔离，便于使用，提高复用性和安全性。 - 继承
提高代码复用性；继承是多态的前提。 - 多态
父类或接口定义的引用变量可以指向子类或具体实现类的实例对象。提高了程序的拓展性。
SOLID原则
SOLID是面向对象设计必须遵守的5个基本原则，以软件设计需要的5个原则的首字母命名的。
1. SRP - 单一责任原则
Single Responsibility Principle，对象应该只有一个责任。
指的是一个类或者一个方法只做一件事。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化就可能抑制或者削弱这个类完成其他职责的能力。例如餐厅服务员负责把订单给厨师去做，而不是服务员又要订单又要炒菜。
2. OCP - 开放封闭原则
Open-Closed Principle，对象对扩张要开放，对修改要封闭的原则。
对扩展开放，对修改关闭。意为一个类独立之后就不应该去修改它，而是以扩展的方式适应新需求。例如一开始做了普通计算器程序，突然添加新需求，要再做一个程序员计算器，这时不应该修改普通计算器内部，应该使用面向接口编程，组合实现扩展。
3. LSP - 里氏替换原则
Liskov Substitution Principle，子类总是可以代替父母类的原则。
所有基类出现的地方都可以用派生类替换而不会程序产生错误。子类可以扩展父类的功能，但不能改变父类原有的功能。例如机动车必须有轮胎和发动机，子类宝马和奔驰不应该改写没轮胎或者没发动机。
4. ISP - 接口隔离原则
Interface Segregation Principle，类不应该依赖不需要的接口，知道越少越好。例如电话接口只约束接电话和挂电话，不需要让依赖者知道还有通讯录。
5. DIP - 依赖倒置原则
Dependency Inversion Principle，指的是高级模块不应该依赖低级模块，而是依赖抽象。抽象不能依赖细节，细节要依赖抽象。比如类A内有类B对象，称为类A依赖类B，但是不应该这样做，而是选择类A去依赖抽象。例如垃圾收集器不管垃圾是什么类型，要是垃圾就行。
设计模式
1. 策略模式 Strategy Pattern
通常如果一个问题有多种解决方案时，我们会根据不同的场景选择不同的解决方案。而最简单的实现，是利用 if-else 或者 switch-case。但是这样实现的代码耦合性太高、代码臃肿，维护成本大。策略模式能很好的解决这些问题。
使用场景：
- 针对同一类型问题的多种处理方式，仅仅是具体行为有差别时（在运行时动态选择具体要执行的行为）。
- 对客户隐藏具体策略(算法)的实现细节，需要安全地封装多种同一类型的操作。
- 出现同一抽象类有多个子类，而又需要使用 if-else 或者 switch-case 来选择具体子类时。
结构：
- Context ： 用来操作策略模式的上下文环境
- Stragety ： 策略的抽象类
- ConcreteStragety ： 策略的具体实现
2. 状态模式 State Pattern
当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。
状态模式中的行为是由状态来决定的，不同的状态下有不同的行为。
状态模式是把对象的内在状态的变化封装到不同的状态对象里，状态变化时，其行为也随之改变
使用场景：
- 一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为。
- 代码中包含大量与对象状态有关的条件语句。
结构：
- Context ： 环境类，维护了一个 State 子类实例，这个实例定义了对象的当前状态及行为。
- State ： 抽象状态类。
- ConcreteStatteA/B ： 具体状态类，实现了具体状态下的行为。
3. 工厂模式 Factory Pattern
工厂模式属于创建型设计模式之一，是一种结构简单的设计模式，也是应用广泛的设计模式。
工厂模式是用来实例化对象的模式，是用工厂方法代替 new 操作的一种模式。这种替代可以给系统带来更好的可扩展性。
使用场景：
在任何需要生产复杂对象的地方，都可以使用工厂模式。复杂对象适合使用工程模式，用 new 就可以完成创建的对象无需使用工厂模式。
结构：
- AbstractProduct : 抽象产品类
- ConcreteProductA(B/C) ： 具体产品类
- Factory ： 工厂类，负责实例化各种产品