我将通过示例来解释这个问题：在 zend 框架中，当您想向视图类添加功能时，可以使用所谓的 Helper 类。
辅助类是具有一个方法（与类名相同）的类，该方法在每个视图中都可用（通过反射，辅助方法由视图方法包装）
它非常有条理和干净，但是，这意味着额外包括每个这样的助手和一些玩反射。这两件事对性能都有影响。
我的想法不是为每个要添加到视图中的方法开发一个 Helper（每个方法都在不同的文件中），而是编写一个带有 C 样式函数列表的助手（即不是类静态方法，实际函数），它可以是仅在 View 类中使用（因为 View 助手仅包含在 View 中）。
因此，这是将一些程序与 OO 混合，但性能优势是可见的，无论如何，帮助程序是通常不需要维护状态的单一方法......
有人会说：“所以用程序化，性能更好”，不，我很清楚 OO 的好处，除了这件小事，
那么，我应该坚持单一范式还是混合它们？
首先：OOP 是结构化编程的一个子集，它是过程的一个子集，所以你并没有像你暗示的那样走得那么“范式”。（“范式”，多么丑陋和过度使用的词）
第二：OOP，是一种设计风格，不是语言特性。只要您维护（概念）封装，使用函数而不是方法不会使您的程序减少 OOP。
第三：即使是PHP中最多的OOP代码也必须在某种程度上使用内置函数。因此，几乎按照定义，使用函数不能是“反 OOP”。
第四：是的，OOP 是目前最好的设计风格之一，但“忠于愿景”没有任何优点。毕竟，它们都是您工具箱中的工具。如果您选择的语言的 OOP 结构无法提供您对这个特定实例的需求，那么请使用其他技巧使其工作。如果您担心代码的可维护性（谁不担心？），那么将“hacky”部分封装在对象呈现的接口内，这样它就不会泄漏。
回答您的问题的唯一方法是为每个设计决策提供优缺点。
通常，当状态控制参与最少时，程序设计是最好的，对于无状态处理，一次性数据转换。程序处理的例子有：各种数学函数、字符串转换、数组转换、直接内存访问等。
虽然OOP非常适合状态控制。将 OOP 用于 UI 元素（数百万个教科书示例）、套接字编程（打开、侦听、关闭、其他状态）之类的事情非常棒，协议实现也受益匪浅。任何涉及多个实例和状态机的东西都能完美地实现。
因此，一种常见的做法是将用于简单处理的一次性函数与类中的复杂状态控制混合。类中的方法将使用函数进行内部数据处理。
一起破解某些东西可能适用于短暂的非生产代码。但是在多次升级之后，您最终可能会为您的代码寻找意大利面条酱。与临时编码相反，对代码进行深思熟虑的设计总是好的。
另一个方面是框架中的常见做法。如果 zend 框架中的一种常见做法是混合实现（OOP 和用于简单转换的函数式），那么没有理由不这样做。如果不是，最好坚持使用一种方法，否则您将面临可维护性问题，其他人将不得不花费数小时和数天来理解您的代码。
也有必要探索做任何事情的每一个技术限制：
您应该根据您的非功能性需求进行设计。例如，如果吞吐量是您的目标，那么您应该选择性能路径。但是，如果可维护性是您的目标，也许您应该让您的代码更具可读性，而不是放入所有不可读的性能优化代码。
框架给你留下空间来决定事情。OOP 本身只是一个概念。因此，恕我直言，在 OO 程序中使用 C 风格的函数并不是一种罪过。如果合适，那就去吧。