Puede que me esté perdiendo un punto, pero me pregunto por qué a veces hay una declaración de "uso" para una clase específica y otras no.

Ejemplo: app\code\Magento\Email\Model\Template.phptenemos en la parte superior del archivo:

namespace Magento\Email\Model;

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

Luego en el __constructmétodo tenemos los siguientes 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 = []
)

Entonces, podemos ver claramente que, como lo llamamos use Magento\Store\Model\StoreManagerInterface;en la parte superior de la clase, podemos hacerlo StoreManagerInterface $storeManageren los parámetros del constructor.

Mis preguntas son:

• ¿Por qué hacemos esto solo para una clase?
• ¿Por qué no podemos agregar una usedeclaración para cada clase del constructor para no tener que escribir la ruta de clase completa?
• O al revés, ¿por qué no nos deshacemos de la usedeclaración y escribimos la ruta completa a la StoreManagerInterfaceclase?

No hay ninguna razón técnica para preferir uno sobre el otro, excepto si hay conflictos de nombres (como diferentes clases de "Contexto"). Pero esos se pueden resolver con alias y eso es lo que suelo hacer:

use Magento\Framework\Model\Context as ModelContext;

I asumir que en el núcleo muchos métodos, especialmente los constructores, fueron generados por las herramientas como la herramienta de conversión al principio y luego más tarde no cambia para utilizar las importaciones de "uso".

Por lo tanto, sugeriría que en su propio código siempre importe clases con "uso" para que el código real sea menos detallado y más legible.

El uso depende de la situación específica. Mi enfoque es:

Clase mencionada solo una vez dentro de un archivo - FQN

Deje el nombre completo . Esto mejora la legibilidad porque no necesita volver a mirar la sección de uso .

Nombre de clase usado varias veces - importar

Póngalo en una sección de uso . Esto acorta el código donde se menciona la clase.

Clase usada una vez pero necesito una notación corta - importar

Mejor explique con un ejemplo.

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

En mi opinión, el segundo ejemplo es más fácil de leer. (Pero honestamente hablando, preferiría usar variables en lugar de constantes aquí para darle aún más legibilidad).

Interfaces API Magento 2

Hay un aviso con respecto a los puntos finales de API expuestos automáticamente M2. En las interfaces utilizadas para los métodos REST / SOAP, siempre debe usar FQN.

Magento Framework analiza las anotaciones para determinar cómo convertir datos hacia y desde JSON o XML.

¡Las importaciones de clase (es decir, las declaraciones de uso sobre la clase) no se aplican!