爲何用Spring的一個緣由（轉）

做者：Ziphwy
連接：https://www.zhihu.com/question/27053548/answer/85060703
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

當你發現代碼常常重複，你會考慮將其寫成函數，封裝工具；
當你發現多人合做時，代碼耦合嚴重，你會將其模塊化。
每一個輪子的出現都是由於但願優化生產，提升效率，僅此而已。
正如評論裏的朋友所說，spring存在本身的問題，由於複雜度是不會憑空消失的，只是從一個地方轉移去另外一個地方。

一開始個人認識也不太夠，舉了個簡單的通用例子，這個例子實際上是spring依賴注入後帶來的好處，而並不是只是爲了如此。

後面講了個過程，能夠發現，重點在於層層封裝，造成模塊化，良好代碼環境，便於維護。

簡單來講，給你一套ssm，ssh的代碼，你能馬上知道先看什麼，按什麼規範寫；給你一套無接口風格各異的代碼，有可能看半天。

框架這種東西原本就是致力於統一輩子產形式，也有時效性。
面向接口編程如今也常常被懷疑是否有意義。

感受有點偏題了，互勉。

// 添加內容
做爲幾個月前是新手的次新手的我，在以前沒有分層解耦的需求下，徹底不能接受「讓容器（框架）去new對象」這種抽象，由於沒有說出其意義。

假如咱們要實現一個存款的應用，那麼，咱們的思惟是這麼走的：
1.寫一個「存款類」，裏面有「存款方法」，「存款方法」直接操做數據庫實現存款邏輯。

2.你忽然發現，操做數據庫的方法都是增刪查改，爲何不寫成一個類，讓「存款方法」去調用這個操做數據庫的類，減小了很多重複代碼。
（分層思想來了，業務邏輯和數據操做分離了）

3.你的朋友知道了你在寫這個應用，就跟你提意見，不如我幫你寫操做數據庫的類，你寫存款業務的類，這樣不就快了嗎？咱們約定一個接口，你調用這個接口，我實現這個接口，這樣開發就很快了。
（接口思想來了，調用方沒必要理會具體實現，專一於本身的邏輯）（工廠模式）

4.你在寫你的業務邏輯的時候，發現雖然你不用管數據操做邏輯的實現，可是在你的代碼了，建立一個對象的語法：
接口 變量名 = new 實現類();
在作了那麼多分離工做，仍是要寫new 實現類();，仍是依賴於實現類。你就想，能不能作一個容器，自動幫我將實現類賦給接口呢？（依賴注入思想）
因而，你寫出了spring，一開始使用xml配置，在類裏面只須要getBean()，接口和實現類和調用類基本分離了（鬆耦合造成了），後來xml你也懶得寫，弄出一批註解，實現類註解一下是組件，調用類聲明一個接口，寫個@AutoWired，spring容器就幫你完成了將實現類賦給接口的工做，即所謂的spring幫你new了一個對象。

最後你的應用結構以下圖：

比起剛開始一個類裏面參雜着各式各樣的代碼，如今看一個個部件似的，何等舒服！

 

注：spring不止是DI，還有AOP，MVC等等，依賴注入只是它的一個功能。

// 舊答案
舉個例子，好比你寫
Apple apple = new Apple();
People people = new People();
people.eat(apple);

而後有一天，客戶說不想吃Apple了
給我改爲吃Orange，而後你打開源文件

Orange orange = new Orange();
People people = new People();
people.eat(orange);
再從新編譯

再一天，客戶又以爲很差，要Peach了

Peach peach = new Peach();
People people = new People();
people.eat(peach);
再從新編譯

………

而後你在客戶的需求下崩潰了

假若您用spring

Fruit fruit = (Fruit)beanFactory.getBean("fruit");

People people = (People)beanFactory.getBean("people");

people.eat(fruit);

這樣使用了接口Fruit，你只須要在xml文件配置，更換fruit的bean，無需改變源代碼。對於people也如此。

會發現，咱們在這種設計下會少維護了不少代碼，達到這樣的效果的緣由是由於，Fruit和People沒有參雜在一塊兒，沒有誰調用了誰等等，實際上就是沒有耦合，他們的關係由接口代替表示了。