JZOOD面向对象设计 - C1 面向对象设计入门
1 SOLID原则
Single responsibility principle 单一责任原则
改的只有一个小的部分，也适合单元测试
解析：单一责任原则指的是一个类只有一项工作，例如一个格式化数据打印的类，类中的成员函数可以有Json格式化输出函数，String格式化输出函数，List格式化输出函数等等。这边的单一责任就是指这个类的唯一工作就是格式化输出数据。
第二种原则叫做O-Open Close Principle（开放封闭原则）
对扩展开放，对修改关闭
解析：抽象类不允许被直接创建对象，其他类的特性依旧存在。抽象类的实现应在继承该类的子类中去具体实现。抽象类中只负责定义该抽象方法。由于abstract 的方法需要在继承后的子类中实现，因此不可以 与final , private , static 共存。
L – Liskov substitution principle（里氏替换原则）和I – Interface segregation principle（接口分离原则）
机器人不能继承人的类
类不能继承不能实现的接口
解析1：SingleResponsibility 是为了解决后续维护中class过于臃肿的原则，InterfaceSegragation 是为了解决面向外部调用者让其他开发人员更容易明白不同接口的功能区别而总结的原则。
解析2：假设现在我们有一个interface提供给用户，但是里面有太多用户不需要的功能，显得我们的interface过于臃肿；那么这时候我们就要把这个大的接口根据功能再次细分，然后提供给不同的用户。这就叫接口分离。
解析3：当父类的某些方法不确定时，可以用abstract关键字来修饰该方法[抽象方法]，用abstract来修饰该类[抽象类]，一个类中一旦有抽象方法，必须定义成抽象类。子类在继承父类的时候一定要实现父类中的抽象方法，并且会自动继承除构造函数以外的Public和Protect方法，子类可以重写这些方法。此外，子类也可以自定义自身的方法。
最后一个原则是D–Dependency inversion principle（依赖反转原则）
抽象不应该依赖于具体实现，具体实现应该依赖于抽象，因为如果如果具体实现没了，你依赖它就会报错
2 例题和5C解题法
- Clarify
what （提问关键字）：
关键1：Elevator
有没有承重不一样
会不会分客梯和货梯
关键2：Building
是否有多处能搭乘的电梯
how（针对规则来提问）
判断是否电梯超重
按下按钮，哪一台电梯会响应
电梯运行的时候能否按下反向的楼层 - Core Object
以一个Object为基础，线性的把流程需要的Object写出来，比如 Request -> ElevatorSystem -> Elevator -> ElevatorButton
确定Objects之间的关系，比如一对多，或者多对一 - UML类图符号
解析：在UML类图当中，每个方法和属性都会用前缀修饰符来表示其访问级别。若没有前缀修饰符则代表此方法或属性属于Package内都可访问，在不同Package内不能直接访问。若有修饰符：'+'表示Public，代表此方法或属性公开，能在任何地方都能直接访问；'-'表示Private，代表此方法或属性私有 ，只能通过类内部访问；'#'表示Protected，代表此方法或属性为保护，在同一个Package内可以访问，在另一个Package内需要通过子类继承才能进行访问。 -
Cases
利用之前定义的CoreObject，列举每个Object对应产生的use case，如：
-
Class
如：
Use cases，对于use case更加详细地描述这个use case在做什么视频，针对这个描述去已有的Core Object填充进所需要的信息
解析： 使用ENUM相当于提前定义了一个类只能从一组值当中选择，比如定义一个ENUM COLOR，可选的值为 RED, YELLOW, BLUE. 这样的方法和使用String / Integer 做为值相比使得代码的可读性大大提升；同时这样的ENUM告诉编译器传递进来的值只能从红黄蓝三色当中选取，避免错误；同样这个定义过的ENUM可以在任何地方被使用。但ENUM从运行速度上来说和其他做法并没有太大区别。
使用异常处理来处理特殊的情况。 - Strategy Design Pattern
把策略变为interface，符合依赖翻转原则
解析：当一个类只做一件事情的时候，它通常会有更少的函数/变量/接口, 使得这个类更容易被理解；同样，由于这个类只负责一件事，这个类的变化不容易影响到其他的类，使得代码更易维护，也更容易被其他需要相同功能的地方复用；至于高耦合 (Tighter Coupling)，这其实是在设计当中我们避免出现的事情，它指的是类和类之间有很紧密的关联，所以SRP其实引导向的是一种好的设计模式，也就是高内聚，低耦合 (High Cohesion， Loose Coupling)。
