猴子修补 Vs.坚硬的.原则? [英] Monkey-patching Vs. S.O.L.I.D. principles?

问题描述

我正在一些个人项目中慢慢从 PHP5 迁移到 Python，目前我很喜欢这种体验.在选择走 Python 路线之前，我看了看 Ruby.我从 ruby​​ 社区注意到的是，猴子补丁既常见又受到高度重视.我还遇到了很多关于调试 ruby​​ 软件的试验的恐怖故事，因为有人包含了一个相对无害的库来做一些小工作，但它在没有告诉任何人的情况下修补了一些经常使用的核心对象.

I'm slowly moving from PHP5 to Python on some personal projects, and I'm currently loving the experience. Before choosing to go down the Python route I looked at Ruby. What I did notice from the ruby community was that monkey-patching was both common and highly-regarded. I also came across a lot of horror stories regarding the trials of debugging ruby s/w because someone included a relatively harmless library to do a little job but which patched some heavily used core object without telling anyone.

我选择 Python 是因为(除其他原因外)它的语法更简洁，而且它可以做 Ruby 能做的一切.Python 使面向对象的点击变得比 PHP 更好，我正在阅读越来越多的面向对象原则以加深对这种理解.

I chose Python for (among other reasons) its cleaner syntax and the fact that it could do everything Ruby can. Python is making OO click much better than PHP ever has, and I'm reading more and more on OO principles to enhance this better understanding.

今晚我一直在阅读罗伯特·马丁的 SOLID 原则:

This evening I've been reading about Robert Martin's SOLID principles:

• S单一责任原则，
• O笔/封闭原则，
• Liskov 替换原则，
• 我接口隔离原则，以及
• D周期倒置原理

• Single responsibility principle,
• Open/closed principle,
• Liskov substitution principle,
• Interface segregation principle, and
• Dependency inversion principle

我目前最关心的是O:软件实体(类、模块、功能等)应该对扩展开放，但对修改关闭.

我的脑子里一直在思考确保面向对象设计的一致性和整个猴子补丁之间的冲突.我知道可以在 Python 中进行猴子修补.我也明白，pythonic"是遵循通用的、经过良好测试的 oop 最佳实践 &原则.

My head's in a spin over the conflict between ensuring consistency in OO design and the whole monkey-patching thing. I understand that its possible to do monkey-patching in Python. I also understand that being "pythonic" is to follow common, well-tested, oop best-practices & principles.

我想知道的是社区对两个对立主题的看法；它们如何互操作，何时最好使用一个而不是另一个，是否应该在所有...希望你能帮我解决这个问题.

What I'd like to know is the community's opinion on the two opposing subjects; how they interoperate, when its best to use one over the other, whether the monkey-patching should be done at all... hopefully you can provide a resolution to the matter for me.

推荐答案

猴子修补(覆盖或修改预先存在的方法)与简单添加新方法之间存在差异.我觉得后者很好，前者应该怀疑，但我还是赞成保留它.

There's a difference between monkey-patching (overwriting or modifying pre-existing methods) and simple addition of new methods. I think the latter is perfectly fine, and the former should be looked at suspiciously, but I'm still in favour of keeping it.

我遇到过很多这样的问题，其中第三方扩展monkeypatch 核心库并破坏了一些东西，而且它们确实很糟糕.不幸的是，它们似乎总是源于第三方扩展开发人员走阻力最小的道路，而不是考虑如何真正正确地构建他们的解决方案.
这很糟糕，但这不是猴子修补的错，而是人们有时割伤自己的刀具制造商的错.

I've encountered quite a few those problems where a third party extension monkeypatches the core libraries and breaks things, and they really do suck. Unfortunately, they all invariably seem stem from the the third party extension developers taking the path of least resistance, rather than thinking about how to actually build their solutions properly.
This sucks, but it's no more the fault of monkey patching than it's the fault of knife makers that people sometimes cut themselves.

我见过的唯一一次对猴子补丁的合法需求是解决第三方或核心库中的错误.仅就这一点而言，它是无价的，如果他们取消执行此操作的能力，我真的会感到失望.

The only times I've ever seen legitimate need for monkey patching is to work around bugs in third party or core libraries. For this alone, it's priceless, and I really would be disappointed if they removed the ability to do it.

我们遇到的 C# 程序中的一个错误的时间表:

Timeline of a bug in a C# program we had:

1. 阅读奇怪的错误报告并将问题追溯到 CLR 库中的一个小错误.
2. 花几天时间想出一个解决方法，包括在奇怪的地方捕获异常和大量破坏代码的黑客
3. 当 Microsoft 发布服务包时，花几天时间解决一些棘手的问题

我们遇到的 rails 程序中的一个错误的时间表:

Timeline of a bug in a rails program we had:

1. 阅读奇怪的错误报告并将问题追溯到 ruby​​ 标准库中的一个小错误
2. 花 15 分钟执行小猴子补丁以从 ruby​​ 库中删除错误，如果它在错误版本的 ruby​​ 上运行，并在它周围放置守卫以防止其绊倒.
3. 继续正常编码.
4. 在下一个 ruby​​ 版本发布时，只需删除monkeypatch.

错误修复过程看起来很相似，除了使用monkeypatching，它是一个 15 分钟的解决方案，一个 5 秒的提取"，而没有它，痛苦和痛苦随之而来.

The bugfixing process looks similar, except with monkeypatching, it's a 15 minute solution, and a 5-second 'extraction' whereas without it, pain and suffering ensues.

PS:下面的例子是技术上"的monkeypatching，但它是道德上"的monkeypatching吗?我没有改变任何行为 - 这或多或少只是在 ruby​​ 中执行 AOP...

PS: The following example is "technically" monkeypatching, but is it "morally" monkeypatching? I'm not changing any behaviour - this is more or less just doing AOP in ruby...

class SomeClass
  alias original_dostuff dostuff
  def dostuff
    # extra stuff, eg logging, opening a transaction, etc
    original_dostuff
  end
end

这篇关于猴子修补 Vs.坚硬的.原则?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！