Php mysqli：混合OO和过程代码

本文讨论了混合面向对象风格和过程风格，指出“出于代码清晰性和编码风格的原因，不建议混合这两种风格。”

我维护并更新了一个规模更大的项目（数千行代码），这个项目已经有10年的历史了，而且至少还会持续这么久。（如果您愿意，可以将其视为一种图像CMS。）所有现有的mysqli代码都是过程式的，其中大部分与最初使用的旧mysql扩展相比几乎没有变化。（在大多数情况下仍然可以完美地工作。）项目代码模块会根据需要进行滚动更新、添加、删除和/或替换，因此我将在这一项目上做很多年的零星工作

为了清晰、简洁和可维护性，我想将其转换为OO风格。与从mysql到mysqli的变化不同，这不是一件只需一点思考和大量全局搜索/替换就可以轻松完成的事情。一次性改变整个项目不是一个有吸引力的选择。永远简单地使用程序化mysqli可能是最有时间效率的，但我不介意把工作做得更好，只要我不必一次完成所有工作

只更改项目的一部分是否可行，而将其他部分保留为程序样式，直到它们到期重新编写为止

这里的陷阱是什么？当您将OO和程序性mysqli结合起来时，哪些内容可以自由混合，哪些内容不能混合

---

编辑：为了清楚起见，我不是在问广泛的风格问题，纯粹是为了混合对mysqli扩展的OO风格和过程风格调用的细节。手册中除了一条平淡的语句“可以随时在样式之间切换”外，没有任何其他内容。混合使用OO和过程样式没有什么错。正如引文中所说，“出于代码清晰性和编码风格的原因，不建议使用”

但是，如果您在从

mysql\u*

迁移到

mysqli\u*

时所做的一切只是为了更改函数名而进行全局搜索和替换，那么您确实错过了新API的全部要点

其思想是，在迁移时，您应该实现预先准备好的语句，并清理

mysql.*

函数经常导致的混乱的意大利面代码。坚持过程式风格对您没有任何好处，甚至会使代码更加复杂。在OO风格中使用预先准备好的语句和异常时会更加简洁

---

如果您不使用参数绑定和mysqli异常，那么您最好坚持使用

mysql.*

函数

没有办法回答这个问题。这完全取决于您将什么对象化，以及它如何影响代码的其余部分。例如，考虑一个简单的会话包装器。您构建了一个对象来为您处理会话内容，它最终将会话数据存储在$\u session之外的某个地方。任何仍然使用$\u会话的旧代码现在都已绑定。就像在说。“我想把车的方向盘移入后备箱。这会影响什么吗？”这个问题实际上只有你能回答（至少从清晰性和可维护性的角度来看）。你和多少开发人员一起工作？每个人都可以使用两种不同的样式（旧模块上的程序样式和新模块上的OO样式）吗？谢谢你的宝贵意见。我是唯一的开发者；该项目已经包含了OO和过程模块的混合（或多或少是合理的），但我怀疑这与这个问题有多大关系，特别是关于mysqli扩展的问题。