在這本書的很前面就提到了,好的程序設計,就是要易於改變。耦合就是改變的一個大敵。
而且耦合是有傳遞性的。比如A依賴B、C,B依賴D、E,C依賴F、G。那實際上A是和BCDEFG耦合的,而不僅僅是BC。
作者有提到一些具有共性的耦合症狀:
1.不相關的模塊或庫之間存在古怪的依賴關係。
2.對一個模塊的 "簡單 "改變,卻影響到其他不相關的模塊。
3.開發人員害怕改變代碼,因為他們不確定什麼會受到影響。
4.每個人都必須參加的會議,因為沒有人確定誰會受到改變的影響。
後面兩個點,可以說字字戳心。當然,我覺得還有很大一部分是分工的邊界不明確,以及彼此溝通交流不夠的原因。
比如說,登錄的用戶名,原本只能用身份證號,後來,這塊改了,改成也能用手機號了。
但是,另外一位開發,之前在另外一個和登錄無關的模塊,做了一個通過登錄名中的身份證號提取生日的功能,因為用戶名這裡的修改,這個提取生日的功能,可能也用不了了。
原本我覺得這不算耦合的,我只把代碼層面的耦合算作耦合,但其實業務邏輯的耦合也算是一種耦合。只要A的改變會影響到B,那A和B就算耦合的,不論是哪方面。
我上面提到的這個身份證號的例子,剛好對應了作者主要提到的3個耦合發生的重災區之一——全局數據。
不是只有全局變量才叫全局數據,資料庫里的數據(上面的例子),文件系統的數據,這些都算全局數據。因為大家都能拿得到,所以用到這個數據的所有模塊都耦合在了一起。
所以,作者說儘量避免使用全局數據,如果一定要用的話,對數據進行封裝,不要直接調用,這樣至少還有調整的空間。
比如,從Config.name改成Config.getName(),這樣至少能在getName方法裡做點什麼,即便以後有改變的話,也可以做一些向後兼容。
咱今天只聊第一個重災區,其他的我們明天再聊~
字數:637
耗時:55分
··················END··················