关于php:设计模式总结理论篇

如何能力写出高质量的代码？

问如何写出高质量的代码，也就等同于在问，如何写出易保护、易读、易扩大、灵便、简洁、可复用、可测试的代码。

要写出满足这些评估规范的高质量代码，咱们须要把握一些更加细化、更加能落地的编程方法论，包含面向对象设计思维、设计准则、设计模式、编码标准、重构技巧等。而所有这些编程方法论的最终目标都是为了编写出高质量的代码。

比方，面向对象中的继承、多态能让咱们写出可复用的代码；编码标准能让咱们写出可读性好的代码；设计准则中的繁多职责、DRY、基于接口而非实现、里式替换准则等，能够让咱们写出可复用、灵便、可读性好、易扩大、易保护的代码；设计模式能够让咱们写出易扩大的代码；继续重构能够时刻放弃代码的可维护性等等。

什么是面向对象编程和面向对象编程语言？

面向对象编程的英文缩写是 OOP，全称是 Object Oriented Programming。对应地，面向对象编程语言的英文缩写是 OOPL，全称是 Object Oriented Programming Language。

面向对象编程中有两个十分重要、十分根底的概念，那就是类（class）和对象（object）。

• 面向对象编程是一种编程范式或编程格调。它以类或对象作为组织代码的根本单元，并将封装、形象、继承、多态四个个性，作为代码设计和实现的基石。
• 面向对象编程语言是反对类或对象的语法机制，并有现成的语法机制，能不便地实现面向对象编程四大个性（封装、形象、继承、多态）的编程语言。

面向对象

• 面向对象的四大个性：封装、形象、继承、多态

封装（Encapsulation）

封装也叫作信息暗藏或者数据拜访爱护。类通过裸露无限的拜访接口，受权内部仅能通过类提供的形式（或者叫函数）来拜访外部信息或者数据。

对于封装这个个性，咱们须要编程语言自身提供肯定的语法机制来反对。这个语法机制就是拜访权限管制。如 public,private,protected。

类仅仅通过无限的办法裸露必要的操作，也能进步类的易用性。如果咱们把类属性都裸露给类的调用者，调用者想要正确地操作这些属性，就势必要对业务细节有足够的理解。而这对于调用者来说也是一种累赘。相同，如果咱们将属性封装起来，裸露少许的几个必要的办法给调用者应用，调用者就不须要理解太多背地的业务细节，用错的概率就缩小很多。

形象（Abstraction）

类的办法是通过编程语言中的“函数”这一语法机制来实现的。通过函数包裹具体的实现逻辑，这自身就是一种形象。调用者在应用函数的时候，并不需要去钻研函数外部的实现逻辑，只须要通过函数的命名、正文或者文档，理解其提供了什么性能，就能够间接应用了。

形象这个概念是一个十分通用的设计思维，并不单单用在面向对象编程中，也能够用来领导架构设计等。而且这个个性也并不需要编程语言提供非凡的语法机制来反对，只须要提供“函数”这一十分根底的语法机制，就能够实现形象个性、所以，它没有很强的“特异性”，有时候并不被看作面向对象编程的个性之一。

继承（Inheritance）

继承是用来示意类之间的 is-a 关系。从继承关系上来讲，继承能够分为两种模式，单继承和多继承。PHP 只反对单继承，不反对多重继承。

继承最大的一个益处就是代码复用。如果两个类有一些雷同的属性和办法，咱们就能够将这些雷同的局部，抽取到父类中，让两个子类继承父类。这样，两个子类就能够重用父类中的代码，防止代码反复写多遍。

多态（Polymorphism）

多态是指，子类能够替换父类。只有两个类具备雷同的办法，就能够实现多态，并不要求两个类之间有任何关系。多态能够进步代码的扩展性和复用性，是很多设计模式、设计准则、编程技巧的代码实现根底。

面向对象编程与面向过程编程的区别和分割

