Возможно, я упускаю суть, но мне просто интересно, почему иногда есть выражение «использование» для определенного класса, а иногда нет.

Пример: app\code\Magento\Email\Model\Template.phpмы имеем в верхней части файла:

namespace Magento\Email\Model;

use Magento\Store\Model\ScopeInterface;
use Magento\Store\Model\StoreManagerInterface;

Тогда в __constructметоде у нас есть следующие параметры:

public function __construct(
    \Magento\Framework\Model\Context $context,
    \Magento\Framework\View\DesignInterface $design,
    \Magento\Framework\Registry $registry,
    \Magento\Store\Model\App\Emulation $appEmulation,
    StoreManagerInterface $storeManager,
    \Magento\Framework\View\Asset\Repository $assetRepo,
    \Magento\Framework\Filesystem $filesystem,
    \Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig,
    \Magento\Email\Model\Template\Config $emailConfig,
    \Magento\Email\Model\TemplateFactory $templateFactory,
    \Magento\Framework\Filter\FilterManager $filterManager,
    \Magento\Framework\UrlInterface $urlModel,
    \Magento\Email\Model\Template\FilterFactory $filterFactory,
    array $data = []
)

Таким образом, мы можем ясно видеть, что, как мы вызывали use Magento\Store\Model\StoreManagerInterface;в верхней части класса, мы можем сделать это StoreManagerInterface $storeManagerв параметрах конструктора.

Мои вопросы:

• Почему мы делаем это только для одного класса?
• Почему мы не можем добавить useоператор для каждого класса конструктора, чтобы нам не приходилось вводить полный путь к классу?
• Или наоборот, почему бы нам не избавиться от useоператора и не ввести полный путь к StoreManagerInterfaceклассу?

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

use Magento\Framework\Model\Context as ModelContext;

Я предполагаю, что в основном многие методы, особенно конструкторы, сначала генерировались такими инструментами, как инструмент преобразования, а затем не менялись для использования импорта «использования».

Поэтому я бы предложил, чтобы в вашем собственном коде вы всегда импортировали классы с помощью «use», чтобы сделать реальный код менее подробным и более читабельным.

Использование зависит от конкретной ситуации. Мой подход:

Класс, упомянутый только один раз в файле - FQN

Оставьте полностью уточненное имя . Это улучшает читабельность, потому что вам не нужно снова просматривать раздел об использовании .

Имя класса используется несколько раз - импорт

Поместите это в раздел использования . Это делает код короче, где упоминается класс.

Класс используется один раз, но мне нужна короткая запись - импорт

Лучше объясните на примере.

FQN

$collection->getSelect()
           ->joinInner(['campaign_products' => $subSelect],
               'campaign_products.product_id = e.entity_id',
               [self::FIELD_SORT_ORDER => "IFNULL(IF(0 = " . \Custome\Module\Api\Data\ProductListInterface::SORT_ORDER . ", NULL, " . \Custome\Module\Api\Data\ProductListInterface::SORT_ORDER . "), {$defaultSortValue})"]
           );

импорт

$collection->getSelect()
           ->joinInner(['campaign_products' => $subSelect],
               'campaign_products.product_id = e.entity_id',
               [self::FIELD_SORT_ORDER => "IFNULL(IF(0 = " . ProductListInterface::SORT_ORDER . ", NULL, " . ProductListInterface::SORT_ORDER . "), {$defaultSortValue})"]
           );

На мой взгляд, 2-й пример легче читать. (Но, честно говоря, я бы предпочел использовать переменные вместо констант, чтобы сделать их более читабельными.)

Интерфейсы API Magento 2

Существует уведомление, касающееся автоматически выставляемых конечных точек API M2. В интерфейсах, используемых для методов REST / SOAP, вы всегда должны использовать FQN.

Аннотации анализируются в Magento Framework, чтобы определить, как конвертировать данные в JSON или XML.

Импорт класса (то есть операторы использования над классом) не применяются!