1、所有书中都没有把猴子补丁作为一种设计模式来看待。因为设计模式的模式的命名是根据java中提炼出来的，语言方式决定了java绝对不会有也不需要有这种操作，不存在的。那自然设计模式不会包括猴子补丁模式。
2、根据百度百科介绍，设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。只要是解决高可扩展和高可复用的编码问题就可以算是一种设计模式，猴子补丁是在python里面一种很普遍达到这种目的方式，所以可以算是一种设计模式。
3、在python 函数和类和全局变量都是一等公民，不是所有东西必须都要写到一个类里面包裹起来，写起来很自由。有的python人员c语言中毒太深或者连c语言都没学过只自学python，写代码项目里面永远只会有0个类（除开文档上规定死了要写一个类的这种类），模块加函数的写法只能解决局部复用，和类的可复用性相比差距很大。但是别人就是打死也不愿意项目里面有一个类出现，这种情况怎么改造这个模块的整体功能？
假设有个文件叫 xxx.py, 且xxx.py代码如下：
_var_aaa = 1
def _function_bbb(paramx):
return paramx * 10
def function_ccc(paramx):
print(_var_aaa) # 这里假设是print，实际肯定是拿着var_aaa变量做实际有意义的事情
_function_bbb(paramx)
do_othrething() ................................
模块的function_ccc函数是唯一 作为公有函数，是希望被外界调用的。但这个函数很蛋疼，依赖了模块/包 里面的外部变量和外部函数，要改他并不是改这个函数本身就能达到目的，还要改其他地方。
假如希望全局变量 _var_aaa的初始值是2，函数_function_bbb的功能是吧变量扩大100倍，怎么改？
1）、去修改源文件，肯定不靠谱，你硬编码的方式改了这里的代码，如果没通知别人，别人继续使用，别人调用函数会出来新的结果会出毛病。而且猴子补丁很多时候是针对三方包或者官方包，去直接修改那些地方的文件很不靠谱，任何时候都不要这么做。
2）、把整个包/模块复制出来一份，然后修改其中的一小部分几行代码，杀鸡用牛刀，为了0.01%代码的改变，无缘无故增加几千几万行相同字母的代码。
以上两种方法都不好，在最小代价下实现 全局变量 _var_aaa的初始值是2，函数__function_bbb的功能是吧变量扩大100倍，应该就是轮到猴子补丁上场了，
import xxx
xxx._var_aaa = 2
def _my_function_bbb(paramx):
return paramx * 100
xxx._function_bbb = _my_function_bbb
之后再次调用 function_ccc，就会使改变生效了，不止当前代码模块处会生效，运行patch后会使所有地方生效。
猴子补丁赖以实现的基础是
python 模块会导入几次？猴子补丁为什么可以实现？
4、 最好还是使用面向对象来编程。猴子补丁模式虽灵活，猴子补丁是在之前扩展没设计好的基础上才不得已为之才使用的。用起来很多弊端，比如pycharm智能提示和跳转支持很差，因为是在运行时后改变行为的，pycahrm是死的只会根据固定的代码结构进行智能提示和补全，不会去猜测运行时候的行为。模块始终是个单例，一会儿想var_aaa初始变量是3一会希望他是2，一会希望function_bbb的功能是扩大一百倍一会儿希望他是扩大一万倍，猴子补丁是无法实现得，使用面oop这些问题是非常轻松非常正常自然的完成的，完全不需要想。因为类可以继承，模块无法继承；类是多实例的（每个实例就像无数复制出来的内部属性互不干扰的模块），不会像模块一样只有一份。
5、自己写的代码最好设计好扩展使用oop，不要让自己的模块有被别人打猴子补丁的想法和机会。让打猴子补丁只发生在修改三方包和官方包的时候，如果自己写的代码也需要大猴子补丁才能实现改造，那应该是没设计好，没有暴露出使用策略/模板方法。
6、关于面向过程和面向对象编程，介绍了很多次区别，和oop的优点。我绝对没说过所有场景所有地方都要全100%使用纯oop，但我反对那些不管任何情况都坚持代码只有0个类的写法，这种写法情况的人现实和网上见过很多。多试下多对比下才能知道体会到区别，不然老是笼统的二逼的说法就是大项目用oop小项目用ofp当挡箭牌。具体多大才算大？200行代码不算大吗，每次新做项目功能时候把自己的200行代码复制黏贴扣字修改反复弄几百次也算200行吗？大项目也不可能纯100%oop，会两样都有。
要知道什么时候使用oop，而不是数代码的行数再来决定使不使用oop，比如8种方法实现写计数器例子，实现计数器总共才不到10行，写闭包函数明显比使用类更晦涩难懂，难道行数少就适合函数吗？大项目也不是所有函数都需要改成方法包裹在类里面。
到底是用哪一种，一个判断是函数如果是非常孤立的，不依赖外部状态和依赖的外部函数不可能需要改变，比如单独做个时间格式转换，用函数没毛病，放在大项目也可以。
如果函数有一些依赖，特别是依赖的属性和函数需要弹性改变，使用类好。
据我的实践，我使用oop改造了项目里面的很多模块或者子任务，基本上每次使用oop重构都能够比原有的opp代码减少40%-90%的代码行数。