我来自相当强大的 OO 背景，OOD 和 OOP 的好处是我的第二天性，但最近我发现自己在一家开发商店，与程序编程习惯有关。实现语言有一些 OOP 特性，它们没有以最佳方式使用。
更新：每个人似乎都对这个话题有意见，我也是，但问题是：
有没有比较好的比较研究来对比使用过程编程语言和面向对象语言的软件开发成本？
一些评论者指出了将苹果与橙子进行比较的可疑性质，我同意准确测量将非常困难，但也许并非完全不可能。
ceretullis
问问题
5032 次
9 回答
12
大多数所有这些问题都被单个程序员的生产力变化一个数量级或更多的问题所混淆。如果您碰巧有一个 OO 程序员，他是生产力 x 的组之一，而“程序”程序员是 10 倍程序员，那么即使 OO 在某种意义上更快，程序程序员也有可能获胜。
还有一个问题是，编码生产力通常只占实际项目总工作量的 10-20%，因此更高的生产力并没有太大影响；即使是假设的 10 倍程序员或无限快的程序员，也无法将整体工作量减少 10-20% 以上。
你可以看看 Fred Brooks 的论文“No Silver Bullet”。
于 2008-12-08T01:57:12.323 回答
6
面向对象或程序提供不同的开发方式，如果管理不善，两者都可能代价高昂。
如果我们假设在这两种情况下工作都是由最好的人完成的，我认为结果可能在成本方面是相等的。
我相信成本差异将取决于您将如何进入需要添加功能和修改当前功能的维护阶段。程序化项目更难进行自动测试，在不影响其他部分的情况下更难以扩展，并且更难逐部分理解概念（因为没有必要将内聚部分组合在一起）。
所以，我认为，从长远来看，与程序相比，OO 成本会更低。
于 2008-12-08T02:53:40.820 回答
6
在用谷歌搜索后，我在这里找到了这篇论文。我使用的搜索词是面向对象的生产力。
开头的段落继续说
面向对象技术的引入似乎不会阻碍新的大型商业项目的整体生产力，但在前两代产品中似乎也没有提高它。在实践中，主导影响可能是业务工作流程而不是方法论。
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.
于 2009-02-12T16:50:16.477 回答
5
我认为 S.Lott 指的是“不可重复的实验”现象，即你不能在程序上编写应用程序 X 然后倒回时间并编写它 OO 看看有什么区别。
你可以用两种不同的方式编写同一个应用程序两次，但是
- 你会学到一些关于应用程序的第一种方式，它会以第二种方式帮助你，并且
- 您可能在 OO 方面比在程序方面更好，反之亦然，这取决于您的经验以及应用程序的性质和所选择的工具
所以确实没有直接的比较依据
由于类似的原因——不同的应用程序、不同的团队等，实证研究同样无用。
范式转换很困难，一小部分程序员可能永远不会进行转换
如果您可以自由地开发自己的方式，那么解决方案很简单：以自己的方式开发事物，当您的同事注意到您正在围绕他们进行编码并且您的代码几乎没有经常中断时等等，他们会问您你是怎么做的，然后教他们 OOP（连同 TDD 和你可能使用的任何其他良好实践）
如果没有，那么，可能是时候润色简历了... ;-)
于 2008-12-02T02:33:56.497 回答
3
好主意。正面对比。以程序风格和 OO 风格编写应用程序 X 并测量一些东西。开发成本。投资回报。
用两种风格编写同一个应用程序是什么意思？这将是一个不同的应用程序，不是吗？当他们使用继承、消息传递或封装时，程序人员会拒绝 OO 人在作弊。
不可能有这样的比较。比较应用程序的两个“版本”是没有依据的。这就像问苹果或橙子作为水果是否更具成本效益。
话虽如此，您必须专注于其他人实际上可以看到的东西。
是时候建立一些有效的东西了。
错误和问题的比率。
如果你的方法更好，你就会成功，人们会想知道为什么。
当您解释 OO 会导致您的成功时……嗯……您已经赢得了争论。
于 2008-12-02T02:03:59.397 回答
2
关键是时间。公司需要多长时间才能更改设计以添加新功能或修复现有功能。你所做的任何研究都应该集中在那个领域。
我的公司在 90 年代中期为使用 VB3 创建的 CAM 软件进行了面向事件驱动的程序设计。使软件适应新机器需要很长时间。很长一段时间来测试错误修复和新功能的效果。
随着 VB6 的出现，我能够绘制出当前设计和解决测试和适配问题的新设计。非技术型的老板马上就明白了我在做什么。
关键是解释为什么 OOP 将使项目受益。使用 Fowler 的重构和设计模式之类的东西来展示新设计如何减少做事的时间。还包括您如何从 A 点到达 B 点。重构将有助于展示您如何拥有可以交付的工作中间阶段。
于 2008-12-02T13:36:01.077 回答
2
我不认为你会找到这样的研究。至少您应该定义“成本”的含义。因为 OOP 设计有点慢，所以短期内使用过程编程可能会更快。在很短的时间内，意大利面条编码可能会更快。
但是当项目开始增长时，情况恰恰相反，因为 OOP 设计最适合管理代码复杂性。
所以在一个小项目中，程序设计可能更便宜，因为它更快而且你没有缺点。但是在一个大项目中，你会很快得到坚持，只使用像过程编程这样的简单范例
于 2009-02-11T14:33:00.687 回答
1
我怀疑你会找到一个明确的研究。正如一些人所提到的，这不是一个可重复的实验。你会发现很多轶事证据。有些人可能会找到一些统计研究，但我会仔细检查它们。我不知道有什么非常好的。
我还要指出另一点，现实世界中不存在纯粹面向对象或纯粹过程的东西。许多（如果不是大多数）对象方法都是用过程代码编写的。同时，许多过程程序使用 OO 方法，例如封装（也有人称之为抽象）。
不要误会我的意思，OO 和程序程序看起来和不同，但它是深灰色与浅灰色而不是黑白的问题。
于 2009-02-11T14:12:45.103 回答