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