Eu posso estar perdendo um ponto, mas estou me perguntando por que às vezes há uma instrução "use" para uma classe específica e às vezes não.

Exemplo app\code\Magento\Email\Model\Template.php:, temos no topo do arquivo:

namespace Magento\Email\Model;

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

Então, no __constructmétodo, temos os seguintes parâmetros:

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

Portanto, podemos ver claramente que, como chamamos use Magento\Store\Model\StoreManagerInterface;no topo da classe, somos capazes de fazê-lo StoreManagerInterface $storeManagernos parâmetros do construtor.

Minhas perguntas são:

• Por que fazemos isso para apenas uma classe?
• Por que não podemos adicionar uma usedeclaração para todas as classes do construtor para não precisarmos digitar o caminho completo da classe?
• Ou o contrário, por que não nos livramos da useinstrução e digitamos o caminho completo para a StoreManagerInterfaceaula?

Não há motivo técnico para preferir um ao outro, exceto se houver conflitos de nome (como diferentes classes "Contexto"). Mas esses podem ser resolvidos com pseudônimos e é isso que eu costumo fazer:

use Magento\Framework\Model\Context as ModelContext;

Eu presumo que no núcleo muitos métodos, especialmente os construtores, foram gerados por ferramentas como a ferramenta de conversão em primeiro lugar e depois não alterado para usar importações "utilização".

Portanto, sugiro que em seu próprio código você sempre importe classes com "use" para tornar o código real menos detalhado e mais legível.

O uso depende da situação específica. Minha abordagem é:

Classe mencionada apenas uma vez dentro de um arquivo - FQN

Deixe o nome completo . Isso melhora a legibilidade, porque você não precisa procurar o uso seção de novamente.

Nome da classe usado várias vezes - importação

Coloque-o em uma seção de uso . Isso reduz o código onde a classe é mencionada.

Classe usada uma vez, mas preciso de uma notação curta - import

Melhor explicar com um exemplo.

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

importar

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

Na minha opinião, o segundo exemplo é mais fácil de ler. (Mas, honestamente, eu preferiria usar variáveis ​​em vez de constantes aqui para dar ainda mais legibilidade.)

Interfaces de API do Magento 2

Há um aviso sobre os pontos finais da API M2 expostos automaticamente. Nas interfaces usadas para métodos REST / SOAP, você sempre deve usar FQNs.

As anotações são analisadas pelo Magento Framework para determinar como converter dados de e para JSON ou XML.

As importações de classe (ou seja, use instruções acima da classe) não são aplicadas!