Это хороший способ использовать пространства имен в PHP

Question

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

Мой вопрос: правильный ли приведенный ниже код, он содержит файл 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...
    }
}
?>

Answer 1

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

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

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

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

Answer 2

Пространство имен имеет много преимуществ.

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

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's in the same namespace already anyway
{
}

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

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