谈谈开发框架的稳定性

开发框架背后的事

如果某个开发框架向它的客户暴露了一些由底层提供的功能，那么，将客户从底层代码中那些”脏活”和”隐藏限制”的部分隔离开来，到底有多难呢？

你可能凭直觉说，”框架本来就应该将客户完全从底层细节隔离开嘛！这不正是框架应该做的事情吗？” 但是，事情可能没这么美好，特别是当你知道你正在提出的是一个什么样的要求的时候。

如果框架完全将客户从底层细节中隔离，则不管通过什么方式，框架必须为底层代码中的每一个限制提供一种WorkAround来绕开它。这就意味着框架中需要编写很大一部分代码来模拟某个丢失的特性或者移除某一种限制，这些代码仅仅是为了防止有人在使用框架时偶然碰到这个限制。

举个例子

我们来看看ToolTip的AutoPopDelay属性。ToolTip类是一个基于通用ToolTip窗口类的一个封装。如果你仔细看看关于TTM_SETDELAYTIME这个消息的话，你会发现，延迟时间(iTime)是通过LPARAM的低16位进行传递的。所以，这就会出现一个限制了，也即这个延迟时间会被限制为一个16位的值，而在这个例子中，它将会是一个16位的带符号的整数，因为它的负数值也有一些特殊的含义。

因为对于一个16位带符号的整数来说，其最大值是32767，所以你能设置的最大的延迟时间仅仅会比32秒长一点点。

所以，如果你尝试设置这个ToolTip.AutoPopDelay属性的值长一点，比如60秒，则你会发现，代码将不会按照你的预期工作，因为这个ToolTip类仅仅将你设置的值直接传递给底层的Tooltip控件。所以，在你了解这个底层控件的限制之前，你是无论如何也不会明白为什么代码不能正常的。

总结

从破坏性来说，对越底层的代码进行修改，对整体软件结构带来的结构性破坏就越大。

所以，不要，或者说尽量不要随意修改底层代码。

换句话说，设计底层代码结构时，尽量设计成那种不经常需要改动的样子。