2023年Q2用戶偏好榜：12+256G版本成新主流
3月份的性能榜、性價比榜和好評榜之后，就要輪到2023年的第二季度偏好榜了，上半年的新機潮已經過去，最明顯的肯定就是大內存和存儲的機型了，另外部分中端機也取消了屏幕塑料支架
從 Java 轉到 Go 的開發同學，大概都會踩到第一個“坑”：Go 的包循環引用。
Go 的包循環引用是什么意思呢？有一定經驗的開發者都知道循環依賴，比如 A 依賴了 B， B 依賴了 C ，C 又依賴了 A。這就構成了一個循環依賴（有環圖）。
在 Java 里面，循環依賴是類級別的；但 Go 里要更嚴格一些：Go 的循環引用判定是 包級別的。舉個例子，包 A 下的類 A 依賴了包 B 下的類 B，類 B 又依賴了包 C 下的類 C， 類 C 又依賴了包 A 下的 D。在 Java 里面，這里并沒有構成循環依賴。但在 Go 里面，這導致了包循環引用：包 A => 包 B = > 包 C => 包 A。Go 會編譯不通過：報 import circle not allowed。
對包依賴不太重視的人，初期會感到不適應。本文舉幾個自己踩過的坑，作一說明。
哎呀呀，初來乍到，一下子給我來了八個包循環引用，打擊得我有點不知所措了。這是怎么回事呢 ？
圖片
第一個循環引用，是因為上報的包 agent 下對象 DetectionBase 依賴了包 denoise 下的降噪模型結果對象 HitDenoiseModel，而在某一處，HitDenoiseModel 又引用了包 agent 下的另一個對象。
為什么會發生這個事情？這是因為，圖省事，我直接把輸出對象放到了輸入對象的包里，不想復制一份。正確的做法是，輸入的對象只能放輸入對象，不能放輸出對象，否則依賴就會擴大出去。
如何解決？有兩種方案：
啟示：避免篡改輸入對象。應用中的對象往往是很多的，不太重視包依賴，很容易造成對象的循環引用。即使你自己能夠小心確保不出問題，也會和別人添加的類造成循環引用。
梅開二度。又來了一個包循環引用。
圖片
這又是怎么回事？有了第一次經驗，第二次就不那么慌了。先提個 MR ，看看引入了哪些類。尤其是循環引用的那條鏈路。我們看到 cdc/msg 這個地方作為起點開始循環。為什么會有循環呢？因為我本來打算把 msg 相關的消息對象和消息處理都放在一起。但這種方式很容易導致 循環引用。為什么呢？因為 引入消息對象的時候， 就會把包下的所有類引入的所有包都引進來，這樣就會把 /cdc/msg/XXXReceiver 引入，進而引入 /cdc/handler/XXXhandler, 而 msg/handler/XXXhandler 又會引入 msg/XXXSender。就導致了包循環引用依賴。
看來之前還是隨意慣了。
圖片
怎么解決？把 XXXReceiver 放在包 receiver 下，把 XXXSender 放在包 sender 下即可。
啟示：
一鍵三連。
下圖又是怎么回事？借鑒業界最佳實踐，咱們把一個工程下的代碼分為了 internal 和 share。其中 internal 的代碼不能被其它模塊訪問，只有 share 下的代碼作為橋梁，為其它模塊提供服務。
圖片
這個是因為 internal/detect_config/AService 引用了 share/detect_config/BService ，然后 share/detect_config/CService 又引用了 internal/detect_config/DService。internal 包怎么能夠引用 share 下的包呢 ？內部模塊怎么能夠依賴外部模塊 ？世界似乎不那么美好了。
與同事討論，他們認為，helper 不應該依賴 service ，而應該依賴 repository， 而我一直認為 helper 是對 service 提供服務的一種高層封裝, helper 依賴 service 是很正常。helper 依賴 repository， 看上去說得也很有道理。不過 internal 模塊依賴 share 模塊，看上去總是感覺有點違反單向依賴的設計原則。
經過討論后，我和同事各做了修改。我的修改是讓 helper 依賴 repository， 同事的修改是，把原來 service 拆分成公共的 service 和內部的 service，保證 share 對 internal 的單向依賴。
即使你幸運地逃過了包循環引用的檢測，但存在運行時循環依賴，Go 會直接卡住。
一個例子如下圖所示：有若干個流程組件 A, B, C，加載到一個工廠 F 下，由一個 執行器 E 依次從 F 中取出執行。但是呢，在流程組件C 中，又依賴了 E 來執行任務。這樣會導致循環依賴。在 Java 中，Spring 會忽略組件 C， 初始化成功，但運行時找不到 C 而導致流程出錯（可以用懶加載機制解決）；但是 Go 就不那么幸運了（也許是幸運的，因為它讓你早點發現問題）。
對于這種場景，可以用消息隊列來解耦。
圖片
遇到包循環引用，有哪些經驗可循呢 ？
（1） 提倡小而獨立的包。不要把大量的有關聯的類都放在一個包下。這樣，很容易因為一個類的引入，而引入更多依賴，導致依賴不可控。
（2）單向依賴原則。internal 下的類不應當依賴 share 下的類。因為 share 下的類一定會依賴 internal。如果 internal 又依賴 share ，就破壞了“單向依賴”原則。當工程越來越大時，一定會有一個點會爆發。不是不報，時候未到。細分包可以緩解這種問題，但不能從根本上避免單向依賴的破壞。
（3） 依賴倒置原則。盡量依賴接口，而不是具體實現類。
（4）使用消息隊列解耦依賴。
（5）相對合理的依賴方向：model => (constants, 無依賴的 model) ; dto => types => constants ；util => (dto, types, constants, models)；service => repository => model ；helper => (repository, util, cache) ; controller => (helper, service) ; receiver => handler => (service, helper)
最后問一句：Go 為什么不允許包循環引用呢 ？聽聽 Go 語言作者怎么說：
圖片
再聽聽 AI 怎么說 ：
本文討論了幾個包循環引用的例子，并給出了相應的對策。
個人覺得，這種禁止循環引用的做法還是可取的，能培養良好的設計習慣。軟件開發，本質是應對結構復雜性的技藝。而設計思維，則是應對結構復雜性的重要法寶。開發人員應多多學習設計思考，保持系統和架構的優雅。
[1]go循環依賴最佳解決方案:https://juejin.cn/post/7290389972406501432
本文鏈接：http://m.www897cc.com/showinfo-26-76488-0.htmlGo 包循環引用及對策，你學會了嗎？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
下一篇： 業務開發做到零 bug 有多難？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號