Possible Duplicate:
Classes. Whats the point?
我已经阅读了大量的教程，编写了很多类，并使用了它们，但我仍然无法弄清楚一些 OOP 点。
我的意思是，我想我已经掌握了理论。这是一种范式，一种思考和解决问题的不同方式。我知道所有的共同点:代码重用、封装、更好的错误处理、更容易维护、继承、按契约设计、更好的文档、聚合、组合、一些设计模式……
也就是说，让我们开始真正的交易。假设我有以下内容:
- 一个数据库，以及一个访问和查询它的类。
- 我有一个名为 person 的表和另一个名为 address 的表
- 简单的业务规则:一个人可以有一个或多个地址(家庭、工作、送货...)，简单的一对多关系
- 我有一个用于公共(public)操作 (CRUD) 的高级类(class)。每个表都有一个类，是这个表的扩展。
- 当然，每个类(人和地址)都有自己的方法:例如，getAddressByLocation 或 getPersonsByAge。
- 还有十几个 View 和几个表单
所有这些都很棒而且肯定有用，但是......我无法停止思考最简单的情况:列出一些人。是的，因为输出表中的每一行都基于一个类实例。我无法停止思考在未使用的资源上使用了多少内存和 CPU。
列出 50 个人意味着创建 50 个实例，其中充满资源，如 crud、过滤处理上传、验证规则等，而我需要的是运行查询并仅通过一个简单的循环输出结果。
这让我很困惑。而不仅仅是混淆，因为我已经看到一些应用程序，当业务规则稍微复杂一些时，运行时间随数据库呈指数级增长。
我认为，是否需要创建新类或纯脚本来处理输出和报告？如果是的话，那么这意味着双重努力，使用 OOP 毫无意义，一旦我需要为同一个数据库实体创建许多不同的类。编码变得更难，维护变得不酷。
我错过了什么吗？或者这是 OOP 方法的缺点？
我们是否应该牺牲直截了当的、精简的、更快的代码以获得更快的开发和维护？
编辑
不出所料，我之前提出的一些观点对某些人产生了误导......
首先，我对非常非常大的项目经验丰富(我曾在 IBM 为 Sprint/Nextel USA 和 Directv North America 供应商工作，所以我习惯于每天处理一些 TB 的数据)。
当我说从数据库中检索 50 个人时，我并不是严格意义上的 50 个人，我只是想表达很多记录的意思。我知道 50 条记录对今天的服务器来说不算什么。 5000万。如果合适的话，想象一下最后一个数字。
最佳答案
这就是问题的症结所在。如前所述，每种范例都需要权衡取舍。 OOP 有很多好处，但正如您所指出的，它也有一些负面影响。关键是权衡它们。
OOP 建立在开发人员昂贵而硬件便宜的原则之上。它使用此原则导致高度可维护(从长远来看易于修复)和高度适应性强的代码(从长远来看易于更改)。如果您购买 60/60 Rule (也就是说 60% 的开发时间用于维护，60% 的时间用于增强)那么可维护性就是专业编程的最终目标。
如果您了解 OOP 的工作原理(我说的是您在 OOP 范例中的思考点)，一切都会变得非常简单。我认为您仍然感到困惑，因为您没有完全理解 OOP。但话又说回来，它也不是编程的 chalice ，所以如果你更习惯使用另一种范式，一定要使用它。选择之所以存在，是因为我们并不完全相同。使用你最擅长的和最适合你最想做的事情。如果您拥有的唯一工具是锤子，那么每个问题看起来都像钉子...
哦，与流行观点相反，OOP 不是关于永远不要对任何东西进行两次编码。这就是 DRY(不要重复自己)原则。虽然它经常与 OOP 一起使用，但它并不直接附加到。事实上，我建议在开发时不要遵循 DRY 作为规则。把它作为一个目标来争取，但让它成为一个指导方针而不是一条规则。正如 Fred Brooks 所说，计划扔掉一个；无论如何，你会的。(来自 The Mythical Man-Month )。如果你严格地从不重复自己，当你需要扔掉你第一次没有做对的东西时，你最终会重新做很多工作。只有当它构建好并运行良好时，你才应该开始精简它并真正让代码变干。 (至少个人意见)...
关于php - 为什么我看不到使用 OOP 的真正意义？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4471387/