过程式编程与 OOP 的开发成本？
我有相当深厚的 OO 背景，了解 OOD 和 OOD 的好处。 OOP 是我的第二天性，但最近我发现自己在一家与过程编程习惯相关的开发商店中。 实现语言具有一些 OOP 功能，但它们没有以最佳方式使用。
更新：每个人似乎都对这个主题有自己的看法，我也是如此，但问题是：
是否有任何好的比较研究来对比使用过程编程语言与面向对象语言的软件开发成本？
一些评论者指出试图将苹果与橙子进行比较的可疑性质，我同意准确测量非常困难，但也许并非完全不可能。
I come from a fairly strong OO background, the benefits of OOD & OOP are second nature to me, but recently I've found myself in a development shop tied to a procedural programming habits. The implementation language has some OOP features, they are not used in optimal ways.
Update: everyone seems to have an opinion about this topic, as do I, but the question was:
Have there been any good comparative studies contrasting the cost of software development using procedural programming languages versus Object Oriented languages?
Some commenters have pointed out the dubious nature of trying to compare apples to oranges, and I agree that it would be very difficult to accurately measure, however not entirely impossible perhaps.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
所有这些问题中的大多数都被以下问题所困扰：个体程序员的生产力存在一个数量级或更多的差异； 如果你碰巧有一个 OO 程序员，他是生产力 x 组中的一员，还有一个“过程式”程序员，他是 10x 程序员，那么即使 OO 在某种意义上更快，过程式程序员也有可能获胜。
还有一个问题是，在实际项目中，编码效率通常只占总工作量的 10-20%，因此更高的效率并没有太大影响； 即使是假设的 10 倍程序员，或者无限快的程序员，也无法将总体工作量减少超过 10-20%。
您可以查看 Fred Brooks 的论文“没有灵丹妙药”。
Most all of these questions are confounded by the problem that individual programmer productivity varies by an order of magnitude or more; if you happen to have an OO programmer who is one of the gruop at productivity x, and a "procedural" programmer who is a 10x programmer, the procedural programmer is liable to win even if OO is faster in some sense.
There's also the problem that coding productivity is usually only 10-20 percent of the total effort in a realistic project, so higher productivity doesn't have much impact; even that hypothetical 10x programmer, or an infinitely fast programmer, can't cut the overall effort by more that 10-20 percent.
You might have a look at Fred Brooks' paper "No Silver Bullet".
经过谷歌搜索后，我在这里找到了这篇论文。 我使用的搜索术语是面向生产力对象的。
开头几段继续说
我想你会发现面向对象编程在特定情况下更好，但对其他一切都是中立的。 说服我的老板将我公司的 CAD/CAM 应用程序转换为面向对象框架的原因是我精确地展示了它可以提供帮助的确切领域。 重点不是整个方法论，而是它如何帮助我们解决我们遇到的一些具体问题。 对我们来说，有一个可扩展的框架，可以添加更多形状、报告和机器控制器，并使用集合来消除旧设计的内存限制。
After poking around with google I found this paper here. The search terms I used are Productivity object oriented.
The opening paragraphs goes on to say
I think you will find that Object Oriented Programming is better in specific circumstances but neutral for everything else. What sold my bosses on converting my company's CAD/CAM application to a object oriented framework is that I precisely showed the exact areas in which it will help. The focus wasn't on the methodology as a whole but how it will help us sold some specific problem we had. For us was having a extensible framework for adding more shapes, reports, and machine controllers, and using collections to remove the memory limitation of the older design.
面向对象或程序提供了不同的开发方式，如果管理不善，两者的成本都可能很高。
如果我们假设这两种情况下的工作都是由最好的人完成的，我认为结果在成本方面可能是相等的。
我相信成本差异将取决于您将如何维护阶段，您将需要添加功能和修改当前功能。 程序项目更难进行自动测试，不太容易在不影响其他部分的情况下进行扩展，并且更难以逐部分理解概念（因为没有必要将内聚部分组合在一起）。
所以，我认为，从长远来看，与过程相比，面向对象的成本会更低。
OO or procedural offer to different way to develop and both can be costly if badly managed.
If we suppose that the works are done by the best person in both case, I think the result might be equal in term of cost.
I believe the cost difference will be on how you will be the maintenance phase where you will need to add features and modify current features. Procedural project are harder to have automatic testing, are less subject to be able to expand without affecting other part and is more harder to understand the concept part by part (because cohesive part aren't grouped together necessary).
So, I think, the OO cost will be lower in the long run compared to Procedural.
我认为 S.Lott 指的是“不可重复的实验”现象，即你不能按程序编写应用程序 X，然后倒带时间并编写 OO 来看看有什么区别。
你可以用两种不同的方式编写同一个应用程序两次，但是
因此实际上没有直接的比较基础，
实证研究同样是无用的，出于类似的原因 - 不同的应用程序，不同的团队等。
范式转变是困难，并且一小部分程序员可能永远无法实现转变，
如果您可以自由地按自己的方式开发，那么解决方案很简单：按自己的方式开发事物，当您的同事注意到您正在这样做时他们周围的编码圈子，你的代码不会经常崩溃等等，他们会问你如何做到这一点，然后教他们 OOP（以及 TDD 和你可能使用的任何其他良好实践），
如果没有，那么，它可能是是时候润色简历了...;-)
i think S.Lott was referring to the "unrepeatable experiment" phenomenon, i.e. you cannot write application X procedurally then rewind time and write it OO to see what the difference is.
you could write the same app twice two different ways, but
so there really is no direct basis for comparison
empirical studies are likewise useless, for similar reasons - different applications, different teams, etc.
paradigm shifts are difficult, and a small percentage of programmers may never make the transition
if you are free to develop your way, then the solution is simple: develop things your way, and when your co-workers notice that you are coding circles around them and your code doesn't break nearly as often etc. and they ask you how you do it, then teach them OOP (along with TDD and any other good practices you may use)
if not, well, it might be time to polish the resume... ;-)
好主意。 头对头的比较。 以过程风格和面向对象风格编写应用程序 X 并测量某些内容。 开发成本。 投资回报。
用两种风格编写同一个应用程序意味着什么？ 这将是一个不同的应用程序，不是吗？ 程序化的人们会认为面向对象的人们在使用继承、消息传递或封装时是在作弊。
不可能有这样的比较。 没有比较应用程序的两个“版本”的基础。 这就像问苹果或橙子作为水果是否更具成本效益一样。
话虽如此，你必须关注其他人实际上可以看到的东西。
是时候构建一些有用的东西了。
错误和问题的发生率。
如果你的方法更好，你就会成功，人们会想知道为什么。
当您解释面向对象会导致您的成功时...好吧...您已经赢得了争论。
Good idea. A head-to-head comparison. Write application X in a procedural style, and in an OO style and measure something. Cost to develop. Return on Investment.
What does it mean to write the same application in two styles? It would be a different application, wouldn't it? The procedural people would balk that the OO folks were cheating when they used inheritance or messaging or encapsulation.
There can't be such a comparison. There's no basis for comparing two "versions" of an application. It's like asking if apples or oranges are more cost-effective at being fruit.
Having said that, you have to focus on things other folks can actually see.
Time to build something that works.
Rate of bugs and problems.
If your approach is better, you'll be successful, and people will want to know why.
When you explain that OO leads to your success... well... you've won the argument.
关键是时间。 公司需要多长时间更改设计以添加新功能或修复现有功能。 你所做的任何研究都应该集中在该领域。
我的公司在 90 年代中期使用 VB3 创建了一个面向事件驱动程序的 CAM 软件设计。 让软件适应新机器需要很长时间。 长时间测试bug修复和新功能的效果。
随着 VB6 的出现，我能够绘制出当前的设计和解决测试和适应问题的新设计。 这位不懂技术的老板立刻就明白了我在做什么。
关键是解释为什么 OOP 将使项目受益。 使用 Fowler 的《重构》和设计模式等内容来展示新设计将如何减少做事的时间。 还包括如何从 A 点到 B 点。重构将有助于展示如何拥有可交付的工作中间阶段。
The key is time. How long does it take the company to change the design to add new features or fix existing ones. Any study you make should focus on that area.
My company had a event driven procedure oriented design for a CAM software in the mid 90's created using VB3. It was taking a long time to adapt the software to new machines. A long time to test the effects of bug fixes and new features.
With VB6 came along I was able to graph out the current design and a new design that fixed the testing and adaptation problem. The non-technical boss grasped what I was trying doing right away.
The key is to explain WHY OOP will benefit the project. Use things like Refactoring by Fowler and Design Patterns to show how a new design will lower the time to do things. Also include how you get from Point A to Point B. Refactoring will help with showing how you can have working intermediate stages that can be shipped.
我认为你不会找到这样的研究。 至少你应该定义“成本”的含义。 由于 OOP 设计在某种程度上较慢，因此从短期来看，过程式编程的开发可能会更快。 从短期来看，意大利面条式编码可能会更快。
但当项目开始增长时，情况就会相反，因为 OOP 设计的最佳特点是管理代码复杂性。
因此，在小型项目中，程序设计可能会更便宜，因为它更快并且没有缺点。
但在大型项目中，仅使用过程编程等简单范例，您很快就会上手
I don't think you'll find a study like that. At least you should define what you mean by "cost". Because OOP designing is somehow slower, so on the short term development is maybe faster with procedural programming. On very short term maybe spaghetti coding is even more faster.
But when project begins growing things are opposite, because OOP designing is best featured to manage code complexity.
So in a small project maybe procedural design MAY be cheaper, because it's faster and you don't have drawbacks.
But in a big project you'll get stick very quickly using only a simple paradigm like procedural programming
我怀疑你能否找到一项明确的研究。 正如几个人提到的，这不是一个可重复的实验。 你会发现很多轶事证据。 有些人可能会找到一些统计研究，但我会仔细检查它们。 我不知道有什么真正好的。
我还要指出另一点，现实世界中不存在纯粹面向对象或纯粹过程的东西。 许多（如果不是大多数）对象方法都是用过程代码编写的。 同时，许多过程程序使用面向对象的方法，例如封装（也称为抽象）。
不要误会我的意思，面向对象和过程式程序看起来不同，但这是深灰色与浅灰色的问题，而不是黑白的问题。
I doubt you will find a definitive study. As several people have mentioned this is not a reproducible experiment. You will find anecdotal evidence, a lot of it. Some people may find some statistical studies, but I would examine them carefully. I am not aware of any really good ones.
I also will make another point, there is no such thing as purely object oriented or purely procedural in the real world. Many if not most object methods are written with procedural code. At the same time many procedural programs use OO methodologies such as encapsulation (also call abstraction by some).
Don't get me wrong, OO and procedural programs look and are different, but it is a matter of dark gray vs light gray instead of black and white.
这篇文章没有提及 OOP 与过程式。 但我认为您可以使用您公司的类似指标进行讨论。
我发现这很有趣，因为我的公司正在开始探索 ROWE 计划。 在我们的第一次会议中，很明显我们目前没有捕获足够的结果指标。
所以你需要关注1）当前流程的维护是否会阻碍未来的发展？ 2）不同的方法将如何影响#1？
This article says nothing about OOP vs Procedural. But I'd think that you could use similar metrics from your company for a discussion.
I find it interesting as my company is starting to explore the ROWE initiative. In our first session, it was apparent that we don't currently capture enough metrics on outcomes.
So you need to focus on 1) Is the maintenance of current processes impeding future development? 2) How are different methods going to affect #1?