自从有了它，我就再也没有用过函数重写

前言

了解过编程的人应该对函数重写 ( 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。

结尾

通过了一段时间的学习，在亲身实践中确实领会到了插件化给系统带来的益处。它不只给予了程序无限扩展的可能，也为代码赋予了稳定的基础结构。这很是重要，由于若是地基不够稳固，程序大厦将会在某个时刻瞬间崩塌。

现实中，其实全部的程序都在跟随着实际业务不停地发展。因此历来都没有一劳永逸的设计模式，只有不停地在优化着的代码结构。当一种编码方式没法知足现状、知足需求时。总会有人去推翻它，去构建属于这个时代的新模式。而这，正是编程的魅力所在。

以为本文有帮助能够点个赞哦，也欢迎关注个人公众号。