面向对象编程是一种编程范式或编程格调。它以类或对象作为组织代码的根本单元，并将封装、形象、继承、多态四个个性，作为代码设计和实现的基石。

面向过程编程也是一种编程范式或编程格调。它以过程（能够了解为办法、函数、操作）作为组织代码的根本单元，以数据（能够了解为成员变量、属性）与办法相拆散为最次要的特点。面向过程格调是一种流程化的编程格调，通过拼接一组程序执行的办法来操作数据实现一项性能。

面向过程和面向对象最根本的区别就是，代码的组织形式不同。面向过程格调的代码被组织成了一组办法汇合及其数据结构（struct User），办法和数据结构的定义是离开的。面向对象格调的代码被组织成一组类，办法和数据结构被绑定一起，定义在类中。

以 PHP 为例，假如咱们有一个记录了用户信息的文本文件 users.txt，每行文本的格局是 name&age&gender（比方，小王 &28& 男）。咱们心愿写一个程序，从 users.txt 文件中逐行读取用户信息，而后格式化成 name\tage\tgender（其中，\t 是分隔符）这种文本格式，并且依照 age 从小到大排序之后，从新写入到另一个文本文件 formatted_users.txt 中。

// 面向过程编程

function parse_to_user($text)
{// 将 text(“小王 &28& 男”)解析成数组
    return $user;
}

function format_to_text($user)
{
    // 将 $user 格式化成文本（"小王 \t28\t 男"）return $user;
}

function sort_users_by_age($user)  
{
    // 依照年龄从小到大排序 users
    return $user
}

function format_user_file($origin_file_path, $new_file_path)  {

    // open files...

    $count = 0;
    $user = array();
    while(1) { // read until the file is empty

        $user[] = parse_to_user(line);

    }

    sort_users_by_age(users);

    for (int i = 0; i < count($user); ++i) {$text = format_to_text(users[i]);

        // write to new file...

    }

    // close files...

}
format_user_file("user.txt", "formatted_users.txt");

// 面向对象编程
public class User(){
    private $name;
    private $age;
    private $sex;
    public static User praseFrom($userInfoText)  {// 将 text(“小王 &28& 男”)解析成类 User
        $this->name=$name;
        $this->age=$age;
        $this->sex=$sex;
    }

    public String formatToText()  {
        // 将类 User 变量格式化成文本（"小王 \t28\t 男"）return $formatUser;
    }
}

public  class  UserFileFormatter  {public  function  format(String userFile, String formattedUserFile)  {
        // Open files...
        $userArr = array();
        while (1) { // read until file is empty
            // read from file into userText...
            $user = new User();
            $user->praseFrom($line);
            $userArr[] = $user}
        // sort users by age...
        for (int i = 0; i < count($userArr); ++i) {$formattedUserText = $userArr[$i].formatToText();
            // write to new file...
        }
        // close files...
    }
}
$userFileFormatter = new UserFileFormatter();
$userFileFormatter->format("user.txt", "formatted_users.txt");

1. 对于大规模简单程序的开发，程序的解决流程并非繁多的一条主线，而是盘根错节的网状结构。面向对象编程比起面向过程编程，更能应答这种简单类型的程序开发。

2. 面向对象编程相比面向过程编程，具备更加丰盛的个性（封装、形象、继承、多态）。利用这些个性编写进去的代码，更加易扩大、易复用、易保护。

3. 从编程语言跟机器打交道的形式的演进法则中，面向对象编程语言比起面向过程编程语言，更加人性化、更加高级、更加智能。

在面向对象编程中，为什么容易写出面向过程格调的代码？

你能够联想一下，在生活中，你去实现一个工作，你个别都会思考，应该先做什么、后做什么，如何一步一步地程序执行一系列操作，最初实现整个工作。面向过程编程格调恰好合乎人的这种流程化思维形式。而面向对象编程格调正好相同。它是一种自底向上的思考形式。它不是先去依照执行流程来合成工作，而是将工作翻译成一个一个的小的模块（也就是类），设计类之间的交互，最初依照流程将类组装起来，实现整个工作。

