結(jié)構(gòu)化編程強(qiáng)調(diào)單一出口的原則，其目的在于增強(qiáng)函數(shù)流程的邏輯性。本身這個(gè)原則有些過(guò)于死板，但其保持代碼邏輯性的目的是非常正確的。在面向?qū)ο笤O(shè)計(jì)，我們都知道要遵循單一職責(zé)原則(SRP)，而函數(shù)也應(yīng)遵循這一原則，以保證函數(shù)體邏輯的清晰并且高內(nèi)聚。

以下示例中， UpdateValue 函數(shù)與下面 m_value 的賦值語(yǔ)句造成了邏輯的分散 ：

當(dāng)需要變更 m_value 的賦值邏輯時(shí)，往往會(huì)修改 UpdateValue 函數(shù)，而忽略了下面的賦值語(yǔ)句，這就會(huì)引起新的問(wèn)題。顧此失彼嘛 !

這種情況在代碼維護(hù)時(shí)最容易引入。我們解 Bug 時(shí)，如果只是頭疼醫(yī)頭，腳疼醫(yī)腳，就容易留下一個(gè)個(gè)補(bǔ)丁，而每個(gè)補(bǔ)丁就可能是一個(gè)個(gè)邏輯碎片。

這樣的分散的邏輯會(huì)加重維護(hù)的成本和風(fēng)險(xiǎn)。為了減少這種風(fēng)險(xiǎn)，首先在設(shè)計(jì)時(shí)和解 Bug 時(shí)要努力保持邏輯的一致性。遇到問(wèn)題，不是將問(wèn)題掩蓋起來(lái)，而是要實(shí)實(shí)在在的解決它。不要形成破窗，使得風(fēng)險(xiǎn)不斷累積。請(qǐng)參考 << 如何有效地解 Bug (RED 方法 ) >>

在上圖的例子中，應(yīng)當(dāng)盡量將下面的賦值語(yǔ)句移入 UpdateValue 函數(shù)中，這樣將 UpdateValue 視為 m_value 的經(jīng)紀(jì)人，統(tǒng)一管理 m_value 的值的設(shè)定。當(dāng)然，也許 m_value 所依賴(lài)的條件可能分散于各處，這是可以提供較低層次的函數(shù)來(lái)形成 m_value 的賦值入口，比如 setValue( … ) 。這就是 setter/getter 的概念了。

總之，當(dāng)設(shè)計(jì)一個(gè)函數(shù)時(shí)就要明確它的職責(zé)，讓相關(guān)的事務(wù)放到內(nèi)部處理，而不是分散各處。當(dāng)發(fā)現(xiàn)邏輯碎片產(chǎn)生時(shí)，應(yīng)當(dāng)及時(shí)加以清除，以免擴(kuò)散到影響系統(tǒng)的維護(hù)。

轉(zhuǎn)載請(qǐng)注明出處: http://blog.csdn.net/horkychen

函數(shù)的單一職責(zé)原則(SRP)