Mejores prácticas de Magento 2 DI

Digamos que estoy construyendo una extensión de Magento 2 que ... bueno ... no es importante. Digamos que hace cosas súper increíbles.
Pero quiero asegurarme de que esto se construya utilizando los estándares adecuados para que otros desarrolladores puedan extenderlo.

¿Cuándo debería usar el DI en combinaciones con interfaces y cuándo no debería?
Para que quede claro aquí es un ejemplo central.

La clase Magento\Core\Helper\Datatiene un constructor como este:

public function __construct(
    \Magento\Framework\App\Helper\Context $context,
    \Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig,
    \Magento\Store\Model\StoreManagerInterface $storeManager,
    \Magento\Framework\App\State $appState,
    PriceCurrencyInterface $priceCurrency,
    $dbCompatibleMode = true
) {
    parent::__construct($context);
    $this->_scopeConfig = $scopeConfig;
    $this->_storeManager = $storeManager;
    $this->_appState = $appState;
    $this->_dbCompatibleMode = $dbCompatibleMode;
    $this->_priceCurrency =  $priceCurrency;
}

Mi pregunta se centra en la var \Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig(sé que hay otros en el mismo constructor, pero creo que una explicación se ajustará a todos los casos).

De acuerdo con el di.xmldel módulo central, la var será una instancia de Magento\Framework\App\Config:

<preference for="Magento\Framework\App\Config\ScopeConfigInterface" type="Magento\Framework\App\Config" />

pero puedo cambiar eso fácilmente si lo necesito.

¿Cuándo debo usar interfaces como esas en mi código?
Creé este módulo de muestra incompleto (perdón por la publicidad), donde utilicé tales interfaces, pero todas provienen del núcleo. No he creado uno propio. ¿Debería?

En mi opinión, esa no es una pregunta específica de Mage2, más generalmente "Cuándo usar las interfaces". Eso depende de dónde desea que alguien pueda extender su extensión. Diría que en todas partes donde trabajas con lógica de negocios, lo que podría cambiar. ;) Además de eso, los objetos sin comportamiento (por ejemplo, objetos de datos simples) generalmente no cambiarán.

Si quieres ser 100% flexible, de alguna manera tienes que usar interfaces en todas partes. Pero no lo ingeniaría demasiado. Personalmente también me gusta http://odetocode.com/blogs/scott/archive/2009/06/08/when-do-i-use-interfaces.aspx como una introducción cuando es realmente útil.

Magento2 promover el uso de SOLID principios.

El principio de inversión de dependencia directa dice que el código debe depender de abstracciones (interfaces).

El principio de segregación de interfaz dice que muchas interfaces específicas del cliente son mejores que una interfaz de propósito general. Las clases también pueden definir una interfaz protegida, por lo que las interfaces son más preferidas desde un punto de vista arquitectónico.

Además, PHP no admite la herencia múltiple de clases, pero admite la implementación múltiple de interfaces. Ese es un punto más para las interfaces.

Por lo tanto, se puede usar una regla simple: si no sabe qué usar, SIEMPRE use interfaces .

PD. El rendimiento no es motivo para que no use interfaces