除此之外，面向对象编程要比面向过程编程难一些。在面向对象编程中，类的设计还是挺须要技巧，挺须要肯定设计教训的。你要去思考如何封装适合的数据和办法到一个类里，如何设计类之间的关系，如何设计类之间的交互等等诸多设计问题。

接口和抽象类的区别以及各自的利用场景

抽象类

1. 抽象类不容许被实例化，只能被继承。
2. 抽象类能够蕴含属性和办法。
3. 子类继承抽象类，必须实现抽象类中的所有形象办法。

接口

1. 接口不能蕴含属性（也就是成员变量）。
2. 接口只能申明办法，办法不能蕴含代码实现。
3. 类实现接口的时候，必须实现接口中申明的所有办法。

抽象类实际上就是类，只不过是一种非凡的类，这品种不能被实例化为对象，只能被子类继承。咱们晓得，继承关系是一种 is-a 的关系，那抽象类既然属于类，也示意一种 is-a 的关系。绝对于抽象类的 is-a 关系来说，接口示意一种 has-a 关系，示意具备某些性能。对于接口，有一个更加形象的叫法，那就是协定（contract）。

什么时候该用抽象类？什么时候该用接口？实际上，判断的规范很简略。如果要示意一种 is-a 的关系，并且是为了解决代码复用问题，咱们就用抽象类；如果要示意一种 has-a 关系，并且是为了解决形象而非代码复用问题，那咱们就用接口。

基于接口而非实现编程的设计思维

1.“基于接口而非实现编程”，这条准则的另一个表述形式，是“基于形象而非实现编程”。后者的表述形式其实更能体现这条准则的设计初衷。咱们在做软件开发的时候，肯定要有形象意识、封装意识、接口意识。越形象、越顶层、越脱离具体某一实现的设计，越能进步代码的灵活性、扩展性、可维护性。

2\. 咱们在定义接口的时候，一方面，命名要足够通用，不能蕴含跟具体实现相干的字眼；另一方面，与特定实现无关的办法不要定义在接口中。

3.“基于接口而非实现编程”这条准则，不仅仅能够领导十分细节的编程开发，还能领导更加下层的架构设计、零碎设计等。比方，服务端与客户端之间的“接口”设计、类库的“接口”设计。

多用组合少用继承的设计思维

继承是面向对象的四大个性之一，用来示意类之间的 is-a 关系，能够解决代码复用的问题。尽管继承有诸多作用，但继承档次过深、过简单，也会影响到代码的可维护性。在这种状况下，咱们应该尽量少用，甚至不必继承。

继承次要有三个作用：示意 is-a 关系，反对多态个性，代码复用。而这三个作用都能够通过组合、接口、委托三个技术手段来达成。除此之外，利用组合还能解决档次过深、过简单的继承关系影响代码可维护性的问题。

只管咱们激励多用组合少用继承，但组合也并不是完满的，继承也并非一无是处。在理论的我的项目开发中，咱们还是要依据具体的状况，来抉择该用继承还是组合。如果类之间的继承构造稳固，档次比拟浅，关系不简单，咱们就能够大胆地应用继承。反之，咱们就尽量应用组合来代替继承。除此之外，还有一些设计模式、非凡的利用场景，会固定应用继承或者组合。

面向对象分析（OOA）、面向对象设计（OOD）、面向对象编程（OOP）

面向对象分析（OOA）、面向对象设计（OOD）、面向对象编程（OOP），是面向对象开发的三个次要环节。

面向对象分析的产出是具体的需要形容。面向对象设计的产出是类。在面向对象设计这一环节中，咱们将需要形容转化为具体的类的设计。这个环节的工作能够拆分为上面四个局部。

1\. 划分职责进而辨认出有哪些类

依据需要形容，咱们把其中波及的性能点，一个一个列举进去，而后再去看哪些性能点职责相近，操作同样的属性，可否归为同一个类。

