Dependency inversion principle

如同我們之前提到的，依賴於抽象而非實體，這是我們應該盡力去遵守的規範，依賴於抽象的系統，相對於依賴於實體的，更穩定且更有彈性，在抽象上的修改會影響到實體，但相對的，在實體（抽象的實作）的修正不會影響到抽象，只要抽象沒被更動，就能相信其穩定性，不會影響到其他模組

一個善用依賴反轉的設計模式是，抽象工廠模式，我們使用工廠介面去產出其他介面，並在工廠實體中回傳其他介面的實體，而藉著這兩個層介面，應用可以呼叫介面方法，且不需擔心自己如何定義和實作實體，這一層隔離，我們稱之為抽象界線

另一個管理依賴的強力工具是依賴注入，在了解依賴注入之前，先聽聽一個生活化的例子，一間比薩店不需要自己生產起司，他們會向外需下訂單說他們需要起司，而比薩店就會收到他們要的起司，而且可以立即使用

依賴注入大概就是這樣ＸＤ

類別不生產和自己職責無關的類別，而是由外部提供，並編寫成保證到時候一定會有需要的類別，那現在來了解為什麼要由外部提供呢？自己做難道不好嗎？

不好，一來職責模糊，二來功能太多，如果你開一間比薩店，還得買地、種麥子、做澆灌系統、養乳牛、開起司工廠、裝潢、設計、網站、行銷、會計、稅金、物流等，不對吧，一個比薩店類別，突然變成了財團等級的公司，沒人這麼幹的吧

記得前面講過的東西嗎？
單一職責，繼承的概念，類別只應負責一個商務邏輯，而對於其他的需要的東西，以組合和抽象的方式連貫起來

至於更細節的依賴注入，完全就是另外 30 天的題目了ＸＤ
等不及的人自己去看依賴注入：原理、實作與設計模式

English

As we mentioned before, relay on abstract, not implementation, it is not a advice, it is a rule we should follow, relay on abstract can make the system stable and flexible, any change on the abstract will influence its implement, on the contract, change in implementation usually won't affect abstract, abstract is stable, as long as the abstract is same, we don't need to worry about change of other module,

A good sample is abstract factory design pattern, in abstract factory, we use factory interface to generate another interface, with factory implement return a real class, by using those two abstract, application can call method by interface, and wouldn't even worry how to define and create the instance itself, we call this line boundary.

The other powerful tool to manage dependency is dependency injection, di with a life example is, a pizza wouldn't need to make cheese by themself, they make an order saying they need cheese, then the cheese will deliver to pizza shop and ready to use.

This is what dependency inject look like ＸＤ

Class doesn't generate class instances that have different responsibilities, instead, we define what it needs, and the provider guarantees that we will get it when we need it, but why? what is the advantage?

If we always generate class in another class, there will be too much responsibility there, and too much functionality, take an example. if you want to open pizza shop, you have to buy a field, plant malt, open cheese factory, design and decorate, make website, marketing, account, tax, delivery ...etc, that is not right, a simple pizza shop turn out to be a financial group

Remember what we discussed before?
Single responsibility, inheritage concept, class only incharge of single business logic, and other things they needed, using composition and abstract to connect them.

For more detail on dependency inject, that is another 30 days topic XD

For those that can't wait, check it out Dependency Injection Principles, Practices, and Patterns 1st Edition