週末隨筆 聊一聊IOC和DI

首先，本文**的目的是如何讓系統的擴充套件性變高，以實現降低迭代成本。追求開發速度的完全不必理會。

ioc（inverse of control），控制反轉，但這個說法不夠直白，在實際生產中，用控制轉移來描述反而地道一點。今天不摳字眼，物件的控制權轉交給第三方，往往就是：某一介面具體實現類的選擇控制權從呼叫類中移除，轉交給第三方決定。 但還是很難理解。

隨後martin fowler提出了di（dependency injection）依賴注入的概念用以代替ioc，即：

讓呼叫類對某一介面實現類的依賴關係由第三方（容器或協作類）注入，以移除呼叫類對某一介面實現類的依賴。

inte***ce i 

//...
}class b 
public
void
bar() 
}

當然，使用組合要比讓b繼承a並進行擴充套件好得多，這不是今天要討論的。

這個例子的問題在於：b依賴的a由b構建。看起來好像沒什麼問題，但是：

這就是大家說的耦合變高了。

按照ioc或者di來構建**，可以減少這樣的問題。

class b 

}

class b 

public
void
seti(i i) 
}

上面介面名字定的不好，暫不修改了

inte***ce

injectdependencyi 
class
bimplements
injectdependencyi 
public
void seti(i i) 
}

顯然，這裡存在乙個ioc容器，按照規則幫我們進行一定的自動化處理，減少了手動注入的工作，而這些規則是使用註解描述的。

android中使用較多的是dagger/dagger2.本篇就先不擴充套件了。

為什麼在android客戶端工作中我們比較難體會到ioc/di的作用呢？

往往實際情況是：更多的注意力在介面、互動上，業務部分沒有那麼龐大，某一種業務的客戶可能只有乙個，即使當前的設計耦合高了不利於擴充套件，但根本沒有矛盾爆發的機會。

隨筆 聊一聊伺服器的那些事兒

今天和乙個搞前端的同學聊天，他認為的伺服器貌似和我們開發的時候的伺服器不一樣，正好藉著這個機會聊聊什麼是伺服器 大家眼中的伺服器是什麼樣子的。也就是大家心目中最常見的機房的形象，專門的環境和人員對大型伺服器進行管理。而在運維的同學眼中可能是這樣的 特點 企業購買或者租用伺服器，需要配備專門的運維人員...

聊一聊抽象類和介面

什麼是抽象類 乙個允許有抽象定義存在的類，可以像普通類一樣有屬性，成員方法，建構函式。只有方法的宣告，沒有方法的實現。也可以有預設的方法實現。怎樣定義抽象類訪問修飾符 abstract class 類名 抽象方法的作用為了約束當前方法都具有某種行為 注意 1.抽象類必須使用關鍵字宣告。2.抽象類不可...

聊一聊MyISAM和InnoDB的區別

主要有以下區別 1 mysql預設採用的是myisam。2 myisam不支援事務，而innodb支援。innodb的autocommit預設是開啟的，即每條sql語句會預設被封裝成乙個事務，自動提交，這樣會影響速度，所以最好是把多條sql語句顯示放在begin和commit之間，組成乙個事務去提交...