Можливо, мені не вистачає пункту, але мені просто цікаво, чому іноді є вираз "використання" для конкретного класу, а іноді ми цього не робимо.

Приклад: 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класу?

Немає технічних причин віддавати перевагу одному над іншим, за винятком випадків, коли є конфлікти імен (наприклад, різні класи "Контекст"). Але це можна вирішити за допомогою псевдонімів, і саме це я зазвичай роблю:

use Magento\Framework\Model\Context as ModelContext;

Я припускаю, що в основному багато методів, особливо конструкторів, спочатку генерувались такими інструментами, як інструмент перетворення, а потім пізніше, а не змінено на імпорт "використання".

Тому я б запропонував, щоб у власному коді ви завжди імпортували класи з «використанням», щоб зробити фактичний код менш дослідним та більш читабельним.

Використання залежить від конкретної ситуації. Мій підхід:

Клас згадується лише один раз у файлі - 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})"]
           );

На мою думку, другий приклад легше читати. (Якщо чесно кажучи, я вважаю за краще використовувати тут змінні замість констант, щоб зробити це ще більш зрозумілим.)

Інтерфейси API Magento 2

Існує повідомлення про кінцеві точки API, виставлені автоматично на M2. У інтерфейсах, які використовуються для методів REST / SOAP, ви завжди повинні використовувати FQN.

Анотації аналізуються Рамою Magento, щоб визначити, як конвертувати дані в JSON або XML.

Імпорт класу (тобто використання операцій вище класу) не застосовується!