众所周知，python 是面向对象的语言。

但大多数人学习 python 只是为了写出“能够实现某些任务的自动化脚本”，因此，python 更令人熟知的是它脚本语言的身份。

那么，更近一步，如果使用 python 实现并维护一个大的项目，进行软件开发，简单的串并联脚本就难以满足日常繁重的维护需求。

此时需要借鉴其他编程语言的精化，比如说 JAVA 语言中的面向对象的思想。通过将核心功能抽象化并原子化，赋予 python 脚本更高的可维护性。

这篇文章是我读秦小波老师的《设计模式之禅》有感。虽然书里全篇都是Java语言，看不懂，但书中提到的 6 大程序设计原则还是让我受益匪浅。下面我将分别介绍这 6 大原则，并将尝试给出正反例帮助大家理解。

文章目录

单一职责原则
里氏替换原则
依赖倒置原则
接口隔离原则
迪米特原则
开闭原则

单一职责原则

简单理解就是，一个类、或者一个函数，只能承担一项职责。
这一设计思想指导我们，在设计业务逻辑时，要尽可能的剥离不相干的业务，降低业务逻辑的颗粒度，进而实现“原子函数”、“原子类”。

如何有效的鉴别“不相干”的业务，成为了履行单一职责原则的核心难点。一种常见的解释是：类的变更仅由一件业务决定。

一个违反了该原则的案例可以是：

class Tiger:
    def walk(self):
        print('walk')
        
    def swim(self):
        print('swim')

可以看到，老虎类包含了两个方法，走和游泳。然而，游泳的业务和走是相对独立的。所以说， Tiger 类将受到两种变更因素的影响，违背了单一职责的原则。

一种解决方案是将二者剥离，如下：

class Walk_animal():
    def walk(self):
        print('walk')


class Swim_animal():
    def swim(self):
        print('swim')


class Tiger(Walk_animal, Swim_animal):
    pass


a_tiger = Tiger()
a_tiger.swim()

Tiger 类通过继承父类，获得游泳和走的能力，这种设计很好的遵守了单一职责原则，但凭空增加了两个类，因此在大多数业务实践中，我们也不会这样做。

秦小波老师的《设计模式之禅》中是这样解决的：Java 环境下，面向对象的精髓是面向接口编程。

我们通过增加接口来规范类的功能，虽然 python 原生不支持接口，但我们可以使用抽象类来实现接口类。相关教程：python–接口类与抽象类 - 知乎 (zhihu.com)

from abc import abstractmethod, ABCMeta


class Walk_animal(metaclass=ABCMeta):
    @abstractmethod
    def walk(self): pass


class Swim_animal(metaclass=ABCMeta):
    @abstractmethod
    def swim(self): pass


class Tiger(Walk_animal, Swim_animal):
    def walk(self):
        print('walk')

    def swim(self):
        print('swim')


a_tiger = Tiger()
a_tiger.swim()

这种实现方式看似更复杂，但在大型项目中，可以提高代码的可读性和可维护性。

里氏替换原则

该原则规定了继承操作的要点，通俗解释的话就是，父类能够使用的地方，将父类替换为子类，程序也能正常运行。

具体来说：

子类必须完全使用父类的方法；
子类可以有自己的个性；
覆写方法时，子类对应的参数类型范围只能比父类窄；
覆写方法时，子类对应的输出结果的类型只能比父类窄；

可以看到，里氏替换原则关注的焦点是覆写父类方法。因为正常的继承操作是一定满足上述要求的，如下：

class Walk_animal():
    def walk(self):
        print('walk')


class Swim_animal():
    def swim(self):
        print('swim')


class Tiger(Walk_animal, Swim_animal):
    pass

那么一种违反里氏替换原则的案例可以是：

class do_plus:
    def plus(self, addon):
        return addon + 1

class math(do_plus):
    def plus(self, addon):
        return addon + 2

a = do_plus()
assert a.plus(1) == 2

b = math()
assert b.plus(1) == 2

