这出现在我在网上的一次对话中，我发现我不知道这应该如何工作：相当多的程序员似乎只是作为一个给定的 - 事实上，很明显，类是管理大型软件项目的必要语言功能。
我不明白他们是如何做到这一点的。
我的问题是，你怎么知道的？哪些客观测量表明类可以提高生产力，重用代码并降低程序生产的复杂性？课程的哪些方面使其成为大型团队合作的理想选择？
现在，我想问一个问题，这有点难以表达。如果我弄错了，最后会让任何人感到困惑或愤怒，我很抱歉：
客观地说，您如何知道类的使用不是应用程序开始时的原因？也就是说，是否有可能使用其他代码重用策略编写具有相同功能的程序，代码少得多，小到不需要任何特殊措施来“管理”它？ （有许多选择，例如函数式编程范例或面向方面编程）。
最后一点是Steve Yegge在他的博客上暗示的东西。但我对这一论点的双方都持怀疑态度，因为任何人都缺乏任何硬数据，而且没有足够的经验可以自己得出结论。
您怎么看？
编辑：特别是我感兴趣的是为什么许多程序员认为原型样式继承在大型应用程序方面不能胜任任务。我很抱歉这个问题含糊不清 - 这是我对这个话题缺乏了解的结果。
edit2：似乎对函数式编程的含义感到困惑。 （我认为任何版本的VB都不具备功能，当然不是旧版本）。请参阅维基百科文章。 http://en.wikipedia.org/wiki/Functional_programming
edit3：让我强调一下，我正在寻找客观的措施。不是主观意见。
答案 0 :(得分：6)
这是一个非常好的问题。将代码组织到类中是开发团队创建小型可重用模块的一种方式。此外，这些模块具有富有表现力和有限的界面，仅表达了该类的功能，而不表示它是如何实现的。每个类都与其他类正交，因此在出错时可高度测试和模块化。
现在我刚才描述的是一个完美世界的奇怪场景。但任何做OOP工作的优秀开发人员都应该努力做到这一点。
OOP是对我们开发人员只是人类并且不能同时理解整个系统的承认。因此，我们将系统分解为微小的可重用部分并专注于那些。
以一个十位数的美国电话号码为例。很难记住你头上的十位数字，所以我们做了心理学家所说的“分块”。这意味着我们在精神上将这些数字分解成我们可以更好地记住的块。
因此1234567890变为123-456-7890。对我们来说幸运的是，电话公司也以同样的方式打破这些数字并分配块的含义。 123是区号，456是前缀，7890是行号。这些块中的每一个都像一个类，它们都有各自的职责，格式和含义。
总而言之，我能说的最好的事情是OOP允许我们构建具有集中和封装功能的大型可扩展系统。它使我们不必一直看到大局，并能够专注于做一件事并做得好。
答案 1 :(得分：2)
对于任何编程范式来说，我绝不是一个偏见，但我已经在OO风格中运作了一段时间。
就个人而言，我有很多'a-HA！'课程直接帮助我理解我正在更好地工作的领域。
最值得注意的是，如果对系统出现故障的原因或系统应该做什么感到困惑，那么课程往往迫使我思考整个系统应该做什么，而且经常而不是导致重构手头的类/方法。
简而言之，封装真的让我更快乐。 ;）
希望有所帮助。
答案 2 :(得分：2)
我认为课程可以提供帮助，因为它们符合categorization的一般认知概念，因此可以帮助自然地描述大型应用程序。
答案 3 :(得分：2)
封装理论提供了一个客观原因，即为什么类比没有类更好。
国际标准化组织将封装定义为“只有通过对象支持的接口上的交互才能访问对象中包含的信息的属性。”
因此，由于某些信息可通过这些接口访问，因此某些信息必须隐藏在对象内且无法访问。这些信息展示的属性被称为信息隐藏，Parnas认为模块应该被设计为隐藏可能发生变化的困难决策和决策。
请注意：改变。信息隐藏涉及潜在事件，例如将来更改困难的设计决策。
考虑一个有两个方法的类：方法a（），它是隐藏在类中的信息，方法b（）是公共的，因此可以直接由其他类访问。
对方法a（）的未来更改有可能需要更改其他类中的方法。未来对方法b（）的更改也有可能需要更改其他类中的方法。然而，方法a（）发生这种波纹变化的概率通常会低于方法b（）的波动，因为方法b（）可能依赖于更多的类。
这种降低的纹波影响概率是封装的一个关键优势。
在任何程序中考虑源代码依赖性的最大潜在数量（MPE - 首字母缩略词来自图论）。从上面的定义推断，我们可以说，鉴于两个程序向用户提供相同的功能，具有最低MPE的程序被更好地封装，并且从统计上来说，更好的封装程序将更便宜地维护和开发，因为成本对它的最大潜在变化将低于封装较少的系统的最大潜在变化。
此外，考虑一种只使用方法而没有类的语言，因此没有彼此信息隐藏方法的方法。假设我们的程序有1000种方法。这个计划的MPE是什么？
封装理论告诉我们，给定n个公共节点的系统，该系统的MPE为n（n-1）。因此，我们的1000种公共方法的MPE是999,000。
现在让我们将systém分成两个类，每个类有500个方法。由于我们现在有类，我们可以选择公开一些方法，私有一些方法。除非每个方法实际上都依赖于其他所有方法（这是不可能的），否则就是这种情况。假设每个类中有50种方法是公开的。系统的MPE会是什么？
封装理论告诉我们：n（（n / r）-1 +（r-1）p）其中r是类的数量，p是每个类的公共方法的数量。这将使我们的两级系统的MPE达到499,000。因此，这个两级系统的最大潜在成本已经大大低于未封装系统的成本。
假设您将系统分为3个类，每个类有333个类（好的，一个将有334个），并且每个类都有50个公共方法。什么是MPE？再次使用上述等式，MPE约为482,000。
如果系统分为4类，每组250个方法，则MPE将为449,000。
如果看起来增加我们系统中的类数量总会降低其MPE，但事实并非如此。封装理论表明，应该将系统分解为最小化MPE的类的数量是：r = sqrt（n / p），对于我们的系统实际上是4.例如，具有6个类的系统将具有MPE 465,666。
答案 4 :(得分：1)
我更喜欢上课，这样我就可以把一个大问题分成可以作为单个单元测试的可管理部分。恕我直言，代码重用被高估 - 我几乎没有看到它发生在我工作的地方。对我而言，我从优秀的OO中获得的最大好处是可测试性。
另一个极端是使用一堆全局变量并在public static void main（或ASP.NET中的Page_Load）中阻塞所有逻辑，并调用调用其他静态方法的静态方法，依此类推。 ..（在最后一句话的结尾我感到头晕。）
唯一能打破我的OO心态的是，如果我正在使用一种纯粹的功能语言，这是我从大学开始就没有想过的事情。
答案 5 :(得分：1)
通过使一个简单的问题变得不必要地复杂化（OO一直向下），可能会过度设计。但是，对于任何足够大的问题，我认为OO范式很可能不会导致它首先变大。以一个操作系统为例，如果它不是以面向对象的方式编写的话，很难想象它很容易维护（代码方面）。
答案 6 :(得分：1)
如果在大型应用程序中有一堆“裸”函数，则很难对这些函数进行更改。
如果将函数包装在类中，则有助于隔离代码的范围。这不是一个神奇的子弹，但它有所帮助。
答案 7 :(得分：0)
两件事。
第一个是类是不透明域实体的想法。 如果正确完成，面向对象的程序会引入一个抽象层：在下一个最高层，您可以编组对象以执行您想要的操作，而不是处理细节。您不需要知道对象和类如何工作：只需要知道它们的作用。这是一种信息隐藏，它降低了团队在工作时必须保持头脑的复杂性。
第二个是OO编程允许一种代码重用：你可以定义覆盖其他类（继承）中某些行为的类，或者其实例包含其他类的实例的类，使用它们来实现它们的目标（封装）和组成）。
正确使用OO技术可以减少您需要管理的代码量，并减少在您工作或维护系统时需要记住的事项数量。在实践中，这种方法并不总是有效。
答案 8 :(得分：0)
客观地说，你怎么知道的 使用类不是原因 应用程序开始时很大？
使用非OO语言编写的任何大型程序/应用程序（例如C，COBOL，甚至是纯SQL），您应该能够看到代码大小不直接归因于语言范例。对于每一个精心设计，高度精炼，可重用的C＃或Java组件，还有相同数量的精心设计，高度精炼，可重用的C DLL。相反，有相同数量的可怕，臃肿的代码。
关键是，优秀的程序员无论语言/平台如何都能够优化他们的系统设计。
关于OOP，至少对我来说，它带来了一个“潜力” - 一个关于编程世界的视图 abit close close 到我们的现实世界。我们都知道我们的世界，这个物质世界充满了由较小的物体组成的物体。从恒星系统一直到分子，原子和亚原子粒子一直保持放大，真正令人惊讶的是，不同物质是由不同图案组合的相同微小颗粒组成的。甚至看看我们自己的生物学，有时候认为我们60％的身体实际上只是水，当它被分解成最好的时候是令人难以置信的。然而，看看所有用化学物质燃烧的各种系统和器官，让我们保持活力和活力。
当我们学会理解构成我们在日常生活中看到的真实世界系统的构造块的简单性（哦，真的......哈哈）时，我们应该能够理解设计和构建极其复杂或复杂的系统应该从小部件开始，这些部件本身很少。通过将它们慢慢组合并将它们组合成更大的组件，我们可以获得更多的功能和能力。直到我们达到我们想象的所需系统。
（正确）使用类是将系统分解为最好的。尽可能。这样你就可以一次看一些东西和一个特定的抽象层次，而不会被不涉及你目前关注领域的目的和逻辑所淹没。无论何时设计系统，都要考虑自己的解剖结构;想想如何你会设计人体。无论何时设计系统，都要考虑创办新公司;什么是主要部门，即运营业务所需的部门。谁是运营这些部门所需的员工类型。他们需要使用和互动的各种设备来完成他们的工作。你如何将业务运营分解为最好的，让自己更好地理解它？
当你理解一些物体只是由较小物体组成的基本原理时，你就会开始创造高度可重复使用的细胞或分子。
答案 9 :(得分：0)
在我可以同时处理复杂项目的一个小方面的方面，类对我来说最有帮助。能够将代码的一个方面与大型项目分离是非常有帮助的，因此您不会感到不知所措。最后，这些类之间的凝聚力可以让您快速了解程序如何工作而无需处理内部。
就可维护性而言，在我看来，查看UML类图并找出所有内容的布局比查看函数列表要容易得多。
答案 10 :(得分：0)
我认为通过说课程，你应该指对象。类只是放置对象的地方。 OOP范式之所以如此成功是有原因的。一旦你有'啊哈！'当你认为自己终于理解了OOP的概念时，你可以以更有条理的方式开始编程。
我已经在Visual Basic 3中编程了很长时间，因此我在函数式编程方面有很多经验，然后进入VB5并发现对象是一个巨大的解脱，因为我可以将真实世界的实体与我的代码相关联，它帮了很大忙。
这就是它的全部要点，在代码中重新创建真实世界的实体。它使阅读和工作变得更容易，因为你可以拿起东西并用它做东西，或者做些东西。