Является ли это хорошим способом использования пространств имен в PHP

Я изучил использование пространств имен в PHP некоторое время назад, но недавно просмотрел проект, который использовал ключевое слово use, а затем обратился к объекту с расширением имен, как если бы они были нормальными без пространства имен.

Мой вопрос в том, что код ниже правильный, это hs файл index.php и использует пространство имен MyLibrary\Base, а затем использует use для ввода \MyLibrary\Registry \MyLibrary\User и \MyLibrary\Request

Затем он может получить доступ к любому из этих объектов, не помещая там пространство имен, поэтому фактический код под секцией use выглядит как обычный файл php с предварительным пространством имен.

Я спрашиваю, как именно вы используете пространства имен? Или я что-то упускаю?

Файл: index.php

<?php
namespace MyLibrary\Base;

use \MyLibrary\Registry;
use \MyLibrary\User;
use \MyLibrary\Request;


class Base
{
    public $registry;

    function __construct($registry)
    {
        $this->registry = $registry;
        $this->user = New User;
        $this->request = new Request;
        # code...
    }
}
?>

Файл: registry.class.php

<?php
namespace MyLibrary\Registry;

class Registry
{
    public $user;

    function __construct($user)
    {
        $this->user = $user;
        # code...
    }
}
?>

Ответ 1

Да. use -statement импортирует имя класса или пространства имен в текущую область. Чтобы написать все, что является короткой причиной, почему PHP-разработчики реализовали пространства имен;)

namespace MyFirstNamespace {
    class Foo {}
}
namespace MySecondNamespace {
    use \MyFirstNamespace\Foo as Bar;
    $foo = new Bar;
}

a) он делает все более читаемым, потому что он намного короче, чем Vendor_Package_Foo_Bar_XyzClass и b), вы можете очень быстро использовать классы.

# use \MyFirstNamespace\Foo as Bar; // I don't like Foo anymore
use \MyFirstNamespace\SimilarToFoo as Bar;

Ответ 2

У Namespacing есть много преимуществ.

В первую очередь вы можете повторно использовать имена методов и даже имена классов, если это имеет смысл, если они существуют в другом пространстве имен. Пример:

namespace \myNamespace\data\postgres;

class DataBase extends \PDO
{
}

namespace \myNamespace\data\mysql;

class DataBase extends \PDO
{
}

Вы даже можете повторно использовать имена, которые обычно зарезервированы для функций PHP

namespace \myNamespace\dir;

function makedir ()
{
    if (// some condition is true)
    {
        \makedir ();
    }
}

Все это призвано упростить использование кода из разных источников, не беспокоясь о конфликтах имен. При условии, что программисты достаточно учтивы, чтобы соблюдать несколько простых правил, тогда шансы на конфликты имен значительно сокращаются. Фактически, в значительной степени единственное правило, в котором вам нужно заботиться, чтобы избежать конфликтов имен, - это сделать первый уровень вашего пространства имен своим. Например, используйте название вашей компании или какой-либо другой способ идентифицировать вас как уникального поставщика в качестве первого уровня вашего пространства имен, и все должно быть хорошо.

Например, я использую \gordian как корневое пространство имен во всем коде, который я пишу, так как тогда я могу называть мои классы под этим пространством имен чем угодно, не беспокоясь о том, что они сталкиваются с кем-то, кто выбрал другое корневое пространство имен.

Итак, что случилось с соглашениями PEAR, вы могли бы спросить? За ними следуют многие проекты, в том числе популярная структура Zend.

Ответ: имена очень быстро становятся очень громоздкими. Например, Zend, как следует из соглашения PEAR, использует своего рода псевдо-именное пространство. Все классы в коллекции начинаются с Zend_ и с каждым уровнем иерархии класса добавляют дополнительную часть имени.
Ze В результате вы получаете имена классов, такие как Zend_Db_Adaptor_Abstract и Zend_Dojo_Form_Decorator_TabContainer.

Если Zend обновит свою фреймворк для использования пространств имен (что, как мне сказали, происходит с Zend Framework 2.0), они будут заменены на \Zend\Db\Adapter\Abstract и\Zend\ Dojo\Form\Decorator\TabContainer. Так что, спросите вы? Ответ заключается в том, что вы можете использовать их для более коротких имен с ключевым словом Use, как вы уже видели. Это означает, что вам не нужно писать полное имя класса, но только в отношении того, что вы наложили.

use \Zend\Dojo\Forn\Decorator as Dec;

$a = new Dec\TabContainer; // Not easy to do without namespaces!

Кроме того, если вы уже находитесь в определенном пространстве имен, вам даже не нужно использовать ключевое слово use для доступа к другим элементам в одном и том же пространстве имен по короткому имени, так как это автоматически произойдет в этом случае, Для разработчиков фреймворков это огромный развал.

Например, вы можете увидеть что-то вроде подзаголовка в Zend Framework 2 (поскольку я никоим образом не работаю над этим, это просто пример, а не фактический источник ZF2).

namespace \Zend\Db\Adaptor;

class Postgres extends Abstract // We don't need to use \Zend\Db\Adaptor\Abstract here because it in the same namespace already anyway
{
}

Есть и другие преимущества, например, сделать автозагрузчики смехотворно простыми (при условии, что ваша структура пространства имен точно соответствует структуре каталогов файловой системы).

Пространства имен могут показаться одной из тех функций, которые на самом деле не очень важны или даже не кажутся имеющими смысл, но после их использования в течение некоторого времени их полезность вдруг станет очень очевидной.