Как вызывать методы из расширенных классов с различными пространствами имен в PHP - PullRequest
Новая
       9

Как вызывать методы из расширенных классов с различными пространствами имен в PHP

0 голосов
/ 06 февраля 2012

Вопрос был задан, потому что у меня была ошибка при поиске фактического пространства имен в ситуации:

  • пространство имен родительского класса \ demo \ parent \ config () (сотни строк)
  • пространство имен дочернего класса \ demo \ child1 \ config () extends \ demo \ parent \ config () (пусто)
  • пространство имен дочернего класса \ demo \ child2 \ config () extends \ demo \ parent \ config () (пусто)

Но ... я обнаружил, что с этим проблем не было, но я сделал а) не полностью определил мой class_exists () (предполагая, что класс будет занимать пространство имен над ним, но этонет) И у меня был тип в моей строке class_exists ...

В любом случае этот обходной путь работает для получения фактического пространства имен:

обходной путь

Если я использую что-то 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);
        }
    }

1 Ответ

1 голос
/ 06 февраля 2012

Таким образом, настоящий ответ здесь заключается в том, что вы допустили ошибку проектирования. Слишком большой для рефакторинга (хотя в действительности это может быть не так уж и плохо). Таким образом, чтобы обойти вашу ошибку в дизайне, вам нужно взломать все вместе, как вы сейчас.

Существует чрезвычайно веская причина, по которой существует разница между классом и объектом. Объекты позволяют создавать подклассы, и все эти причудливые функции ООП привязаны к создаваемым классам. Я думаю, что вы выбрали эстетику за полезность.

Возможно, вы можете сделать проблему не такой большой, если будете рассматривать Config :: более или менее как прокси для вашей реальной конфигурации. Я все еще хотел бы предложить переписать этот бит вашей кодовой базы для правильного использования ООП, а затем, возможно, использовать существующий Config :: для обратной совместимости. Если ваше приложение должно жить долго, вы можете почувствовать, что введение новой концепции (и сохранение старой) может быть целесообразным в долгосрочной перспективе. Иначе вам, возможно, придется долго и долго жить с этим плохим решением.

Наконец, сделайте рефакторинг. Я обнаружил, что даже с массивными кодовыми базами это может быть скучной работой ... но ничего, что займет не более нескольких часов.

Если бы у вас были юнит-тесты, было бы также очень легко убедиться, что это изменение правильно реализовано везде.

...