python设计模式之猴子补丁模式

 

一、全部书中都没有把猴子补丁做为一种设计模式来看待。由于设计模式的模式的命名是根据java中提炼出来的，语言方式决定了java绝对不会有也不须要有这种操做，不存在的。那天然设计模式不会包括猴子补丁模式。

 

二、根据百度百科介绍，设计模式（Design pattern）表明了最佳的实践，一般被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程当中面临的通常问题的解决方案。这些解决方案是众多软件开发人员通过至关长的一段时间的试验和错误总结出来的。只要是解决高可扩展和高可复用的编码问题就能够算是一种设计模式，猴子补丁是在python里面一种很广泛达到这种目的方式，因此能够算是一种设计模式。

 

三、在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 模块会导入几回？猴子补丁为何能够实现？

 

 

四、  最好仍是使用面向对象来编程。猴子补丁模式虽灵活，猴子补丁是在以前扩展没设计好的基础上才不得已为之才使用的。用起来不少弊端，好比pycharm智能提示和跳转支持不好，由于是在运行时后改变行为的，pycahrm是死的只会根据固定的代码结构进行智能提示和补全，不会去猜想运行时候的行为。模块始终是个单例，一下子想var_aaa初始变量是3一会但愿他是2，一会但愿function_bbb的功能是扩大一百倍一下子但愿他是扩大一万倍，猴子补丁是没法实现得，使用面oop这些问题是很是轻松很是正常天然的完成的，彻底不须要想。由于类能够继承，模块没法继承；类是多实例的（每一个实例就像无数复制出来的内部属性互不干扰的模块），不会像模块同样只有一份。

 

五、本身写的代码最好设计好扩展使用oop，不要让本身的模块有被别人打猴子补丁的想法和机会。让打猴子补丁只发生在修改三方包和官方包的时候，若是本身写的代码也须要大猴子补丁才能实现改造，那应该是没设计好，没有暴露出使用策略/模板方法。

 

六、关于面向过程和面向对象编程，介绍了不少次区别，和oop的优势。我绝对没说过全部场景全部地方都要全100%使用纯oop，但我反对那些无论任何状况都坚持代码只有0个类的写法，这种写法状况的人现实和网上见过不少。多试下多对比下才能知道体会到区别，否则总是笼统的二逼的说法就是大项目用oop小项目用ofp当挡箭牌。具体多大才算大？200行代码不算大吗，每次新作项目功能时候把本身的200行代码复制黏贴扣字修改反复弄几百次也算200行吗？大项目也不可能纯100%oop，会两样都有。

要知道何时使用oop，而不是数代码的行数再来决定使不使用oop，好比8种方法实现写计数器例子，实现计数器总共才不到10行，写闭包函数明显比使用类更晦涩难懂，难道行数少就适合函数吗？大项目也不是全部函数都须要改为方法包裹在类里面。

究竟是用哪种，一个判断是函数若是是很是孤立的，不依赖外部状态和依赖的外部函数不可能须要改变，好比单独作个时间格式转换，用函数没毛病，放在大项目也能够。

若是函数有一些依赖，特别是依赖的属性和函数须要弹性改变，使用类好。

据个人实践，我使用oop改造了项目里面的不少模块或者子任务，基本上每次使用oop重构都可以比原有的opp代码减小40%-90%的代码行数。