在一些个人项目中,我正在慢慢地从PHP5转向Python,我现在很喜欢这种体验.在选择沿着Python路线前,我看了Ruby.我从红宝石社区注意到的是,猴子修补既常见又备受推崇.我也遇到了很多关于调试ruby s/w的试验的恐怖故事,因为有人包括一个相对无害的库来完成一些工作但是修补了一些使用频繁的核心对象而没有告诉任何人.
我选择Python(除了其他原因)之外它的语法更清晰,而且它可以完成Ruby所能做的一切.Python正在使得OO点击比PHP更好,我正在越来越多地阅读OO原则以增强这种更好的理解.
今晚我一直在阅读Robert Martin的SOLID原则:
小号英格尔责任的原则,
O pen/closed原理,
L iskov替代原则,
我接口隔离原则,和
d ependency倒置原则
我目前正在接受O:软件实体(课程,模块,功能等)应该开放扩展,但是为了修改而关闭.
我的头脑是在确保OO设计的一致性和整个猴子修补之间的冲突.我知道可以在Python中进行猴子修补.我也明白,"pythonic"是遵循常见的,经过良好测试的oop最佳实践和原则.
我想知道的是社区对两个对立主题的看法; 他们如何互操作,当它最好地使用一个在另一个上时,是否应该完成猴子修补......希望你能为我提供解决问题的方法.
猴子修补(覆盖或修改预先存在的方法)与简单添加新方法之间存在差异.我认为后者非常好,前者应该被怀疑地看待,但我仍然赞成保留它.
我遇到了很多问题,其中第三方扩展monkeypatches核心库和破坏东西,他们真的很糟糕.不幸的是,它们总是看起来源于第三方扩展开发人员采取阻力最小的路径,而不是考虑如何正确地构建他们的解决方案.
这很糟糕,但它不再是猴子修补的错误,而不是刀具制造者的错,人们有时会割伤自己.
我见过的唯一合法的猴子补丁需求是解决第三方或核心库中的错误.仅此一点,它是无价的,如果他们取消了这样做的能力,我真的很失望.
我们有一个C#程序中的错误时间表:
阅读奇怪的错误报告并将问题跟踪到CLR库中的小错误.
投资日期提出了一个解决方法,涉及在陌生的地方捕获异常和许多黑客攻击,这会严重影响代码
当Microsoft发布Service Pack时,花几天时间解决hacky变通办法
我们有一个rails程序中的错误时间表:
阅读奇怪的错误报告并将问题跟踪到ruby标准库中的小错误
花15分钟进行小型猴子补丁以从红宝石库中移除错误,如果它运行在错误版本的红宝石上,则在它周围放置警卫.
继续正常编码.
稍后在下一版本的ruby发布时删除monkeypatch.
错误修正过程看起来很相似,除了monkeypatching,它是一个15分钟的解决方案,一个5秒的'提取',而没有它,痛苦和痛苦随之而来.
PS:下面的例子是"技术上"monkeypatching,但它是"道德"monkeypatching？我没有改变任何行为 - 这或多或少只是在红宝石中做AOP ......
class SomeClass
alias original_dostuff dostuff
def dostuff
# extra stuff, eg logging, opening a transaction, etc
original_dostuff
end
end
在我看来,monkeypatching对于拥有可以被滥用的东西很有用.人们倾向于发现它,并且觉得应该在每种情况下使用它,也许混合或其他结构可能更合适.
我不认为这是你应该禁止的东西,它只是Ruby家伙喜欢使用的东西.你可以用Python做类似的事情,但社区已采取的立场应该更简单,更明显.
京公网安备 11010802040832号 | 京ICP备19059560号-6 