結構化編程強調單一出口的原則，其目的在于增強函數流程的邏輯性。本身這個原則有些過于死板，但其保持代碼邏輯性的目的是非常正確的。在面向對象設計，我們都知道要遵循單一職責原則(SRP)，而函數也應遵循這一原則，以保證函數體邏輯的清晰并且高內聚。

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

當需要變更 m_value 的賦值邏輯時，往往會修改 UpdateValue 函數，而忽略了下面的賦值語句，這就會引起新的問題。顧此失彼嘛 !

這種情況在代碼維護時最容易引入。我們解 Bug 時，如果只是頭疼醫頭，腳疼醫腳，就容易留下一個個補丁，而每個補丁就可能是一個個邏輯碎片。

這樣的分散的邏輯會加重維護的成本和風險。為了減少這種風險，首先在設計時和解 Bug 時要努力保持邏輯的一致性。遇到問題，不是將問題掩蓋起來，而是要實實在在的解決它。不要形成破窗，使得風險不斷累積。請參考 << 如何有效地解 Bug (RED 方法 ) >>

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

總之，當設計一個函數時就要明確它的職責，讓相關的事務放到內部處理，而不是分散各處。當發現邏輯碎片產生時，應當及時加以清除，以免擴散到影響系統的維護。

轉載請注明出處: http://blog.csdn.net/horkychen

函數的單一職責原則(SRP)