Uso de tipos en programacion orientada a objetos
Hola :
Aqui envio una pequena introduccion a la programacion orientada a objetos y el uso de tipos, esto para los que estan comenzando en el mundo de PHP5 ,sobre todo, puede resultarle muy util.
Proceso de clasificacion :
Porque usar el modelo OO ?
Cita de Booch:
En el mundo fisico interactuamos a diario con muchos objetos, la mayoria de los cuales presentan una complejidad verdaderamente aterradora; el software, por su parte, tambien puede involucrar elementos de una complejidad extrema.
Einstein dijo:
En algun momento que “debe haber explicaciones simplificadas de la naturaleza, porque Dios no es caprichoso ni arbitrario”; sin embargo, para el ingeniero del software como nosotros, no hay fe semejante que nos conforte. La realidad es que en muchos de los problemas que tratamos la complejidad que debemos dominar es una complejidad arbitraria.
El software es inherentemente complejo y la descomposicion de un problema en varios subproblemas o subconjuntos del mismo problema y la organizacion de sus elementos ataca directamente esta complejidad, por eso es que surge el modelo orientado a objetos como una de las tecnicas de programacion que se hacen imprescindibles hoy dia. Imaginen un ingeniero civil que desea construir un sotano a un edificio de 100 plantas, eso seria es en realidad muy costoso y seguramente una invitacion al fracaso, sin embargo, en nuestro mundo del software los clientes no dudan en solicitar cambios equivalentes; por eso es necesario dominar esta complejidad, y nuestra habilidad en ese sentido es lo que nos llevara al exito o a la terminacion de proyectos con atrasos y problemas ( espero que nunca al fracaso, claro esta ).
Porque es necesario el proceso de clasificacion ?
Es el proceso mediante el cual se identifican los elementos esenciales a un problema que vamos a enfrentar y se organizan jerarquicamente como uds. han aprendido ya; este procesos puede ser tan variado como apreciaciones personales de una mancha de tinta puedan haber. Como habiamos mencionado la descomposicion y organizacion de forma jerarquica ataca directamente la complejidad del problema y al colaborar todas estas partes entre si consiguen un funcionamiento de un nivel superior para realizar asi soluciones complejas. Veamos el ejemplo del cuerpo humano, un verdadero paradigma en este sentido …. esta organizado en multiples niveles de complejidad, tanto como nosotros deseamos analizar; las celulas tienen un comportamiento bien definido ( notese que podriamos abstraernos mas aun, identificando cada uno de los componentes celulares e identificando dentro de una ceula otro nivel de complejidad ), las celulas colaboran entre si y en conjunto forma tejidos, estos a su vez tienen un comportamiento bien definido y forman organos, luego sistemas de organos, etc…
Concepto de Objeto:
El concepto de objeto es muy dificil de formalizar por su gran generalidad. En el diccionario filosofico se expresa “Es obvio que el concepto de objeto no coincide enteramente con ninguna de sus especificaciones posibles. Las cosas, los cuerpos fisicos, las entidades logicas y matematicas, los valores, los estados psiquicos, etc., son todos objetos especificados o especificables por medio de modos de ser particulares procedimientos de comprobacion, pero ninguna de estas clases de objetos posee una objetividad privilegiada y ninguna se presta para especificar, en su ambito, la caracteristica del objeto en general”
Son ejemplos de objetos: la computadora con que trabajo, el omnibus en el que voy a trabajar, los pequenos gemelos de al lado, las piezas de mi reloj despertador, etc. Los objetos tienen estado, un comportamiento bien definido e identidad.
El estado de un objeto se define a partir de los valores que en un momento dado tiene el conjunto de los atributos que lo forman. La estructura de un objeto se define como el conjunto de todos sus atributos o propiedades. Un objeto puede contener o conocer a otros objetos. Estas relaciones tambien son parte de su estado.
El comportamiento define como los objetos actuan frente a estimulos externos en terminos de cambios de estado. Esto introduce el concepto de mecanismo como un proceso de comunicacion entre objetos, donde un objeto cliente actua sobre un objeto servidor. Si un objeto servidor genera otros estimulos como parte de un mecanismo, entonces se le llama agente. Los mecanismos necesitan que el objeto servidor ofrezca una interfaz o protocolo de comunicacion conocido por el cliente.
La identidad es la propiedad de un objeto que lo distingue del conjunto de todos los demas objetos del universo a que pertenece. Los modelos de programacion orientados a objetos son representaciones abstractas de universos de este tipo.
Concepto de Clase:
Una clase, por otra parte, es una representacion abstracta que define la estructura y el comportamiento que le son comunes a un grupo de objetos. Las clases se organizan jerarquicamente en el proceso de clasificacion. Los elementos que le son comunes a dos o mas clases se generalizan en una clase mas abstracta. A las relaciones de generalizacion seles conoce como herencia. Una clase puede heredar de una o mas clases diferenciando dos tipos de herencia: simple o multiple.
Las clases mas abstractas representan a una poblacion mayor de objetos por lo que se dice que tienen mayor extension. Las mas especificas definen mayor contenido por lo que tienen mayor intension. El par extension/intension fue introducido por Leibniz para expresar la distincion que la Logica de Port Royal habia expresado mediante la pareja comprension/ extension. En una parte de su trabajo senala “El animal comprende mas individuos, pero el hombre comprende mas ideas y mas formas; el uno tiene mas ejemplares, el otro mas grados de realidad, el uno tiene mas extension, el otro tiene mas intension”
Forma canonica del modelo de objetos. Analizar un modelo desde la perspectiva del modelo de objetos implica entender ambas estructuras jerarquicas: la que define las relaciones entre los objetos; y la que define las relaciones entre clases. Grady Booch le llama forma canonica del modelo de objetos a la definicion de dos planos ortogonales, el de los objetos y el de las clases.
Que es y que no es un tipo ?
Tipos y clases:
En Programacion Orientado a Objetos es muy usual definir tipo como un sinonimo de clase. Mas adelante veremos que no son conceptos intercambiables aunque muchos teoricos prefieran considerarlo asi bajo criterios practicos. El propio Booch expresa que “Un tipo y una clase no son exactamente la misma cosa; algunos lenguajes distinguen ambos conceptos. Por ejemplo, versiones actuales del lenguajes Trellis/Owl le permite a un objeto tener simultaneamente clase y tipo. En Smalltalk, por ejemplo, los objetos de las clases SmallInteger, LargeNegativeInteger, y LargePositiveInteger son todos del mismo tipo, Integer, aunque no de la misma clase. Sin embargo, para la mayoria de los mortales, separar los conceptos de tipo y clase es confuso y adiciona muy poco valor. Es suficiente decir que una clase implementa un tipo”.
Veamos un ejemplo que demuestra que la diferencia entre tipo y clase es evidente y que define uno de los elementos mas importantes de la Programacion Orientada a Objetos (el polimorfismo).
Ejemplo del uso de tipos ( relacion de especificacion y Polimorfismo ) :
Type
TAnimal = class
Public
Procedure Muere;
End;
TMamifero = class
End;
THombre = class ( TMamifero )
Public
procedure Piensa;
End;
TRoedor = class ( TAnimal )
Public
Procedure Roe;
End;
Traton = class ( TRoedor )
End;
TReptil = class ( TAnimal )
End;
TLagarto = class ( TReptil )
End;
Var
ElAnimal : TAnimal;
Cuando nos referimos a “ElAnimal” sabes el tipo ( TAnimal ) pero no la clase de la instancia que esta referenciada por la variable ElAnimal; para saber el tipo necesitariamos conocer como se creo la instancia a la que apunta “ElAnimal”.
ElAnimal := THombre.Create;
ElAnimal := TLagarto.Create;
ElAnimal := TAnimal.Create;
ElAnimal := TRaton.Create;
Es necesario hacer una analisis referente a las implicaciones que estan relacionadas con la clase de la instancia representada por la variable ElAnimal … la sentencias que se muestran a continuacion sentencias claramente nos llevan a un error
ElAnimal.Piensa;
ElAnimal.Roe;
porque el tipo o contrato de la variable ElAnimal nos prohibe invocar operaciones o metodos que esten fuera del protocolo de ese tipo.
Aunque podriamos hacer typecast THombre(ElAnimal).Piensa y funcionaria, pero esto denota realmente un problema en el diseno del modelo porque se esta rompiendo la definicion de tipo de ElAnmial.
Como pueden seguramente observar en la mayoria de los lenguajes de programacion al definir una clase se esta definiendo tambien un tipo que representa la misma clase, porque la clase encapsula un comportamiento bien definido que puede ser contemplado como un rol, el de la misma abstraccion.
Roles y Responsabilidades :
Al definir una clase estamos definiendo a la vez un tipo ( el representado por el protocolo de la misma clase, o sea, su conjunto de operaciones ) … pero en muchas ocaciones nos encontramos con el problema de que una misma abstraccion ( o clase ) necesita presentarse de diferentes maneras a un observador diferente, o interactuar mediante diferentes protocolos con diferentes objetos.
Colectivamente, todos los metodos y subprogramas libres asociados con un objeto en particular definen su protocolo. De esta forma el protocolo de un objeto define la envoltura del comportamiento admitido por el objeto, y asi representan todas las vistas o interacciones con los demas objetos. Para la mayoria de las abstracciones no triviales o de dificil comprension es util organizar los largos protocolos en grupos logicos de comportamiento. Esas colecciones que dividen el espacio de comportamiento de un objeto, denotan los roles que un objeto puede jugar. Un rol es la mascara con que un objeto se presenta, y define un contrato entre una abstraccion y sus clientes.
estas son definiciones geniales de tipo, y es extrano que estos grandes teoricos de la programacion no se hayan cuestionado por que algunos lenguajes orientados a objetos no tienen estructuras para definir estos roles de forma explicita si tienen tal importancia en el plano del problema.
El uso de clases donde deberian usarse tipos genera problemas a la hora de entender los modelos. La relacion que existe entre las clases “Hombre” y “Animal” no estan al mismo nivel semantico que la capacidad de los hombres de tener un conjunto de operaciones que permiten que se comparen unos con otros bajo cierto criterio. La clase “Hombre” hereda de la clase “Animal” e implementan el tipo “Comparable”.
Como se puede ver el tipo “Comparable” esta mas relacionado con la necesidad que tendran objetos externos de comparar hombres en cierto mecanismo u operacion, que con la propia naturaleza de los hombres.
unit Unit2;
interface
uses SysUtils;
type
IComparable = interface
function Comparar( MiObjeto : TOBject ) : integer;
end;
THombre = class ( TInterfacedObject, IComparable )
Private
HEdad : integer;
function Comparar( MiObjeto : TObject ) : integer;
public
property Edad : integer read HEdad;
end;
implementation
function THombre.Comparar( MiObjeto : TObject ) : integer;
var
Hombre : THombre;
begin
if ( not (MiObjeto is THombre) )
then
raise Exception.Create( ‘No se pueden comparar estas instancias’ )
else
begin
Hombre := MiObjeto as THombre;
If (Hombre.Edad < self.Edad)
Then
Result := -1
Else
If (Hombre.Edad > self.Edad)
Then Result := 1
Else Result := 0;
end;
end;
end.
Espero que les sea util,
Saludos