開發框架背后的事
如果某個開發框架向它的客戶暴露了一些由底層提供的功能，那么，將客戶從底層代碼中那些”臟活”和”隱藏限制”的部分隔離開來，到底有多難呢？
你可能憑直覺說，”框架本來就應該將客戶完全從底層細節隔離開嘛！這不正是框架應該做的事情嗎？” 但是，事情可能沒這么美好，特別是當你知道你正在提出的是一個什么樣的要求的時候。
如果框架完全將客戶從底層細節中隔離，則不管通過什么方式，框架必須為底層代碼中的每一個限制提供一種WorkAround來繞開它。這就意味著框架中需要編寫很大一部分代碼來模擬某個丟失的特性或者移除某一種限制，這些代碼僅僅是為了防止有人在使用框架時偶然碰到這個限制。
舉個例子
我們來看看ToolTip的AutoPopDelay屬性。ToolTip類是一個基于通用ToolTip窗口類的一個封裝。如果你仔細看看關于TTM_SETDELAYTIME這個消息的話，你會發現，延遲時間(iTime)是通過LPARAM的低16位進行傳遞的。所以，這就會出現一個限制了，也即這個延遲時間會被限制為一個16位的值，而在這個例子中，它將會是一個16位的帶符號的整數，因為它的負數值也有一些特殊的含義。
因為對于一個16位帶符號的整數來說，其最大值是32767，所以你能設置的最大的延遲時間僅僅會比32秒長一點點。
所以，如果你嘗試設置這個ToolTip.AutoPopDelay屬性的值長一點，比如60秒，則你會發現，代碼將不會按照你的預期工作，因為這個ToolTip類僅僅將你設置的值直接傳遞給底層的Tooltip控件。所以，在你了解這個底層控件的限制之前，你是無論如何也不會明白為什么代碼不能正常的。
總結
從破壞性來說，對越底層的代碼進行修改，對整體軟件結構帶來的結構性破壞就越大。所以，不要，或者說盡量不要隨意修改底層代碼。換句話說，設計底層代碼結構時，盡量設計成那種不經常需要改動的樣子。
