当前位置：文江博客话题详情

为什么方法和属性的可见性很重要？

发布于 2024-12-04 13:46:01 字数 141 浏览 1 评论 0原文

为什么不应该让所有方法和属性都可以从任何地方（即 public）访问？

您能否给我一个示例，说明如果我将属性声明为 public 可能会遇到的问题？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

夜未央樱花落 2024-12-11 13:46:01

将麦当劳视为一个对象。有一个众所周知的公共方法来订购巨无霸。

在内部，将会有无数次其他调用来实际获取制作巨无霸的材料。他们不想让您知道他们的供应链是如何运作的，因此您得到的只是公共 Gimme_a_BigMac() 调用，并且永远不会允许您访问 Slaughter_a_cow() 或 Buy_potatoes_for_fries() 方法。

对于您自己的代码，没有人会看到，请继续将所有内容公开。但是，如果您正在创建一个可供其他人重用的库，那么您就需要保护内部细节。这使得麦当劳可以自由地改用斯科蒂在肉饼上微笑，而不必打电话给卡车运输公司通过陆路运送肉。最终用户永远不会知道其中的区别 - 他们只是得到了巨无霸。但在内部，一切都可能发生根本性的改变。

回复收藏 0 原文

待＂谢繁草 2024-12-11 13:46:01

为什么不应该让所有方法和属性都可以从任何地方（即公共）访问？

因为那太贵了。

我制定的每一个公共方法都必须经过架构师团队的精心设计，然后批准，并且必须实施才能 >面对任意敌对或有缺陷的调用者时具有鲁棒性，它必须经过全面测试，测试期间发现的所有问题都必须添加回归套件，方法必须是记录，该文档必须翻译成至少十二种不同的语言。

不过，最大的成本是：该方法必须保持不变，永远不变，阿门。如果我在下一个版本中决定我不喜欢该方法的功能，我无法更改它，因为客户现在依赖它。破坏公共方法的向后兼容性会给用户带来成本，而我不愿意这样做。公共方法的糟糕设计或实现会给下一版本的设计者、测试者和实现者带来高昂的成本。

公共方法很容易花费数千甚至数万美元。在一个课程中制作一百个这样的课程，那就是一个价值百万美元的课程。

私有方法没有这些成本。 明智地使用股东的钱；尽可能将所有内容设为私有。

回复收藏 0 原文

妖妓 2024-12-11 13:46:01

将可见范围视为信任的内部圈子。

以您自己为例，思考哪些活动是公共的，哪些活动是私人的或受保护的。有很多事情您不能委托任何人代表您做。有些可以很好地触发，有些则访问权限有限。

同样，在编程中，范围为您提供了创建不同信任圈的工具。此外，将事物设为私有/受保护，可以让您更好地控制正在发生的事情。例如，您可以允许第三方插件扩展您的某些代码，但它们的范围可能会受到限制。

因此，总而言之，范围为您提供了额外的安全级别，并使事情比其他情况更有条理。

回复收藏 0 原文

聆听风音 2024-12-11 13:46:01

因为这违反了 OOP 的一个关键原则——封装的概念。

回复收藏 0 原文

风流物 2024-12-11 13:46:01

你说这是你冒的风险？

<?php

class Foo
{
    /**
     * @var SomeObject
     */
    public $bar;
}

您的代码声明 $bar 应包含 SomeObject 的对象实例。但是，任何使用您的代码的人都可以这样做

$myFoo->bar = new SomeOtherObject();

......并且任何依赖 Foo::$bar 作为 SomeObject 的代码都会中断。使用 getter 和 setter 以及受保护的属性，您可以强制执行此期望：

<?php

class Foo
{
    /**
     * @var SomeObject
     */
    protected $bar;

    public function setBar(SomeObject $bar)
    {
        $this->bar = $bar;
    }
}

现在您可以确定任何时候设置 Foo::$bar 时，它将带有 SomeObject 的对象实例。

A risk you run, you say?

<?php

class Foo
{
    /**
     * @var SomeObject
     */
    public $bar;
}

Your code states that $bar should contain an object instanceof SomeObject. However, anyone using your code could do

$myFoo->bar = new SomeOtherObject();

... and any code relying on Foo::$bar being a SomeObject would break. With getters and setters and protected properties, you can enforce this expectation:

<?php

class Foo
{
    /**
     * @var SomeObject
     */
    protected $bar;

    public function setBar(SomeObject $bar)
    {
        $this->bar = $bar;
    }
}

Now you can be certain that any time Foo::$bar is set, it will be with an object instanceof SomeObject.

回复收藏 0 原文