2\. 定义类及其属性和办法

咱们辨认出需要形容中的动词，作为候选的办法，再进一步过滤筛选出真正的办法，把性能点中波及的名词，作为候选属性，而后同样再进行过滤筛选。

3\. 定义类与类之间的交互关系

UML 对立建模语言中定义了六品种之间的关系。它们别离是：泛化、实现、关联、聚合、组合、依赖。咱们从更加贴近编程的角度，对类与类之间的关系做了调整，保留四个关系：泛化、实现、组合、依赖。

4\. 将类组装起来并提供执行入口

咱们要将所有的类组装在一起，提供一个执行入口。这个入口可能是一个 main() 函数，也可能是一组给内部用的 API 接口。通过这个入口，咱们能触发整个代码跑起来。

设计准则

SOLID 准则 -SRP 繁多职责准则

繁多职责准则的英文是 Single Responsibility Principle，缩写为 SRP。这个准则的英文形容是这样的：A class or module should have a single responsibility。翻译成中文: 一个类或者模块只负责实现一个职责（或者性能）。

一个类只负责实现一个职责或者性能。不要设计大而全的类，要设计粒度小、性能繁多的类。繁多职责准则是为了实现代码高内聚、低耦合，进步代码的复用性、可读性、可维护性。

上面这几条判断准则，比起很主观地去思考类是否职责繁多，要更有指导意义、更具备可执行性：

• 类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性，咱们就须要思考对类进行拆分；
• 类依赖的其余类过多，或者依赖类的其余类过多，不合乎高内聚、低耦合的设计思维，咱们就须要思考对类进行拆分；
• 公有办法过多，咱们就要思考是否将公有办法独立到新的类中，设置为 public 办法，供更多的类应用，从而进步代码的复用性；
• 比拟难给类起一个适合名字，很难用一个业务名词概括，或者只能用一些抽象的 Manager、Context 之类的词语来命名，这就阐明类的职责定义得可能不够清晰；
• 类中大量的办法都是集中操作类中的某几个属性;

SOLID 准则 -OCP 开闭准则

开闭准则的英文全称是 Open Closed Principle，简写为 OCP。它的英文形容是：software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification。咱们把它翻译成中文就是：软件实体（模块、类、办法等）应该“对扩大凋谢、对批改敞开”。

增加一个新的性能，应该是通过在已有代码根底上扩大代码（新增模块、类、办法、属性等），而非批改已有代码（批改模块、类、办法、属性等）的形式来实现。对于定义，咱们有两点要留神。第一点是，开闭准则并不是说齐全杜绝批改，而是以最小的批改代码的代价来实现新性能的开发。第二点是，同样的代码改变，在粗代码粒度下，可能被认定为“批改”；在细代码粒度下，可能又被认定为“扩大”。

咱们要时刻具备扩大意识、形象意识、封装意识。在写代码的时候，咱们要多花点工夫思考一下，这段代码将来可能有哪些需要变更，如何设计代码构造，当时留好扩大点，以便在将来需要变更的时候，在不改变代码整体构造、做到最小代码改变的状况下，将新的代码灵便地插入到扩大点上。

SOLID 准则 -LSP 里式替换准则

子类对象（object of subtype/derived class）可能替换程序（program）中父类对象（object of base/parent class）呈现的任何中央，并且保障原来程序的逻辑行为（behavior）不变及正确性不被毁坏。

里式替换准则是用来领导，继承关系中子类该如何设计的一个准则。了解里式替换准则，最外围的就是了解“design by contract，依照协定来设计”这几个字。父类定义了函数的“约定”（或者叫协定），那子类能够扭转函数的外部实现逻辑，但不能扭转函数原有的“约定”。这里的约定包含：函数申明要实现的性能；对输出、输入、异样的约定；甚至包含正文中所列举的任何非凡阐明。

了解这个准则，咱们还要弄明确里式替换准则跟多态的区别。尽管从定义形容和代码实现上来看，多态和里式替换有点相似，但它们关注的角度是不一样的。多态是面向对象编程的一大个性，也是面向对象编程语言的一种语法。它是一种代码实现的思路。而里式替换是一种设计准则，用来领导继承关系中子类该如何设计，子类的设计要保障在替换父类的时候，不扭转原有程序的逻辑及不毁坏原有程序的正确性。

SOLID 准则 -ISP 接口隔离准则

接口隔离准则的英文翻译是“Interface Segregation Principle”，缩写为 ISP。Robert Martin 在 SOLID 准则中是这样定义它的：“Clients should not be forced to depend upon interfaces that they do not use。”直译成中文的话就是：客户端不应该被强制依赖它不须要的接口。其中的“客户端”，能够了解为接口的调用者或者使用者。

了解“接口隔离准则”的重点是了解其中的“接口”二字。这里有三种不同的了解。

如果把“接口”了解为一组接口汇合，能够是某个微服务的接口，也能够是某个类库的接口等。如果局部接口只被局部调用者应用，咱们就须要将这部分接口隔离进去，独自给这部分调用者应用，而不强制其余调用者也依赖这部分不会被用到的接口。

如果把“接口”了解为单个 API 接口或函数，局部调用者只须要函数中的局部性能，那咱们就须要把函数拆分成粒度更细的多个函数，让调用者只依赖它须要的那个细粒度函数。

如果把“接口”了解为 OOP 中的接口，也能够了解为面向对象编程语言中的接口语法。那接口的设计要尽量繁多，不要让接口的实现类和调用者，依赖不须要的接口函数。

繁多职责准则针对的是模块、类、接口的设计。接口隔离准则绝对于繁多职责准则，一方面更侧重于接口的设计，另一方面它的思考角度也是不同的。接口隔离准则提供了一种判断接口的职责是否繁多的规范：通过调用者如何应用接口来间接地断定。如果调用者只应用局部接口或接口的局部性能，那接口的设计就不够职责繁多。

SOLID 准则 -DIP 依赖倒置准则

依赖反转准则。依赖反转准则的英文翻译是 Dependency Inversion Principle，缩写为 DIP。中文翻译有时候也叫依赖倒置准则。

高层模块（high-level modules）不要依赖低层模块（low-level）。高层模块和低层模块应该通过形象（abstractions）来相互依赖。除此之外，形象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖形象（abstractions）。

所谓高层模块和低层模块的划分，简略来说就是，在调用链上，调用者属于高层，被调用者属于低层。在平时的业务代码开发中，高层模块依赖底层模块是没有任何问题的。实际上，这条准则次要还是用来领导框架层面的设计

1\. 管制反转

实际上，管制反转是一个比拟抽象的设计思维，并不是一种具体的实现办法，个别用来领导框架层面的设计。这里所说的“管制”指的是对程序执行流程的管制，而“反转”指的是在没有应用框架之前，程序员本人管制整个程序的执行。在应用框架之后，整个程序的执行流程通过框架来管制。流程的控制权从程序员“反转”给了框架。

2\. 依赖注入

依赖注入和管制反转恰恰相反，它是一种具体的编码技巧。咱们不通过 new 的形式在类外部创立依赖类的对象，而是将依赖的类对象在内部创立好之后，通过构造函数、函数参数等形式传递（或注入）给类来应用。

3\. 依赖注入框架

咱们通过依赖注入框架提供的扩大点，简略配置一下所有须要的类及其类与类之间依赖关系，就能够实现由框架来主动创建对象、治理对象的生命周期、依赖注入等本来须要程序员来做的事件。

4\. 依赖反转准则

依赖反转准则也叫作依赖倒置准则。这条准则跟管制反转有点相似，次要用来领导框架层面的设计。高层模块不依赖低层模块，它们独特依赖同一个形象。形象不要依赖具体实现细节，具体实现细节依赖形象。

