A diferencia de la mayoría de los modelos de objetos de automatización, como Microsoft Office, los objetos de FlexPro están estructurados jerárquicamente. Las propiedades y los métodos comunes a distintos objetos se resumen en un objeto base. Esta estructuración tiene lugar en varios niveles, de lo general a lo específico. La jerarquía de objetos de FlexPro sigue un poderoso principio de programación orientada a objetos: la herencia. El siguiente gráfico muestra la jerarquía de objetos del diagrama 2D de FlexPro.
|
La herencia ofrece una serie de ventajas, tanto para la implementación de FlexPro como para el uso del modelo de objetos FlexPro. Al implementar FlexPro, la herencia implica que la implementación de un objeto base pueda ser reutilizada en todos los objetos que se basan en ese objeto base. Esto hace que el software sea más compacto y fácil de mantener. El CursorObject del ejemplo anterior es el objeto base para el diagrama 2D (Diagram2D), el diagrama 3D (Diagram3D), la planilla (Worksheet) y el documento (Document). Por lo tanto, aquí se utiliza una aplicación para cuatro objetos diferentes. Cuanto más se asciende en la jerarquía de objetos, mayor es la llamada "reutilización de código". Todos los objetos que se pueden guardar en la base de datos FlexPro derivan de FpObject, por ejemplo.
La jerarquía de objetos de FlexPro es también una gran ventaja a la hora de desarrollar aplicaciones de automatización que accedan al modelo de objetos de FlexPro. Un programa que solo utiliza las propiedades y métodos de la interfaz CursorObject, por ejemplo, se ejecuta sin modificaciones con todos los CursorObjects de FlexPro (diagrama 2D, diagrama 3D, etc.), incluso si versiones posteriores de FlexPro contienen objetos adicionales derivados de CursorObject. El compilador utilizado para implementar la aplicación (Basic, C++, Java...) puede generar código muy rápido porque todos los métodos y propiedades de CursorObject ya se conocen al compilar. De este modo, las llamadas pueden convertirse directamente en direcciones, con lo que el procesamiento posterior del programa es muy rápido. En Basic, puede conseguir esta ventaja declarando la variable objeto como de tipo CursorObject. De ese modo indica al compilador qué conjunto de propiedades y métodos puede suponer que estarán presentes al traducir el programa.
Si FlexPro no tuviera una jerarquía de objetos, una variable de objeto que contuviera cualquier objeto que admita cursores tendría que ser declarada como del tipo indefinido Object. Un programa de este tipo también podría funcionar sin modificaciones con nuevos objetos que admitan cursores. Sin embargo, el proceso sería mucho más lento. Como el compilador no conoce las propiedades y los métodos del objeto concreto que contiene la variable objeto al traducir el programa, la dirección, por ejemplo, de un método solo puede determinarse cuando se ejecuta el programa. El índice del método en la interfaz se determina primero a partir de su nombre y, a continuación, se llama al método con una función general Invoke. Todos los argumentos deben empaquetarse en las denominadas variantes, ya que sus tipos de datos no se conocían en el momento de la traducción. Otra grave desventaja de este método es que muchos errores, como un nombre de método incorrecto, un número incorrecto de argumentos o un tipo de datos de argumento incorrecto, no se reconocen hasta que el programa se está ejecutando.