《Java设计模式及实践》第一章读书笔记
第一章：从面向对象到函数式编程
Java 编程范式
对于不同的编程语言，有一系列的概念、原则和规定。这些概念、原则和规定就被称为编程范式。从理论上来说，我们希望编程语言只遵守一个编程范式，但是实际上，一个语言往往拥有多个编程范式。
命令式编程
用语句改变程序的状态。C语言就是典型。
面向对象编程
这个下面面向对象编程来总结。
声明式编程
与命令式编程相反，声明式编程是：它知道程序应该做什么，而不具体说明怎么做。与命令式编程语言相比，声明式编程语言更抽象。它们不模拟硬件结构，因此不会改变程序状态，而是将它们转换为新状态，并且更接近数学逻辑。
函数式编程（lambda）
函数式编程是声明式编程的子范式。与命令式编程相反，函数式编程不会改变程序额内部状态。
在函数式编程术语中，函数类似于数学函数，函数的输出仅依赖于其参数而不依赖与程序的状态，也就是说它们可以在任何地方运行，然后将多个执行结果连接起来进一步使用。
类之间的关系（ UML ）
泛化（Is-A）
当一个类表示多个类的共享特征时（父类），这称为泛化。类似的，当一个类表示一般类的特殊实例时（子类），这称为特化。
实现
如果说泛化式面向对象中继承概念对应的 UML 中的术语，则 UML 中的实现表示面向对象编程中类的接口实现。
依赖（Uses-A）
它用于定义类以某种方式依赖于另一个类，而另一个类可能依赖于或不依赖与第一个类。
通常，在面向对象的编程语言中，依赖关系用于描述一个类在方法的声明中是否包含第二个类的参数，或者说它只是通过方法将第二个类传递给其他类，而不是使用方法来创建第二个类的实例。
关联
关联白哦是两个实体之间的关系。有两种类型的关联：组合和聚合。
聚合（Has-A）
聚合是一种特殊类型的关联。
聚合用于面熟两个或多个类之间的关系：一个类在逻辑上包含另一个类，但所包含的类的实例又可以独立于第一个类在其上下文之外生存，或者可以被其他的类所引用。
组合
一个类是另一个类的组成部分称为两者间存在组合关系。这有点类似与聚合，不同之处在于当主类不再存在时，依赖类不再存在。
实际上，尤其在具有垃圾回收器的Java等语言中，组合和聚合之间的界限并不是很清晰。对象不必手动销毁，当它们不再被引用时，它们会被垃圾回收器自动销毁。因此，从编码角度来看，我们不需要真正关系处理的是组合还是聚合关系，但是如果我们想在 UML 中定义一个良好的模型，考虑这点就很重要了。
面向对象编程
三个基本特征
有的地方还包括了抽象，四种基本特征。
封装
封装主要是指属性和行为的绑定。封装的思路是将对象的属性和行为保存在一个地方，以便于维护和扩展。封装还提供了一种隐藏用户所不需要的细节的机制（访问权限）。
继承
继承是指对象或类基于另一个对象或类的能力。有一个父类或者基类，它为实体提供顶级行为。每一个满足“父类的属性和方法是子类的一部分”条件的子类实体或者子类都可以从父类中继承，并根据需要添加其他行为。
多态
从广义上讲，多态为我们提供了让不同类型的实体使用相同或接口的选项。主要有两种类型的多态：编译时多态和运行时多态。编译器可以根据调用参数的数量来决定调用哪个方法，这是编译时多态。运行时多态（有时也称为子类型多态）在子类继承父类并覆盖其方法时起作用，这种情况下，编译器无法决定最终执行子类的实现还是父类的实现，只能在运行时做出判定。
五个基本原则
面向对象的设计原则也被称为SOLID。在设计和开发软件时可以应用这些原则，以便创建易于维护和开发的程序。这也是敏捷开发过程中的一部分。SOLID原则包括单一职责原则、开闭原则、里氏替换原则、接口隔离原则和依赖倒置原则。
单一职责原则
单一职责是一种面向对象的设计原则，该原则指出软件模块应该只有一个被修改的理由。
如果类需要更改的原因不止一个，那么每个类都可能引入影响其他类的更改。当这些更改单独管理但影响同一模块时，一系列更改可能会破坏与其他更改原因相关的功能。
另一方面，每个更改的职责或理由都会增加新的依赖关系，使代码不那么健壮，更难以修改。
比如在关于数据库的操作中，因区分Entity类和负责持久的类。
开闭原则
模块、类和函数应该对扩展开发，对修改关闭。
应用此原则将有助于我们开发复杂而稳健的软件。我们必须想象：开发的软件正在构建一个复杂的结构，一旦我们完成了它的一部分，不应该再修改它，而是应该在它的基础上继续建设。
最好的方法是尝试在完成后保持模块不变，并通过继承和多态扩展来添加新功能。开闭原则是最重要的设计原则之一，是大多数设计模式的基础。
里氏替换原则
里氏替换原则声明，在设计模块和类时，必须确保派生类型从行为的角度来看是可替代的。当派生类型被其父类型替换时，其余代码就像它是子类一样使用它。从这个角度来看，派生类型应该像其父类型那样表现，不应该破坏它的行为。这称为强行为子类型。
接口隔离原则
客户端不应该依赖于它所不需要的接口。
实际应用中，接口隔离原则减少了代码耦合，使代码更健壮，更易于维护和扩展。
如果接口隔离原则被破坏，客户端被迫依赖它们不使用的接口时，代码就会变得紧密耦合，几乎不可能为其添加新功能。
依赖倒置原则
高级模块不应该依赖低级模块，两者都应该依赖抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
将高级逻辑和低级模块分开，尝试让他们都依赖于抽象进而减少二者之间的依赖关系。如此就可以替换或扩展其中任何一个模块而不影响其他模块。