我想這幾張圖大家都能看懂，不過多贅述。
可以看出如果想呼叫乙個方法，在有這些dao類的基礎上，在service類中我們首先得new乙個userdaoimpl的物件，或者userdaomysqlimpl類（即如果我們想要切換兩個方法需要在**層對其進行操作，因為物件在service類中已經被初始化好）。
思考：1、切換想要的操作時，步驟繁瑣複雜，不靈活。
2、之前周陽老師在講阻塞佇列實現生產者消費者時，講到在企業中，我們要學會將口做的足夠大，使得能跟介面的多種實現類都能適配使用。
因此，我們將思維公升級一下，能否不固化service類中的userdao物件，而是在測試中，讓使用者去自定義。顯然這是可以實現的。
測試時，set注入乙個物件，使得程式被動接受，來完成此物件所對應的操作。
這就是ioc基本的思想:控制反轉，依賴注入（用set方法注入）。
我們再來對它進行公升級，也就是我們的spring了。
因為在沒有spring的時候，我們還是得需要去test中修改**，自己去new 某乙個userdao物件，這樣還是不便於應用。所以我們怎樣做就只需要寫自己想要什麼，就能得到同樣的效果呢。spring就為我們提供了ioc容器
這是xml配置檔案我們可以將它理解為乙個容器，或者是乙個英雄池。
<?xml version="1.0" encoding="utf-8"?>
英雄池的作用實際上就是各個英雄的登記，就像是發配任務的機構一樣。下面模擬一下這個過程。
那這種方式優化的點在**呢？
我們會發現，使用者發布到英雄完成，這個過程其實是固定的，唯一變的只是，需要的英雄可能不同，有人會說了，不是說英雄池也要找嗎？我們可以將很多分支的英雄池import到乙個總的英雄池中，這樣我們只在這個總的英雄池中找就好了。
是不是又會出現乙個問題？如果乙個英雄在多個英雄池中都註冊了，即多個英雄池都對他的屬性賦值了，那我們該選他的哪乙個呢？
1、如果我們只是挑選乙個分支英雄池的話，那麼自然就不會有這種糾結。
2、如果我們挑選的是總的英雄池的話，那麼對於它的屬性，後面注入到容器中的屬性，會覆蓋前面。即import在後面的保留。
這就是spring的ioc了，**層定義英雄->使用者層自定義及set依賴賦值。
設計記錄江湖仇家的小本本
it江湖亂世紛爭，刀光劍影，各類語言混戰廝打成一片，程式猿的愛恨情仇，實難數盡。為了縷清各俠客的錯綜複雜的關係，匡扶江湖的正義，心繫祖國的安危，特設計出 江湖1.0版通訊錄。此通訊錄全程c語言編寫，相容一切，適合各大俠客使用。為了正義免費使用 以下 include include define na...
mac遮蔽獨顯（我的小本本自救系列）
原文 issue fix updated 本人只負責搬運以及翻譯。整個步驟有效性自己驗證。下述論壇使用者反映，按照這個方法的確有效，簡單翻譯下 macbook有過熱保護機能，當過熱是會自動關機。如果此時被再開機的話，會自動把大多數設定設定為最小效能模式。此時獨顯被關閉，可以用集顯開機。這也意味著，即...
拿出小本本記一下C 指標和引用的混淆點
當年這裡學得亂七八糟，現在需要反覆康康，遇到問題就會補進來噢。int ptr arr 等價於 int ptr arr 0 int ar arr 1 將arr 1 的位址，賦值給ar，即 ar 0 arr 1 ar以arr 1 為首位址 void fun int ptr,int ar,int val ...