晚雾 2024-12-11 13:46:01

通过隐藏实现细节，还可以防止对象进入不一致的状态。

这是一个人为设计的堆栈示例（伪代码）。

public class Stack {

  public List stack = new List();
  public int currentStackPosition = 0;

  public String pop() {
    if (currentStackPosition-1 >= 0) {
      currentStackPosition--;
      return stack.remove(currentStackPosition + 1);
    } else {
      return null;
    }
  }

  public void push(String value) {
    currentStackPosition++;
    stack.add(value);
  }
}

如果将这两个变量设为私有，则实现可以正常工作。但如果是公共的，你可以通过为 currentStackPosition 设置不正确的值或直接修改 List 来轻松破坏它。

如果您只公开功能，那么您就提供了其他人可以使用和信任的可靠合约。公开实现只是让它成为一个可能有效的事情，没有人会扰乱它。

By hiding implementation details, it is also preventing an object from getting into an inconsistent state.

Here is an contrived example of a stack (pseudo code).

public class Stack {

  public List stack = new List();
  public int currentStackPosition = 0;

  public String pop() {
    if (currentStackPosition-1 >= 0) {
      currentStackPosition--;
      return stack.remove(currentStackPosition + 1);
    } else {
      return null;
    }
  }

  public void push(String value) {
    currentStackPosition++;
    stack.add(value);
  }
}

If you make both variables private the implementation works fine. But if public you can easily break it by just setting an incorrect value for currentStackPosition or directly modifying the List.

If you only expose the functions you provide a reliable contract that others can use and trust. Exposing the implementation just make it a thing that might work of nobody messes with it.

回复收藏 0 原文

谁人与我共长歌 2024-12-11 13:46:01

任何语言都不需要封装，但它很有用。
封装用于最大程度地减少更改传播概率最高的潜在依赖项数量，还有助于防止不一致：

简单示例：假设我们创建了一个包含四个变量 - 长度、宽度、面积、周长。请注意，面积和周长是从长度和宽度得出的（通常我不会为它们创建变量），因此改变长度会改变面积和周长。

如果您没有使用正确的信息隐藏（封装），那么利用该 Rectangle 类的另一个程序可以在不改变面积的情况下改变长度，并且您将得到不一致的 Rectangle。如果没有封装，可以创建一个长为 1、宽为 3、面积为 32345 的矩形。

使用封装，我们可以创建一个函数，如果程序想要更改矩形的长度，该对象将适当地更新其面积和周长而不会不一致。

封装消除了不一致的可能性，并将保持一致性的责任转移到对象本身而不是使用它的程序上。

然而，同时封装有时是一个坏主意，运动规划和碰撞（在游戏编程中）是特别可能出现这种情况的领域。

问题在于，封装在需要的地方非常棒，但是当应用在不需要的地方时就很糟糕了，比如当有全局属性需要由一组封装来维护时，因为 OOP 强制封装不不管怎样，你都被困住了。例如，对象的许多属性都是非局部的，例如任何类型的全局一致性。 OOP 中经常发生的情况是，每个对象都必须对其全局一致性条件的视图进行编码，并尽自己的一份力量来帮助维护正确的全局属性。如果您确实需要封装以允许替代实现，这可能会很有趣。但如果你不需要它，你最终会在多个地方编写大量非常棘手的代码，这些代码基本上做同样的事情。一切看起来都是封装的，但实际上是完全相互依赖的。

Encapsulation is not needed in any language, but it's useful.
Encapsulation is used to minimise the number of potential dependencies with the highest probability of change propagation also it helps preventing inconsistencies :

