最近为项目组整理相关项目相关的规范文档，并整理了项目中，代码中的一些问题，识别项目代码中的一些可以优化的代码，为项目后续的重构提供一些理论基础，下面是为项目组编写的一些技术开发需要了解的概念，虽然内容看上去不多，但是以下的内容想要真正理解其中的含义，并在项目开发过程中合理实现，且不是一件容易的事，可能几年都不一定能够真正理解，真正体会其中的思想，下面就一起看看吧。
相关知识点汇总：
一：命名规范与注解
二：阿里巴巴开发手册简介
三：高内聚，低耦合，易复用的思想
四：面向对象的三大基本特征（封装、继承和多态）
五：23种设计模式初探（创建型，结构型，行为型）
六：面向对象的七大设计原则
七：重构的注意事项与技术实现（重构-改善既有代码的设计）
八：阿里巴巴代码规范插件的使用
九：扩展阅读
一：命名规范与注解
命名规范参考网址：https://www.jianshu.com/p/b7a644ea0d25
注解实现：
例子：/**
* @author 开发者姓名
* @description: 创建类的功能
* @date :${DATE} ${TIME}
*/
编写函数的注释：
二：阿里巴巴开发手册简介
详情请参考网址：
附加：命名规范如有冲突，请以：https://www.jianshu.com/p/b7a644ea0d25的为准。
三：高内聚，低耦合，易复用的思想
内聚性：
内聚：故名思议，表示内部间聚集、关联的程度，那么高内聚就是指要高度的聚集和关联。高内聚是指类与类之间的关系而定，高，意思是他们之间的关系要简单，明了，不要有很强的关系，不然，运行起来就会出问题。一个类的运行影响到其他的类。由于高内聚具备可靠性，可重用性，可读性等优点，模块设计推荐采用高内聚。内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系。
偶然内聚：一个模块内的各处理元素之间没有任何联系，只是偶然地被凑到一起。这种模块也称为巧合内聚，内聚程度最低。
逻辑内聚：这种模块把几种相关的功能组合在一起， 每次被调用时，由传送给模块参数来确定该模块应完成哪一种功能 。
时间内聚：把需要同时执行的动作组合在一起形成的模块称为时间内聚模块。
过程内聚：构建或者操作的组合方式时，允许在调用前面的构建或操作之后，马上调用后面的构件或操作，即使两者之间没有数据进行传递。简单的说就是如果一个模块内的处理元素是相关的，而且必须以特定次序执行则称为过程内聚。例如某要完成登录的功能，前一个功能判断网络状态，后一个执行登录操作，显然是按照特定次序执行的。
通信内聚：指模块内所有处理元素都在同一个数据结构上操作或所有处理功能都通过公用数据而发生关联（有时称之为信息内聚）。即指模块内各个组成部分都使用相同的数据结构或产生相同的数据结构。
顺序内聚：一个模块中各个处理元素和同一个功能密切相关，而且这些处理必须顺序执行，通常前一个处理元素的输出时后一个处理元素的输入。例如某要完成获取订单信息的功能，前一个功能获取用户信息，后一个执行计算均价操作，显然该模块内两部分紧密关联。顺序内聚的内聚度比较高，但缺点是不如功能内聚易于维护。
功能内聚：模块内所有元素的各个组成部分全部都为完成同一个功能而存在，共同完成一个单一的功能，模块已不可再分。即模块仅包括为完成某个功能所必须的所有成分，这些成分紧密联系、缺一不可。
增强内聚度方法：
1、模块只对外暴露最小限度的接口，形成最低的依赖关系。
2、只要对外接口不变，模块内部的修改，就不得影响其他模块。
3、删除一个模块，应当只影响有依赖关系的其他模块，而不应该影响其他无关部分。
耦合性：
耦合：是对模块间关联程度的度量。耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。
模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。模块间联系越多，其耦合性越强，同时表明其独立性越差。降低模块间的耦合度能减少模块间的影响，防止对某一模块修改所引起的“牵一发动全身”的水波效应，保证系统设计顺利进行。
耦合度就是某模块（类）与其它模块（类）之间的关联、感知和依赖的程度，是衡量代码独立性的一个指标。
非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。耦合度最弱，模块独立性最强。
数据耦合：调用模块和被调用模块之间只传递简单的数据项参数。相当于高级语言中的值传递。
标记耦合：调用模块和被调用模块之间传递数据结构而不是简单数据，同时也称作特征耦合。表示和模块间传递的不是简单变量，而是像高级语言中的数据名、记录名和文件名等数据结果，这些名字即为标记，其实传递的是地址。
控制耦合：模块之间传递的不是数据信息，而是控制信息例如标志、开关量等，一个模块控制了另一个模块的功能。
外部耦合：一组模块都访问同一全局简单变量，而且不通过参数表传递该全局变量的信息，则称之为外部耦合。
公共耦合：一组模块都访问同一个全局数据结构，则称之为公共耦合。公共数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。如果模块只是向公共数据环境输入数据，或是只从公共数据环境取出数据，这属于比较松散的公共耦合；如果模块既向公共数据环境输入数据又从公共数据环境取出数据，这属于较紧密的公共耦合。
公共耦合会引起以下问题：
1. 无法控制各个模块对公共数据的存取，严重影响了软件模块的可靠性和适应性。
2. 使软件的可维护性变差。若一个模块修改了公共数据，则会影响相关模块。
3. 降低了软件的可理解性。不容易清楚知道哪些数据被哪些模块所共享，排错困难。
一般地，仅当模块间共享的数据很多且通过参数传递很不方便时，才使用公共耦合。
内容耦合：一个模块直接访问另一模块的内容，则称这两个模块为内容耦合。
若在程序中出现下列情况之一，则说明两个模块之间发生了内容耦合：
1. 一个模块直接访问另一个模块的内部数据。
2. 一个模块不通过正常入口而直接转入到另一个模块的内部。
3. 两个模块有一部分代码重叠（该部分代码具有一定的独立功能）。
4. 一个模块有多个入口。
内容耦合可能在汇编语言中出现。大多数高级语言都已设计成不允许出现内容耦合。这种耦合的耦合性最强，模块独立性最弱。
降低耦合度的方法：
1、少使用类的继承，多用接口隐藏实现的细节。 Java面向对象编程引入接口除了支持多态外， 隐藏实现细节也是其中一个目的。
2、模块的功能化分尽可能的单一，道理也很简单，功能单一的模块供其它模块调用的机会就少。（其实这是高内聚的一种说法，高内聚低耦合一般同时出现）。
3、遵循一个定义只在一个地方出现。
4、少使用全局变量。
5、类属性和方法的声明少用public，多用private关键字。
6、多用设计模式，比如采用MVC的设计模式就可以降低界面与业务逻辑的耦合度。
7、尽量不用“硬编码”的方式写程序，同时也尽量避免直接用SQL语句操作数据库。
8、最后当然就是避免直接操作或调用其它模块或类（内容耦合）；如果模块间必须存在耦合，原则上尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，避免使用内容耦合。
四：面向对象的三大基本特征（封装、继承和多态）
一、封装
封装从字面上来理解就是包装的意思，专业点就是信息隐藏，是指利用抽象数据类型将数据和基于数据的操作封装在一起，使其构成一个不可分割的独立实体，数据被保护在抽象数据类型的内部，尽可能地隐藏内部的细节，只保留一些对外接口使之与外部发生联系，系统的其他对象只能通过包裹在数据外面的已经授权的操作来与这个封装的对象进行交流和交互，也就是说用户是无需知道对象内部的细节，但可以通过该对象对外的提供的接口来访问该对象。
对于封装而言，一个对象它所封装的是自己的属性和方法，所以它是不需要依赖其他对象就可以完成自己的操作。
使用封装有四大好处：
1、良好的封装能够减少耦合。
2、类内部的结构可以自由修改。
3、可以对成员进行更精确的控制。
4、隐藏信息实现细节。
封装把一个对象的属性私有化，同时提供一些可以被外界访问的属性的方法，如果不想被外界方法，我们大可不必提供方法给外界访问。但是如果一个类没有提供给外界访问的方法，那么这个类也没有什么意义了。
封装可以使我们容易地修改类的内部实现，而无需修改使用了该类的客户代码。就可以对成员变量进行更精确的控制。
二、继承
2.1 继承综述：
继承是使用已存在的类的定义作为基础建立新类的技术，新类的定义可以增加新的数据或新的功能，也可以用父类的功能，但不能选择性地继承父类。通过使用继承我们能够非常方便地复用以前的代码，能够大大的提高开发的效率。
继承所描述的是“is-a”的关系，如果有两个对象A和B，若可以描述为“A是B”，则可以表示A继承B，其中B是被继承者称之为父类或者超类，A是继承者称之为子类或者派生类。
实际上继承者是被继承者的特殊化，它除了拥有被继承者的特性外，还拥有自己独有得特性。例如猫有抓老鼠、爬树等其他动物没有的特性。同时在继承关系中，继承者完全可以替换被继承者，反之则不可以，例如我们可以说猫是动物，但不能说动物是猫就是这个道理，其实对于这个我们将其称之为“向上转型”。
继承定义了类如何相互关联，共享特性。对于若干个相同或者相似的类，我们可以抽象出他们共有的行为或者属性并将其定义成一个父类或者超类，然后用这些类继承该父类，他们不仅可以拥有父类的属性、方法还可以定义自己独有的属性或者方法。
同时在使用继承时需要记住三句话：
1、子类拥有父类非private的属性和方法。
2、子类可以拥有自己属性和方法，即子类可以对父类进行扩展。
3、子类可以用自己的方式实现父类的方法。
学习继承一定少不了这三个东西：构造器、protected关键字、向上转型
2.2 构造器
通过前面我们知道子类可以继承父类的属性和方法，除了那些private的外还有一样是子类继承不了的---构造器。对于构造器而言，它只能够被调用，而不能被继承。 调用父类的构造方法我们使用super()即可。
构建过程是从父类“向外”扩散的，也就是从父类开始向子类一级一级地完成构建。而且我们并没有显示的引用父类的构造器，这就是java的聪明之处：编译器会默认给子类调用父类的构造器。
但是，这个默认调用父类的构造器是有前提的：父类有默认构造器。如果父类没有默认构造器，我们就要必须显示的使用super()来调用父类构造器，否则编译器会报错：无法找到符合父类形式的构造器。
对于子类而已,其构造器的正确初始化是非常重要的,而且当且仅当只有一个方法可以保证这点：在构造器中调用父类构造器来完成初始化，而父类构造器具有执行父类初始化所需要的所有知识和能力。
对于继承而言，子类会默认调用父类的构造器，但是如果没有默认的父类构造器，子类必须要显示的指定父类的构造器，而且必须是在子类构造器中做的第一件事(第一行代码)。
2.3 protected关键字
private访问修饰符，对于封装而言，是最好的选择，但这个只是基于理想的世界，有时候我们需要这样的需求：我们需要将某些事物尽可能地对这个世界隐藏，但是仍然允许子类的成员来访问它们。这个时候就需要使用到protected。
对于protected而言，它指明就类用户而言，他是private，但是对于任何继承与此类的子类而言或者其他任何位于同一个包的类而言，他却是可以访问的。
2.4 向上转型
在上面的继承中我们谈到继承是is-a的相互关系，猫继承与动物，所以我们可以说猫是动物，或者说猫是动物的一种。这样将猫看做动物就是向上转型。
将子类转换成父类，在继承关系上面是向上移动的，所以一般称之为向上转型。由于向上转型是从一个叫专用类型向较通用类型转换，所以它总是安全的，唯一发生变化的可能就是属性和方法的丢失。这就是为什么编译器在“未曾明确表示转型”或“未曾指定特殊标记”的情况下，仍然允许向上转型的原因。
2.5 谨慎继承
在这里我们需要明确，继承存在如下缺陷：
1、父类变，子类就必须变。
2、继承破坏了封装，对于父类而言，它的实现细节对与子类来说都是透明的。
3、继承是一种强耦合关系。
所以说当我们使用继承的时候，我们需要确信使用继承确实是有效可行的办法。那么到底要不要使用继承呢？《Think in java》中提供了解决办法：问一问自己是否需要从子类向父类进行向上转型。如果必须向上转型，则继承是必要的，但是如果不需要，则应当好好考虑自己是否需要继承。
三、多态
3.1 多态综述
所谓多态就是指程序中定义的引用变量所指向的具体类型和通过该引用变量发出的方法调用在编程时并不确定，而是在程序运行期间才确定，即一个引用变量到底会指向哪个类的实例对象，该引用变量发出的方法调用到底是哪个类中实现的方法，必须在由程序运行期间才能决定。因为在程序运行时才确定具体的类，这样，不用修改源程序代码，就可以让引用变量绑定到各种不同的类实现上，从而导致该引用调用的具体方法随之改变，即不修改程序代码就可以改变程序运行时所绑定的具体代码，让程序可以选择多个运行状态，这就是多态性。
所以对于多态我们可以总结如下：
指向子类的父类引用由于向上转型了，它只能访问父类中拥有的方法和属性，而对于子类中存在而父类中不存在的方法，该引用是不能使用的，尽管是重载该方法。若子类重写了父类中的某些方法，在调用该些方法的时候，必定是使用子类中定义的这些方法（动态连接、动态调用）。
对于面向对象而言，多态分为编译时多态和运行时多态。其中编辑时多态是静态的，主要是指方法的重载，它是根据参数列表的不同来区分不同的函数，通过编辑之后会变成两个不同的函数，在运行时谈不上多态。而运行时多态是动态的，它是通过动态绑定来实现的，也就是我们所说的多态性。
3.2 多态的实现条件
在刚刚开始就提到了继承在为多态的实现做了准备。子类Child继承父类Father，我们可以编写一个指向子类的父类类型引用，该引用既可以处理父类Father对象，也可以处理子类Child对象，当相同的消息发送给子类或者父类对象时，该对象就会根据自己所属的引用而执行不同的行为，这就是多态。即多态性就是相同的消息使得不同的类做出不同的响应。
Java实现多态有三个必要条件：继承、重写、向上转型。
继承：在多态中必须存在有继承关系的子类和父类。
重写：子类对父类中某些方法进行重新定义，在调用这些方法时就会调用子类的方法。
向上转型：在多态中需要将子类的引用赋给父类对象，只有这样该引用才能够具备技能调用父类的方法和子类的方法。
只有满足了上述三个条件，我们才能够在同一个继承结构中使用统一的逻辑实现代码处理不同的对象，从而达到执行不同的行为。
对于Java而言，它多态的实现机制遵循一个原则：当超类对象引用变量引用子类对象时，被引用对象的类型而不是引用变量的类型决定了调用谁的成员方法，但是这个被调用的方法必须是在超类中定义过的，也就是说被子类覆盖的方法。
3.3 实现形式
在Java中有两种形式可以实现多态：继承和接口。
3.2.1、基于继承实现的多态
基于继承的实现机制主要表现在父类和继承该父类的一个或多个子类对某些方法的重写，多个子类对同一方法的重写可以表现出不同的行为。
基于继承实现的多态可以总结如下：对于引用子类的父类类型，在处理该引用时，它适用于继承该父类的所有子类，子类对象的不同，对方法的实现也就不同，执行相同动作产生的行为也就不同。
如果父类是抽象类，那么子类必须要实现父类中所有的抽象方法，这样该父类所有的子类一定存在统一的对外接口，但其内部的具体实现可以各异。这样我们就可以使用顶层类提供的统一接口来处理该层次的方法。 3.2.2、基于接口实现的多态
继承是通过重写父类的同一方法的几个不同子类来体现的，那么就可通过实现接口并覆盖接口中同一方法的几个不同的类体现的。
在接口的多态中，指向接口的引用必须是指定这实现了该接口的一个类的实例程序，在运行时，根据对象引用的实际类型来执行对应的方法。
继承都是单继承，只能为一组相关的类提供一致的服务接口。但是接口可以是多继承多实现，它能够利用一组相关或者不相关的接口进行组合与扩充，能够对外提供一致的服务接口。所以它相对于继承来说有更好的灵活性。
五：23种设计模式初探（创建型，结构型，行为型）
一、设计模式的分类
创建型模式：这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
共五种：工厂模式（Factory Pattern）、抽象工厂模式（Abstract Factory Pattern）、单例模式（Singleton Pattern）、建造者模式（Builder Pattern）、原型模式（Prototype Pattern）
结构型模式：这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。
共七种：适配器模式（Adapter Pattern）、桥接模式（Bridge Pattern）、外观模式（Facade Pattern）、组合模式（Composite Pattern）、装饰器模式（Decorator Pattern）、享元模式（Flyweight Pattern）、代理模式（Proxy Pattern）
行为型模式：这些设计模式特别关注对象之间的通信。
共十一种：责任链模式（Chain of Responsibility Pattern）、命令模式（Command Pattern）、解释器模式（Interpreter Pattern）、迭代器模式（Iterator Pattern）、中介者模式（Mediator Pattern）、备忘录模式（Memento Pattern）、观察者模式（Observer Pattern）、状态模式（State Pattern）、策略模式（Strategy Pattern）、模板模式（Template Pattern）、访问者模式（Visitor Pattern）
其实还有两种模式：并发型模式和线程池模式。
模式一：工厂方法模式（Factory Method）
工厂方法模式分为三种： 普通工厂模式：就是建立一个工厂类，对实现了同一接口的一些类进行实例的创建。
类图：
多个工厂方法模式：是对普通工厂方法模式的改进，在普通工厂方法模式中，如果传递的字符串出错，则不能正确创建对象，而多个工厂方法模式是提供多个工厂方法，分别创建对象。
类图：
静态工厂方法模式：将上面的多个工厂方法模式里的方法置为静态的，不需要创建实例，直接调用即可。
总体来说，工厂模式适合：凡是出现了大量的产品需要创建，并且具有共同的接口时，可以通过工厂方法模式进行创建。在以上的三种模式中，第一种如果传入的字符串有误，不能正确创建对象，第三种相对于第二种，不需要实例化工厂类，所以，大多数情况下，我们会选用第三种——静态工厂方法模式。
模式二：抽象工厂模式（Abstract Factory）
工厂方法模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，如何解决？就用到抽象工厂模式，创建多个工厂类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。
其实这个模式的好处就是，如果你现在想增加一个功能：发及时信息，则只需做一个实现类，实现Sender接口，同时做一个工厂类，实现Provider接口，就OK了，无需去改动现成的代码。这样做，拓展性较好。
类图：
模式三：单例模式（Singleton）
单例对象（Singleton）是一种常用的设计模式。在Java应用中，单例对象能保证在一个JVM中，该对象只有一个实例存在。
这样的模式有几个好处：
1、某些类创建比较频繁，对于一些大型的对象，这是一笔很大的系统开销。
2、省去了new操作符，降低了系统内存的使用频率，减轻GC压力。
3、有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。（比如一个军队出现了多个司令员同时指挥，肯定会乱成一团），所以只有使用单例模式，才能保证核心交易服务器独立控制整个流程。
单例模式的分类：
1、懒汉式单例模式
2、饿汉式单例模式
3、双重锁单例模式：在Java指令中创建对象和赋值操作是分开进行的，也就是说instance = new Singleton();语句是分两步执行的。但是JVM并不保证这两个操作的先后顺序，也就是说有可能JVM会为新的Singleton实例分配空间，然后直接赋值给instance成员，然后再去初始化这个Singleton实例，这样就可能出错了。
4、静态内部类单例模式：单例模式使用内部类来维护单例的实现，JVM内部的机制能够保证当一个类被加载的时候，这个类的加载过程是线程互斥的。这样当我们第一次调用getInstance的时候，JVM能够帮我们保证instance只被创建一次，并且会保证把赋值给instance的内存初始化完毕，这样我们就不用担心上面的问题。同时该方法也只会在第一次调用的时候使用互斥机制，这样就解决了低性能问题。
单例模式与静态类的区别：
1、静态类不能实现接口，从类的角度说是可以的，但是那样就破坏了静态了。因为接口中不允许有static修饰的方法，所以即使实现了也是非静态的。
2、单例可以被延迟初始化，静态类一般在第一次加载是初始化。之所以延迟加载，是因为有些类比较庞大，所以延迟加载有助于提升性能。
3、单例类可以被继承，他的方法可以被覆写。但是静态类内部方法都是static，无法被覆写。
4、单例类比较灵活，毕竟从实现上只是一个普通的Java类，只要满足单例的基本需求，你可以在里面随心所欲的实现一些其它功能，但是静态类不行。从上面这些概括中，基本可以看出二者的区别，但是，从另一方面讲，我们上面最后实现的那个单例模式，内部就是用一个静态类来实现的，所以，二者有很大的关联，只是我们考虑问题的层面不同罢了。
模式四：建造者模式（Builder）
工厂类模式提供的是创建单个类的模式，而建造者模式则是将各种产品集中起来进行管理，用来创建复合对象，所谓复合对象就是指某个类具有不同的属性，其实建造者模式就是前面抽象工厂模式和最后的Test结合起来得到的。
建造者模式将很多功能集成到一个类里，这个类可以创造出比较复杂的东西。所以与工程模式的区别就是：工厂模式关注的是创建单个产品，而建造者模式则关注创建符合对象的多个部分。因此，是选择工厂模式还是建造者模式，依实际情况而定。
模式五：原型模式（Prototype）
原型模式虽然是创建型的模式，但是与工程模式没有关系，从名字即可看出，该模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。
本小结会通过对象的复制，进行讲解。在Java中，复制对象是通过clone()实现的，先创建一个原型类：
public class Prototype implements Cloneable {
public Object clone() throws CloneNotSupportedException {
Prototype proto = (Prototype) super.clone();
return proto; }
}
一个原型类，只需要实现Cloneable接口，覆写clone方法，此处clone方法可以改成任意的名称，因为Cloneable接口是个空接口，你可以任意定义实现类的方法名，如cloneA或者cloneB，因为此处的重点是super.clone()这句话，super.clone()调用的是Object的clone()方法，而在Object类中，clone()是native的，具体怎么实现，我会在另一篇文章中，关于解读Java中本地方法的调用，此处不再深究。在这儿，我将结合对象的浅复制和深复制来说一下，首先需要了解对象深、浅复制的概念：
浅复制：将一个对象复制后，基本数据类型的变量都会重新创建，而引用类型，指向的还是原对象所指向的。
深复制：将一个对象复制后，不论是基本数据类型还有引用类型，都是重新创建的。简单来说，就是深复制进行了完全彻底的复制，而浅复制不彻底。
要实现深复制，需要采用流的形式读入当前对象的二进制输入，再写出二进制数据对应的对象。
代码示例：
/* 浅复制 */
public Object clone() throws CloneNotSupportedException {
Prototype proto = (Prototype) super.clone();
return proto;
}
/* 深复制 */
public Object deepClone() throws IOException, ClassNotFoundException {
/* 写入当前对象的二进制流 */
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(this);
/* 读出二进制流产生的新对象 */
ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bis);
return ois.readObject();
}
结构型模式：
模式六：适配器模式（Adapter）
适配器模式将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。主要分为三类：类的适配器模式、对象的适配器模式、接口的适配器模式。
类的适配器模式：核心思想就是有一个Source类，拥有一个方法待适配，目标接口时Targetable，通过Adapter类，将Source的功能扩展到Targetable里。
应用场景：当希望将一个类转换成满足另一个新接口的类时，可以使用类的适配器模式，创建一个新类，继承原有的类，实现新的接口即可。
类图：
对象的适配器模式：基本思路和类的适配器模式相同，只是将Adapter类作修改，这次不继承Source类，而是持有Source类的实例，以达到解决兼容性的问题。
应用场景：当希望将一个对象转换成满足另一个新接口的对象时，可以创建一个Wrapper类，持有原类的一个实例，在Wrapper类的方法中，调用实例的方法就行。
类图：
接口的适配器模式：接口的适配器是这样的：有时我们写的一个接口中有多个抽象方法，当我们写该接口的实现类时，必须实现该接口的所有方法，这明显有些比较浪费，因为并不是所有的方法都是我们需要的，有时只需要某一些，此处为了解决这个问题，我们引入了接口的适配器模式，借助于一个抽象类，该抽象类实现了该接口，实现了所有的方法，而我们不和原始的接口打交道，只和该抽象类取得联系，所以我们写一个类，继承该抽象类，重写我们需要的方法就行。
应用场景：接口的适配器模式：当不希望实现一个接口中所有的方法时，可以创建一个抽象类Wrapper，实现所有方法，我们写别的类的时候，继承抽象类即可。
类图：
模式七：装饰模式（Decorator）
装饰模式就是给一个对象增加一些新的功能，而且是动态的，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例。
装饰器模式的应用场景：
1、需要扩展一个类的功能。
2、动态的为一个对象增加功能，而且还能动态撤销，继承不能做到这一点，继承的功能是静态的，不能动态增删。
缺点：产生过多相似的对象，不易排错。
类图：
模式八：代理模式（Proxy）
代理模式就是多一个代理类出来，替原对象进行一些操作，比如我们在租房子的时候回去找中介，为什么呢？因为你对该地区房屋的信息掌握的不够全面，希望找一个更熟悉的人去帮你做，此处的代理就是这个意思。再如我们有的时候打官司，我们需要请律师，因为律师在法律方面有专长，可以替我们进行操作，表达我们的想法。
应用场景：
如果已有的方法在使用的时候需要对原有的方法进行改进，此时有两种办法：
1、修改原有的方法来适应。这样违反了“对扩展开放，对修改关闭”的原则。
2、就是采用一个代理类调用原有的方法，且对产生的结果进行控制。这种方法就是代理模式，使用代理模式，可以将功能划分的更加清晰，有助于后期维护。
类图：
模式九：外观模式（Facade）
外观模式是为了解决类与类之间的依赖关系，外观模式就是将他们的关系放在一个Facade类中，降低了类类之间的耦合度，该模式中没有涉及到接口。
如果我们没有Computer类，那么，CPU、Memory、Disk他们之间将会相互持有实例，产生关系，这样会造成严重的依赖，修改一个类，可能会带来其他类的修改，这不是我们想要看到的，有了Computer类，他们之间的关系被放在了Computer类里，这样就起到了解耦的作用，这就是外观模式。
类图：
模式十：桥接模式（Bridge）
桥接模式就是把事物和其具体实现分开，使他们可以各自独立的变化。桥接的用意是：将抽象化与实现化解耦，使得二者可以独立变化。
通过对Bridge类的调用，实现了对接口Sourceable的实现类SourceSub1和SourceSub2的调用。
类图：
模式十一：组合模式（Composite）
组合模式有时又叫部分-整体模式在处理类似树形结构的问题时比较方便。
使用场景：将多个对象组合在一起进行操作，常用于表示树形结构中，例如二叉树，树等。
类图：
模式十二：享元模式（Flyweight）
享元模式的主要目的是实现对象的共享，即共享池，当系统中对象多的时候可以减少内存的开销，通常与工厂模式一起使用。
FlyWeightFactory负责创建和管理享元单元，当一个客户端请求时，工厂需要检查当前对象池中是否有符合条件的对象，如果有，就返回已经存在的对象，如果没有，则创建一个新对象，FlyWeight是超类。一提到共享池，我们很容易联想到Java里面的JDBC连接池，想想每个连接的特点，我们不难总结出：适用于作共享的一些个对象，他们有一些共有的属性，就拿数据库连接池来说，url、driverClassName、username、password及dbname，这些属性对于每个连接来说都是一样的，所以就适合用享元模式来处理，建一个工厂类，将上述类似属性作为内部数据，其它的作为外部数据，在方法调用时，当做参数传进来，这样就节省了空间，减少了实例的数量。
通过连接池的管理，实现了数据库连接的共享，不需要每一次都重新创建连接，节省了数据库重新创建的开销，提升了系统的性能。
类图：
行为型模式：
共11种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式，共四类。
第一类：通过父类与子类的关系进行实现。
第二类：两个类之间。
第三类：类的状态。
第四类：通过中间类。
模式十三：策略模式（strategy）
策略模式定义了一系列算法，并将每个算法封装起来，使他们可以相互替换，且算法的变化不会影响到使用算法的客户。需要设计一个接口，为一系列实现类提供统一的方法，多个实现类实现该接口，设计一个抽象类（可有可无，属于辅助类），提供辅助函数。
策略模式的决定权在用户，系统本身提供不同算法的实现，新增或者删除算法，对各种算法做封装。因此，策略模式多用在算法决策系统中，外部用户只需要决定用哪个算法即可。
类图：
模式十四：模板方法模式（Template Method）
一个抽象类中，有一个主方法，再定义1...n个方法，可以是抽象的，也可以是实际的方法，定义一个类，继承该抽象类，重写抽象方法，通过调用抽象类，实现对子类的调用。
类图：
模式十五：观察者模式（Observer）
观察者模式很好理解，类似于邮件订阅和RSS订阅，当我们浏览一些博客或wiki时，经常会看到RSS图标，就这的意思是，当你订阅了该文章，如果后续有更新，会及时通知你。其实，简单来讲就一句话：当一个对象变化时，其它依赖该对象的对象都会收到通知，并且随着变化！对象之间是一种一对多的关系。
类图：
模式十六：迭代子模式（Iterator）
迭代器模式就是顺序访问聚集中的对象，一般来说，集合中非常常见，如果对集合类比较熟悉的话，理解本模式会十分轻松。这句话包含两层意思：一是需要遍历的对象，即聚集对象，二是迭代器对象，用于对聚集对象进行遍历访问。
类图：
模式十七：责任链模式（Chain of Responsibility）
有多个对象，每个对象持有对下一个对象的引用，这样就会形成一条链，请求在这条链上传递，直到某一对象决定处理该请求。但是发出者并不清楚到底最终那个对象会处理该请求，所以，责任链模式可以实现在隐瞒客户端的情况下，对系统进行动态的调整。
此处强调一点就是，链接上的请求可以是一条链，可以是一个树，还可以是一个环，模式本身不约束这个，需要我们自己去实现，同时，在一个时刻，命令只允许由一个对象传给另一个对象，而不允许传给多个对象。
类图：
模式十八：命令模式（Command）
司令员下令让士兵去干件事情，从整个事情的角度来考虑，司令员的作用是，发出口令，口令经过传递，传到了士兵耳朵里，士兵去执行。这个过程好在，三者相互解耦，任何一方都不用去依赖其他人，只需要做好自己的事儿就行，司令员要的是结果，不会去关注到底士兵是怎么实现的。
Invoker是调用者（司令员），Receiver是被调用者（士兵），MyCommand是命令，实现了Command接口，持有接收对象。
命令模式的目的就是达到命令的发出者和执行者之间解耦，实现请求和执行分开，熟悉Struts的同学应该知道，Struts其实就是一种将请求和呈现分离的技术，其中必然涉及命令模式的思想。
类图：
模式十九：备忘录模式（Memento）
主要目的是保存一个对象的某个状态，以便在适当的时候恢复对象，个人觉得叫备份模式更形象些，通俗的讲下：假设有原始类A，A中有各种属性，A可以决定需要备份的属性，备忘录类B是用来存储A的一些内部状态，类C呢，就是一个用来存储备忘录的，且只能存储，不能修改等操作。
Original类是原始类，里面有需要保存的属性value及创建一个备忘录类，用来保存value值。Memento类是备忘录类，Storage类是存储备忘录的类，持有Memento类的实例，该模式很好理解。
类图：
模式二十：状态模式（State）
当对象的状态改变时，同时改变其行为，就拿QQ来说，有几种状态，在线、隐身、忙碌等，每个状态对应不同的操作，而且你的好友也能看到你的状态，所以，状态模式就两点：
1、可以通过改变状态来获得不同的行为。
2、你的好友能同时看到你的变化，状态模式在日常开发中用的挺多的，尤其是做网站的时候，我们有时希望根据对象的某一属性，区别开他们的一些功能，比如说简单的权限控制等。
类图：
模式二十一：访问者模式（Visitor）
访问者模式把数据结构和作用于结构上的操作解耦合，使得操作集合可相对自由地演化。访问者模式适用于数据结构相对稳定算法又易变化的系统。因为访问者模式使得算法操作增加变得容易。若系统数据结构对象易于变化，经常有新的数据对象增加进来，则不适合使用访问者模式。访问者模式的优点是增加操作很容易，因为增加操作意味着增加新的访问者。访问者模式将有关行为集中到一个访问者对象中，其改变不影响系统数据结构。其缺点就是增加新的数据结构很困难。
简单来说，访问者模式就是一种分离对象数据结构与行为的方法，通过这种分离，可达到为一个被访问者动态添加新的操作而无需做其它的修改的效果。
适用场景：如果我们想为一个现有的类增加新功能，不得不考虑几个事情：
1、新功能会不会与现有功能出现兼容性问题？
2、以后会不会再需要添加？
3、如果类不允许修改代码怎么办？
面对这些问题，最好的解决方法就是使用访问者模式，访问者模式适用于数据结构相对稳定的系统，把数据结构和算法解耦。
类图：
模式二十二：中介者模式（Mediator）
中介者模式也是用来降低类类之间的耦合的，因为如果类类之间有依赖关系的话，不利于功能的拓展和维护，因为只要修改一个对象，其它关联的对象都得进行修改。如果使用中介者模式，只需关心和Mediator类的关系，具体类类之间的关系及调度交给Mediator就行。
类图：
模式二十三：解释器模式（Interpreter）
解释器模式是我们暂时的最后一讲，一般主要应用在OOP开发中的编译器的开发中，解释器模式用来做各种各样的解释器，如正则表达式等的解释器等，所以适用面比较窄。
类图：
六：面向对象的七大设计原则
原则一：开闭原则(Open-Closed Principle, OCP)
定义：软件实体应当对扩展开放，对修改关闭。这句话说得有点专业，更通俗一点讲，也就是：软件系统中包含的各种组件，例如模块（Modules）、类（Classes）以及功能（Functions）等等，应该在不修改现有代码的基础上，去扩展新功能。开闭原则中原有“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中“闭”，是指对于代码的修改是封闭的，即不应该修改原有的代码。
问题由来：凡事的产生都有缘由。我们来看看，开闭原则的产生缘由。在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。这就对我们的整个系统的影响特别大，这也充分展现出了系统的耦合性如果太高，会大大的增加后期的扩展，维护。为了解决这个问题，故人们总结出了开闭原则。解决开闭原则的根本其实还是在解耦合。所以，我们面向对象的开发，我们最根本的任务就是解耦合。
解决方法：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
小结：开闭原则具有理想主义的色彩，说的很抽象，它是面向对象设计的终极目标。其他几条原则，则可以看做是开闭原则的实现。我们要用抽象构建框架，用实现扩展细节。
原则二：单一职责原则（Single Responsibility Principle）
定义：一个类，只有一个引起它变化的原因。即：应该只有一个职责，每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离。需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都需要遵循这一重要原则。
问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
解决方法：分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。
原则三：里氏替换原则（Liskov Substitution Principle）
定义：子类型必须能够替换掉它们的父类型。注意这里的能够两字。有人也戏称老鼠的儿子会打洞原则。
问题由来：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
解决方法：类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
小结：所有引用父类的地方必须能透明地使用其子类的对象。子类可以扩展父类的功能，但不能改变父类原有的功能，即：子类可以实现父类的抽象方法，子类中也可以增加自己特有的方法，但不能覆盖父类的非抽象方法。当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
原则四：迪米特法则（Law Of Demeter）
定义：迪米特法则又叫最少知道原则，即：一个对象应该对其他对象保持最少的了解。如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。简单定义只为与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。
问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大，最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。
解决方法：尽量降低类与类之间的耦合。 自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。
迪米特法则的初衷是降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系。但是凡事都有度，虽然可以避免与非直接的类通信，但是要通信，必然会通过一个“中介”来发生联系。故过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。
原则五：依赖倒置原则（Dependence Inversion Principle）
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象，中心思想是面向接口编程。
问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
解决方法：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
在实际编程中，我们一般需要做到如下3点：
1、低层模块尽量都要有抽象类或接口，或者两者都有。
2、变量的声明类型尽量是抽象类或接口。
3、使用继承时遵循里氏替换原则。
采用依赖倒置原则尤其给多人合作开发带来了极大的便利，参与协作开发的人越多、项目越庞大，采用依赖倒置原则的意义就越重大。
小结：依赖倒置原则就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。
原则六：接口隔离原则（Interface Segregation Principle）
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法
解决方法：
1、使用委托分离接口。
2、使用多重继承分离接口。
3、将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系，也就是采用接口隔离原则。
小结：我们在代码编写过程中，运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。对接口进行细化可以提高程序设计灵活性是不争的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。设计接口的时候，只有多花些时间去思考和筹划，就能准确地实践这一原则。
原则七：合成/聚合原则(Composite/Aggregate Reuse Principle,CARP)
定义：也有人叫做合成复用原则，及尽量使用合成/聚合，尽量不要使用类继承。换句话说，就是能用合成/聚合的地方，绝不用继承。
为什么要尽量使用合成/聚合而不使用类继承？
1、对象的继承关系在编译时就定义好了，所以无法在运行时改变从父类继承的子类的实现。
2、子类的实现和它的父类有非常紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。
3、当你复用子类的时候，如果继承下来的实现不适合解决新的问题，则父类必须重写或者被其它更适合的类所替换，这种依赖关系限制了灵活性，并最终限制了复用性。
总结：这些原则在设计模式中体现的淋淋尽致，设计模式就是实现了这些原则，从而达到了代码复用、增强了系统的扩展性。所以设计模式被很多人奉为经典。我们可以通过好好的研究设计模式，来慢慢的体会这些设计原则。
七：重构的注意事项与技术实现（重构-改善既有代码的设计）
代码的坏味道：
1、重复的代码
重复的代码是坏味道中出现频率最高的情形非其莫属。如果在一个的以上地方看到相同的代码，那么就可以肯定：想办法将它们合而为一，代码会变得更好。最单纯的重复代码就是“同一个类的两个函数含有相同的表达式”，这时候可以采用抽取方法提炼出重复的代码，然后让这两个地点都调用被提炼出的那一段代码。
另一种常见情况就是“两个互为兄弟的子类内含相同的表达式”，这时候只需对两个类抽取方法，然后将提炼出的代码推入到超类中。如果代码之间只是类似而并非完全相同，那么就需要通过抽取方法将相似部分和差异部分分开，构成单独一个函数。如果有些函数以不同的算法做相同的事，可以使用比较清晰的一个替换掉其余的。
2、过长的函数
程序员都喜欢简短的函数。拥有短函数的对象会活的比较好、比较长。不熟悉面向对象技术的人，常常觉得对象程序中只有无穷无尽的委托，根本没有进行任何计算。和此类程序共同生活数年后，你才会知道这些小小函数的价值。
应该积极地分解函数，将长长的函数变为多个短小的函数。一般会遵循这样的原则：每当感觉需要用注释来说明点什么的时候，就把需要说明的东西写进一个独立函数中，并以其用途命名。不要嫌麻烦。可以对一组甚至短短一行代码做这件事，哪怕替换后的函数调用动作比函数自身还长，只要函数名称能够解释其用途，也应毫不犹豫地那么做。关键不在于函数的长度，而在于函数“做什么”和“如何做”之间的语义距离。
3、过大的类
如果想利用单个的类做太多的事情，其内往往会出现太多实例变量。一旦如此，重复的代码就接踵而来。
可以将几个变量一起提炼至新类内。提炼时应该选择类内彼此相关的变量，将它们放在一起。通常如果类内的数个变量有着相同的前缀或字尾，这就意味有机会把它们提炼到某个组件内。
和“太多实例变量”一样，类内如果有太多代码，也是代码重复、混乱并最终走向死亡的源头。最简单的方案是把多余的东西消弭于类内部。如果有五个“百行函数”，它们之中很多代码都相同，那么或许你可以把它们变成五个“十行函数”和十个提炼出的“双行函数”。
4、过长的参数列
刚开始学编程的时候，或许都是“把函数所需的所有东西都以参数传递进去”。这样也是可以理解的，因为除此之外就只能选择全局数据，而全局数据是邪恶的东西。对象技术告诉我们，如果你手上没有所需的东西，总可以叫一个对象给你。有了对象，你就不必要把函数所需的所有东西都以参数传递给它，只需传给它足够的、让函数能从中获得自己的东西就行。
太长的的参数列难以理解，太多参数会造成前后不一致、不易使用，而且一旦需要更多数据，就不得不修改它。如果将对象传递给函数，大多数修改都将没有必要，因为很可能只需增加一两条请求，就能得到更多的数据。
5、发散式变化
我们希望软件能够容易被修改——毕竟软件再怎么说本来就该是“软”的。一旦需要修改，我们希望能够跳到系统某一点，只在该处做修改。如果不能做到这点，你就会嗅出两种紧密相关的刺鼻味道中的一种。
如果某个类经常因为不同的原因在不同的方向上发生变化，发散式变化就出现了。其主要指“一个类受多种变化的影响”。当你看着一个类说：“呃，如果新加入一个数据库，就必须修改这三个函数；如果新出现一种工具，就必须修改这四个函数。”那么此时也许将这个对象分成两个会更好，这样对每个对象就可以只因一种变化而需要修改。
6、霾弹式修改
如果每遇到变化，都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是霾弹式修改。其主要指“一种变化引发多个类相应修改”。如果需要修改的代码散布四周，不但很难找到它们，也很容易忘记某个重要的修改。
这种情况可以把所有需要的代码放进同一个类。如果眼下没有合适的类可以安置这些代码，就创造一个。通常可以运用内联类把一系列相关行为放进同一个类。
7、依恋情节
众所周知，对象技术的全部要点在于：其是一种“将数据和对数据的操作行为包装在一起”的技术。有一种经典的气味：函数对于某个类的兴趣高过对自己所处类的兴趣。在很多情况下，都能够看到：某个函数为了计算某个值，从另一个对象那儿调用几乎半打的取值函数。疗法也显而易见：把这个函数移至另一个地点，移到它该去的地方。‘
有时候一个函数往往会用到几个类的功能，那么它究竟该被置于何处呢？处理原则通常为：判断哪个类拥有最多被此函数使用的数据，然后就把这个函数和那些数据摆在一起。
8、数据泥团
如果用比较形象的事物来形容数据项，我想“小孩子”是一个不错的选择，数据项就像小孩子，喜欢成群结队地呆在一块儿。常常可以在很多地方看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。这些总是绑在一起出现的数据真应该拥有属于它们自己的对象。
这种情况可以先找出这些数据以字段形式出现的地方，将它们提炼到一个独立对象中，然后将注意力转移到函数签名上，运用参数对象为它减肥。这样做的直接好处是可以将很多参数列缩短，简化函数调用。一个比较好的评判方法是：删掉众多数据中的一项。这么做其它数据有没有因而失去意义？如果它们不再有意义，这就是一个明确的信号：应该为它们产生一个新对象。
9、基本类型偏执
大多数编程环境都有两种数据：结构类型允许你将数据组织成有意义的形式；基本类型则是构成结构类型的积木块。但是请记住：结构总是会带来一定的额外开销。它们可能代表着数据库中的表，如果只为做一两件事而创建结构类型也可能显得很麻烦。
对象的一个极大价值在于：它们模糊甚至打破横亘于基本数据和体积较大的类之间的界限。如果你有一组应该总是被放在一起的字段，可以将其抽取为一个独立的类。如果你在参数列中看到基本型数据，可以引入参数对象进行处理。如果你发现自己正从数组中挑选数据，可以运用以对象取代数组进行处理。
10、Switch惊悚现身
面向对象程序的一个较明显特征是：少用switch语句。从本质上说，switch语句的问题在于重复。你常会发现同样的switch语句散布于不同的地方。如果要为它添加一个新的case语句，就必须找到所用switch语句并修改它们。面向对象中的多态概念可为此带来优雅的解决办法。
大多数时候，一看到switch语句，那就应该考虑以多态来替换它。switch语句常常根据类型码进行选择，你要的是“与该类型码相关的函数或类”，所以应该将switch语句提炼到一个独立函数中，再将它搬移到需要多态性的那个类里。
11、平行继承体系
平行继承体系其实是霾弹式修改的特殊情况。在这种情况下，每当为某个类增加一个子类，必须也为另一个类增加一个子类。如果发现某个继承体系的类名称前缀和另一个继承体系的类名称前缀完全相同，这种坏味道就会被嗅出。
消除这种重复性的一般策略是：让一个继承体系的实例引用另一个继承体系的实例。
12、冗赘类
你所创建的每一个类，都得有人去理解它、维护它，这些工作都是需要花钱的。如果一个类的所得并不值其身价，他就应该消失。项目中经常会出现这样的情况：某个类原本对得起自己的价值，但重构使它身形缩水，不再做那么多工作；或开发者事先规划了某些变化，并添加一个类来应付这些变化，但变化实际没有发生。
不管是哪种原因，都应该让这个类庄严赴义吧。如果某些子类并没有做足够的工作，我们可以尝试“折叠继承体系”，将超类和子类合为一体，那样就会减少维护时间。对于那些几乎没用的组件，就应该将这个类的所有特性搬移到另一个类中，然后移除原类。
13、夸夸其谈未来性
我们经常会说：“我想总有一天需要做这事”，并因而企图以各样的钩子和特殊情况来处理一些非必要的事情。一旦这样，坏味道就浮现出来了。夸夸其谈未来的结果往往会造成系统更加难以理解和维护。如果所有的装置都被用到了，那就值得那么做；如果用不到，就不值得。用不上的装置只会阻挡你的路，给你添乱，那就搬开它吧。
如果某个抽象类其实没有太大作用，可以将超类和子类合为一体。将不必要的委托转移到另一个类中，并消除原先的类。如果函数的某些参数未被用上，那么就将参数移走。如果函数名称带有多余的抽象意味，就应该对它重命名，让它现实一些。
14、令人迷惑的暂时字段
有时候你会发现：类中的某个实例变量仅为某种特定情况而设。这样的代码让人难以理解，因为你通常认为对象在所有时候都需要它的所有变量。当变量在未被使用的情况下去猜测其当初设置的目的，会让你发疯的。
可以使用提炼新类为这个可怜的孤儿创造一个家，然后把所有和这个变量相关的代码都放进这个新家。
也许还可以使用“将Null值替换为Null对象”在“变量不合法”的情况下创建一个Null对象，从而避免写出条件式代码。
15、过度耦合的消息链
如果你看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象.....这就是消息链。这种方式意味着客户代码将与某些功能函数中的导航结构紧密耦合。一旦对象间的关系发生任何变化，客户端就不得不做出相应修改。
这时候我们可以隐藏“委托关系”，并在服务类上建立客户所需要的所有函数。你可以在消息链的不同位置进行这种重构手法。理论上是可以重构消息链上的任何一个对象，但是这样做往往会把一系列对象都变成“中间人”。通常更好的选择是：先观察消息链最终得到的对象是用来干什么的，再看看能否通过抽取方法把使用该对象的代码提炼到一个独立函数中，然后再将这个函数推入消息链。
16、中间人
我们都知道对象的基本特征之一就是封装——对外部世界隐藏其内部细节。封装往往伴随着委托。比如你对Boss说是否有时间参加一个会议，他把这个消息“委托”给他的记事本，然后才能回答你。但是，你没有必要知道Boss到底使用传统记事本或电子记事本亦或秘书来记录自己的约会。
人们可能会过度使用委托。你也许会看到某个类接口中有一半的函数都委托给其它类，这样就是过度委托。这时候就应该移除中间人，直接和真正的负责人打交道。如果这样“不干实事”的函数只有少数几个，可以将它们放进调用端。如果中间人还有其它行为，可以把它变成实责对象的子类，这样你既可以扩展原对象的行为，又不必负担那么多的委托动作。
17、狎昵关系
有时候你会看到两个类过于亲密，花费太多时间去探究彼此的private成分。如果这发生在两个“人”之间，我们无比做卫道士；但对于类，我们就希望它们严守清规。
也许就像古代的恋人一样，过分狎昵的类必须拆散。可以通过“移动方法”和“移动字段”帮它们划清界限，从而减少狎昵行径。如果两个类实在是情投意合，可以把两者共同点提炼到一个安全地点，让它们坦荡地使用这个新类。或者通过隐藏“委托关系”让另一个类来为它们传递相思情。
18、异曲同工的类
如果两个函数做同一件事，却有着不同的签名，可以根据它们的用途重新命名。
但这往往不够，可以反复将某些行为移入类中，直到两者的协议一致为止。
19、不完美的库类
复用常被视为对象的终极目的。不过我们认为复用的意义经常被高估——大多数对象只要够用就好。但是无可否认，许多编程技术都建立在程序库的基础上。库类构建者没有未卜先知的能力，我们不能因此责怪它们。
幸好我们有两个专门应付这种情况的工具。如果你只想修改库类的一两个函数，可以使用“引入外加参数”来进行修改。如果想要添加一大堆额外行为，就得运用“引入本地扩展（建立一个新类，使它包含这些额外函数。让这个扩展品成为源类的子类或包装类）”来进行修改。
20、纯稚的数据类
纯稚的数据类是指：它们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长物。这样的类只是一种不会说话的数据容器，它们几乎一定被其它类过分细琐地操控着。
这些类早期可能拥有public字段，果真如此就应该在别人注意到它们之前将它们封装起来。如果这些类内含容器类的字段，就应该检查它们是不是得到了恰当的封装；如果没有，就把它们封装起来。对于那些不该被其它类修改的字段，就应该去掉该字段的所有设值函数。
21、被拒绝的遗赠
子类应该继承超类的函数和数据。但是如果它们不想或者不需要继承，又该怎么办呢？它们得到了所有的礼物，但却只从中挑选几样来玩！
这可能意味着继承体系设计错误。你需要为这个子类新建一个兄弟类，再把所有用不到的函数下推给那个兄弟。这样一来，超类就只持有所有子类共享的东西。你常常会听到这样的建议：所有超类都应该是抽象的。
22、过多的注释
不要担心，并不是说不应该写注释。从嗅觉上说，注释不是一种坏味道，事实上它还是一种香味呢。常常还有这样的情况：你看到一段代码有着长长的注释，然后发现，这些注释之所以存在乃是因为代码很糟糕。这种情况出现次数多的实在令人吃惊。
注释可以带我们找到本文先前提到的各种坏味道。找到坏味道后，我们首先应该以各种重构手法把坏味道去除。完成之后我们发现注释已经变得多余了，因为代码已经清楚说明了一切。
如果你需要注释来解释一块代码做了什么，试试将该代码抽取为一个单独的函数；如果函数已经被提炼出来，但还是需要注释来解释其行为，试着对其重新命名。当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余。
八：阿里巴巴代码规范插件的使用
如何安装：
使用结果：
九：扩展阅读
2、https://www.jianshu.com/p/b7a644ea0d25（Android你不能忽略的代码命名规范）
4、书籍：重构-改善既有代码的设计
5、Android插件：Alibaba Java Coding Guidelines
6、https://www.cnblogs.com/zsychanpin/p/6871668.html（22 种代码的坏味道）
7、https://www.cnblogs.com/Braveliu/p/7388503.html（重构列表）
8、https://blog.csdn.net/qq_41331645/article/details/81102015（面向对象之七大原则）
9、https://blog.csdn.net/pistolove/article/details/42041757（重构笔记——代码的坏味道（上））
10、https://www.cnblogs.com/bell1991/p/7797947.html（对高内聚，低耦合的理解）
11、https://blog.csdn.net/jianyuerensheng/article/details/51602015（面向对象编程三大特性------封装、继承、多态）
12、https://blog.csdn.net/zhangerqing/article/list/2（Java之美[从菜鸟到高手演变]之设计模式系列）
