單元是邏輯上的，單元這詞還真不好拿一個比較準確的句子去概述，在實際的代碼編寫過程中，究竟怎麼劃分單元，是一個很有意思的問題，拿一個DAO的編寫來探討。
寫一個DAO的時候，先寫接口，再寫實現類，程序員基本是這麼幹的，那麼DAO中需要用到的SQL語句放在什麼地方呢？不外乎這四種做法
- 在接口中定義靜態公共變量，並初始化之
- 在實現類中定義靜態公有(或私有)變量，並初始化之
- 在外部資源文件中定義SQL語句，在實現類中合適的時機讀取該SQL語句
- 在實現類的方法中定義局部變量，並初始化之
代碼編寫的步驟是先寫SQL，然後在函數中執行，並返回結果。在理想的情況下，SQL是正確的，在函數中執行也沒有遇到問題，這個過程只需要一遍即可完成。但是這種情況極少能出現，一個函數編寫完到調試完畢，輸出正確的結果，怎麼的說也要在檢查SQL語句，調試函數內語句之間切換個好幾次的，如果初次的SQL語句不正確，還要對其進行修改。
因此，前面所說到的單元問題在這個時候產生了效應，第一種方法需要修改接口中的靜態公共變量，也就是要切換到另外一個類中，這個時候，類可以看着是一個單元。函數本身也是一個單元，在這種做法中，總共需要跨越兩個單元。
第二種方法，修改SQL，需要跨越函數本身，跨越了一個單元。
第三種方法，如果需要修改SQL，需要到相關的資源文件中去修改，假如讀取SQL文件的類也算一個單元，那麼可能會有一些額外的成本去調試讀取的SQL是否正確，對SQL語句進行資源統一編號。這樣算下來，修改SQL最多需要跨越四個單元。
第四種方法，本地的局部變量，直接修改，對其他的模塊無任何影響。前面三種做法中，假如SQL被多個模塊所引用，修改SQL時，也修改了另外一個實現函數的邏輯。因此，耦合性很大。
但前三種方法在代碼的設計過程中，經常被用到，不止如此，第四種做法還經常被嘲笑爲低手的做法。但是仔細的分析後，第四種做法恰恰是在代碼設計上一個好的做法，它遵循了修改其本身對其他單元不影響的原則，修改其本身時，也只要在其單元內部進行。這個原則我們稱之爲單元功能代碼的就地原則。
<完>