会报错：

Traceback (most recent call last):
  File "H:/123123123/main.py", line 65, in <module>
    assert b.plus(1) == 2
AssertionError

可见，math 的覆写没有通过父类的测试案例。上述代码改为：

class do_plus:
    def plus(self, addon):
        return addon + 1

class math(do_plus):
    def plus_2(self, addon):
        return addon + 2

a = do_plus()
assert a.plus(1) == 2

b = math()
assert b.plus(1) == 2

通过了测试案例，同时子类也有了自己的个性，很好的满足了里氏替换原则的前两条。

事实上，第一条，子类必须完全使用父类的方法 更多是针对接口类的继承，接口类中的抽象方法是一定要继承的。

另一方面，后两条，则可以通过下面一段代码展示：

from typing import Union

class do_plus:
    def plus(self, addon: int) -> float:
        return float(addon) + 1

class math(do_plus):
    def plus(self, addon: Union[int, float]) -> Union[int, float]:
        return addon + 1


a = do_plus()
a_results = a.plus(1)
assert type(a_results) == float

b = math()
b_results = b.plus(1)
assert type(b_results) == float

运行后，报错信息如下：

Traceback (most recent call last):
  File "H:/123123123/main.py", line 70, in <module>
    assert type(b_results) == float
AssertionError

可以看到，math 拓宽了 do_plus 类的应用范围，输入类型增加了浮点型。这点是正确的，符合里氏替换原则的第三条。但输出时的类型也拓宽了，因此没有通过原有测试案例的类型检查。

解决办法就是约束输出的变量类型，如下：

from typing import Union

class do_plus:
    def plus(self, addon: int) -> float:
        return float(addon) + 1

class math(do_plus):
    def plus(self, addon: Union[int, float]) -> float:
        return float(addon) + 1


a = do_plus()
a_results = a.plus(1)
assert type(a_results) == float

b = math()
b_results = b.plus(1)
assert type(b_results) == float

总的来说，检验里氏替换原则的最简单方法就是，子类能够通过所有情况下的父类的测试案例。

依赖倒置原则

该原则在面向对象的语境下指：

高层模块不应该依赖于低层模块，二者均应该依赖其抽象。
抽象不应该依赖细节，细节应该依赖于抽象。

所谓抽象就是指接口类，细节就是实例化的接口类。

依赖倒置原则指，面向对象编程的核心是面向接口编程，即不同类之间的依赖耦合在接口层上就已经实现。

一种不满足依赖倒置原则的情况可以是：

class ase_optimizer():
    def __init__(self):
        self.name = 'ASE'
    def ase_check(self):
        print('ase check')

class xtb_optimizer():
    def __init__(self):
        self.name = 'xTB'
    def xtb_check(self):
        print('xtb check')

class checker():
    def __init__(self, optimizer):
        self.optimizer = optimizer
    def check(self):
        if self.optimizer.name == 'ASE':
            self.optimizer.ase_check()
        elif self.optimizer.name == 'xTB':
            self.optimizer.xtb_check()

a = checker(ase_optimizer())
a.check()

这段代码中，高层模块 checker 通过调用低层模块 optimizer 完成业务逻辑，没有用到接口类，三个类均为细节，因此我们说，这是以细节为基础搭建起来的架构。

一个很显然的弊端在于：

        if self.optimizer.name == 'ASE':
            self.optimizer.ase_check()
        elif self.optimizer.name == 'xTB':
            self.optimizer.xtb_check()

如果需要增加优化器，我们要修改 checker 类，如下：

        if self.optimizer.name == 'ASE':
            self.optimizer.ase_check()
        elif self.optimizer.name == 'xTB':
            self.optimizer.xtb_check()
        elif self.optimizer.name == 'gauss':
            self.optimizer.gauss_check()

显然，低层业务逻辑的变动，惊动了高层业务逻辑，因此我们说，违反了依赖倒置原则。

一种改进方法如下：

