在VBA中面向对象编程

面向对象编程（Object Oriented Programming，即OOP）相信读者都不陌生，特别是了解其他编程语言，比如C++，Python，Java等的读者。面向对象编程的思想可能是学习这些语言所必须掌握的。

然而VB/VBA的学习者，具我肤浅的了解，绝大多数都不是计算机科班出身，他们在实际工作中使用微软Office办公软件，无意或者偶然的机会，通过Alt+F11打开了Office办公软件VBE的界面，运行了一些在同事看来是魔法一样的代码，从而让平时需要耗费大量时间和精力的信息处理工作，在一瞬间就自动完成了。这种强烈的成就感促使他们开始了学习VBA的旅程。

VBA是VB6的一个子集，VB6早在本世纪初开始就逐渐淡出主流编程语言的行列。VB6/VBA之所以存活到今天，主要得益于微软的Office办公软件的成功，因为办公软件套件中，几乎全部都集成了VBE的编程界面，例如Word, Excel, PowerPoint, Outlook, Access。正式这些软件的成功，催生了一大批VBA学习者。他们遍布在各行各业的财务，人事，行政，销售，市场等等企事业部门，唯独没有来自IT部门的。

正式因为VBA的学习者五花八门的专业背景，以及学习VBA语言的简单明了的目的，导致企事业单位的各种VBA项目的可读性，可维护性，可扩展性，相比专业的软件项目而言，惨不忍睹。尽管如此，这些VBA项目很有可能又是各部门的核心关键任务工具，它将部门核心商业逻辑融入到代码中。该部门的正常运转依赖这些惨不忍睹的VBA项目。

如果VBA项目开发者离职，调岗，作为继任者，对部门核心商业逻辑方面的掌握，一般来说不会存在任何问题。然而继任者对VBA的掌握程度就不好说了。退一步来讲，就算继任者也有很好的VBA功底，前任的VBA项目代码是否具有可读性，也是一个问题。如果他能看懂，代码是否易于维护，又是另外一个问题。如果他能维护，当部门商业逻辑发生重大变化，项目的扩展性还是一个问题。

会使用VBA的员工是一把双刃剑，有他在时，一个人能扛起部门信息管理的半壁江山，一旦他离开，部门原有的高效信息流程可能就要瘫痪。作为企业和部门的管理者，要充分认识到这一点，提前采取措施，比如当VBA项目的开发者还在位时，就需要储备其他有VBA经验的员工接入其中。

作为VBA开发者，除了让VBA项目能完成部门既定任务以外，也需要规范VBA代码，学习专业软件开发人员的编程思想，提升代码的可读性，可维护性和可扩展性。

而在VBA中使用OOP，正是行之有效的方法。它不仅能达成上述目标，还能将降低复杂项目的开发难度，以及实现VBA开发者以前不敢想象的功能。

关于OOP的思想在软件开发行业的地位我就不再赘述，尽管当前行业内开始反思面向对象编程的一些不足之处，但总体而言，该思想在软件编程行业内的共识是毋庸置疑的。

市面上很少有介绍如何在VBA中使用OOP的书籍，读到这里的读者应该非常清楚其中的原因了。介绍在VB6中使用面向对象编程的书籍倒是能找出一些来，然而从语言上来讲，VBA只是VB6的一个子集，很多VB6的语言特性，已经在VBA中被削减了，比如在VB6中类模块有多种实例化属性，在VBA中简化到了2种。再如，在VB6中用于对象持久化的Property Bag功能在VBA中被削减了。一些在VB6中实现OOP的方法，在VBA中已经失效。

严格来讲，VB6/VBA甚至不算面向对象的编程语言，因为VB6/VBA只有接口继承和多态，缺少真正意义上的类的继承和多态的，直到http://VB.Net才让VB成为真正意义上的OOP语言。所以其他面向对象编程的语言的也无法适用于VB6/VBA。尽管如此，在工作实践中，我还是找到了利用现有的VB6/VBA的语言特性，实现OOP思想的最佳实践。

我以前在工作中大量使用OOP的思想来开发我的每一个VBA项目，例如，将商业逻辑写入Access类模块中，而不是写在窗体和查询中，从而可以集中化管理这些商业逻辑，当商业逻辑发生变化时，只需要修改一个地方，而不需要检查更新所有的窗体和查询以及代码模块；使用OOP来创建响应式的项目界面，在我的个人网站上，该界面的开源文件的下载量是排名第一；使用OOP来创建通用项目开发平台，集成通用的Excel文件导入模块，加密压缩导出文件等；数据层，视图层，控制层的MVC三层逻辑构建中也是基于OOP的思想才能实现。

有意进一步提升VBA编程技能，需要有一定的VBA初级开发经验。