面向对象编程的5个原则--python实例

作为一名开发工程师或者测试开发来说，掌握程序设计、编程技能已经是基本要求了，但如果你想进阶更高的层次，或者你想成为一名合格的测试架构师，除了要掌握如何实现以外，还得要学会如何实现好！ 因为掌握功能编码的实现并不代表你能写出或者设计出“好”的代码、好的架构。
想成为一名优秀的测试架构师，在程序设计这块需要掌握的一些开发技能、设计技巧。能够立即改善程序设计、写出“好”代码的知识有以下几点：

• 面向对象五个基本原则

• 常见的三种架构

• 绘图

• 起一个好名字

• 优化嵌套的 if else 代码；

  当然，其他技术知识的丰富程度也决定了程序设计的好坏。例如通过引入消息队列解决双端性能差异问题、通过增加缓存层提高查询效率等。下面我们一起来看看，上面列出的知识点包含哪些内容，这些内容对代码和程序设计的改善有何帮助。这篇博文就关注在面向对象的五个原则。

面向对象的五个基本原则

• 单一职责原则
• 开放封闭原则
• 依赖倒置原则
• 接口隔离原则
• 合成复用原则

1、立杆见影的单一职责原则

对于大多数自学编程无师自通的人来说，能把功能实现就可以了，根本没有时间考虑代码优化和维护成本问题。时光流逝，竟在接触编程很长一段时间后才发现它竟如此重要。

俗话说只要代码写的够烂，提升就足够明显。以一个从文件内容中匹配关键数据并根据匹配结果发出网络请求的案例，看看大部分程序员的写法：

## 我写的--LOW版
import re
import requests

FILE = "./information.fet"
def extract(file):
    fil = open(file, "r")
    content = fil.read()
    fil.close()
    find_object = re.search(r"url=\d+", content)
    find = find_object.group(1)
    text = requests.get(find)
    return text


if __name__ == "__main__":
    text = extract(FILE)
    print(text)

需求已经实现，这点毋庸置疑，但是问题来了：

• 如果读取文件的时候发生异常了怎么办？
• 如果数据源发生变化该如何处理？
• 如果网络请求返回的数据不符合最终要求怎么办？

如果你心里的第一个反应是改代码，那你就要注意了。完成一件事中间的某个环节发生变化，改代码是在所难免的，但是如果按照上面这种写法，不仅代码越改越乱，连逻辑也会越来越乱。

单一职责原则表达的是让一个函数尽量只做一件事，不要将多件事混杂在一个函数中。上面的代码如果重新设计，我认为至少应该是这样的：

## 狂狮写的--高大上版
def get_source():
    """获取数据源"""
    return


def extract_(val):
    """匹配关键数据"""
    return


def fetch(val):
    """发出网络请求"""
    return


def trim(val):
    """修剪数据"""
    return


def extract(file):
    """提取目标数据"""
    source = get_source()
    content = extract_(source)
    text = trim(fetch(content))
    return text


if __name__ == "__main__":
    text = extract(FILE)
    print(text)

把原来放在一个函数中实现的多个步骤拆分成为多个更小的函数，每个函数只做一件事。
当数据源发生变化时，只需要改动 get_source 相关的代码即可；如果网络请求返回的数据不符合最终要求，我们可以在 trim 函数中对它进行修剪。这样一来，代码应对变化的能力提高了许多，整个流程也变得更清晰易懂。改动前后的变化如下图所示：

**单一职责原则的核心是解耦和增强内聚力，**如果一个函数承担的职责过多，等于把这些职责耦合在一起，这种耦合会导致脆弱的设计。当发生变化时，原本的设计会遭受到意想不到的破坏。单一职责原则实际上是把一件事拆分成多个步骤，代码修改造成的影响范围很小。

2、让代码稳定性飞升的开放封闭原则和依赖倒置原则

开放封闭原则中的开放指的是对扩展开放，封闭指的是对修改封闭。需求总是变化的，业务方这个月让你把数据存储到 MySQL 数据库中，下个月就有可能让你导出到 Excel 表格里，这时候你就得改代码了。

稳定这个词如何理解呢？
—较少的改动或者不改动即视为稳定，稳定意味着调用这个对象的其它代码拿到的结果是可以确定的，整体是稳定的。

按照一般程序员的写法，上面提到的数据存储的代码大概是这样的：

## 我写的 --low版
class MySQLSave:

    def __init__(self):
        pass

    def insert(self):
        pass

    def update(self):
        pass


class Business:
    def __init__(self):
        pass

    def save(self):
        saver = MySQLSave()
        saver.insert()

以上代码的功能是能够实现的，这点毋庸置疑。来看看它如何应对变化，如果要更换存储，那么就意味着需要改代码。按照上面的代码示例，有两个选择：

• 重新写一个存储到 ExcelSave 的类；
• 对 MySQLSave 类进行改动；

上面的两种选择，无论怎么选都会改动 2 个类。因为不仅存储的类需要改动，调用处的代码也需要更改。这样一来，它们整体都是不稳定的。如果换一种实现方式，根据依赖倒置的设计指导可以轻松应对这个问题。边看代码边理解：

## 狂狮写的---高大上版
import abc


class Save(metaclass=abc.ABCMeta):
    @abc.abstractmethod
    def insert(self):
        pass

    @abc.abstractmethod
    def update(self):
        pass


class MySQLSave(Save):

    def __init__(self):
        self.classify = "mysql"
        pass

    def insert(self):
        pass

    def update(self):
        pass


