我应该根据范式还是根据语言提供的工具来设计我的软件？
我将通过例子来解释这个问题： 在 zend 框架中，当您想向视图类添加功能时，可以使用所谓的 Helper 类。
辅助类是具有一个方法（与类名相同）的类，该方法在每个视图中都可用（通过反射，辅助方法由视图方法包装）
它非常有组织和干净，但是，这意味着每个这样的助手都需要额外包含，并且需要一些反射。 这两件事都对性能产生影响。
我的想法是，我不会为要添加到视图中的每个方法开发一个帮助程序（每个方法都在不同的文件中），而是编写一个带有 C 风格函数列表的帮助程序（即不是类静态方法，真正的函数），这些函数可以是仅在 View 类中使用（因为 View 助手仅包含在 View 中）。
所以，这是将一些过程与 OO 混合在一起，但性能优势是显而易见的，而且无论如何，助手都是单一方法，通常不需要维护状态......
有些人会说：“所以使用过程，性能更好明智的”，不，我非常清楚 OO 的好处，除了这件小事，
那么，我应该坚持单一范式还是混合使用它们？
I will explain the question by example:
In zend framework, when you want to add a functionality to the view class, you can use what is called a Helper class.
A helper class is a class that has one method (Same as name of class) that becomes available in each of the views (by reflection the helper method is wrapped by a view method)
It is very organized and clean, BUT, it means an extra include for each such helper and some playing with reflection. Both things takes their tole on performance.
My thought was instead of developing a Helper per method I want to add to the view (Each in a different file), I will write one helper with a list of C style functions (i.e. not class static methods, real functions) which can be used only in the View class (as View helpers are include only in the View).
So, this is mixing some procedural with OO, but the performance benefits are visible, and anyway, helpers are single methods which usually don't need to maintain state...
Some will say: "So go with procedural, it is better performance wise", No, I am very well aware of the benefits of OO, except in this small matter,
So, should I stick to a single paradigm or mix them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
第一：OOP 是结构化编程的一个子集，结构化编程是过程性编程的子集，因此您不会像您暗示的那样在“范式方面”走得太远。 （“范式”，多么难看又被滥用的词）
第二：OOP，是一种设计风格，而不是一种语言特性。 只要您维护（概念上的）封装，使用函数而不是方法并不会让您的程序减少 OOP。
第三：即使 PHP 中最面向对象的代码也必须在某种程度上使用内置函数。 因此，几乎根据定义，使用函数不能是“反 OOP”。
第四：是的，OOP 是最好的设计风格之一，但“忠于愿景”并没有什么优点。 毕竟，它们都是您工具箱中的工具。 如果您选择的语言的 OOP 结构无法提供此特定实例所需的内容，那么请使用其他技巧来使其工作。 如果您担心代码的可维护性（谁不担心？），那么请将“hacky”部分封装在对象呈现的接口内，这样就不会泄漏。
first: OOP is a subset of structured programming, which is a subset of procedural, so you're not going so far 'paradigm-wise' as you imply. ("paradigm", what an ugly and overused word)
second: OOP, is a design style, not a language feature. using functions instead of methods doesn't make your program any less OOP, as long as you maintain the (conceptual) encapsulations.
third: even the most OOP code in PHP has to use the built-in functions at some level. so, almost by definition, using functions can't be "anti-OOP".
fourth: yeah, OOP is one of the best design styles out there, but there's no virtue on 'staying true to a vision'. after all, they're all tools in your toolchest. if the OOP constructs of your language of choice can't deliver what you need for this specific instance, then use other tricks to make it work. if you're worried about code maintainability (and who isn't?), then encapsulate the 'hacky' parts inside the interface presented by your objects, so it doesn't leak.
回答你的问题的唯一方法是给出每个设计决策的优点和缺点。
一般来说，当状态控制参与最少时，对于无状态处理、一次性数据转换，程序设计是最好的。 过程处理的例子有：各种数学函数、字符串变换、数组变换、直接内存访问等。
而OOP非常适合状态控制。 使用 OOP 来处理 UI 元素（数以百万计的教科书示例）、套接字编程（打开、监听、关闭、其他状态）等事情非常棒，协议实现也会受益。 任何涉及多个实例和状态机的东西都能完美地实现自身。
那么，将用于简单处理的一次性函数与类中的复杂状态控制混合起来是一种常见的做法。 类中的方法将使用函数进行内部数据处理。
一起破解某些东西可能适用于短暂的非生产代码。 但在多次升级之后，您可能最终会为您的代码寻找意大利面条酱。 与临时编码相比，对代码进行深思熟虑的设计总是好的。
另一个方面是框架中的常见做法。 如果 zend 框架中的常见做法是混合实现（面向简单转换的 OOP 和函数式实现），那么没有理由不这样做。 如果不是，最好坚持使用一种方法，否则您将面临可维护性问题，而其他人将不得不花费数小时和数天来理解您的代码。
还有必要探索所做的任何事情的每一个技术限制：
The only way to answer your question is to give pros and cons for each design decision.
Generally going for procedural design is best when there is minimal state-control involvement, for stateless processing, one-shot data transformation. Examples for procedural processing would be: all kinds of mathematical functions, string transformations, array transformations, direct memory access and the like.
While OOP is great for state control. It is great to use OOP for things like UI elements (millions of textbook examples), socket programming (open, listening, closed, other states), protocol implementations also benefit. Anything that involves multiple instances and state machines implements itself wonderfully.
It is a common practice then, to mix one-shot functions for simple processing with complex state controls in classes. Methods in classes would be using functions for their internal data processing.
Hacking something together might work for the short-lived, non-production code. But after multiple upgrades you might end up looking for spaghetti sauce for your code. It is always good to have a deliberate design for the code as opposed to ad-hoc coding.
Another aspect is the common practice in the framework. If it is a common practice in zend framework to have mixed implementations (OOP and functional for simple transformations), there is little reason not to. If it is not, better stick with one approach, otherwise you will face maintainability issues and other people will have to spend hours and days understanding your code.
It is also necessary to explore every bit of technical limitations of doing whatever you do:
您应该根据您的非功能需求进行设计。 例如，如果吞吐量是您的目标，那么您应该选择性能路径。 但如果可维护性是您的目标，也许您应该使代码更具可读性，而不是将所有不可读的性能优化代码放入其中。
框架为您留下了决定事情的空间。 OOP本身只是一个概念。 因此，恕我直言，在 OO 程序中使用 C 风格的函数并不是一种罪过。 如果合适就去吧。
You should design according to your non-functional requirements. For example, if the throughput is your goal, you should go for the performance path. But if the maintainability is your goal, maybe you should make your code more readable than putting all unreadable performance optimized code in.
Frameworks leave you spaces to decide things. OOP itself is just a concept. So it is not a sin to use C-style functions in OO program, IMHO. If it is appropriate than go for it.