- 三大特性即是: 封装、继承、多态
- 六大原则即是: 单一职责、里氏替换、依赖倒置、接口隔离、最少知识、开闭原则
三大特性
封装
首先，属性可用来描述同一类事物的特征，方法可描述一类事物可做的操作。封装就是把属于同一类事物的共性（包括属性与方法）归到一个类中，以方便使用。
- 1.概念：封装也称为信息隐藏，是指利用抽象数据类型将数据和基于数据的操作封装在一起，使其构成一个不可分割的独立实体，数据被保护在抽象数据类型的内部， 尽可能地隐藏内部的细节，只保留一些对外接口使之与外部发生联系。系统的其他部分只有通过包裹在数据外面的被授权的操作来与这个抽象数据类型交流与交互。 也就是说，用户无需知道对象内部方法的实现细节，但可以根据对象提供的外部接口(对象名和参数)访问该对象。
- 2.好处：(1)实现了专业的分工。 将能实现某一特定功能的代码封装成一个独立的实体后，各程序员可以在需要的时候调用，从而实现了专业的分工。(2)隐藏信息，实现细节。通过控制访问权限 可以将可以将不想让客户端程序员看到的信息隐藏起来，如某客户的银行的密码需要保密，只能对该客户开发权限。
继承
就是个性对共性的属性与方法的接受，并加入个性特有的属性与方法
- 1.概念：一个类继承另一个类，则称继承的类为子类，被继承的类为父类。
- 2.目的：实现代码的复用。
- 3.理解：子类与父类的关系并不是日常生活中的父子关系，子类与父类而是一种特殊化与一般化的关系，是is-a的关系，子类是父类更加详细的分类。如 class dog extends animal,就可以理解为dog is a animal.注意设计继承的时候，若要让某个类能继承，父类需适当开放访问权限，遵循里氏代换原则，即向修改关闭对扩展开放，也就是开-闭原则。
- 4.结果：继承后子类自动拥有了父类的属性和方法，但特别注意的是，父类的私有属性和构造方法并不能被继承。
另外子类可以写自己特有的属性和方法，目的是实现功能的扩展，子类也可以复写父类的方法即方法的重写。
多态
多态的概念发展出来，是以封装和继承为基础的。
多态就是在抽象的层面上实施一个统一的行为，到个体（具体）的层面上时，这个统一的行为会因为个体（具体）的形态特征而实施自己的特征行为。（针对一个抽象的事，对于内部个体又能找到其自身的行为去执行。）
1.概念：相同的事物，调用其相同的方法，参数也相同时，但表现的行为却不同。
2.理解：子类以父类的身份出现，但做事情时还是以自己的方法实现。子类以父类的身份出现需要向上转型(upcast)，其中向上转型是由JVM自动实现的， 是安全的，但向下转型(downcast)是不安全的，需要强制转换。子类以父类的身份出现时自己特有的属性和方法将不能使用。
六大原则
一.单一职责原则
Single Responsibility Principle, 简称SRP。
定义：There should never be more than one reason for a class to change.
应该有且仅有一个原因引起类的变更。
职责的划分？单一的定义和级别？
应该根据实际业务情况而定。关注变化点。
实际使用时，类很难做到职责单一，但是接口的职责应该尽量单一。
二.里氏替换原则
Liskov Substitution Principle, 简称LSP。
定义：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
(所有引用基类的地方必须能透明地使用其子类的对象)
里氏替换原则为良好的继承定义了一个规范：
- 1.子类必须完全实现父类的方法。
- 2.子类可以有自己的个性（属性和方法）。
- 3.覆盖或实现父类的方法时输入参数可以被放大。
- 4.覆写或实现父类的方法时输出结果可以被缩小。
注：在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。
三.依赖倒置原则
Dependence Inversion Principle, 简称DIP
定义：High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.
翻译过来，包含三层含义：
- 1.高层模块不应该依赖低层模块，两者都应该依赖其抽象。
- 2.抽象不应该依赖细节。
- 3.细节应该依赖抽象。
精简的定义： 面向接口编程。
- Test-Driven Development 测试驱动开发是依赖倒置原则的最好体现。
- 测试驱动开发要求先写测试类，测试通过才写实现类，这就要求你要先想接口定义。
依赖的三种写法：
- 1.构造函数传递依赖对象。
- 2.Setter方法传递依赖对象。
- 3.接口声明依赖对象。
最佳实践：
- 1.每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备。
- 2.变量的表面类型尽量是接口或抽象类。
- 3.任何类都不应该从具体类派生。
- 4.尽量不要覆写基类的方法。
- 5.结合里氏替换原则使用。
四.接口隔离原则：
接口–这里指用interface关键字定义的接口。
定义：
- 1.Clients should not be forced to depend upon interfaces that they don’t use.(客户端不应该依赖它不需要的接口)
- 2.The dependency of one class to anther one should depend on the smallest possible interface.(类间的依赖关系应该建立在最小的接口上)
概括：建立单一接口，不要建立臃肿庞大的接口。
- 通俗来讲：接口尽量细化，同时接口中的方法尽量少。
- 如何细化？细化到什么程序？
- 没有统一的标准，应根据业务合理细分，适合业务才是重点。
保证接口的纯结性：
- 1.接口要尽量小。
- 2.接口要高内聚。
- 3.定制服务。
- 4.接口的设计是有限度的。
最佳实践：
- 1.一个接口只服务于一个子模块或业务逻辑。
- 2.通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法。
- 3.已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理。
- 4.了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，不要盲从大师的设计，要根据业务逻辑进行最好的接口设计。
五.迪米特法则
Law of Demeter, LOD。又称最少知识原则（Least Knowledge Principle, LKP）。
通俗来讲：一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没有关系，那是你的事情，我就调用你提供的public方法，其他一概不关心。
低耦合要求：
- 1.只和朋友交流
朋友类：出现在成员变量、方法的输入输出参数中的类。方法体内部的类不属于朋友类。
- 2.朋友间也是有距离的
迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。
- 3.是自己的就是自己的
如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放置在本类中。
- 4.谨慎使用Serializable
- 1.只和朋友交流
六.开闭原则
Software entities like classes, modules and functions should be open for extension but closed for modifications.（一个软件实体如类、模块和函数应该对扩展开放，对修改关闭）
软件实体包括以下几个部分：
- 1.项目和软件产品中按照一定的逻辑规则划分的模块。
- 2.抽象和类。
- 3.方法。
变化的三种类型：
- 1.逻辑变化
- 2.子模块变化
- 3.可见视图变化