KISS 准则

Keep It Simple and Stupid.

KISS 准则算是一个万金油类型的设计准则，能够利用在很多场景中。它不仅常常用来领导软件开发，还常常用来领导更加宽泛的零碎设计、产品设计等。

对于如何写出满足 KISS 准则的代码，总结了上面几条领导准则：

1. 不要应用共事可能不懂的技术来实现代码；
2. 不要反复造轮子，要长于应用曾经有的工具类库；
3. 不要适度优化。

YAGNI 准则

YAGNI 准则的英文全称是：You Ain’t Gonna Need It。直译就是：你不会须要它。这条准则也算是万金油了。当用在软件开发中的时候，它的意思是：不要去设计以后用不到的性能；不要去编写以后用不到的代码。实际上，这条准则的核心思想就是：不要做适度设计。

DRY 准则

Don’t Repeat Yourself

实现逻辑反复、性能语义反复、代码执行反复。实现逻辑反复，但性能语义不反复的代码，并不违反 DRY 准则。实现逻辑不反复，但性能语义反复的代码，也算是违反 DRY 准则。除此之外，代码执行反复也算是违反 DRY 准则。

进步代码可复用性的一些办法

1. 缩小代码耦合
   对于高度耦合的代码，当咱们心愿复用其中的一个性能，想把这个性能的代码抽取进去成为一个独立的模块、类或者函数的时候，往往会发现牵一发而动全身。挪动一点代码，就要牵连到很多其余相干的代码。所以，高度耦合的代码会影响到代码的复用性，咱们要尽量减少代码耦合。
2. 满足繁多职责准则
   如果职责不够繁多，模块、类设计得大而全，那依赖它的代码或者它依赖的代码就会比拟多，进而减少了代码的耦合。依据上一点，也就会影响到代码的复用性。相同，越细粒度的代码，代码的通用性会越好，越容易被复用。
3. 模块化
   这里的“模块”，不单单指一组类形成的模块，还能够了解为单个类、函数。咱们要长于将性能独立的代码，封装成模块。独立的模块就像一块一块的积木，更加容易复用，能够间接拿来搭建更加简单的零碎。
4. 业务与非业务逻辑拆散
   越是跟业务无关的代码越是容易复用，越是针对特定业务的代码越难复用。所以，为了复用跟业务无关的代码，咱们将业务和非业务逻辑代码拆散，抽取成一些通用的框架、类库、组件等。
5. 通用代码下沉
   从分层的角度来看，越底层的代码越通用、会被越多的模块调用，越应该设计得足够可复用。个别状况下，在代码分层之后，为了防止穿插调用导致调用关系凌乱，咱们只容许下层代码调用上层代码及同层代码之间的调用，杜绝上层代码调用下层代码。所以，通用的代码咱们尽量下沉到更上层。
6. 继承、多态、形象、封装
   利用继承，能够将公共的代码抽取到父类，子类复用父类的属性和办法。利用多态，咱们能够动静地替换一段代码的局部逻辑，让这段代码可复用。除此之外，形象和封装，从更加狭义的层面、而非广义的面向对象个性的层面来了解的话，越形象、越不依赖具体的实现，越容易复用。代码封装成模块，暗藏可变的细节、裸露不变的接口，就越容易复用。
7. 利用模板等设计模式
   一些设计模式，也能进步代码的复用性。比方，模板模式利用了多态来实现，能够灵便地替换其中的局部代码，整个流程模板代码可复用。

咱们在第一次写代码的时候，如果当下没有复用的需要，而将来的复用需要也不是特地明确，并且开发可复用代码的老本比拟高，那咱们就不须要思考代码的复用性。在之后开发新的性能的时候，发现能够复用之前写的这段代码，那咱们就重构这段代码，让其变得更加可复用。

LOD 法令

