很早之前不知道什么时候，是在哪本书上看到还是自己臆想，得出了dll库尽量尽量只导出函数不要导出类的思维定势。总觉得似乎导出类了就心里不舒服。随着项目规模扩大被划分为越来越多的模块，只能导出函数使得基于OO思想进行设计的过程苦不堪言。比如一个数据结构，我没法导出针对这个数据结构的类定义，于是我只好声明为结构体，然后在各个使用该结构体的模块中单独的用一个类来封装他，实现在模块内部的局部低耦合高内聚，但这样问题就来了，当多个模块都要用到这个数据结构，每一模块里写一份相同的代码本身就违背了代码一次性原则，其次一旦数据结构出现变动，我还是需要在多个模块之间来回修改这些封装类，如果一个封装类出现了BUG我还需要兼顾其他封装类是不是也有问题，最后，你们都懂得，面对这种重复代码，一般我们都是C-c + C-v，这已经是个更大的忌讳了……

今天我就面临这样的问题，仔细思考后我觉得为什么要死守着这个该死的思维定势？难道就因为在def文件里很难写出来class的函数定义(确实很难写出来，我尝试过多次都放弃)，只能用__delspec(dllexport)导出所以我就厌恶了？这种理由和小孩子喜欢坐电梯不喜欢爬楼梯所以一哭二闹三上吊有什么本质区别么？没有！纯粹幼稚！以OO观点来设计系统，组成系统的重要构件dll被强制限制为不能导出OO中的第一类值Class，那这样的系统设计出来一定很别扭，或者参合着很多非OO的思想，我不反对混合编程，但问题是它确实不应该出现在这里。

写这么多的意思，就在于告诉自己，很多时候应该灵活变通，不要因为我个人喜欢A讨厌B，或者书上写了这样不好就一直墨守成规，其实好与不好本没什么分别，只有当放进一个具体的环境上下文时，才有了好与不好之说。作为设计人员，如果仅仅从自己的喜好出发墨守陈规，那必死无疑了。

项目中面临的这个问题导致了代码一次性被打破，但还不至于无可救药。在继续完成新的功能前，我大概需要2-3天时间调整一下设计做些重构和测试，这个时间是值得花的，但是如果在最初我就不那么死板，那么这个时间是完全可以省去的。

特此纪念，干活去了。