受保护的修改器（setter）
问题
假设您有一个班级用户。您希望能够将此用户对象返回给其他人，以便他们可以使用它通过 getter 来提取信息。但是，您不希望人们能够轻松设置内部状态，因为内部信息应该直接与数据库中的行相关。使用受保护的修改器（设置器）以便只有扩展类可以设置变量是否有意义？这是一种不好的做法、无关紧要、矫枉过正还是无用？
我曾考虑过尝试将 __construct 限制为一种用途（我相信这有时被称为单例模式 - 尽管我不确定我是否完全理解。）
我是一名业余程序员，请原谅任何无知。谢谢。
示例：
<?php
class user
{
private username;
protected function set_username($username)
{
$this->username = $username;
}
public function get_username()
{
return $this->username;
}
?>
Problem
Suppose you have a class user. You want to be able to return this user object to others so they can use it to extract information using getters. However, you don't want people to be able to readily set the internal state because the internal information should directly relate to a row in the database. Does it make sense to have protected mutators (setters) so that only an extended class could set the variables? Is this a bad practice, irrelevant, overkill or useless?
I have considered trying to limit __construct to one use ( I believe this is sometimes refereed to as a singleton pattern - although I am not sure if I understand entirely. )
I am an amateur programer, forgive any ignorance. Thanks.
Example:
<?php
class user
{
private username;
protected function set_username($username)
{
$this->username = $username;
}
public function get_username()
{
return $this->username;
}
?>
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
视情况而定。如果状态更改时不需要发生任何特别的事情，那么您可以完全忽略设置器。任何子类都可以直接访问设置为受保护或较宽松的属性。
如果您需要在状态更改时发生某些事情（例如，在状态更改时发生数据库 UPDATE），那么 setter 将使您的生活变得更加轻松，因为对数据库更新代码的调用将放在 setter 中。这意味着如果您始终通过 setter，那么当您更改对象的状态时，数据库将始终更新。
简而言之，这取决于情况。
Depends. If nothing in particular needs to happen when the state is changed then you can leave the setters out altogether. Any subclass will have direct access to the properties that are set protected or looser.
If you need something to happen when the state changes (for example having a database UPDATE happen when the state changes) then the setters will make your life a lot easier, as the call to the database updating code be put in the setter. This means if you always go through the setter then the DB will always update when you change the object's state.
So in short, it depends.
例如，如果您有一个接受 id 的构造函数，那么您为什么要使用 setter。没有任何规则强迫您仅仅因为对象具有 getter 就为其提供 setter。如果您的用例正在某处构造对象，然后仅使用它来从中提取数据，则根本不创建任何设置器。
扩展对象可以操作受保护的类变量本身，因此它们也不需要任何形式的设置器。如果您不希望“外部世界”能够为班级设置某些内容，请不要允许。
If you have a constructor that accepts an id for instance, why would you want to have setters at all. There is no rule forcing you to give an object setters just because it has getters. If your usecase is constructing the object somewhere and after that only use it to extract data from it, simply create no setter at all.
Extending objects can manipulate the protected class variables itself so they don't require any form of setter as well. If you don't want the "outside world" to be able to set something to the class, don't allow it.
你的代码完全没问题，恕我直言，它封装得很完美。 Tt 还支持松耦合。
为了更方便使用，您可以添加所有需要（必须具有）的成员作为构造函数参数。
关于单例模式，请谨慎使用。共同用户不是单身用户。请参阅重构模式 (Joshua Kerievsky)。
Your code is totaly fine and IMHO it encapsulates perfectly. Tt also supports loose coupling.
For easier use, you can add all needed (must have) members as constructor parameters.
Regarding the singleton pattern, use it with care. Users in common aren't singletons. Refer to Refactoring to Patterns (Joshua Kerievsky).