我一直在研究不同的编程方法：Scrum，瀑布，螺旋，但有人讲述了一个名为面向对象的方法。现在据我所知，这是一种范式，而不是一种方法论。
如果是方法论，有人可以解释它与敏捷或瀑布的区别吗？
答案 0 :(得分：10)
好吧，谷歌发现了一些beast的痕迹，这清楚地描述了类似方法论的事情：
本文档旨在向读者简要介绍面向对象方法（OOM）。文件中涉及的信息包括OOM的简要概述，其优点，过程以及OOM中的一些主要技术。
OOM是一种新的系统开发方法，可以促进和促进软件组件的重复使用。利用这种方法，可以在组件的基础上开发计算机系统，其能够有效地重用现有组件并促进其他系统共享其组件。通过采用OOM，可以实现更高的生产率，更低的维护成本和更高的质量。
该方法采用来自对象管理组（OMG）的国际标准统一建模语言（UML）。 UML是面向对象分析和设计的建模标准，已在IT行业中广泛采用。
OOM生命周期包括六个阶段。这些阶段是业务规划阶段，业务体系结构定义阶段，技术体系结构定义阶段，增量交付规划阶段，增量设计和构建阶段以及部署阶段。
但这件事并没有（很可能）蔓延到很远的地方。也许您应该向您的联系人询问一些参考资料。
答案 1 :(得分：5)
面向对象编程是一种在编写代码时使用的编程技术。这与规划，管理和实施软件项目的方法不同。
请参阅：http://en.wikipedia.org/wiki/Object-oriented_programming
答案 2 :(得分：3)
苹果和橘子。 OO是一种设计代码的方法。 Scrum /瀑布/螺旋等等......关于你如何管理项目。他们彼此独立。
那就是说，你真的应该看看OO。
答案 3 :(得分：2)
在20世纪80年代末和90年代初期，一些作者发表了作品（尤其是书籍），其中包括标题和简介，其中包括“方法”或“方法论”;这些工作侧重于面向对象的建模方法，详细解释了人们应该用来构建系统的结构和动态模型的建模原语（元模型）。然而，他们对过程的处理是微乎其微的。后来，他们被应用“方法论”一词批评。
如今，“方法论”通常被认为至少包括流程方面，建模（或产品）方面和人员方面。基于上世纪80年代至20世纪90年代作品传统的现代方法通常被称为“面向对象”，因为当时使用的建模方法实际上是面向对象的。
实际上，根据所述方法的建模方面，研究界的一个争议话题是，方法的过程方面是否有很大不同。例如，面向对象方法的流程方面是否与面向代理的流程方面有很大不同？如果你认为不是，那么“面向对象的方法论”这个词对你来说可能毫无意义。
答案 4 :(得分：1)
面向对象是一种完整的迭代方法，每个阶段用于验证或暴露前面的漏洞。它涵盖了从识别所有利益相关者，从中获取需求的所有内容，记录用例中的要求（不是原始OO方法的一部分，但在Jacobsen在他的Objectory中合并的Rational＆amp; UML中加入Booch＆amp; Rumbaugh时采用）的所有内容。一旦使用基于文本的用例文档验证了需求，利益相关者就可以理解这些需求。分析仍处于业务问题空间，而不是软件解决方案领域。 Architechure＆amp;系统级设计是为已识别的业务需求创建解决方案空间的第一步。然后可以分解任务，并通过最初在Analysis期间创建并在UML案例/对象图中的系统设计中进行细化的案例层次实现设计的低级设计和编程最终传递给编码人员。 OOADP中的一条严格的规则是，在允许开始编码之前，分析和设计工件是基线的。业务或营销部门在编码期间所需的任何变更必须提交给由开发主导的变更控制委员会。他们将优先考虑所请求的更改，评估它们对规范类层次结构和分布式设计的影响，确定每个更改将带来多少额外时间，金钱和资源，然后返回到业务＆amp;营销人员并说 - ＆＃34;这是时间，金钱和资源的成本。你愿意接受这笔费用吗？＆＃34;如果不是，则可以丢弃更改或将其移至下一版本。当您设计一个企业级项目时，您只能真正获得创建其类层次结构骨架的机会。稍后您尝试修改系统并且必须修改类和依赖项，您更有可能产生额外费用，时间延迟，需求需求和错误。在以前经过回归测试的地区经常会出现细微的错误。
敏捷人过去曾轻蔑地将完整的OOADP方法称为＆＃34; BDUF＆＃34; （前面的大设计）。 Scrum旨在与此相反，有5个或6个程序员团队只与一个负责业务/客户需求的产品负责人合作，并且只知道所有需求的钥匙孔视图，偶尔会引入其他中小企业，因为她识别出需要或差距。任务被写成＆＃34;故事＆＃34; （这有点简化 - 它们可以是几种形式的要求或要求变更中的任何一种），并且一次只能处理一小组，目的是在每个小组结束时完成2或者3周＆＃34; sprint。＆＃34;将未完成的任务放回到积压的故事中，进行分析以确定该团队负责的项目的状态，并将剩余的一些故事传递给下一个sprint。商业＆amp;营销LOVE Agile和HATED O-O一样多，因为他们可以在开发阶段结束时插入新的或改变的故事或用例或其他形式的要求。最终产品不断变化，以满足商业和业务需求。营销看到快速转变的需求和时间窗口（通常是歇斯底里夸大）。当你将一个项目扩展到一个以上的Scrum团队时引起的各种小烟囱都是使用Scrums Scrums定期处理的，Scrum Master团队聚集在一起并试图让每个团队保持在同一轨道并确定是否有任何团队有阻止其他团队进展的积压项目。项目越大，协调所有这些团队的官僚机构就越多，每个团队都会随着故事的更新或新增的故事而巧妙地改变他们的原始职责。
自从最初的CRC卡和Wirf-Brock改进以及今天的UML迭代以来，我一直与O-O合作。我甚至花了几年时间作为贝尔实验室四人团队的一员，将O-O和C ++教授给AT＆amp; T开发团队。我也和Agile合作过（主要是Scrum和ScrumBan，Scrum和日本看板的合并）。我从1998年开始使用Agile Scrum，之后才有官方标准。敏捷只是一种部分方法，因此每个项目都必须找到其他工具或方法来填补空白。如果团队不是由一级ScrumMaster和所有专家开发人员组成，并且彼此进行交叉训练，那么我发现事情变得非常丑陋。技能。今天的公司已经把利率做得如此之低，以至于我在15或20年前工作过的大多数真正有天赋的程序员都在为生活而做其他事情。让他们的编码jollies在移动应用程序或开源项目上工作。你很少看到一支真正有才华的球队。公司雇用的人没有必要的10x＆＃34;摇滚明星＆＃34;某些角色的技能，Scrum团队的人员配备不规律。此外，您尝试为更大的项目扩展Scrum越多，结果就越成问题，部门开始放弃规范的Scrum规则越多，寻找一些效果更好的混合。
敏捷正如其早期的支持者首先所说的那样，非常适合进行维护，增强和较小的非时间盒项目，并且我已经非常有效地使用它。然而，对于一个公司企业项目而言，这不是由营销人员和商人的变幻无常的驱使，他们对外部市场的需求或时间窗口的微小变化感到歇斯底里，我每次都会采取OO每当我在同一组要求中提供具有面向对象和敏捷的合同机会时，我就会以另一种方式运行。
答案 5 :(得分：0)
当天人们认为面向对象编程将解决世界饥饿问题。我怀疑现在敏捷就会这样做，他们把它们混在一起： - ）
尽管如此，虽然有些人将面向对象的设计转变为设计方法的地位 - 但确定了演员和演员。以正式方式开发设计的行为，实际上是一套关于如何设计软件的原则。它当然不是管理Scrum和敏捷等软件项目开发的方法论。