Magento 2 DI thực hành tốt nhất

Giả sử tôi đang xây dựng một tiện ích mở rộng Magento 2 không .... à ... không quan trọng. Hãy nói rằng nó làm những thứ siêu tuyệt vời.
Nhưng tôi muốn chắc chắn rằng đây là bản dựng sử dụng các tiêu chuẩn phù hợp để các nhà phát triển khác có thể mở rộng nó.

Khi nào tôi nên sử dụng DI kết hợp với giao diện và khi nào tôi không nên?
Để làm cho nó rõ ràng ở đây là một ví dụ cốt lõi.

Lớp Magento\Core\Helper\Datacó một hàm tạo như thế này:

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;
}

Câu hỏi của tôi tập trung vào var \Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig(tôi biết có những người khác trong cùng một hàm tạo, nhưng một lời giải thích sẽ phù hợp với tất cả các trường hợp tôi nghĩ).

Theo di.xmlmô-đun lõi, var sẽ là một thể hiện của Magento\Framework\App\Config:

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

nhưng tôi có thể dễ dàng thay đổi điều đó nếu tôi cần.

Khi nào tôi nên sử dụng các giao diện như thế trong mã của mình?
Tôi đã tạo mô-đun mẫu không hoàn chỉnh này (xin lỗi vì quảng cáo), nơi tôi đã sử dụng các giao diện như vậy, nhưng tất cả chúng đều đến từ cốt lõi. Tôi đã không tạo ra một trong những của riêng tôi. Tôi có nên

Imho đó không phải là một câu hỏi cụ thể của Mage2, nói chung là "Khi nào nên sử dụng giao diện". Điều đó phụ thuộc vào nơi bạn muốn ai đó có thể mở rộng tiện ích mở rộng của mình. Tôi sẽ nói ở mọi nơi mà bạn làm việc với logic kinh doanh, có thể thay đổi. ;) Bên cạnh đó các đối tượng không có hành vi (ví dụ: các đối tượng dữ liệu đơn giản) thường sẽ không thay đổi.

Nếu bạn muốn linh hoạt 100%, bằng cách nào đó bạn phải sử dụng giao diện ở mọi nơi. Nhưng tôi sẽ không quá kỹ sư. Cá nhân tôi cũng thích http://odetocode.com/bloss/scott/archive/2009/06/08/when-do-i-use-interfaces.aspx như một lời giới thiệu khi nó thực sự hữu ích.

Magento2 thúc đẩy việc sử dụng các nguyên tắc RẮN .

Nguyên tắc đảo ngược phụ thuộc trực tiếp nói rằng, mã đó nên phụ thuộc vào trừu tượng (giao diện).

Nguyên tắc phân tách giao diện nói rằng nhiều giao diện dành riêng cho khách hàng tốt hơn một giao diện có mục đích chung. Các lớp cũng có thể định nghĩa giao diện được bảo vệ, vì vậy các giao diện được ưa thích hơn từ quan điểm kiến ​​trúc.

Ngoài ra PHP không hỗ trợ nhiều kế thừa của các lớp, nhưng hỗ trợ nhiều triển khai giao diện. Đó là một điểm nữa cho các giao diện.

Vì vậy, một quy tắc đơn giản có thể được sử dụng: nếu bạn không biết nên sử dụng cái gì, LUÔN LUÔN sử dụng các giao diện .

Tái bút Hiệu suất không phải là lý do để tôi không sử dụng giao diện