Być może brakuje mi punktu, ale po prostu zastanawiam się, dlaczego czasami istnieje instrukcja „use” dla określonej klasy, a czasem nie.

Przykład: app\code\Magento\Email\Model\Template.phpmamy na górze pliku:

namespace Magento\Email\Model;

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

Następnie w __constructmetodzie mamy następujące parametry:

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 = []
)

Widzimy więc wyraźnie, że jak nazywamy use Magento\Store\Model\StoreManagerInterface;na szczycie klasy, jesteśmy w stanie wykonać StoreManagerInterface $storeManagerparametry konstruktora.

Moje pytania to:

• Dlaczego robimy to tylko dla jednej klasy?
• Dlaczego nie możemy dodać useinstrukcji dla każdej klasy konstruktora, abyśmy nie musieli wpisywać pełnej ścieżki klasy?
• Lub na odwrót, dlaczego nie pozbędziemy się useinstrukcji i nie podamy pełnej ścieżki do StoreManagerInterfaceklasy?

Nie ma technicznego powodu, aby preferować jeden nad drugim, z wyjątkiem konfliktów nazw (takich jak różne klasy „Kontekst”). Ale można je rozwiązać za pomocą aliasów i zwykle to robię:

use Magento\Framework\Model\Context as ModelContext;

I zakładamy, że w wielu podstawowych metod, zwłaszcza konstruktorów, były generowane za pomocą narzędzi takich jak narzędzie do konwersji w pierwszym i potem nie zmieniło użyć importu „użytkowania”.

Sugeruję więc, aby we własnym kodzie zawsze importować klasy za pomocą „use”, aby faktyczny kod był mniej szczegółowy i bardziej czytelny.

Wykorzystanie zależy od konkretnej sytuacji. Moje podejście to:

Klasa wspomniana tylko raz w pliku - FQN

Pozostaw w pełni kwalifikowaną nazwę . Poprawia to czytelność, ponieważ nie trzeba ponownie patrzeć na sekcję użycia .

Nazwa klasy używana wielokrotnie - import

Umieść go w sekcji użytkowania . To sprawia, że ​​kod jest krótszy tam, gdzie wspomniana jest klasa.

Klasa używana raz, ale potrzebuję krótkiej notacji - import

Lepiej wyjaśnij na przykładzie.

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})"]
           );

import

$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})"]
           );

Moim zdaniem drugi przykład jest łatwiejszy do odczytania. (Szczerze mówiąc wolałbym tutaj używać zmiennych zamiast stałych, aby zapewnić jeszcze większą czytelność).

Interfejsy API Magento 2

Zawiadomienie dotyczy punktów końcowych interfejsu API z automatyczną ekspozycją M2. W interfejsach używanych w metodach REST / SOAP należy zawsze używać nazw FQN.

Adnotacje są analizowane przez środowisko Magento w celu ustalenia, jak konwertować dane do i z JSON lub XML.

Importowane klasy (czyli użyj instrukcji powyżej klasy) nie są stosowane!