依賴注入成癮？

就不用擔心它的最好的文章之一。我認爲，IoC技術對於大多數開發者來說將是第二天性。我正在努力在這裏教授開發人員關於它的事情，我發現很難傳達信息，因爲它對我們一直做事情的方式感覺非常不自然，這恰恰是錯誤的方式。另外，IoC新手和我發現的新項目的開發人員都遇到了更多困難。他們習慣於使用IDE來追蹤依賴關係，以瞭解整個事物如何「掛在一起」。這些信息通常寫入奧術XML。

來源

2008-09-03 22:18:59 tgeros

此外，如果它是我使用的語言的一部分，我覺得它會好很多。

僅供參考如果您需要輕量級，簡單的依賴注入，然後使用它，那麼在JDK 6中有一個非常簡單且功能強大的依賴注入。

使用基於一類ServiceLoader類，你可以請求服務（或服務的許多實現）：

package dependecyinjection; 
import java.util.ServiceLoader; 

public abstract class FooService { 

    public static FooService getService() { 
     ServiceLoader<FooService> loader = ServiceLoader.load(FooService.class); 

     for (FooService service : loader) { 
      return provider; 
     } 

     throw new Exception ("No service"); 
    } 

    public abstract int fooOperation(); 

} 

package dependecyinjection; 
public class FooImpl extends FooService { 
    @Override 
    public int fooOperation() { 
     return 2; 
    } 
}

怎樣的ServiceLoader定義返回的服務實現？

在項目文件夾中創建一個名爲META-INF /服務文件夾，並創建一個名爲dependencyinjection.FooService文件。該文件包含指向服務實現的一行。在這種情況下：依賴注入.FooImpl

這還不是廣爲人知。

來源

2008-09-03 22:19:07

這種模式不是稱爲「服務定位器」而是「依賴注入」嗎？請參閱http://www.martinfowler.com/articles/injection.html獲取兩者的描述。 – 2009-04-29 01:49:19

使用這種模式會導致開發人員瘋狂時，他們必須爲服務隱藏的依賴關係...... – mathieu 2012-07-31 09:55:30

我有DI的問題是同樣的問題，我有一個COM，並與看起來像任何代碼：

i = GetServiceOrInterfaceOrObject(...)

的問題是，這樣的系統不能從代碼可以理解。在[else]中必須有文檔定義服務/接口/對象X可以請求哪些服務/接口/對象。該文檔不但必須保留，而且可以像源代碼那樣容易地獲得。

除非文檔寫得很好，否則通常很難看到對象之間的關係。有時候，關係是暫時的，這使得他們更難以發現。

我喜歡KISS的原則，我堅信使用正確的工具來完成這項工作。如果給定項目的DI的好處超過編寫可理解代碼的需要，那麼比使用它更好。

來源

2011-02-12 20:23:28 Tergiver

依賴注入成癮？

回答

相關問題