前言
了解过编程的人应该对函数重写 ( override ) 不陌生，但其实，这个普适的方法并不适用于所有的应用场景。举个简单的例子，当多个项目代码贡献方都想参与同一程序的修改时，频繁的函数重写会使代码变得异常混乱，让整个项目变得难以维护。
那么，有没有更优雅的方法能够兼顾代码的扩展性与稳定性呢？
有的，pytest ( python 单元测试框架 ) 的作者就意识到了这个问题。在其源码中，可以发现许多经过 @pytest.hookimpl 关键字装饰的函数，这代表这个函数是一个插件的实现，其作用是通过用插件调用的形式来替代函数重写。。
pytest 部分源码：
@pytest.hookimpl(hookwrapper=True)
def pytest_load_initial_conftests(early_config: Config):
ns = early_config.known_args_namespace
if ns.capture == "fd":
_py36_windowsconsoleio_workaround(sys.stdout)
_colorama_workaround()
_readline_workaround()
pluginmanager = early_config.pluginmanager
capman = CaptureManager(ns.capture)
pluginmanager.register(capman, "capturemanager")
# make sure that capturemanager is properly reset at final shutdown
early_config.add_cleanup(capman.stop_global_capturing)
# finally trigger conftest loading but while capturing (issue93)
capman.start_global_capturing()
outcome = yield
capman.suspend_global_capture()
if outcome.excinfo is not None:
out, err = capman.read_global_capture()
sys.stdout.write(out)
sys.stderr.write(err)
早前在 pytest 中这只是一个插件工具库，而随着这个库的日益发展， 作者把它从 pytest 中分离了出来，并将其命名为了 pluggy。
什么是 pluggy ？
pluggy 是 pytest 中插件管理和钩子函数调用的核心组件。它已经让 500 多个插件自由扩展和自定义了 pytest 的默认行为。甚至可以说 pytest 本身就是根据良好的规范协议依次调用的插件的集合。
通过为主程序安装插件，它使用户能够扩展或修改主程序的行为。插件代码将作为正常程序执行的一部分运行，从而更改或增强程序的某些功能。
本质上，pluggy 让所有函数 "钩子化"，因此使用者可以用其轻松构建 "可插拔" 系统。
为什么要用 pluggy ？
当有多方想要定制化扩展程序时，使用函数重写的方式将会导致程序代码异常混乱。而通过 pluggy 可以使得到主程序与插件之间松耦合。
pluggy 也让主程序的设计者去仔细考虑钩子函数实现中需要用到哪些对象。而这为插件创建者提供了一个清晰的框架，因为它说明了如何通过一组定义良好的函数和对象来扩展主程序，最终让整个项目代码框架结构越来越清晰。
pluggy 是如何工作的？
首先我们需要了解两个概念：
主程序：通过指定钩子函数并在程序执行过程中调用其实现来提供可扩展性的程序；
插件：程序实现指定的钩子（的一部分）并在主程序调用实现时参与程序执行。
而 pluggy 的作用则是通过使用以下几个方面 联通主程序与插件：
- 定义主程序提供的调用签名对应的钩子规范；
- 由注册插件提供的钩子实现（也称为hookimpl-可参阅回调）；
- 钩子调用者 - 在主程序中适当的位置触发的调用循环，调用实现并收集结果。
一个简单的例子
来演示一下 pluggy 的核心功能 - 即插即用。
import pluggy
hookspec = pluggy.HookspecMarker("myproject")
hookimpl = pluggy.HookimplMarker("myproject")
class MySpec(object):
"""A hook specification namespace."""
@hookspec
def myhook(self, arg1, arg2):
"""My special little hook that you can customize."""
class Plugin_1(object):
"""A hook implementation namespace."""
@hookimpl
def myhook(self, arg1, arg2):
print("inside Plugin_1.myhook()")
return arg1 + arg2
class Plugin_2(object):
"""A 2nd hook implementation namespace."""
@hookimpl
def myhook(self, arg1, arg2):
print("inside Plugin_2.myhook()")
return arg1 - arg2
# create a manager and add the spec
pm = pluggy.PluginManager("myproject")
pm.add_hookspecs(MySpec)
# register plugins
pm.register(Plugin_1())
pm.register(Plugin_2())
# call our `myhook` hook
results = pm.hook.myhook(arg1=1, arg2=2)
print(results)
在上述代码中，开发者
定义了主程序提供的调用签名 （myproject）对应的钩子规范 - hookspec；
定义了钩子实现 - hookimpl；
在 MySpec 中定义了 myhook 的入参；
在 Plugin_1 和 Plugin_2 中定义了 myhook 具体实现；
新建了插件管理对象 pm；
在 pm 中添加设置好的钩子规格 MySpec；
在 pm 中注册了定义好的 Plugin_1 和 Plugin_2；
通过 pm 进行了 myhook 的调用。
运行代码后控制台输出如下：
inside Plugin_2.myhook()
inside Plugin_1.myhook()
[-1, 3]
为什么输出是 [-1,3] 呢？ 其实我们可以看出两个插件中实现了相同的函数名，根据插件调用的先进后出原则，在调用 myhook 后程序会先执行后注册的 Plugin_2.myhook()，后执行先注册的 Plugin_1.myhook()。所以在最终的返回结果中，会获得按执行顺序排列的返回值列表，其值分别是 -1 和 3。
结尾
经过了一段时间的学习，在亲身实践中确实领会到了插件化给系统带来的益处。它不仅给予了程序无限扩展的可能，也为代码赋予了稳定的基础结构。这非常重要，因为如果地基不够稳固，程序大厦将会在某个时刻瞬间崩塌。
现实中，其实所有的程序都在跟随着实际业务不停地发展。所以从来都没有一劳永逸的设计模式，只有不停地在优化着的代码结构。当一种编码方式无法满足现状、满足需求时。总会有人去推翻它，去构建属于这个时代的新模式。而这，正是编程的魅力所在。
