PHP中的面向对象编程 - 某些方面对于应用程序来说是否过分？答案

【问题标题】：Object-oriented programming in PHP - are SOME aspects overkill for an application?PHP中的面向对象编程 - 某些方面对于应用程序来说是否过分？
【发布时间】：2015-12-31 23:26:23
【问题描述】：

我最近一直在阅读和深入研究 OOP 中的理论，但似乎总是有一个问题出现在我面前。

似乎一些概念，例如抽象类、接口以及在较小程度上的可见性，与其他人将扩展您的代码的情况有更多关系...

例如，假设我正在为一家小公司制作一个简单的CRUD 应用程序来存储客户信息、联系信息、订单等。应用程序的大小可能需要 OOP 架构，但我从偏移量知道没有其他人会扩展此代码，并且一旦我完成它，它将是一个“封闭”项目。因此，似乎为未来做好准备，并通过抽象类、接口创建这些保护和契约可能是矫枉过正？这看起来准确吗？

话虽如此，我始终坚持正确、彻底地做事。而且我也明白，OOP 的主要目的之一是为了未来的可维护性和可扩展性。有时，我只是很难将自己的注意力集中在接口和抽象类上，我觉得这是因为我所做的较小的项目很少涉及其他人扩展代码或创建 API 等。

【问题讨论】：

这比其他任何事情都更符合您的利益。当你不得不回去维护它的时候，你想让事情井井有条、简单吗？
真的，我明白了。但我想我不太确定在处理小型应用程序时接口和抽象类如何发挥作用

标签： php oop

【解决方案1】：

应用程序的大小可能需要 OOP 架构，但我从偏移量中知道没有其他人会扩展此代码，并且一旦我完成它，它将是一个“封闭”项目。因此，似乎为未来做好准备，并通过抽象类、接口创建这些保护和契约可能是矫枉过正？这看起来准确吗？

嗯，简而言之，这是不准确的。如果您出于某种原因编写代码，则很有可能需要对其进行维护。遵循良好的 OOP 实践将使将来更容易调试问题。但这不是 OOP 的关键所在。

正如您所指出的，OOP 范式的真正好处在于未来的修改。从the 60/60 rule，我们知道项目成本的 60% 是在交付之后产生的。其中 60% 的成本来自规范的更改。这就是为什么你应该做“所有这些工作”。

当然，对于某些项目，这完全是矫枉过正。但关键是，您真正知道它是否矫枉过正的唯一时间是在您不更改应用程序的交付之后。我亲眼目睹了许多同时属于这两个类别的项目（在交付之前，我们认为会死掉，但实际上并没有，而那些我们认为会非常活跃但死了的项目）。因此，由于在进行修改之前您无法确定，因此为所有项目投入所有精力可能（或更可能是，取决于您的具体情况）是值得的......

记住，如果你第一次没有时间把它做好，你什么时候有时间再做一遍？

【讨论】：

+1 因为this

【解决方案2】：

老实说，在您开始编写足够复杂的代码之前，您不会编写任何接口或抽象类。他们觉得你在书中读到的例子有点矫枉过正的原因是他们经常这样。但是，一旦您真正进入其中一个大型项目，您就会明白它们为什么有用。

您将立即受益于简单的类，可能还有一些浅继承。最明显的地方将是您的数据库抽象和数据模型。即使您的程序很小，您也可以立即从这样做中受益。如果您在两个地方创建了一篇新博客文章，那么拥有一个博客文章对象会立即将创建它的代码以及与之相关的所有数据库交互移动到一个地方，而不是重复：

$post = new BlogPost();
$post->setTitle("Hello World");
$post->setContent("An awesome update about my life!");
$post->save();

...等

【讨论】：

【解决方案3】：

不仅仅是其他人在扩展您的代码，而是您在未来的某个日期。

如果您的应用程序只有一页，或者非常小，您可以按程序对 PHP 进行编码。

【讨论】：

当然，我明白了。我说的不是一页，肯定是多页，可能是15个类。基本 CRUD，最适合 OOP，我只是想知道我在多大程度上应用它，因为在这种情况下，抽象类和接口之类的东西似乎有点不必要

【解决方案4】：

And I also understand that one of the main purposes of OOP is for maintainability and extendability for the future.你总结得差不多了。如果不是为了现在的可用性，在开发过程的早期就采用这种方法，绝对可以防止出现严重的秃斑。

你怎么确定这将是一个“封闭”的项目？真的不可能没有其他功能/修改吗？

【讨论】：

是的，我想它可能需要修改

【解决方案5】：

OOP 首先是一种语法变体。您也可以使用过程或低级语言编写面向对象的代码（参见 glib）。

由于它是一种语法结构，它应该用于使代码更具可读性。仅此而已。可维护性和可扩展性是次要属性（有时是错误属性）。

避免客观的幸福，但不要回避合理的结构。
http://www.codinghorror.com/blog/2007/03/your-code-oop-or-poo.html

【讨论】：