Je manque peut-être un point, mais je me demande simplement pourquoi il existe parfois une instruction "use" pour une classe spécifique et parfois nous ne le faisons pas.

Exemple:, app\code\Magento\Email\Model\Template.phpnous avons en haut du fichier:

namespace Magento\Email\Model;

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

Ensuite, dans la __constructméthode, nous avons les paramètres suivants:

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

Nous pouvons donc clairement voir que, comme nous l'avons appelé use Magento\Store\Model\StoreManagerInterface;en haut de la classe, nous pouvons le faire StoreManagerInterface $storeManagerdans les paramètres du constructeur.

Mes questions sont:

• Pourquoi faisons-nous cela pour une seule classe?
• Pourquoi ne pouvons-nous pas ajouter une useinstruction pour chaque classe du constructeur afin que nous n'ayons pas à taper le chemin complet de la classe?
• Ou l'inverse, pourquoi ne pas nous débarrasser de l' useinstruction et taper le chemin complet vers la StoreManagerInterfaceclasse?

Il n'y a aucune raison technique de préférer l'un à l'autre, sauf s'il y a des conflits de noms (comme différentes classes "Context"). Mais ceux-ci peuvent être résolus avec des alias et c'est ce que je fais habituellement:

use Magento\Framework\Model\Context as ModelContext;

Je suppose que dans le noyau, de nombreuses méthodes, en particulier les constructeurs, ont été générées par des outils comme l'outil de conversion au début, puis n'ont pas été modifiées pour utiliser les importations "use".

Je suggère donc que dans votre propre code, vous importiez toujours des classes avec "use" pour rendre le code réel moins verbeux et plus lisible.

L'utilisation dépend de la situation spécifique. Mon approche est:

Classe mentionnée une seule fois dans un fichier - FQN

Laissez un nom complet . Cela améliore la lisibilité car vous n'avez pas besoin de consulter à nouveau la section utilisation .

Nom de classe utilisé plusieurs fois - importation

Mettez-le dans une section d' utilisation . Cela rend le code plus court lorsque la classe est mentionnée.

Classe utilisée une fois mais j'ai besoin d'une notation courte - import

Mieux vaut expliquer avec un exemple.

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

importation

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

À mon avis, le 2e exemple est plus facile à lire. (Mais honnêtement, je préfère utiliser des variables plutôt que des constantes ici pour lui donner encore plus de lisibilité.)

Interfaces API Magento 2

Il existe un avis concernant les points de terminaison d'API auto-exposés M2. Dans les interfaces utilisées pour les méthodes REST / SOAP, vous devez toujours utiliser des FQN.

Les annotations sont analysées par le Magento Framework pour déterminer comment convertir les données vers et depuis JSON ou XML.

Les importations de classe (c'est-à-dire, utilisez des instructions au-dessus de la classe) ne sont pas appliquées!