程序编程比OOP有什么优势吗? [英] Does procedural programming have any advantages over OOP?
问题描述
早些时候，我问这是一个关于何时使用OOP以及何时使用过程编程的框架，可能是一个框架不完善的问题-有些回答暗示我在寻求帮助以帮助理解OOP.相反，我经常使用OOP，但想知道何时使用过程方法.从响应的角度来看，我认为有一个相当强烈的共识，即OOP通常是一种更好的全方位方法，但是，如果OOP架构从长远来看不会提供任何重用的好处，则应使用过程语言.
但是，我作为Java程序员的经历却并非如此.我看到了一个Perl大师用我编写的代码的1/10重写构造的海量Java程序，它看起来和我的OOP完美模型一样强大.我的体系结构有大量的重用，但是更简洁的过程方法产生了出色的解决方案.
因此，冒着重蹈覆辙的风险，我想知道在什么情况下我应该选择一种过程而不是面向对象的方法.您将如何预先确定OOP体系结构可能会过时并且程序方法更简洁，更有效的情况.
任何人都可以提出这些情况的样例吗?
什么是预先确定可通过程序编程方法更好地服务的项目的好方法?
我建议您使用针对任何给定问题可以找到的最简洁，基于标准的方法.您使用Perl的同事证明，一个很好的开发人员，只要他对某种特定的工具了如指掌，无论使用哪种方法，都能取得很好的效果.我希望将Perl与类似Ruby之类的简洁语言进行对峙，而不是将Java对比Perl项目作为过程与OOP辩论的一个很好的例子进行比较.面向对象.现在，这是我想看到的东西.我的猜测是Ruby会拔得头筹，但我对在这里引发一场语言大战不感兴趣-我的观点只是选择适合该工作的工具-哪种方法都能以最有效，最强大的方式完成任务可能的方式. Java可能会因为其面向对象而变得健壮，但是随着您和您的同事以及许多正在转换为动态语言(例如Ruby和Python)的其他人的发现，如今，无论是过程还是OOP，都存在着更加有效的解决方案.
[Edit:] Earlier I asked this as a perhaps poorly-framed question about when to use OOP versus when to use procedural programming - some responses implied I was asking for help understanding OOP. On the contrary, I have used OOP a lot but want to know when to use a procedural approach. Judging by the responses, I take it that there is a fairly strong consensus that OOP is usually a better all-round approach but that a procedural language should be used if the OOP architecture will not provide any reuse benefits in the long term.
However my experience as a Java programmer has been otherwise. I saw a massive Java program that I architected rewritten by a Perl guru in 1/10 of the code that I had written and seemingly just as robust as my model of OOP perfection. My architecture saw a significant amount of reuse and yet a more concise procedural approach had produced a superior solution.
So, at the risk of repeating myself, I'm wondering in what situations should I choose a procedural over an object-oriented approach. How would you identify in advance a situation in which an OOP architecture is likely to be overkill and a procedural approach more concise and efficient.
Can anyone suggest examples of what those scenarios would look like?
What is a good way to identify in advance a project that would be better served by a procedural programming approach?
I would suggest using the most concise, standards-based approach that you can find for any given problem. Your colleague who used Perl demonstrated that a good developer who knows a particular tool well can achieve great results regardless of the methodology. Rather than compare your Java-versus-Perl projects as a good example of the procedural-versus-OOP debate, I would like to see a face-off between Perl and a similarly concise language such as Ruby, which happens to also have the benefits of object orientation. Now that's something I'd like to see. My guess is Ruby would come out on top but I'm not interested in provoking a language flame-war here - my point is only that you choose the appropriate tool for the job - whatever approach can accomplish the task in the most efficient and robust way possible. Java may be robust because of its object orientation but as you and your colleague and many others who are converting to dynamic languages such as Ruby and Python are finding these days, there are much more efficient solutions out there, whether procedural or OOP.
这篇关于程序编程比OOP有什么优势吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
