学习笔记: 架构师训练营 - 第二周

1、面向对象（OOP： object-oriented programming）

定义：

把数据及对数据的操作方法放在一起，作为一个相互依存的整体——对象。对同类对象抽象出其共性，形成类。类中的大多数数据，只能用本类的方法进行处理。类通过一个简单的外部接口与外界发生关系，对象与对象之间通过消息进行通信。程序流程由用户在使用中决定。对象即为人对各种具体物体抽象后的一个概念，人们每天都要接触各种各样的对象，如手机就是一个对象

主要思想:

把构成问题的各个事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙一个事物在整个解决问题的步骤中的行为。面向对象程序设计中的概念主要包括：对象、类、数据抽象、继承、动态绑定、数据封装、多态性、消息传递。通过这些概念面向对象的思想得到了具体的体现。

特证：

抽象：将一类对象的共同特征总结出来构造类的过程,包括数据抽象和行为抽象两方面,抽象只关注对象的哪些属性和行为,并不关注这此行为的细节是什么

封装：把数据和操作数据的方法绑定起来,对数据的访问只能通过已定义的接口.面向对象的本质就是将现实世界描绘成一系列完全自治,封闭的对象,可以说,封装就是隐藏一切可隐藏的东西,只向外界提供最简单的编程接口。封装给对象提供了隐藏内部特性和行为的能力，对象提供一些能这被其它对象访问的方法来改变它内部的数据

继承：从已有类得到继承信息创建新类的过程,继承让变化中的软件系统有了一定的延续性,同时继承也是封装程序中可变因素的重要手段.子类继承父类属性(静态特征)和方法(动态特征),继承必须遵循封装当中的控制访问

多态：相同的操作或函数、过程可作用于多种类型的对象上并获得不同的结果。不同的对象，收到同一消息可以产生不同的结果，这种现象称为多态性。包括了重载和重写。

重载：重载发生在同一个类中，在该类中如果存在多个同名方法，但是方法的参数类型和个数不一样，那么说明该方法被重载了

重写：重写发生在子类继承父类的关系中，父类中的方法被子类继承，方法名，返回值类型，参数完全一样，但是方法体不一样，那么说明父类中的该方法被子类重写了

与面向过程程序设计对比

2、设计臭味:糟糕的代码有哪些特点

僵硬性: 很难对系统进行感动，因为每个改动都会迫使许多对系统其他功能的改动

脆弱性：对系统的改动会导致系统中和改动无关的地方出现问题

牢固性：很难解开系统的纠结，使之成为一些可在其他系统总重要的组件

粘纸性：做正确的事情比错误的事情要困难

不必要的复杂性：设计中包含不具有任何直接好处的基础结构

不必要的重复：设计中包含重复的结构，而该重复的机构本可以使用单一的抽象进行统一

晦涩性：很难阅读、理解。没有很好的表现出意图。

3、面向对象设计基本原则

3.1、开闭原则(Open-Closed Principle, OCP)

　　一个软件实体应当对扩展开放，对修改关闭。也就是说在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现在不修改源代码的情况下改变这个模块的行为。

3.2、依赖倒置原则(Dependence Inversion Principle, DIP)

　　高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。要针对接口编程，不要针对实现编程。

3.3、里氏替换原则(Liskov Substitution Principle，LSP)

所有引用基类（父类）的地方必须能透明地使用其子类的对象。

3.4、单一职责原则(Single Responsibilities Principle,SRP)

就一个类而言，应该仅有一个引起它变化的原因。简而言之，就是功能要单一。

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。(敏捷软件开发)

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。(敏捷软件开发)

单一职责原则可以看做是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这样导致职责依赖，相互之间就会产生原因，大大损伤其内聚性和耦合度。

3.5、接口隔离（Interface Segregation Principle, ISP）

使用多个专门的接口比使用单一的总接口要好。

一个类对另外一个类的依赖性应当是建立在最小的接口上的。

一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。

不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变

3.6、迪米特法则

最少知道原则：一个类对自己依赖的类知道的越少越好

只与直接的朋友通信：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。

迪米特法则的初衷是降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系。但是凡事都有度，虽然可以避免与非直接的类通信，但是要通信，必然会通过一个“中介”来发生联系，例如本例中，总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合