Question

提出问题是因为我在查找情况中的实际命名空间时遇到错误：

父类namespace \ demo \ parent \ config（）（数百行）
子类命名空间\ demo \ child1 \ config（）extends \ demo \ parent \ config（）（空）
子类命名空间\ demo \ child2 \ config（）extends \ demo \ parent \ config（）（空）

但是......我发现这不是问题，但是我做了a）没有完全量化我的class_exists（）（假设类会占用它上面的命名空间但它没有）并且我在我的类型中有一个类型class_exists line ...

无论如何，这种解决方法适用于获取实际命名空间：

解决方法

如果我使用getnamespace：

function getNameSpace()
{
    $currentClass = get_class($this);
    $refl = new \ReflectionClass($currentClass);
    $namespace = $refl->getNamespaceName();
    return $namespace . '\\';
}

然后类似于以下内容，用于在正确的命名空间中实例化类

$module1 = '\\' . self::getNameSpace() . 'Module1';
new $module1

并且在静态类的场景中：

self::callConfig('GetOptionsName');

其中“callConfig”=

function callConfig($method,$par='')
    {
        if ('' == $par)
        {
            return call_user_func(array(self::getNameSpace() . 'Config',
                $method));
        }
        else
        {
            return call_user_func_array(array(self::getNameSpace() . 'Config',
                $method),$par);
        }
    }

Answer 1

所以这里真正的答案是你犯了一个设计错误。重构太大（虽然实际上，它可能并不那么糟糕）。因此，要解决您的设计错误，您需要像现在一样破解一起。

为什么类和对象之间存在差异是一个非常好的理由。对象允许子类化，所有那些花哨的OOP特性都与实例化的类相关联。我的猜测是你选择了美学而不是有用。

如果你认为Config ::或多或少是你真实配置的代理，也许你可以解决这个问题。我仍然希望建议重写代码库的这一部分以正确利用OOP，然后可能使用现有的Config :: for向后兼容性。如果您的应用程序应该存在很长时间，您可能会觉得从长远来看，引入一个新概念（并维护旧概念）可能是值得的。否则你可能不得不长时间忍受这个糟糕的决定。

最后，重构一次。我发现即使有大量的代码库，它也可能是一项无聊的工作......但是没有什么需要花费几个小时的时间。

如果您进行了单元测试，那么验证此更改是否在所有地方都正确实施也很容易。

如何在PHP中使用具有不同命名空间的扩展类调用方法

1 个答案: