我有相当强的面向对象编程背景，对OOD和OOP的好处了然于心，但最近我发现自己所在的开发团队习惯于过程式编程。虽然实现语言具有一些面向对象的特征，但它们并没有被用于最优化的方式。
更新: 每个人似乎都有关于这个话题的观点，我也有自己的看法，但问题是：
是否有任何良好的比较研究来对比使用过程式编程语言和面向对象编程语言进行软件开发的成本？
一些评论者指出了将苹果与橙子进行比较的可疑性，我同意这种比较可能会非常困难，但并非完全不可能。
9个回答
12
大部分这些问题都会受到一个事实的干扰：程序员的个人生产力可能相差一两个数量级。如果你偶然拥有一个OO程序员，他的生产力是X，而一个“过程式”程序员的生产力是10X，即使在某种意义上OO更快，过程式程序员也可能获胜。
还有一个问题是，在现实项目中，编码生产率通常只占总工作量的10-20％，因此更高的生产率影响不大；即使是那个理论上的10倍速度或无限快的程序员，也不能将总工作量缩减超过10-20％。
您可以查看弗雷德·布鲁克斯（Fred Brooks）的论文 "No Silver Bullet"。
- Charlie Martin
6
面向对象编程和过程式编程都是不同的开发方式，如果管理不善，两者都可能代价高昂。
如果我们假设在两种情况下都由最好的人来完成工作，我认为成本方面的结果可能相等。
我认为成本差异将在于您如何进行维护阶段，在此阶段中，您需要添加功能并修改当前功能。过程式项目更难进行自动化测试，不太可能扩展而不影响其他部分，并且更难以逐个部分理解概念（因为连贯的部分未必被组合在一起）。
因此，我认为，从长远来看，面向对象的成本将比过程式的成本更低。
- Daok
1
我可以告诉你，我们店里几乎100%的工作都是维护工作...所以看起来面向对象编程会是一个不错的选择。 - oz10
6
在谷歌上搜索“Productivity object oriented”后，我找到了这篇文章（链接）。开头几段写道：“在新的大型商业项目中引入面向对象技术似乎不会阻碍总体生产力，但在前两代产品中也没有表现出提高生产力。实际上，主导影响可能是业务工作流程，而不是方法论。”
我认为你会发现，在特定情况下，面向对象编程更好，但对其他方面来说则是中性的。我的老板们同意将我们公司的CAD/CAM应用程序转换为面向对象框架的原因是我明确地展示了它将在哪些方面有所帮助。重点不是整个方法论，而是如何解决我们遇到的具体问题。对我们来说，重要的是拥有可扩展的框架，以添加更多形状、报告和机器控制器，并使用集合来消除旧设计的内存限制。
我认为你会发现，在特定情况下，面向对象编程更好，但对其他方面来说则是中性的。我的老板们同意将我们公司的CAD/CAM应用程序转换为面向对象框架的原因是我明确地展示了它将在哪些方面有所帮助。重点不是整个方法论，而是如何解决我们遇到的具体问题。对我们来说，重要的是拥有可扩展的框架，以添加更多形状、报告和机器控制器，并使用集合来消除旧设计的内存限制。
- RS Conley
3
你知道这篇论文是否已经发表了吗？ - oz10
在浏览该网站时，我发现了一份PDF文件，并附有以下注释：发表于1999年《软件-实践与经验》杂志第29卷第10期，页码为833-847。 - RS Conley
Booch的架构书报告了类似的结果，但在完成前两个项目后，团队变得经验丰富，进一步节省了成本和时间，如果能够在过程中开发出重要的可复用架构，则可以获得更多的收益。 - Steven A. Lowe
5
我认为S.Lott指的是“不可重复实验”的现象，即你不能先以过程方式编写应用程序X，然后倒回时间并以面向对象方式编写它，以查看差异。虽然你可以用两种不同的方式编写相同的应用程序，但是第一种方式会让你对应用程序有更深刻的了解，并且取决于你的经验、应用程序的性质和所选择的工具，你可能会更擅长于面向对象或过程化编程。
因此，真正的比较基础是不存在的。经验研究同样无用，原因类似——不同的应用程序、不同的团队等等。范式转变很困难，只有少数程序员可能永远无法进行转变。
如果你有自由发展的空间，那么解决方案就很简单：按照自己的方式开发，当你的同事注意到你比他们编码得更好，代码几乎不会出错等等，并询问你如何做到时，再教他们面向对象编程（连同TDD和任何其他好的实践）。
如果没有这种自由，嗯，也许是时候更新简历了……;-)
因此，真正的比较基础是不存在的。经验研究同样无用，原因类似——不同的应用程序、不同的团队等等。范式转变很困难，只有少数程序员可能永远无法进行转变。
如果你有自由发展的空间，那么解决方案就很简单：按照自己的方式开发，当你的同事注意到你比他们编码得更好，代码几乎不会出错等等，并询问你如何做到时，再教他们面向对象编程（连同TDD和任何其他好的实践）。
如果没有这种自由，嗯，也许是时候更新简历了……;-)
- Steven A. Lowe
5
两条评论。（1）顺便说一句，我认为称S.Lott是在提到这种现象有些牵强。谢谢你在这里指出这个现象。我已经忘记了它...但我真的想知道是否有人进行了非科学研究。肯定有一些软件公司已经做过转换并注意到了成本吧？ - oz10
这是我第一份“专业”的编程工作，我拥有计算机科学硕士学位，并自幼从事编程... 经过数月的寻找，这是我唯一得到的软件开发工作机会。 - oz10
@ceretullis：继续寻找，同时尝试融入吧；-) - Steven A. Lowe
@ceretullis：确实，我指的是软件实验总是可疑的，因为它们无法具有可重复的控制。软件开发是知识的捕获；它是最糟糕的不可重复和不可控的现象。 - S.Lott
@[S.Lott]：我会说这是“最糟糕的一种”，我认为最糟糕的是“幻想”类型，比如“如果我在那里为他们加油，我的团队就会赢了”;-) - Steven A. Lowe
3
好主意。进行一次逐项比较。在过程式风格和面向对象风格下编写应用程序X，并测量某些内容。开发成本。投资回报率。
同样的应用程序采用两种风格是什么意思？它将成为一个不同的应用程序，不是吗？过程式编程的人会反对面向对象的人在使用继承、消息传递或封装时作弊。
这样的比较是不可能的。没有比较两个“版本”应用程序的基础。这就像问苹果和橙子哪种水果更具成本效益一样。
话虽如此，你必须关注其他人实际能看到的事情。
构建可工作应用程序所需时间。
错误和问题的率。
如果你的方法更好，那么你就会成功，而且人们会想知道为什么。
当你解释面向对象导致你的成功时……嗯……你已经赢了。
- S.Lott
14
谢谢评论。我不确定这是在比较两个不同的事物。这就像说我不能比较两种不同的滑雪跳跃技术...虽然这可以做到...尽管这有相同的问题，因为它取决于各自风格中从业者的相对技能水平。 - oz10
不同意：不喜欢滑雪跳台。除非你摔倒，否则很难有客观的区别。大部分得分都是评判“风格”。而且每个人着陆的位置都在几米之内。我想说的是，这就像比较滑雪跳台和水肺潜水一样，相似之处太少了。 - S.Lott
实现任务所需的打字量（包括重新输入和计算退格键次数）对我来说看起来是捕捉在开发软件时引入变更的易用性（和必要性！）的好方法，这些变更可能包括由于合同变更而重新实现某些“组件”，重构它们甚至扔掉一些。也就是说，如果完成相同任务所需的打字量较少，则一种方法论比另一种更有效的“编码策略”（在某种意义上），并且这种知识可能很有用。 - mlvljr
我的观点是关于实现的努力，而不是代码本身。但真正的大师们当然更喜欢游艇 :)) - mlvljr
@S.Lott（1）如果有/将会有足够实用的方法来提供任何实质性的有益见解（对于面向对象/过程化/其他比较），那就可以了（至少最初是这样）。 （2）重新输入工作比心理工作要容易得多（并且更容易研究！），然而前者的变化/添加反映了后者的转变（至少是实质性的转变）。一个问题是，当选择一个项目的方法论时，是否任何以代码为基础的度量标准都足够有帮助。 - mlvljr
显示剩余9条评论
2
重点在于时间。公司需要多长时间来改变设计以添加新功能或修复现有问题。您进行的任何研究都应该集中在这个领域。
90年代中期，我们公司使用VB3创建了一种用于CAM软件的事件驱动过程式设计。但当适应新机器时需要花费很长时间，测试错误修复和新功能的效果也需要很长时间。
随着VB6的出现，我能够绘制当前设计和一个新设计，解决了测试和适应性的问题。非技术老板立即理解我的意图。
关键是解释为什么面向对象编程(OOP)会有利于项目。使用像Fowler的重构和设计模式之类的工具来展示如何通过新的设计来降低完成任务所需的时间。还要包括如何从A点到B点的过程。重构有助于显示如何拥有可运行的中间阶段，并可进行发布。
90年代中期，我们公司使用VB3创建了一种用于CAM软件的事件驱动过程式设计。但当适应新机器时需要花费很长时间，测试错误修复和新功能的效果也需要很长时间。
随着VB6的出现，我能够绘制当前设计和一个新设计，解决了测试和适应性的问题。非技术老板立即理解我的意图。
关键是解释为什么面向对象编程(OOP)会有利于项目。使用像Fowler的重构和设计模式之类的工具来展示如何通过新的设计来降低完成任务所需的时间。还要包括如何从A点到B点的过程。重构有助于显示如何拥有可运行的中间阶段，并可进行发布。
- RS Conley
2
我认为你不会找到这样的研究。至少你应该定义一下“成本”的含义。因为面向对象（OOP）设计有点慢，所以在短期内，使用过程式编程开发可能更快。甚至在非常短的时间内，混乱的编码方式可能更快。
但是，当项目开始变得复杂时，情况就相反了，因为OOP设计最适合管理代码复杂性。
因此，在小型项目中，也许过程式设计可能更便宜，因为它更快速，而且没有缺点。但是在大型项目中，仅使用简单的范例，如过程式编程，你很快就会陷入困境。
- happy_emi
1
随着时间的推移成本将是一个合适的指标。我指的是成本的字面定义，也就是为完成任务所需支付的开销。 - oz10
1
我怀疑你会找不到一个明确的研究。正如几个人提到的，这不是一个可重复的实验。你会发现大量的轶事证据。有些人可能会找到一些统计研究，但我建议你仔细审查它们。我不知道是否有真正好的研究。
我还想再强调一点，在现实世界中并不存在纯面向对象或纯过程化的程序。许多面向对象的方法都是用过程化代码编写的。同时，许多过程化程序使用面向对象的方法，例如封装（也被一些人称为抽象）。
不要误解我的意思，面向对象和过程化程序看起来和表现出来是不同的，但这只是黑色和白色之间的深灰色和浅灰色的区别。
- Jim C
1
我同意你的评论，认为C++并不是纯面向对象的语言。在面向对象设计中，有一种思维方式鼓励更有意义的封装和抽象，这种方式比过程式代码中通常看到的更加重要。 - oz10
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接