Estas son algunas observaciones que he hecho mientras se trabaja con conceptos de POO en VBA:
- No se puede sobrecargar métodos en VBA. Sin embargo, tiene parámetros opcionales a su disposición, para bien o para mal.
- Tiene un método
Class_Initialize
sin parámetros que se invoca cuando se crea una instancia del objeto, pero no se puede sobrecargar para controlar los parámetros. Si desea obligar a su clase a no ser "completamente funcional" sin tener determinadas propiedades establecidas, tendrá que escribir su propia forma de hacerlo.
- El entorno de edición VB6 y VBA te obliga a crear "archivos de clase" y mantener cada clase en un archivo separado, que son distintos de los módulos.
- Las clases y los módulos pueden tener campos públicos y privados. Un campo público en un módulo es esencialmente una variable global.
- Los módulos son funcionalmente similares a las clases estáticas en C#. El código público se puede llamar desde los módulos en cualquier lugar dentro de su aplicación.
El paradigma VB6/VBA visualiza las clases como una manera de encapsular la funcionalidad y las propiedades de un objeto. En este sentido, los objetos de VB6/VBA existen como cualquier otro entorno de OOP básico y su uso y diseño deben fomentarse cuando corresponda.
Sin embargo, la falta de varias características clave de OOP hace que VB6/VBA no llegue a ser capaz de implementar completamente un patrón de diseño de OOP completo.
http://stackoverflow.com/documentation/vba/5357/object-oriented-vba – Slai