ListView是一个用来呈现数据的 ， 非常强大的控件 。 当它处于报告模式(report mode)时 ， 它会创建一个列头控件 ， 用来显示表格中每一列的标题 。 这个列头控件是ListView控件的属性 ， 但是ListView还是十分善意第提供了一个获取其句柄的方法 ， 这样你就可以操作列头控件 。
【苹果|关于ListView控件的兼容性的一则轶事】但是 ， 有些开发者却滥用了这种善意 。
在原始版本的ListView控件中 ， 它没有使用列头控件条目的LPARAM来保存任何数据 。 有些开发者就说 ， ”挺好啊 ， 你们没有用到这个 ， 我就用了哦” 然后就在这个LPARAM中保存一些应用程序的一些私有数据 。
冲突在新版本的ListView中发生了 。 ListView的开发团队决定 ， ”我需要在每一个列头条目中保存一些状态数据了 。 幸运的是 ， 这个是ListView内部使用的控件 ， 我可以保存一些私有数据到列头项目的LPARAM中 ， 客户代码应该不会有任何影响 ， 太棒了！”
然后应用程序兼容性团队将这两种成分（将数据填充到标题控件中的程序和执行相同操作的列表视图）带到他们的实验室 ， 将它们混合 ， 然后爆炸就发生了 。
经过一些取证分析 ， ListView开发团队弄清楚了发生了什么 ， 他们必须设计一种方案来解决这个内部数据结构导致的冲突 。 后来 ， 开发团队绞尽脑汁 ， 终于将他们用到的私有数据存储在控件的其他地方 ， 以便这些客户程序可以继续运行而不会崩溃 。
这个故事的寓意是：即使你改变了一些没人应该依赖的东西 ， 也很有可能有人依赖它 。
有人会说 ， 你可以直接不考虑兼容性 ， 这样应用程序的开发者就不得不修改他们的程序了 。
如果我告诉你 ， 如果这个程序是一个被广泛使用的系统工具怎么办？用户只会看到他们之前正常使用功能的工具不能工作了 ， 而不会想到底层的原因 。
算了 ， 还是继续努力保持兼容性为妙 。
总结我学习到：如果你不希望别人访问你的对象 ， 就不要暴露出可以操作对象的句柄 。
看来 ， 面向对象编程我还得再学几年 。
最后Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一 ， 里面有很多关于Windows的小知识 ， 对于广大Windows平台开发者来说 ， 确实十分有帮助 。
本文来自：《The compatibility constraints of even your internal bookkeeping》

猜你喜欢