我有相当强的面向对象编程背景,对OOD和OOP的好处了然于心,但最近我发现自己所在的开发团队习惯于过程式编程。虽然实现语言具有一些面向对象的特征,但它们并没有被用于最优化的方式。
更新: 每个人似乎都有关于这个话题的观点,我也有自己的看法,但问题是:
是否有任何良好的比较研究来对比使用过程式编程语言和面向对象编程语言进行软件开发的成本?
一些评论者指出了将苹果与橙子进行比较的可疑性,我同意这种比较可能会非常困难,但并非完全不可能。
我有相当强的面向对象编程背景,对OOD和OOP的好处了然于心,但最近我发现自己所在的开发团队习惯于过程式编程。虽然实现语言具有一些面向对象的特征,但它们并没有被用于最优化的方式。
更新: 每个人似乎都有关于这个话题的观点,我也有自己的看法,但问题是:
是否有任何良好的比较研究来对比使用过程式编程语言和面向对象编程语言进行软件开发的成本?
一些评论者指出了将苹果与橙子进行比较的可疑性,我同意这种比较可能会非常困难,但并非完全不可能。
大部分这些问题都会受到一个事实的干扰:程序员的个人生产力可能相差一两个数量级。如果你偶然拥有一个OO程序员,他的生产力是X,而一个“过程式”程序员的生产力是10X,即使在某种意义上OO更快,过程式程序员也可能获胜。
还有一个问题是,在现实项目中,编码生产率通常只占总工作量的10-20%,因此更高的生产率影响不大;即使是那个理论上的10倍速度或无限快的程序员,也不能将总工作量缩减超过10-20%。
您可以查看弗雷德·布鲁克斯(Fred Brooks)的论文 "No Silver Bullet"。
面向对象编程和过程式编程都是不同的开发方式,如果管理不善,两者都可能代价高昂。
如果我们假设在两种情况下都由最好的人来完成工作,我认为成本方面的结果可能相等。
我认为成本差异将在于您如何进行维护阶段,在此阶段中,您需要添加功能并修改当前功能。过程式项目更难进行自动化测试,不太可能扩展而不影响其他部分,并且更难以逐个部分理解概念(因为连贯的部分未必被组合在一起)。
因此,我认为,从长远来看,面向对象的成本将比过程式的成本更低。
好主意。进行一次逐项比较。在过程式风格和面向对象风格下编写应用程序X,并测量某些内容。开发成本。投资回报率。
同样的应用程序采用两种风格是什么意思?它将成为一个不同的应用程序,不是吗?过程式编程的人会反对面向对象的人在使用继承、消息传递或封装时作弊。
这样的比较是不可能的。没有比较两个“版本”应用程序的基础。这就像问苹果和橙子哪种水果更具成本效益一样。
话虽如此,你必须关注其他人实际能看到的事情。
构建可工作应用程序所需时间。
错误和问题的率。
如果你的方法更好,那么你就会成功,而且人们会想知道为什么。
当你解释面向对象导致你的成功时……嗯……你已经赢了。
我认为你不会找到这样的研究。至少你应该定义一下“成本”的含义。因为面向对象(OOP)设计有点慢,所以在短期内,使用过程式编程开发可能更快。甚至在非常短的时间内,混乱的编码方式可能更快。
但是,当项目开始变得复杂时,情况就相反了,因为OOP设计最适合管理代码复杂性。
因此,在小型项目中,也许过程式设计可能更便宜,因为它更快速,而且没有缺点。但是在大型项目中,仅使用简单的范例,如过程式编程,你很快就会陷入困境。
我怀疑你会找不到一个明确的研究。正如几个人提到的,这不是一个可重复的实验。你会发现大量的轶事证据。有些人可能会找到一些统计研究,但我建议你仔细审查它们。我不知道是否有真正好的研究。
我还想再强调一点,在现实世界中并不存在纯面向对象或纯过程化的程序。许多面向对象的方法都是用过程化代码编写的。同时,许多过程化程序使用面向对象的方法,例如封装(也被一些人称为抽象)。
不要误解我的意思,面向对象和过程化程序看起来和表现出来是不同的,但这只是黑色和白色之间的深灰色和浅灰色的区别。