迪米特法令的英文翻译是：Law of Demeter，缩写是 LOD。单从这个名字上来看，咱们齐全猜不出这个准则讲的是什么。不过，它还有另外一个更加达意的名字，叫作最小常识准则，英文翻译为：The Least Knowledge Principle。

每个模块（unit）只应该理解那些与它关系密切的模块（units: only units“closely”related to the current unit）的无限常识（knowledge）。或者说，每个模块只和本人的敌人“谈话”（talk），不和陌生人“谈话”（talk）。

“高内聚、松耦合”是一个十分重要的设计思维，可能无效进步代码的可读性和可维护性，放大性能改变导致的代码改变范畴。“高内聚”用来领导类自身的设计，“松耦合”用来领导类与类之间依赖关系的设计。

所谓高内聚，就是指相近的性能应该放到同一个类中，不相近的性能不要放到同一类中。相近的性能往往会被同时批改，放到同一个类中，批改会比拟集中。所谓松耦合指的是，在代码中，类与类之间的依赖关系简略清晰。即便两个类有依赖关系，一个类的代码改变也不会或者很少导致依赖类的代码改变。

不该有间接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。迪米特法令是心愿缩小类之间的耦合，让类越独立越好。每个类都应该少理解零碎的其余局部。一旦发生变化，须要理解这一变动的类就会比拟少。

总结：面向对象设计的实质就是把适合的代码放到适合的类中。正当地划分代码能够实现代码的高内聚、低耦合，类与类之间的交互简略清晰，代码整体构造高深莫测。

重构代码

1\. 重构的目标：为什么重构（why）？

对于我的项目来言，重构能够放弃代码品质继续处于一个可控状态，不至于腐化到无可救药的境地。对于集体而言，重构十分锤炼一个人的代码能力，并且是一件十分有成就感的事件。它是咱们学习的经典设计思维、准则、模式、编程标准等理论知识的练兵场。

2\. 重构的对象：重构什么（what）？

依照重构的规模，咱们能够将重构大抵分为大规模高层次的重构和小规模低层次的重构。大规模高层次重构包含对代码分层、模块化、解耦、梳理类之间的交互关系、形象复用组件等等。这部分工作利用的更多的是比拟形象、比拟顶层的设计思维、准则、模式。小规模低层次的重构包含标准命名、正文、修改函数参数过多、打消超大类、提取反复代码等等编程细节问题，次要是针对类、函数级别的重构。小规模低层次的重构更多的是利用编码标准这一理论知识。

3\. 重构的机会：什么时候重构（when）？

咱们肯定要建设继续重构意识，把重构作为开发必不可少的局部，融入到日常开发中，而不是等到代码呈现很大问题的时候，再大刀阔斧地重构。

4\. 重构的办法：如何重构（how）？

大规模高层次的重构难度比拟大，须要组织、有打算地进行，分阶段地小步快跑，时刻让代码处于一个可运行的状态。而小规模低层次的重构，因为影响范畴小，改变耗时短，所以，只有你违心并且有工夫，随时随地都能够去做。

改善代码品质的编程标准

1\. 对于命名

• 命名的要害是能精确达意。对于不同作用域的命名，咱们能够适当地抉择不同的长度。
• 咱们能够借助类的信息来简化属性、函数的命名，利用函数的信息来简化函数参数的命名。
• 命名要可读、可搜寻。不要应用生僻的、不好读的英文单词来命名。命名要合乎我的项目的对立标准，也不要用些反直觉的命名。
• 接口有两种命名形式：一种是在接口中带前缀“I”；另一种是在接口的实现类中带后缀“Impl”。对于抽象类的命名，也有两种形式，一种是带上前缀“Abstract”，一种是不带前缀。这两种命名形式都能够，要害是要在我的项目中对立。

2\. 对于正文

• 正文的内容次要蕴含这样三个方面：做什么、为什么、怎么做。对于一些简单的类和接口，咱们可能还须要写明“如何用”。
• 类和函数肯定要写正文，而且要写得尽可能全面具体。函数外部的正文要绝对少一些，个别都是靠好的命名、提炼函数、解释性变量、总结性正文来进步代码可读性。

