我应该根据范例或者语言提供的工具来设计我的软件吗?

首先:OOP是结构化编程的一个子集,它是过程编程的一个子集,所以您不会像您所暗示的那样“以范式为导向”。(范例,一个多么难看和使用过度的词)

第二:OOP是一种设计风格,而不是语言特性。只要维护(概念上的)封装,使用函数而不是方法并不会减少程序的OOP。

第三:即使是PHP中最面向对象的代码也必须在某种程度上使用内置函数。所以,根据定义,使用函数不能是“反OOP”。

第四:是的,OOP是目前最好的设计风格之一,但是“忠于愿景”并没有什么优点。毕竟,它们都是你工具箱里的工具。如果您选择的语言的OOP构造不能提供您对此特定实例所需的内容,那么可以使用其他技巧使其工作。如果您担心代码的可维护性(谁不担心呢?),然后将对象提供的接口中的“hacky”部分封装起来,这样它就不会泄漏。

回答问题的唯一方法是为每个设计决策提供利弊。

一般来说 程序设计 对于无状态处理、单次数据转换,在状态控制参与最小的情况下是最好的。过程处理的例子有:各种数学函数、字符串转换、数组转换、直接内存访问等。

同时 面向对象程序设计 对国家控制来说很好。对于UI元素(数以百万计的教科书示例)、套接字编程(打开、侦听、关闭、其他状态)、协议实现等,使用OOP也很好。任何涉及 多个实例 和 状态机 实现得非常好。

因此,将用于简单处理的一次性函数与类中的复杂状态控件混合在一起是一种常见的做法。类中的方法将使用函数进行内部数据处理。

把一些东西拼凑在一起可能适用于短期的、非生产性的代码。但是在多次升级之后,您可能最终会为代码寻找意大利面酱。与即席编码相比,对代码进行仔细的设计总是很好的。

另一个方面是 框架中的常见做法 . 如果Zend框架中有混合实现(OOP和简单转换的函数实现)是一种常见的实践,那么几乎没有理由不这样做。如果不是,最好坚持一种方法,否则您将面临可维护性问题,其他人将不得不花费数小时和数天的时间来理解您的代码。

也有必要探索 技术限制 不管你做什么:

• 如果涉及编译器(而不是解释器)和链接,请确保没有问题。
• 如果您的代码被拆分为模块(库),请确保混合操作不会破坏兼容性。
• 如果存在性能问题,请对其进行量化;一旦这样做,决策可能会变得更容易。
• 做许多测试应用程序来验证您的选择——意外的崩溃、缓慢的启动/停止、数据损坏、为了完成任务而跳过圈都表明选择不是最佳的。知道 为什么? 和知道一样重要 什么 .

您应该根据您的非功能需求进行设计。例如,如果吞吐量是您的目标,那么您应该选择性能路径。但是,如果可维护性是您的目标,那么也许您应该使您的代码比放入所有不可读的性能优化代码更具可读性。

框架为您留出空间来决定事情。OOP本身只是一个概念。因此,在OO程序imho中使用C样式的函数并不是一种罪恶。如果合适的话,那就去做吧。