三言兩語說透設計模式的藝術-單例模式
寫在前面單例模式是一種常用的軟件設計模式，它所創建的對象只有一個實例，且該實例易于被外界訪問。單例對象由于只有一個實例，所以它可以方便地被系統中的其他對象共享，從而減少
作為一名開發者，我想，你最不希望發生的事情之一是：當你調試一個Bug的時候，Bug就消失了，但直接運行的時候，Bug又出現了。
通過 #ifdef DEBUG 技法，可以將額外的調試代碼放置到程序中。畢竟，這些調試代碼僅會在程序的調試版本中才會生效。但是，一定要注意的是，這些調試代碼不應該修改程序的執行邏輯。
你可以在調試代碼中執行參數驗證，執行斷言，追蹤資源的使用，這可能會降低程序的性能并消耗更多的計算資源，這些都是可以接受的，唯一需要注意的一條是：不要在調試代碼中修改程序的流程。
我們來看看下面的例子。
上面的代碼是錯誤的，你是否已經看出來了？
調試版本的行為與發行版本根本不同。如果有人使用 NULL 為 p 參數調用此函數，則程序的發行版本將崩潰，但調試版本將捕獲錯誤并使調用失敗。
不要在調試版本中修改函數的語義。如果發行版本崩潰，則調試版本也必須以相同的方式崩潰。當然，你可以在崩潰之前記錄錯誤日志信息，但你仍然需要它”崩潰”，和發行版本行為保持一致。
下面是一個展現了類似問題的 C# 代碼的例子。
在上面的例子中，調試版本記錄并吞掉了異常，而發行版本直接讓異常跳出了此函數。
如果你恰好也寫了這樣的代碼，發行版本和調試版本的行為方式根本不同，你最終會陷入這種情況：發行版本有一些問題，但調試版本工作正常。
你的客戶無法弄清楚有什么區別，因此他們切換到生產服務器上的調試版本。它的運行速度是原來的兩倍，內存消耗的內存是原來的三倍，需要大量的資源才能擴展到以前的服務級別。但這是他們能做的最好的事情，因為問題不會出現在調試版本上（因此無法在那里調試）。
我看到過關于軟件陷入這種困境的報道，這對開發人員的影響非常糟糕。
今天的論點也是我一直所忽視的：調試的代碼，就干調試的活，不要做其他事情，更不要修改程序執行流程。
第二個：調試版本和發行版本可能在執行速度，占用資源存在差異，但兩者的行為必須完全一致。
本文鏈接：http://www.tebozhan.com/showinfo-26-13573-0.html避坑：不要在調試版本中的修改程序邏輯
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 數據分析，如何助力運營？
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號