3\. 对于代码格调

• 函数、类多大才适合？函数的代码行数不要超过一屏幕的大小，比方 50 行。类的大小限度比拟难确定。
• 一行代码多长最合适？最好不要超过 IDE 的显示宽度。当然，也不能太小，否则会导致很多略微长点的语句被折成两行，也会影响到代码的整洁，不利于浏览。
• 善用空行宰割单元块。对于比拟长的函数，为了让逻辑更加清晰，能够应用空行来宰割各个代码块。
• 四格缩进还是两格缩进？我集体比拟举荐应用两格缩进，这样能够节俭空间，尤其是在代码嵌套档次比拟深的状况下。不论是用两格缩进还是四格缩进，肯定不要用 tab 键缩进。
• 大括号是否要另起一行？将大括号放到跟上一条语句同一行，能够节俭代码行数。然而将大括号另起新的一行的形式，左右括号能够垂直对齐，哪些代码属于哪一个代码块，更加高深莫测。
• 类中成员怎么排列？在 Google Java 编程标准中，依赖类依照字母序从小到大排列。类中先写成员变量后写函数。成员变量之间或函数之间，先写动态成员变量或函数，后写一般变量或函数，并且依照作用域大小顺次排列。

4\. 对于编码技巧

• 将简单的逻辑提炼拆分成函数和类。
• 通过拆分成多个函数或将参数封装为对象的形式，来解决参数过多的状况。
• 函数中不要应用参数来做代码执行逻辑的管制。
• 函数设计要职责繁多。
• 移除过深的嵌套档次，办法包含：去掉多余的 if 或 else 语句，应用 continue、break、return 关键字提前退出嵌套，调整执行程序来缩小嵌套，将局部嵌套逻辑形象成函数。
• 用字面常量取代魔法数。
• 用解释性变量来解释简单表达式，以此进步代码可读性。

5\. 对立编码标准

• 最初，还有一条十分重要的，那就是，我的项目、团队，甚至公司，肯定要制订对立的编码标准，并且通过 Code Review 督促执行，这对进步代码品质有空谷传声的成果。

编程标准

编程标准次要解决的是代码的可读性问题。编码标准绝对于设计准则、设计模式，更加具体、更加并重代码细节。即使你可能对设计准则不相熟、对设计模式不理解，但你最起码要把握根本的编码标准，比方，如何给变量、类、函数命名，如何写代码正文，函数不宜过长、参数不能过多等等。

代码重构

在软件开发中，只有软件在不停地迭代，就没有一劳永逸的设计。随着需要的变动，代码的不停堆砌，原有的设计必定会存在这样那样的问题。针对这些问题，咱们就须要进行代码重构。重构是软件开发中十分重要的一个环节。继续重构是放弃代码品质不降落的无效伎俩，能无效防止代码腐化到无可救药的境地。

• 面向对象编程因为其具备丰盛的个性（封装、形象、继承、多态），能够实现很多简单的设计思路，是很多设计准则、设计模式等编码实现的根底。
• 设计准则是领导咱们代码设计的一些经验总结，对于某些场景下，是否应该利用某种设计模式，具备指导意义。比方，“开闭准则”是很多设计模式（策略、模板等）的领导准则。
• 设计模式是针对软件开发中常常遇到的一些设计问题，总结进去的一套解决方案或者设计思路。利用设计模式的次要目标是进步代码的可扩展性。从形象水平上来讲，设计准则比设计模式更形象。设计模式更加具体、更加可执行。
• 编程标准次要解决的是代码的可读性问题。编码标准绝对于设计准则、设计模式，更加具体、更加并重代码细节、更加能落地。继续的小重构依赖的实践根底次要就是编程标准。
• 重构作为放弃代码品质不降落的无效伎俩，利用的就是面向对象、设计准则、设计模式、编码标准这些实践。