OO 思想
原创整理与编写，转载请注明出处
三大特性
封装
软件对象包括状态和相关行为。
方法对的内部状态进行操作，并作为对象通信的主要机制。
隐藏内部状态并要求通过对象的方法执行所有交互称为数据封装 - 面向对象编程的基本原则。
好处：
- 模块化：可以独立于其他对象的源码。
- 信息隐藏：内部实现的细节隐藏于外部。
- 代码重用：如果对象已存在，则可以重用。
- 可插拔性和调试简易性：如果某个对象有问题，只需将其从应用程序中删除，然后插入另一个对象作为替代。这类似于现实世界中的机械问题：如果螺栓断裂，更换它就行，不用换整个机器。
继承
在Java语言中，类可以从其他类派生，从而继承字段和方法。
子类从其超类继承（这里的继承要理解为拷贝）所有成员（字段，方法和嵌套类）。构造函数不是成员，它们不会类继承，但可以从子类调用。
继承应该遵循里氏替换原则，子类对象必须能够替换掉所有父类对象。
可以在子类中执行的操作
子类继承所有公共成员和受保护成员。如果子类与父类在同一个包中，它还继承父类包私有成员。
下面是一些注意点：
- 子类中声明同名字段，会隐藏父类字段（不推荐）。
- 子类中编写一个新的静态方法，与父类具有相同的签名，会实现隐藏。
- 子类中编写一个新实例方法，与父类具有相同的签名，会实现覆盖。
- 子类构造函数，它可以隐式地或使用关键字来调用父类的构造函数。
父类私有域
子类不继承父类的private成员。
嵌套类可以访问其封闭类的所有私有成员 - 包括字段和方法。于是，子类继承的嵌套类可以间接访问超类的所有私有成员。
@see code
多态
Java虚拟机（JVM）为每个变量引用的对象调用适当的方法。它不会调用声明类型的方法。此行为称为虚方法调用。
多态的三个条件：
- 继承
- 覆盖（重写）
- 向上转型
@see code
抽象的一些tip
抽象类与接口
抽象类与接口类似，都无法实例化。但是，使用抽象类，可以声明非静态和非final的字段，并定义public，protected和private方法。使用接口，所有字段都自动为public，static和final，所有方法（作为默认方法）都是公共的。此外，只能扩展一个类，而可以实现多个接口。
使用哪个？
- 抽象类：
- 公用的方法或字段，或者需要除public之外的访问修饰符（例如protected和private）。
- 声明非静态或非最终字段
- 接口：
- 不相关的类会实现，代表特性。如，接口 Comparable以及 Cloneable
- 指定特定数据类型的行为，但不关心谁实现。
- 多重继承。
JDK中的抽象类的示例
AbstractMap是集合框架的一部分。它的子类（包括HashMap，TreeMap，和ConcurrentHashMap）共享许多方法（包括get，put，isEmpty，containsKey，和containsValue）。
HashMap实现了接口Serializable，Cloneable和Map
对象关系
这里简单讲下uml里的对象关系，复杂设计可能会用到这些概念。
泛化关系 (Generalization)
用来描述继承关系，在 Java 中使用 extends 关键字。
实现关系 (Realization)
用来实现一个接口，在 Java 中使用 implement 关键字。
聚合关系 (Aggregation)
表示整体由部分组成，但是整体和部分不是强依赖的，整体不存在了部分还是会存在。
组合关系 (Composition)
和聚合不同，组合中整体和部分是强依赖的，整体不存在了部分也不存在了。比如公司和部门，公司没了部门就不存在了。但是公司和员工就属于聚合关系了，因为公司没了员工还在。
关联关系 (Association)
表示不同类对象之间有关联，这是一种静态关系，与运行过程的状态无关，在最开始就可以确定。因此也可以用 1 对 1、多对 1、多对多这种关联关系来表示。比如学生和学校就是一种关联关系，一个学校可以有很多学生，但是一个学生只属于一个学校，因此这是一种多对一的关系，在运行开始之前就可以确定。
依赖关系 (Dependency)
和关联关系不同的是，依赖关系是在运行过程中起作用的。A 类和 B 类是依赖关系主要有三种形式：
- A 类是 B 类方法的局部变量；
- A 类是 B 类方法当中的一个参数；
- A 类向 B 类发送消息，从而影响 B 类发生变化。
设计理念
Steve Smith在微软TechED 上有个SOLIDify Your ASP.NET MVC的讲座, 很好的解释了SOLID原则。
SOLID（稳固的）
| 简写 | 全拼 | 中文翻译 |
|---|---|---|
| SRP | The Single Responsibility Principle | 单一责任原则 |
| OCP | The Open Closed Principle | 开放封闭原则 |
| LSP | The Liskov Substitution Principle | 里氏替换原则 |
| ISP | The Interface Segregation Principle | 接口分离原则 |
| DIP | The Dependency Inversion Principle | 依赖倒置原则 |
1. 单一责任原则
修改一个类的原因应该只有一个。
换句话说就是让一个类只负责一件事，当这个类需要做过多事情的时候，就需要分解这个类。
如果一个类承担的职责过多，就等于把这些职责耦合在了一起，一个职责的变化可能会削弱这个类完成其它职责的能力。
@see java.util.Map，java.util.Collection
2. 开放封闭原则
类应该对扩展开放，对修改关闭。
在穿外套时不需要开胸手术。
扩展就是添加新功能的意思，因此该原则要求在添加新功能时不需要修改代码。
符合开闭原则最典型的设计模式是装饰者模式，它可以动态地将责任附加到对象上，而不用去修改类的代码。
@see java.lang.Iterable
3. 里氏替换原则
子类对象必须能够替换掉所有父类对象。
如果它看起来像一只鸭子，像鸭子一样嘎嘎叫，但需要电池——你可能有了错误的抽象。
继承是一种 IS-A 关系，子类需要能够当成父类来使用，并且需要比父类更特殊。
如果不满足这个原则，那么各个子类的行为上就会有很大差异，增加继承体系的复杂度。
@see java.util.ArrayList，和其他java集合类
4. 接口分离原则
不应该强迫客户依赖于它们不用的方法。使用多个专门的接口比使用单一的总接口总要好。
你要我插到哪个接口？
因此使用多个专门的接口比使用单一的总接口要好。
@see java.util.Map，java.util.Collection
5. 依赖倒置原则
底层模块不应该依赖于上层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。
你会把一盏灯直接焊接到墙上的电线上吗？
底层模块包含一个应用程序中重要的策略选择和业务模块；如果底层模块依赖于上层模块，那么上层模块的改动就会直接影响到底层模块，从而迫使底层模块也需要改动。
@see java.util.Map，java.util.Collection
其他常见原则
除了上述的经典原则，在实际开发中还有下面这些常见的设计原则。
| 简写 | 全拼 | 中文翻译 |
|---|---|---|
| LOD | The Law of Demeter | 迪米特法则 |
| CRP | The Composite Reuse Principle | 合成复用原则 |
| CCP | The Common Closure Principle | 共同封闭原则 |
| SAP | The Stable Abstractions Principle | 稳定抽象原则 |
| SDP | The Stable Dependencies Principle | 稳定依赖原则 |
1. 迪米特法则
迪米特法则又叫作最少知识原则（Least Knowledge Principle，简写 LKP），就是说一个对象应当对其他对象有尽可能少的了解。
尽量调用他们的公开方法。
2. 合成复用原则
尽量使用对象组合，而不是通过继承来达到复用的目的。这样可以解耦。
3. 共同封闭原则
一起修改的类，应该组合在一起（同一个包里）。如果必须修改应用程序里的代码，我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。
所以按业务区分包也是不错的选择，可以较充分包可见性。
4. 稳定抽象原则
最稳定的包应该是最抽象的包，不稳定的包应该是具体的包，即包的抽象程度跟它的稳定性成正比。
@see javax.validation.validation-api
5. 稳定依赖原则
包之间的依赖关系都应该是稳定向依赖，包要依赖的包要比自己更具有稳定性。
所以尽量依赖jdk，再就是一些广泛使用的第三方框架，后续是小众框架。
软件设计通用原则
不做重复的事（DRY，Don’t Repeat Yourself）
在一定范围内抽象功能，不要重复。
降低可管理单元复杂度的一个基本策略就是将他们拆解成更小的单元。
违反DRY原则的解决方案通常被称为WET，指代“write everything twice”。
spring文档里面经常提到这个原则。
有需要可以尝试第三方工具如 apache common utils、guava等。
保持简单直接（KISS，Keep it Simple Stupid）
坚持简约原则，避免不必要的复杂化。
对外的接口尽量简洁明了。
这样上游和用户可以减少疑问，也降低沟通成本。
把一个事情搞复杂是一件简单的事，但要把一个复杂的事变简单，这是一件复杂的事。
你不需要它(YAGNI，You Ain’t Gonna Need It)
这是"极限编程"提倡的原则，指的是你自以为有用的功能，实际上都是用不到的。因此，除了最核心（需要）的功能，其他功能一概不要部署，这样可以大大加快开发。
它背后的指导思想，就是尽可能快、尽可能简单地让软件运行起来（do the simplest thing that could possibly work）
就是避免过度设计。
使用2次以上可以考虑抽取功能。
批判性思考
[美] Kirk Knoernschild 在“java应用架构设计：模块化模式与OSGi”提到一个悖论：
重用/可用悖论（重用悖论）
最大化重用会使得可用复杂化。
总体而言，软件模块的可重用性越高，这个模块使用起来就越困难。
所以，软件设计要在重用和可用中找到一个折衷点。
spring项目其实做了很好的折衷：
它分成了几个块：
- 核心技术：依赖注入，事件，资源，i18n，验证，数据绑定，类型转换，SpEL，AOP。
- 测试：模拟对象，TestContext框架，Spring MVC测试，WebTestClient。
- 数据访问：事务，DAO支持，JDBC，ORM，编组XML。
- Spring MVC和 Spring WebFlux Web框架。
- 集成：远程处理，JMS，JCA，JMX，电子邮件，任务，调度，缓存。
- 语言：Kotlin，Groovy，动态语言。
我们可以按需依赖其中几个而不必依赖所有的。spring没有划分的非常细，它划了几个通用的包，使得使用者易于使用，也达到了不错的重用效果。
后记
主要是记住OO3大特性和OO5大原则，在遵守原则的同时可以尽量运用特性进行编程简化。
重用可用悖论也是我们要思考的问题，他说明了了软件设计中模块（代码）粒度需要折衷。
而运用这些原则和特性的目的是实现可读、可维护、可复用、易用的代码，模块，项目和业务系统。
其他原则也可以适时适度的参考。
code
code