from abc import abstractmethod, ABCMeta


class opt_check(metaclass=ABCMeta):
    @abstractmethod
    def check(self): pass


class ase_optimizer(opt_check):
    def __init__(self):
        self.name = 'ASE'

    def check(self):
        print('ase check')


class xtb_optimizer(opt_check):
    def __init__(self):
        self.name = 'xTB'

    def check(self):
        print('xtb check')


class checker():
    def __init__(self, optimizer):
        self.optimizer = optimizer

    def check(self):
        self.optimizer.check()


a = checker(ase_optimizer())
a.check()

可以看到，业务逻辑大大简化，此时如果需要新增逻辑，如下所示：

from abc import abstractmethod, ABCMeta


class opt_check(metaclass=ABCMeta):
    @abstractmethod
    def check(self): pass


class ase_optimizer(opt_check):
    def __init__(self):
        self.name = 'ASE'

    def check(self):
        print('ase check')


class xtb_optimizer(opt_check):
    def __init__(self):
        self.name = 'xTB'

    def check(self):
        print('xtb check')


class gauss_optimizer(opt_check):
    def __init__(self):
        self.name = 'gauss'

    def check(self):
        print('gauss check')


class checker():
    def __init__(self, optimizer):
        self.optimizer = optimizer

    def check(self):
        self.optimizer.check()


a = checker(ase_optimizer())
a.check()

可以看到，虽然我们新增了一个低层类，但在高层 checker 上完全看不到影响。

这就是面向接口编程的奇妙之处：我们通过接口，预先指定了方法 check，因此高层在调用时，不需要了解具体的低层实现，只要知道低层，有这个 check 方法就可以完成业务逻辑的搭建。

这样带来的好处是：

利于并行开发。比如说10个人开发10个子类，如果按照第一种实现方式，每一个人完成开发后都需要改动高层类，这会带来潜在的风险。
高层类和低层类相对解耦，可以分别进行测试。

然而，做到这一步并没有完全实现依赖倒置原则。因为该原则第一条指出，高层模块也要依赖于抽象。

我们上面的改动只是实现了，低层模块依赖于抽象（接口），高层模块并没有依赖接口。我们只是利用接口简化了部分业务逻辑。

事实上，这依然是一种短视的行为。

因为我们无法预知，现在所谓的高层模块会不会在未来，也变成了庞大业务逻辑中的一个低层模块。

真正满足依赖倒置原则的实现如下：

from abc import abstractmethod, ABCMeta


class opt_check(metaclass=ABCMeta):
    @abstractmethod
    def opt_check(self): pass


class chk_check(metaclass=ABCMeta):
    @abstractmethod
    def __init__(self, optimizer: opt_check): pass

    @abstractmethod
    def chk_check(self): pass


class ase_optimizer(opt_check):
    def opt_check(self):
        print('ase check')


class checker(chk_check):
    def __init__(self, optimizer: opt_check):
        self.optimizer = optimizer

    def chk_check(self):
        self.optimizer.opt_check()


class auto_checker():
    def check(self, a_checker: checker):
        a_checker.chk_check()


a = auto_checker()
a.check(a_checker=checker(optimizer=ase_optimizer()))

我们首先通过两个接口 opt_check 和 chk_check ，搭建了清晰的业务逻辑框架。

from abc import abstractmethod, ABCMeta


class opt_check(metaclass=ABCMeta):
    @abstractmethod
    def opt_check(self): pass


class chk_check(metaclass=ABCMeta):
    @abstractmethod
    def __init__(self, optimizer: opt_check): pass

    @abstractmethod
    def chk_check(self): pass

剩余部分只是对抽象的具体实现，即细节

class ase_optimizer(opt_check):
    def opt_check(self):
        print('ase check')


class checker(chk_check):
    def __init__(self, optimizer: opt_check):
        self.optimizer = optimizer

    def chk_check(self):
        self.optimizer.opt_check()

