資料庫其實也是一個製造耦合的地方

莫愆 發佈 2022-09-24T20:10:58.297505+00:00

大家好哇,今天接著看書,今天這一章是講的耦合,算是一個老生常談的話題。在這本書的很前面就提到了,好的程序設計,就是要易於改變。


大家好哇,今天接著看書,今天這一章是講的耦合,算是一個老生常談的話題。

在這本書的很前面就提到了,好的程序設計,就是要易於改變。耦合就是改變的一個大敵。

而且耦合是有傳遞性的。比如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··················


關鍵字: