OO
OO (orientacion a objetos) es el equivalente la 'revolucion industrial' del Software. Segun cuenta la leyenda, la orientacion a objetos nacio debido a la necesidad de utilizar un dispositivo de ingreso de informacion en la Xerox, el mouse. Cuando el encargado de hacer funcionar un mouse en un computador intento programar rutinas que lo manipularan, se dio cuenta que las variantes eran infinitas, lo que obligaba a un nueva concepcion del Software: en vez de hacer funciones que reaccionaran a un diseno tipico 'Top-Down' (ingreso a una opcion, ingreso e datos, grabacion, salida de la opcion y asi sucesivamente), las funciones debian reaccionar sobre cada objeto en el que se situara. De ese modo, las funciones debian relacionarse a los objetos, no  los procedimientos. Luego, cada objeto tendria una coleccion de funciones que respondieran a lo que se hiciera sobre el mismo. Las variables serian de tipo privada y/o publica, segun la necesidad de cada caso.
Como es facil de apreciar, la orientaciona objetos siempre a existido, lo que se hizo fue aplicarla al Software. Las ventajas saltaron a la vista: Era posible escribir objetos, y para cada objeto las funciones (que se llamarian mensajes) que los gobernarian. Asimismo, un grupo de objetos crearian un objeto mayor. Veamoslo asi: un automovil tiene partes, cada parte esta compuesta de partes mas pequenas (una puerta, por ejemplo), y asi hasta llegar a las partes mas sencillas (el pestillo de la puerta). Asimismo,  cada parte tiene sus funciones especificas: el pestillo abre, cierra y asegura la puerta. Creabamos entonces todas las partes necesarias para un automovil. Luego, las partes necesarias para un segundo automovil (donde algunas eran reusadas), y como resultado teniamos ahora la posibilidad de crear varios tipos de autmoviles combinando las partes. Si no deseabamos una puerta especifica, la cambiabamos por otra puerta, o por otra, y asi ensamblabamos el modelo segun la necesidad. Del mismo modo se hizo un sistema operativo orientado a objetos, tan conocido por todos: el Windows. 
Veamos las ventajas de la orientacion a objetos:
- Reusabilidad: Cosntruiremos nuestros componentes, y luego los ensamblaremos. Al desarrollar nuevo Software, los objetos creados se utilizaran Las funciones (mensajes) que falten se anadiran, y serviran para nuestro tercer Software. Noten que, si una funcion debe ser adecuada para un nuevo Software, es mas conveniente crear una nueva funcion. De ese modo, el mismo objeo servira ara ambos Softwares. Cada uno llamara a su funcion. En teoria, el objeto siempre crecera, no se modificara, garantizando compatibilidad hacia atras.
- Facilidad en el mnatenimiento: Imaginemos que nuestro cliente nos dice que, al grabar una factura, el impuesto se calcula mal. Si hemos aplicado la orientacion a objetos, el objeto factura tendra el mensaje calcularimpuestos: el usuario nos dira donde esta la solucion de nuestro problema.
- El analisis de nuestros sistemas sera mas sencillo. Lo demostraremos con un pequeno ejercicio: un levantamiento de datos:
Necesito un modulo para poderingresar facturas, seleccionando el nombre del cliente. Si el cliente no existe, deseo anadirlo. Luego, seleccionar cada uno de los productos a incluir en la factura, poner la cantidad de cada uno en la factura, cerrar la factura, y que la factura  me calcule el monto total, incluido impuestos. 
Ok. Separemos los sustantivos, y pongamos los verbos relacionados a ellos:
factura:ingresar, poner cantidades, cerrar, calcular impuestos, calcular total
cliente:seleccionar nombre, existe,anadir
producto:seleccionar
Los nombres de los mensajes seran mnemotecnicos (p.e. factura.calcularimpuestos). Ya tenemos nuestros objetos y mensajes. El analisis esta concluido. 
Importante: Visual Basic NO es un lenguaje de programacion orientada o objetos. Es un lenguaje de programacion orientada a eventos, al cual se le ha andido la posibilidad de crear clases, pero como esquema propuesto por Microsoft para el desarrollo de aplicaciones en tres capas, donde la primera capa es el manejo de clases, pero relegadas al manejo de datos. Bajo estos terminos, la orientacion a objetos no se podra aplicar 
Terminos de la orientacion a objetos:
Objetos: Cada cosa que existe. ej. La concepcion de una ventana
Clases: La implementacion de un objeto (El crear un Objeto en Software). ej. El codigo de una ventana de Windows
Mensajes :Funciones dentro de un objeto. ej. window.Hide
Atributos: Variables de un objeto. ej. window.left
Amigos: Cuando funciones/variables pueden ser modificado desde otro objeto. ej. window.backcolor=rgb(255,55,0)
Privados: Cuando las funciones/variables no son de acceso de otros objetos. ej. window.hwnd
Herencia : Un objeto puede heredar variables/funciones de otro objeto. ej. window.controls(0).name
Encapsulacion: Un objeto encierra dentro de el sus variables/funciones. ej. windows.left (cada objeto window tiene su propio left).
Polimorfismo: Una funcion puede comportarse de mas de una manera, segun los mensajes que reciba . ej. window.backstyle

El archivo de configuracion
Normalmente, escribimos nuestro codigo fuente y, dentro de el, incorporamos las variables del sistema como "Hard-Code", o codigo duro. Como es logico, estas variables son muchas, y es un dolor de cabeza su mantenimiento y depuracion. Lo que el archivo de configuracion propone nos otorga  tres ventajas:
a. Mantener una sola variable, tipo arreglo (Variant), que nos permite accesar a todas las variables publicas -globales- en una sola.
b. Definir estas variables FUERA del sistema. Esto significa que, si deseamos cambiar un valor, no necesitaremos recompilar nuestro programa.
c. Dar inteligencia a un programa.
Veamos un ejemplo, como caso practico:
Creemos un archivo de configuracion, y pongamos dentro de el la variable de conexion a la base de datos. Pongamos tambien los colores de las ventanas, y una variable que indique si se vende al credito o no. De ese modo,   nuestro codigo sera mas o menos asi:

Ahora, si deseamos cambiar el color, lo haremos en el archivo de configuracion. Si deseamos cambiar de base de datos (Incluso, el tipo de base de datos), cambiamos la conexion. Si deseamos vender al credito, lo definiremos desde el archivo de configuracion.
Con un poco mas de trabajo, haremos nuestra pantalla de configuracion de sistema, donde seleccionaremos los titulos/posicion de las ventanas, los colores del sistema, los iconos, graficos a mostrar, etc. Adicionalmente, tendremos un mismo sistema para todos nuestros clientes, donde la diferencia entre uno y otro sistema radicara en el archivo de configuracion. Definiremos las opciones del menu que estarn visibles, los controles que se encontraran inhabilitados, el usuario que sera el admiinstrador, que elementos de una tabla no seran visibles. Las posibilidades de coniguracion son infinitas, y el limite sera solamente nuestra imaginacion. Un mismo sistema podra trabajar para distintos rubros de empresas. Incluso, un sistema podra de este modo llegar a ser multilingue.

Metodos Integrados
Se imaginan a un sistema hecho en Clipper accesando a una base de datos Access? O a un sistema que, cuando un usuario ingrese al mismo se le notifique. Que tal un sistema hecho en RMS Cobol  que envie un email cuando falle?
Los metodos integrados proponen esta teoria. Normalmente, dos sistemas se comunican entre si a traves de datos. Un sistema escribe un registro, y otro lo recoge. Pero para ello, es necesario que ambos escriban en el mismo tipos de base de datos. En donde pueden escribir todos los sistemas en comun? En archivos ASCII. Asi daremos acceso a nuestros sistemas. Uno escibira/llera instrucciones en un archivo que otro sistema leera/escribra, independientemente de la base de datos, independientemente de la plataforma, y obedecera a la isntruccion que encuentre. Algo asi como:
grenville/logistica/contabilidad/generavoucher(100,"gastos")
<usuario>/<sistema origen>/<sistema destino>/<funcion a invocar(parametros)>
La diferencia estaria en que el sistema origen y destino seran de distintas plataformas! Como es visible, un sistema deberia estar permanentemente monitoreando si se han generado nuevas instrucciones para recogerlas. No todos los lenguajes de programacion permiten hacer una funcion que recoja los menajes permanentemente (un timer), asi que en estos casos, se pondra una opcion en el menu, que recoja las instrucciones cando el usuario lo requiera.
Si se sigue en forma disciplinada esta metodologia, se crearia una libreria de funciones, documentada, y que permitiria a todos los sistemas de una empresa conversar entre si.