【问题标题】:Casting object to its interface from a point of view of PHP从 PHP 的角度将对象转换为其接口
【发布时间】:2015-03-29 01:59:14
【问题描述】:

我正在尝试(出于教育原因)将 Java 代码重写为 PHP。它在这个存储库中。我的问题是第 42 行的here。我们可以在那里看到以下代码:

if (this.getBoard().getTile(boxNextPlace) instanceof ContentOperations && 
    ((ContentOperations)this.getBoard().getTile(boxNextPlace)).getContent() == null)
{
    ...

作为第一步,我们检查this.getBoard().getTile(boxNextPlace) 是否返回实现ContentOperations 接口的对象。如果是,我们进入第二步,再次调用this.getBoard().getTile(boxNextPlace)链,但这一次我们将返回值转换为ContentOperations,然后调用getContent方法进行进一步处理(在这种情况下与null比较,@ 987654329@ 但这与我的问题无关)。

据我了解,在这种情况下,强制转换是一种防止调用方法未由对象实现的保护,但它已经被this.getBoard().getTile(boxNextPlace) instanceof ContentOperations 条件证明,该对象属于ContentOperations 类型。

所以问题是:如果一个对象被证明是所需的类型,为什么还要将它转换成它的接口呢?还是我对铸造这种保护功能的理解是错误的?

【问题讨论】:

    标签: java php casting


    【解决方案1】:

    编写 Java 代码的人在第 42 行检查了 instanceof,但他们忽略了在第 55 行再次检查。如果 getTile() 真的可以返回不是 ContentOperations 的对象,则ClassCastException 会发生。我假设您不需要 PHP 中的任何额外逻辑来说明不同的返回类型。

    【讨论】:

    • 我也注意到了这一点,但令人困惑的是,虽然对象的类型已经确定,但它仍然是被铸造的。我是否应该假设在这种情况下进行强制转换是无关紧要的,而且是没有理由的吗?
    • 是的,这就是我的假设。您可以联系编写 Java 代码的人吗?
    • 很遗憾没有。这是为什么?如果将来不确定,也许我会尝试联系作者,但目前没有什么我无法与 doc 核对或在网上询问。无论如何,感谢您的帮助!
    猜你喜欢
    • 2021-07-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-04-03
    • 2018-04-08
    • 2016-08-02
    相关资源
    最近更新 更多