面向对象的 PHP 中的封装——什么时候真正需要它？答案

【问题标题】：Encapsulation in object oriented PHP - when is it really needed?面向对象的 PHP 中的封装——什么时候真正需要它？
【发布时间】：2018-02-22 09:28:20
【问题描述】：

我知道这是一个信仰问题，之前已经被问过很多次，但我找到的答案要么太笼统，要么不适用于我的用例，要么不能满足其他方面的要求。

我目前正在构建一个使用类作为数据库表表示的应用程序。这些类不提供它们自己的任何方法，我为每个使用它们的对象并以我需要的格式返回数据的解析器类编写了一个解析器类，这使得父类无非是数据存储，并创建了一个数据和逻辑之间很好的区别。

现在，OOP 中的共识似乎是您总是必须使用 getter 和 setter，而不是直接访问类属性。

我经常听到的一个论点是，使用 getter 和 setter 可以在以后扩展这些函数，但在我看来，这与 YAGNI 和其他一些我现在记不起名字的概念背道而驰——即一个方法应该完全符合您对其名称的期望。如果我想做的不仅仅是设置一个值，我会编写一个新方法，而不是将其放入我的 setter 方法中，因为根据定义，该方法只应该设置属性。所以我还不如跳过setter，直接访问属性。

另一个是您可以在设置器中进行验证，我已经在访问这些类的 API 中进行了验证。在我看来，您不应该只传递值并让对象告诉您您的值是否合适，而是在将它们传递给对象之前先验证这些值。

我确实了解“普通”类中私有/受保护属性的目的，但是当该类实际上只是一个没有任何方法的数据容器时，真的需要这样做吗？换句话说：使用公共值是否有明显的缺点，当那些（它们是私有的）的 setter 方法看起来都像 public function getAttr($attr) { $this->atrr = $attr; } 时？

【问题讨论】：

你是唯一维护代码的人吗？其他人是否可能将预期为 DateTime 对象（例如）的属性设置为日期字符串或类似的东西？但最终 - 这个问题可能会被关闭为“主要基于意见”，因为唯一可能的准确答案是“它取决于......”
“面向对象的封装 - 什么时候真正需要？” -- encapsulation 是面向对象代码的基本属性之一。没有封装就没有面向对象编程，只有过程编程。当对象属性有 setter 和 getter 时，它是伪装成 OOP 的过程代码。
“但是当这个类实际上只是一个没有任何方法的数据容器”那为什么它仍然是 php 类？
@bxN5 因为我使用的 ORM 要求数据库表具有相应的类。
类是属性和行为的组合。由于您的类没有行为，只有属性，因此您最终将程序代码包装在一个类中，朝着anemic domain model 移动。

标签： php oop encapsulation

【解决方案1】：

您只需要一个数据结构，但唯一合适的 PHP 构造是类。

通常，在面向对象的分析、设计和编程中，类是事物或概念的模型，它封装了事物或概念的任何知识和/或行为。

但是，在这个问题的上下文中，不需要封装，因为您只需要一个数据结构。

【讨论】：