可以看到，细节实现时，按照抽象的指示，填补空缺即可。此外，更高层调用高层时，依然满足依赖倒置原则：

class auto_checker():
    def check(self, a_checker: checker):
        a_checker.chk_check()

因为 checker 模块已经被定死了。

至此，我们完全实现了依赖倒置原则，搭建了以抽象为框架的业务逻辑。这部分是完全独立的，可以看作业务实现的草稿，更像是论文写作的大纲。

总的来说，依赖倒置原则对编程人员的架构能力要求很高，面向接口编程也因此成为了面向对象编程的精髓。

接口隔离原则

在面向接口的程序设计理念下，我们需要先确定业务逻辑框架，再去实现细节。因此，在设计接口时，其颗粒度要尽可能的小，不然抽象类的实例会实现一些没有必要的功能。

from abc import abstractmethod, ABCMeta


class teach(metaclass=ABCMeta):
    @abstractmethod
    def teach_eng(self): pass

    @abstractmethod
    def teach_math(self): pass


class teacher(teach):
    def teach_eng(self):
        print('teach english')

    def teach_math(self):
        print('teach math')


class eng_class():
    def start_class(self, eng_teacher: teacher):
        eng_teacher.teach_eng()


class math_class():
    def start_class(self, math_teacher: teacher):
        math_teacher.teach_math()

可以看到，实际业务逻辑中，英语课并不需要老师教数学。显然，我们 teacher 接口的设计是失败的。

将其拆分为两个接口，如下：

from abc import abstractmethod, ABCMeta


class eng_teach(metaclass=ABCMeta):
    @abstractmethod
    def teach_eng(self): pass

class math_teach(metaclass=ABCMeta):
    @abstractmethod
    def teach_math(self): pass


class eng_teacher(eng_teach):
    def teach_eng(self):
        print('teach english')


class math_teacher(math_teach):
    def teach_math(self):
        print('teach math')


class eng_class():
    def start_class(self, eng_teacher: eng_teacher):
        eng_teacher.teach_eng()


class math_class():
    def start_class(self, math_teacher: math_teacher):
        math_teacher.teach_math()

上述为两个接口的简易拆分，值得注意的是，接口并不是颗粒度越小越好，因为这另一方面会无端增加接口数量。

事实上，在复杂业务逻辑的实践中，我们应该把相似功能的捆绑在一起，在保证接口纯洁性的同时，尽量降低接口数量。

下图为一种接口设计：

在这里插入图片描述
原博客

该设计中，高层模块 A 调用了低层模块 B，而低层模块 B 通过接口 I1, I2 实现了方法 1,2,3

通过整合相似功能，这种设计很好的体现了接口隔离原则。

总的来说，接口隔离原则理念上和最开始的单一职责原则类似，都在讲原子化。二者的区别在于，单一职责原则的对象是类，是实例。接口隔离原则面向的是接口，因为“面向接口编程”的理念被单独列出。

迪米特原则

该原则指出：一个对象应该对其他对象了解的越少越好。

一个违反了迪米特原则的例子如下：

class products():
    def __init__(self, year):
        self.year = year


class employee():
    def query_products(self, query_year: int):
        print(f'{query_year} has products 100')


class Boss():
    def query(self, a_employee: employee, products_year: int):
        prod = products(year=products_year)
        a_employee.query_products(query_year=prod.year)


b = Boss()
employee_A = employee()
b.query(a_employee=employee_A, products_year=2000)

程序设计的本意是，老板通过员工获知产品信息。

老板和员工是直接朋友，然而，老板方法里冒出了 products 类，并与其产生了交流。

修改后如下所示：

class products():
    def __init__(self, year):
        self.year = year


class employee():
    def query_products(self, query_year: int):
        prod = products(year=query_year)
        print(f'{prod.year} has products 100')


class Boss():
    def query(self, a_employee: employee, products_year: int):
        a_employee.query_products(query_year=products_year)


b = Boss()
employee_A = employee()
b.query(a_employee=employee_A, products_year=2000)