實現驅動和依賴注入的好處與維護實現的成本

我正在啓動一個我希望快速構建的應用程序，稍後將由20多位開發人員開發。實現驅動和依賴注入的好處與維護實現的成本

在一個包含多個開發人員的環境中瞭解您對DI的瞭解，您是否願意與DI一起創建一個您希望構建得相對較快的新應用程序？

現在對我使用DI的成本將是寫入和生成的代碼行，而不是使用每個對象的接口。並且，我希望DI由於反思而不會成爲性能問題。

2011-10-18 MetaChrome

簡單地說，在沒有依賴注入的情況下進行面向對象的開發是不好的。很壞。在我看來，依賴注入是衆所周知的OO開發的根源：關注點的分離，獨立組件之間的鬆散耦合，層次編碼，所有這些都是使用DI完成的。而且，它使得測試變得非常容易，並且允許諸如TDD，嘲諷（BDD）等技術。

由於釋迦牟尼在他的回答中說，DI不是關於你使用的框架。 Spring沒有發明DI，只是提出了實現它的解決方案。所以如果你的原始問題是「我們應該使用Spring」，那麼我會說這是個人品味的問題。如果你自己做，你可以達到完全相同的結果。我曾在有或沒有容器（Spring，pico等）的項目中工作過，他們都有自己的優點和缺點。然而，我個人的偏好並不是使用它來管理你的DI。

這是DI：

// constructor 
public MyClass(MyDependencyInterface injected) { 
    this.dependency = injected; 
}

，或者：

// setter injection 
public void setDependency(MyDependencyInterface injected) { 
    this.dependency = injected; 
}

上下我希望DI不會成爲因反射的性能問題就行了。

不知道你是什麼意思。 DI不需要反射。

來源

2011-11-12 23:22:25 Guillaume

DI基本上不是框架。例如，如果只是將你的依賴關係作爲參數添加到縮尺，那麼你就是在做DI。實際上，你甚至不需要創建接口（儘管這將有助於測試。稍後介紹接口是對Java等語言的簡單重構）。 DI只是消除了課堂用戶的創作責任。

我腦海中唯一最大的代價就是心靈的變化。學會思考DI。的好處包括更容易的測試。分離關注和更多。

來源

2011-11-12 23:11:11 mathiasbn

沒有接口，在類和它的依賴之間保持緊密耦合，這是DI嘗試破壞的一件事。這將是一個恥辱。 – Guillaume

確實。只是要指出，對於快速Spike，界面決定可以推遲 – mathiasbn

我絕對會主張DI，特別是當有很多開發者時。

這允許每個開發人員編寫和測試自己的代碼，而不依賴於在其控制之外開發的注入組件。

它還可以促進接口定義，因此每個人都知道哪些組件可用的功能。

來源

2011-11-12 23:17:00

Java中的基本問題是，當您在A類中執行new B()時，這意味着類A在字節代碼級別與B類非常緊密地綁定。

這通常是一件好事，因爲它意味着由此產生的應用程序變得非常堅固，因爲所有的「磚塊」都很好地「粘在一起」。

然而，你經常需要推遲一些設計問題來部署時間（偶爾甚至是運行時），而在Java中處理這種情況的方式傳統上是委託給工廠，甚至可能委託給另一工廠等，直到你到達你作出決定的地方。這通常是通過一個屬性文件來完成的，該文件包含代碼中對應於if的標誌（需要編程人員在編寫代碼時預見所有情況）或類名稱以解決Class.forName()（編譯器無法幫助）。

依賴注入的優勢在於，您可以通過將自己的代碼之外的適當對象委託給一個容器（但也可能是一個神）來避免new運算符的硬綁定。你可以創建一些非常明確的界限，你可以把所有的東西放在一起，對於那些提供代碼配置的DI框架（比如Guice），結果可以像模塊一樣堅固。

請注意，對接口進行編碼可以更容易地找到切割切口的正確位置，因爲接口用法通常對應於注射點。

來源

2013-01-21 14:31:43

實現驅動和依賴注入的好處與維護實現的成本

回答

相關問題