常聽人說起IOC和Spring，那什么是IOC呢？

IOC可以理解為‘面向接口編程思想’的一種實現方法，通過IOC實現了強制的‘面向接口編程’。

Spring以一種工程化的系統化的方法法，強迫程序員按照架構師的思路去實現class。

舉例來說，架構師設計了三種業務對象：用戶、數據池、數據元。架構師希望這三種對象分別提供各自的接口出來，讓用戶可以調用數據池，而數據池可以包含數據元。

架構師如何讓程序員了解他要做的事情，並且強迫程序員按照他的設計去寫代碼呢？

Spring就是這樣的一個方式，它按照接口定義了各個類，並且定義了各個類的關系。程序員的class如果寫的不對，那么它的類就會‘組裝’不進來。由於接口是先於實現而被定義的，因此一旦程序員的實現不正確，很容易定位出是誰的實現有問題。

這也是為什么Java的程序員很便宜而且必須有架構師這個職位，Spring能否有效的工作起來取決於架構師的設計；程序員的主要工作就是填空。

這也是為什么大家說Java重的原因，做一個東西必須設計出接口出來。如果很敏捷的想要對接口進行改變，則IOC就很吃力了。‘面向接口編程’所會遇到的問題，就是IOC會遇到的問題。

因此，是否要采用Spring和IOC，你只要問自己一個問題“我希望在這個產品中采用面向接口的編程方式”嗎？這個問題會更容易回答。

作為對比，C++里面沒有IOC是怎么解決這種問題呢？一般有這幾種方式：1，把程序切成多個小程序，每個程序對外提供簡單服務；2，寫設計文檔，設計文檔里面定義各個類的作用和接口；3，做一個概要設計，然后小組里面進行敏捷編程。這三種方式各有優缺點，要根據項目以及團隊的情況來選擇。

對比之下可以發現，Java確實比C++更適合寫邏輯復雜的大塊頭。Spring這樣的框架引入了硬性的約束，降低了溝通成本。(此外C++還有一個內存越界的問題)

然后我們也可以發現，超大規模的系統仍然要采用切割的方式，則Java擅長做大塊頭的特點就沒什么優勢了。因為大塊頭同時也會增加超大規模系統的維護難度。

現實世界也是如此，Java適合開發企業應用里面揉成一團的大塊頭。超大規模的系統則形形色色，用什么技術的都有了。