Simple example: Assume we made a Rectangle class that contained four variables - length, width, area, perimeter. Please note that area and perimeter are derived from length and width (normally I wouldn't make variables for them), so that changing length would change both area and perimeter.

If you did not use proper information hiding (encapsulation), then another program utilizing that Rectangle class could alter the length without altering the area, and you would have an inconsistent Rectangle. Without encapsulation, it would be possible to create a Rectangle with a length of 1 and a width of 3, and have an area of 32345.

Using encapsulation, we can create a function that, if a program wanted to change the length of the rectangle, that the object would appropriately update its area and perimeter without being inconsistent.

Encapsulation eliminates the possibilities for inconsistency, and shifts the responsibility of staying consistent onto the object itself rather than a program utilizing it.

However at the same time encapsulation is sometimes a bad idea, and motion planning and collision (in game programming) are areas where this is particularly likely to be the case.

the problem is that encapsulation is fantastic in places where it is needed, but it is terrible when applied in places where it isn’t needed like when there are global properties that need to be maintained by a group of encapsulation, Since OOP enforced encapsulation no matter what, you are stuck. For example, there are many properties of objects that are non-local, for example, any kind of global consistency. What tends to happen in OOP is that every object has to encode its view of the global consistency condition, and do its part to help maintain the right global properties. This can be fun if you really need the encapsulation, to allow alternative implementations. But if you don’t need it, you end up writing lots of very tricky code in multiple places that basically does the same thing. Everything seems encapsulated, but is in fact completely interdependent.

回复收藏 0 原文

独闯女儿国 2024-12-11 13:46:01

好吧，事实上，您可以公开所有内容，并且当您清楚地说明契约是什么、使用对象的正确方法时，它不会破坏封装。也许不是属性，但方法通常比它们必须的更加隐藏。

请记住，并不是您（API 设计者）通过公开事物来破坏封装。类的用户可以通过调用其应用程序中的内部方法来执行此操作。您可以因为他们试图这样做而拍手（即，将方法声明为私有），也可以将责任传递给他们（例如，通过在非 API 方法前加上“_”前缀）。您真的关心有人是否按照您建议的其他方式使用您的库来破坏他的代码吗？我不知道。

将几乎所有内容都设为私有或最终的——或者另一方面，让它们没有 API 文档——是阻碍开源的可扩展性和反馈的一种方式。您的代码可以以您甚至没有想到的方式使用，当所有内容都被锁定时，情况可能并非如此（例如，C# 中的默认密封方法）。

回复收藏 0 原文

野味少女 2024-12-11 13:46:01

您可能遇到的唯一问题是，如果您不使用私有或受保护或抽象静态最终界面，人们会认为您“不酷”强>或其他什么。这些东西就像名牌服装或苹果产品——人们购买它们不是因为需要，而是为了跟上别人的步伐。

是的，封装是一个重要的理论概念，但在实践中“私有”和朋友很少有意义。它们可能在 Java 或 C# 中有意义，但在像 PHP 这样的脚本语言中使用“私有”或“受保护”是完全愚蠢的，因为发明封装是为了由编译器检查，而编译器并不能检查封装。 PHP 中不存在。更多详情。

另请参阅这个出色的回复以及@troelskn和@马里奥评论此处

回复收藏 0 原文

醉殇 2024-12-11 13:46:01

可见性只是您可以为了您自己的利益使用的东西，以帮助您不破坏自己的代码。如果您正确使用它，您将帮助其他人（正在使用您的代码）不会破坏自己的代码（通过不正确使用您的代码）。

在我看来，最简单、广为人知的例子是单例模式。这是一种模式，因为这是一个常见问题。（维基百科的模式定义：

是记录设计问题解决方案的正式方式

维基百科中单例模式的定义：

在软件工程中，单例模式是一种用于实现单例数学概念的设计模式，通过将类的实例化限制为一个对象。当只需要一个对象来协调整个系统的操作时，这非常有用。

http://en.wikipedia.org/wiki/Singleton_pattern

该模式的实现使用 <强>私有构造函数。如果您不将构造函数设为私有，任何人都可能错误地创建一个新实例，并破坏只有一个实例的全部意义。

回复收藏 0 原文

盛夏尉蓝 2024-12-11 13:46:01

您可能认为前面的答案是“理论上的”，如果您在 Doctrine2 实体中使用 public 属性，则会破坏延迟加载。

回复收藏 0 原文

仅冇旳回忆 2024-12-11 13:46:01

为了拯救你自己！

上面有一些很好的答案，但我想补充一点。这称为最小权限原则。特权越少，有权破坏事物的实体就越少。破坏东西是不好的。

如果您遵循最小特权原则，则最小知识原则（或德米特法则）和单一责任原则也不甘落后。由于您编写的用于下载最新足球比分的类遵循了这一原则，并且您必须轮询其数据而不是将其直接转储到您的界面，因此您将整个类复制并粘贴到您的下一个项目中，从而节省了开发时间。节省开发时间是件好事。

如果幸运的话，在创建 gigaquads 的钱。未来的自己会因为不遵守上述原则而徒劳地使用前一个自己的名字，并且他将成为违反最小惊讶原则。也就是说，您的 bug 是足球比分模型中的解析错误，但由于您没有遵循 LOD 和 SRP，因此您会惊讶地发现您正在与输出生成内联进行 XML 解析。生活中有很多比你自己的代码的可怕性更令人惊讶的事情。相信我，我知道。

由于您遵循了所有原则并记录了代码，因此您每周四下午都会花两个小时进行维护编程，其余时间则用于冲浪。