class Excel(Save):
    def __init__(self):
        self.classify = "excel"

    def insert(self):
        pass

    def update(self):
        pass


class Business:
    def __init__(self, saver):
        self.saver = saver

    def insert(self):
        self.saver.insert()

    def update(self):
        self.saver.update()


if __name__ == "__main__":
    mysql_saver = MySQLSave()
    excel_saver = Excel()
    business = Business(mysql_saver)

解释：上述代码通过内置的 abc 实现了一个抽象基类，这个基类的目的是强制子类实现要求的方法，以达到子类功能统一。子类功能统一后，无论调用它的哪个子类，都是稳定的，不会出现调用方还需要修改方法名或者修改传入参数的情况。

依赖倒置中的倒置，指的是依赖关系的倒置。之前的代码是调用方 Business 依赖对象 MySQLSave，一旦对象 MySQLSave 需要被替换， Business 就需要改动。依赖倒置中的依赖指的是对象的依赖关系，之前依赖的是实体，如果改为后面这种依赖抽象的方式，情况就会扭转过来：

实体 Business 依赖抽象有一个好处：抽象稳定。相对于多变的实体来说，抽象更稳定。代码改动前后的依赖关系发生了重大变化，之前调用方 Business 直接依赖于实体 MySQLSave，通过依赖倒置改造后 Busines 和 ExcelSave、 MySQLSave 全都依赖抽象。这样做的好处是如果需要更换存储，只需要创建一个新的存储实体，然后调用 Business 时传递进去即可，这样可以不用改动 Business 的代码，符合面向修改封闭、面向扩展开放的开放封闭原则；

依赖倒置的具体实现方式使用了一种叫做依赖注入的手段，实际上单纯使用依赖注入、不使用依赖倒置也可以满足开闭原则要求，感兴趣的读者不妨试一试。

3、挑肥拣瘦的接口隔离原则

接口隔离原则中的接口指的是 Interface，而不是 Web 应用里面的 Restful 接口，但是在实际应用中可以将其抽象理解为相同的对象。接口隔离原则在设计层面看，跟单一职责原则的目的是一致的。接口隔离原则的指导思想是：

• 调用方不应该依赖它不需要的接口；
• 依赖关系应当建立在最小接口上；

这实际上是告诉我们要给接口减肥，过多功能的接口可以选用拆分的方式优化。举个例子，现在为图书馆设计一个图书的抽象类：

## 我写不出来的low版
import abc

class Book(metaclass=abc.ABCMeta):
    @abc.abstractmethod
    def buy(self):
        pass

    @abc.abstractmethod
    def borrow(self):
        pass

    @abc.abstractmethod
    def shelf_off(self):
        pass

    @abc.abstractmethod
    def shelf_on(self):
        pass

图可以被购买、可以被借阅、可以下架、可以上架，这看起来并没有什么问题。但这样一来这个抽象只能提供给管理人员使用，用户操作时需要再设定一个新的抽象类，因为你不可能让用户可以操纵图书上下架。
接口隔离原则推荐的做法是把图书的上下架和图书购买、借阅分成 2 个抽象类，管理端的图书类继承 2 个抽象类，用户端的图书类继承 1 个抽象类。这么看起来是有点绕，不要慌，我们看图理解：

这样是不是一下就看懂了。这个指导思想很重要，不仅能够指导我们设计抽象接口，也能够指导我们设计 Restful 接口，还能够帮助我们发现现有接口存在的问题，从而设计出更合理的程序。

5、轻装上阵的合成复用原则

合成复用原则的指导思想是：尽量使用对象组合，而不是继承来达到复用的目的。合成复用的作用是降低对象之间的依赖，因为继承是强依赖关系，无论子类使用到父类的哪几个属性，子类都需要完全拥有父类。合成采用另一种方式实现对象之间的关联，降低依赖关系。

为什么推荐优先使用合成复用，而后考虑继承呢？

因为继承的强依赖关系，一旦被依赖的对象（父类）发生改变，那么依赖者（子类）也需要改变，合成复用则可以避免这样的情况出现。要注意的是，推荐优先使用复用，但并不是拒绝使用继承，该用的地方还得用。我们以一段代码为例，说明合成复用和继承的差异：

import abc


class Car:

    def move(self):
        pass

    def engine(self):
        pass


class KateCar(Car):

    def move(self):
        pass

    def engine(self):
        pass


class FluentCar(Car):

    def move(self):
        pass

    def engine(self):
        pass

继承写法中 Car 作为父类，拥有 move 和 engine 2 个重要属性，这时候如果需要给汽车涂装颜色，那么就要新增一个 color 属性，3 个类都要增加。

如果使用合成复用的方式，可以这么写：

## 优先合成复用的写法

class Color:
    pass


class KateCar:

    color = Color()

    def move(self):
        pass

    def engine(self):
        pass


class FluentCar:

    color = Color()

    def move(self):
        pass

    def engine(self):
        pass

类对象合成复用的具体操作是在类中实例化一个类对象，然后在需要的时候调用它。代码可能没有那么直观，我们看图：

这个例子主要用于说明继承和合成复用的具体实现方式和前后变化，对于 Car 的继承无需深究，因为如果你执着地讨论为什么右图中的 2 个 Car 不用继承，就会陷入牛角尖。

这里的合成复用选用的实现方式是在 2 个 Car 里面实例化另一个类 Color，其实也可以用依赖注入的手段在外部实例化 Color，然后把实例对象传递给 2 个 Car。