EJEMPLO 2. CLASES ABSTRACTAS

EN ESTE PROGRAMA ESTAMOS IMPLEMENTANDO CLASES ABSTRACTAS.
CONTIENE 3 CLASES Y UN MODULO PRINCIPAL

Public MustInherit Class poligono
Protected m_x, m_y As Double
Public Property x() As Double
Get
Return m_x
End Get
Set(ByVal Value As Double)
m_x = Value
End Set
End Property
Public Property y() As Double
Get
Return m_y
End Get
Set(ByVal Value As Double)
m_y = Value
End Set
End Property

Public MustOverride Function calcular() As Double

End Class


Public Class cuadrado
Inherits poligono

Public Overrides Function calcular() As Double
Return m_x * m_y
End Function

Public Sub New(Optional ByVal x As Double = 0, Optional ByVal y As Double = 0)
m_x = x
m_y = y
End Sub
End Class


Public Class triangulo
Inherits poligono
Public Overrides Function calcular() As Double
Return (x * y) / 2
End Function
Public Sub New(Optional ByVal x As Double = 0, Optional ByVal y As Double = 0)
m_x = x
m_y = y
End Sub

End Class

' MODULO PRINCIPAL

Module Module1
Sub Main
Dim pol As poligono = New cuadrado (10,5)
MSGBOX(CStr(pol.calcular())

pol = New triangulo (10,10)
MSGBOX(CStr(pol.calcular())
End sub
End Module

Ejemplo de una clase abstracta

EL SIGUIENTE PROGRAMA ES UNA APLICACION DE WINDOWS.
CONTIENE:
TRES CLASES, LAS CUALES ESTAN DIVIDIDAS EN DOS BLOQUES UNO ACTIVO Y OTRO EN COMENTARIOS. EN EL BLOQUE DE COMENTARIOS SE ESTA IMPLEMENTANDO LAS CLASES ABSTRACTAS, EN EL QUE NO TIENE COMENTARIOS SOLO SE LE ESTA APLICANDO HERENCIA.

Public Class Cuenta
Protected m_balance As Decimal
Public Property balance() As Decimal
Get
Return m_balance
End Get
Set(ByVal Value As Decimal)
m_balance = Value
End Set
End Property


Public Sub New(Optional ByVal iniciobalance As Decimal = 0)
m_balance = iniciobalance
End Sub
End Class
'**********************************************************************
'Public MustInherit Class Cuenta
' Protected m_balance As Decimal
' Public Property balance() As Decimal
' Get
' Return m_balance
' End Get
' Set(ByVal Value As Decimal)
' m_balance = Value
' End Set
' End Property

' Public MustOverride Sub CierredelMes()
' Public Sub New(Optional ByVal iniciobalance As Decimal = 0)
' m_balance = iniciobalance
' End Sub
'End Class


Public Class cuentadeahorro
Inherits Cuenta
'interes compartido, por default es 0.5% al mes
'The Shared keyword indicates that one or more declared programming elements are shared. Shared elements are not associated with a specific instance of a class or structure. You can access them by qualifying them either with the class or structure name, or with the variable name of a specific instance of the class or structure.

Protected Shared s_interes As Decimal = CDec(0.005)

Public Shared Property interes() As Decimal
Get
Return s_interes
End Get
Set(ByVal Value As Decimal)
s_interes = Value
End Set
End Property

Public Sub New(Optional ByVal iniciobalance As Decimal = 0)
MyBase.New(iniciobalance)
End Sub

Public Sub CierredelMes()
If m_balance < 0 Then
m_balance -= 25
Else
m_balance *= 1 + s_interes
End If
End Sub
End Class
'**********************************************************************
'Public Class cuentadeahorro
' Inherits Cuenta
' Protected Shared s_interes As Decimal = CDec(0.005)

' Public Shared Property interes() As Decimal
' Get
' Return s_interes
' End Get
' Set(ByVal Value As Decimal)
' s_interes = Value
' End Set
' End Property

' Public Sub New(Optional ByVal iniciobalance As Decimal = 0)
' MyBase.New(iniciobalance)
' End Sub

' Public Overrides Sub CierredelMes()
' If m_balance < 0 Then
' m_balance -= 25
' Else
' m_balance *= 1 + s_interes
' End If
' End Sub
'End Class

Public Class CuentadeCheques
Inherits Cuenta
Public Sub CierredelMes()
If m_balance < 0 Then
m_balance -= 25
ElseIf m_balance < 2500 Then
m_balance -= 4
End If
End Sub

Public Sub New(Optional ByVal iniciobalance As Decimal = 0)
m_balance = iniciobalance
End Sub
End Class
'**********************************************************************
'Public Class CuentadeCheques
' Inherits Cuenta
' Public Overrides Sub CierredelMes()
' If m_balance < 0 Then
' m_balance -= 25
' ElseIf m_balance < 2500 Then
' m_balance -= 4
' End If
' End Sub

' Public Sub New(Optional ByVal iniciobalance As Decimal = 0)
' m_balance = iniciobalance
' End Sub
'End Class

CODIGO DEL BOTON DE LA FORMA:

Dim cc As CuentadeCheques = New CuentadeCheques(CDec(txtinibalanceCC.Text))
cc.CierredelMes()
txtbalanceCC.Text = cc.balance

Dim ca As cuentadeahorro = New cuentadeahorro(CDec(txtIniBalanceCA.Text))
ca.CierredelMes()
txtbalanceCA.Text = ca.balance
'**********************************************************************
'Dim c As Cuenta = New CuentadeCheques(CDec(txtinibalanceCC.Text))
'c.CierredelMes()
'txtbalanceCC.Text = "$ " & c.balance

'c = New cuentadeahorro(CDec(txtIniBalanceCA.Text))
'c.CierredelMes()
'txtbalanceCA.Text = "$ " & c.balance

Funciones Virtuales-Overridable

FUNCIONES VIRTUALES
Las funciones virtuales son usadas principalmente en lenguajes en C++ o C#, la implementación de funciones virtuales en Visual Basic .NET es a través de la sobre escritura de métodos o propiedades o subrutinas.

Public MustInherit Class animal

Public Overridable Function mensaje()
MsgBox("no se que tipo de bestia soy")
End Function

Public Overridable ReadOnly Property msg1() As String
Get
Console.WriteLine("No se que tipo de animal soy")
End Get
End Property

Public Overridable Sub quetipo()
MsgBox("Que tipo soy")
End Sub

Public MustOverride Function mensaje2()


End Class

Public Class humano
Inherits animal
Public Overrides Function mensaje()
MsgBox("se que soy humano")
End Function

Public Overrides ReadOnly Property msg1() As String
Get

Return "soy un humano en la propiedad"
End Get
End Property
Public Overrides Sub quetipo()
MsgBox("soy del tipo de humano")
End Sub

Public Overrides Function mensaje2()
MsgBox("Este es un mensaje de los humanos")
End Function

End Class

Public Class perro
Inherits animal
Public Overrides Function mensaje()
MsgBox("soy un perro")
End Function
Public Overrides ReadOnly Property msg1() As String
Get
Return "soy un tipo de perro"
End Get
End Property

Public Overrides Sub quetipo()
MsgBox("soy del tipo perro")
End Sub

Public Overrides Function mensaje2()
MsgBox("Este es un mensaje de los perros")
End Function
End Class


La idea detrás del polimorfismo es que a un grupo de objetos heterogéneos (por ejemplo, manzanas, naranjas, plátanos) pueda hacer que se vean como homogéneo (por ejemplo, frutas), pero puedan ser diferenciadas basados en su propio tipo especifico al ejecutarse.


Module Module1
Sub Main()
'Console.WriteLine("Vamos a mostrar a un humano")
Dim animal1 As animal = New humano
'animal1.mensaje()
'Console.WriteLine("Vamos a mostrar a un perro")
Dim animal2 As animal = New perro
'animal2.mensaje()
'MsgBox(animal1.msg1)
'animal1.quetipo()
'animal2.quetipo()

animal1.mensaje2()
animal2.mensaje2()
End Sub
End Module

La palabra New introduce una Nueva cláusula (punto, condición), la cual crea un nuevo objeto de la instancia. La cláusula New debe de especificar una clase definida de la cual la instancia pueda ser creada. Podemos usar New en una declaración de un enunciado o en un enunciado de asignación. Cuando el enunciado es ejecutado, este llama al constructor para la clase especifica, pasando cualquier argumento que hayas suplido.

Since arrays are classes, New can create a new array instance:
Dim MyArray As Integer()
MyArray = New Integer() {0, 1, 2, 3}

Clases Abstractas
Habra algunos casos en las cuales la clase base de una herencia gerarquica ocupe un metodo sobrescrito *(overridable ), pero la clase por si misma no puede proveer ninguna implementacion para le método. En este caso lo que necesitamos es una forma de forzar a la clase derivada sobre escribir el Método.
<<>>


Los métodos declarados como MustOverride no deben de tener un cuerpo, y no deben de terminar en End Sub ó End Function. Ademas una clase que contiene uno o mas métodos de este tipo (conocidos como métodos abstractos) deben de ser declarados como MustInherits aun así que no tenga métodos abstractos, solo para prevenir que algunos clientes creen instancias de este tipo.

Public MustInherits Class Account
Protected m_balance as Decimal
‘el resto del código omitido
Public MustOverrides Sub CloseMonth()
End Class

Esto significa que podemos ahora tratar cualquier método o subrutina gericamente. En general se puede tener herencia jerárquica con múltiples niveles de clases abstractas, pero esto es inusual. En caso de que no pueda omitirse, todas las clases derivadas deben de implementar en todos los métodos declarados como MustOverride de todas las clases abstractas en sus ancestros de los cuales heredaron, o convertirse a si mismo abstractos (usando MustInherit).

Bibliografía
Virtual functions
Foundations of OOP Using dot NET 2.0 Patterns.pdf p.13
Visual Basic .NET by example p.327-328

Polimorfismo

Polimorfismo viene de la raíz del Griego polu (muchos) y morphe (forma), y significa en términos de computación una entidad que puede tener múltiples formas o comportamiento diferente. En el caso especifico de herencia significa que las clases derivadas pueden tener comportamientos diferentes para el mismo método.
Ejemplo de un metodo sencillo

Public Class Empleado
Inherits Person
Protected m_salario as Decimal
‘El resto del código omitido
Public Function PagoMensual() as Decimal
Return m_salario / 12
End Function

Public Class Empleado
Inherits Person
Protected m_salario as Decimal
‘El resto del codigo omitido
Public Overridable Function PagoMensual() As Decimal
Return m_salario/12
End Function
End Class

Sobre escribiendo el metodo en una clase derivada

Public Class EmpleadoVentas
Inherits Empleado
Protected m_bonoExtra as Decimal
‘el resto del codigo omitido
Public Overrides Function PagoMensual() as Decimal
Return (m_salario / 12) * (1+ m_bonoExtra)’Es el porcentaje del bono
End Function
End Class

Public Class Gerente
Inherits Empleado
Protected m_bono as Decimal
‘El resto del codigo omitido
Public Overrides Function PagoMensual() as Decimal
Return MyBase.PagoMensual() * m_bono
End Function
End Class

Como podemos ver de este ejemplo, usamos Overrides para los métodos en las clases derivadas para especificar que vamos a sobreescribir el comportamiento de un método declarado en la clase base. Podemos acceder de un método que fue Overridable (se puede sobre escribir) en una clase derivada y utilizar la implementación del método utilizando la palabra MyBase.

La razón por la que el polimorfismo es una técnica tan popular en la programación orientada a objetos es el hecho de que el compilador conoce que tipo de objeto esta tratando. Aun así de que el objeto se use a través de una referencia de su clase base.

Es importante que entendamos que hay una diferencia fundamental entre el concepto de sobrecargo (overloaded) en métodos y propiedades y el concepto de polimorfismo Sobre escritura de métodos y propiedades (overridable methods and properties). Sobrecargo (Overloading) significa tener mas de un método con el mismo nombre, pero un listado diferente de argumentos (numero, orden o tipo), en la misma clase o en combinación de las clases base o derivadas. Sobrescribir (Overriding) un método significa tener un método con el mismo nombre y los mismos argumentos en una clase derivada, un metodo que sera llamado automáticamente cuando un objeto de la clase derivada es el objetivo de la invocación. Cuando un método sobrecargado es llamado, esta determinado por el que lo llama. Cuando se llama a un método Sobrescrito (Overridden), el programa decodifica la implementación del método a llamar (la clase base o la clase derivada) dependiendo del tipo.


Un comportamiento existente de una clase base puede ser completamente redefinido o sobreescrito en una clase derivada, pero solo si el programador de la clase base lo hace permisible. Para que un metodo pueda ser sobrescrito (overridden), debe de ser declarado usando el modificador Overridable.

Métodos y Sobrecargos

Métodos
Sobrecargo

Hay algunos casos cuando una clase necesita realizar la misma actividad empezando con los mismos valores de entrada-esto es, con diferentes argumentos. Hemos visto algunos ejemplos de este comportamiento cuando vimos constructores. Las mismas reglas aplican para los métodos con sobrecargo. Una clase que modele una calculadora podria tener un método llamado Add que podria ser sobrecargado para que tome diferentes tipos de valores numericos (short, Integer, Long, etc…)

Public Class Calculator
Public Overloads Function Add(ByVal x As Short, ByVal y As Short) As Long
Return x + y
End Function
Public Overloads Function Add(ByVal x As Integer, ByVal y As Integer) As Long
Return x + y
End Function
Public Overloads Function Add(ByVal x As Long, ByVal y As Long) As Long
Return x + y
End Function
End Class

La palabra Overloads es usado para indicar que el método esta siendo sobrecargado. Podemos ahora usar la clase para calcular la suma de dos Integer, longs u otros. Por ejemplo podriamos usar la clase Calculador de la siguiente manera:


Module Module1
Sub Main()
Dim result As Long
Dim calc As Calculator
calc = New Calculator
'Dim calc As New Calculator()

Dim s1 As Short = 3, s2 As Short = 5
result = calc.Add(s1, s2)

Console.WriteLine("Resultado de la suma de Short: {0}", result)

Dim i1 As Integer = 3, i2 As Integer = 5
result = calc.Add(i1, i2)
Console.WriteLine("Resultado de la suma de Integer: {0}", result)

Dim j1 As Long = 3, j2 As Long = 5
result = calc.Add(j1, j2)
Console.WriteLine("Resultado de la suma de Long: {0}", result)

Console.ReadLine()

End Sub
End Module

El uso de la palabra Overloads es requerida para todos los métodos que tienen el mismo nombre. Tambien, los métodos sobrecargados deben diferir en su listado de argumentos: Deben de tener diferentes numeros o diferente tipos de argumentos, o tenerlos en diferente orden.

Los Métodos sobrecargados deben de ser usados para realizar tareas que son muy similares pero pueden tener parámetros de entrada diferentes. No debemos utilizar los métodos sobrecargados para realizar tareas que son semánticamente diferentes, esto es, tareas que no realizan la misma acción.

Se verá más a detalle a cerca de los métodos sobrecargados cuando veamos herencia e interfaces.

Herencia Multinivel

Herencia Multinivel

La herencia puede tener multiples niveles. Esto es, una clase base puede tener clases derivadas, cada una de las cuales puede tener clases derivadas, y continuar heredando.Estas clases constituyen lo que conocido como herencia jerárquica o arbol de herencia. Todas las reglas que aplican a una herencia de un solo nivel tambien aplican para la herencia múltiple. Podemos extender nuestro ejemplo de la persona, empleado y cliente y agregarle dos mas clases a la herencia: EmpleadoVentas y Gerente. Estas estan derivadas de la clase Empleado. Los empleados de ventas tienen un salario base (representado por la clase base Empleado m_salario) y un bono mensual, que es calculado en base a un porcentaje de su salario. El gerente tiene un salario (como el empleado) y tiene tambien un bono gerencial. Hemos cambiado el campo m_salario como protected y le hemos agregado dos nuevas clases.

Public Class EmpleadoVentas
Inherits Empleado

Protected m_bono As Decimal

Public Property bono() As Decimal
Get
Return m_bono
End Get
Set(ByVal Value As Decimal)
m_bono = Value
End Set
End Property

Public Sub New(Optional ByVal nombre As String = "", _
Optional ByVal fecha As Date = #1/1/1990#, _
Optional ByVal email As String = "", _
Optional ByVal salario As Decimal = 0, _
Optional ByVal bono As Decimal = 0)
MyBase.New(nombre, fecha, email, salario)
m_bono = bono
End Sub
End Class

Public Class Gerente
Inherits Empleado
Protected m_bono As Decimal

Public Property bono() As Decimal
Get
Return m_bono
End Get
Set(ByVal Value As Decimal)
m_bono = Value
End Set
End Property

Public Sub New(Optional ByVal nombre As String = "", _
Optional ByVal fecha As Date = #1/1/1990#, _
Optional ByVal email As String = "", _
Optional ByVal salario As Decimal = 0, _
Optional ByVal bono As Decimal = 0)
MyBase.New(nombre, fecha, email, salario)
m_bono = bono
End Sub
End Class
Module Module1

Sub Main()
Dim EV As EmpleadoVentas
EV = New EmpleadoVentas("jose", #12/12/2006#, "jose@uabc.mx", 500.55, 200.45)


End Sub

End Module


Una cosa que es muy notable en las clases que son derivadas de otras clases derivadas es el uso de la palabra MyBase. Cuando se uso en la clase EmpleadoVentas, por una instancia, no refleja solo los miembros de la clase base de EmpleadoVenta (empleado), si no todos los miembros de Empleado, y cualquier miembro del cual el Empleado hereda de sus parientes (person). Estos miembros seran visibles cuando teclees MyBase el cual le va a seguir un punto y saldrá el listado de todos los miembros.

Bibliografia VB .NET by Example p .315-321

Implicaciones de la Herencia

Implicaciones de la Herencia

Visibilidad
Hemos visto que los miembros de una clase puede tener uno de los tres modificadores de acceso estandares (Public, Private, y Friend). Tambien hemos mencionado, que podemos tener miembros declarados como protected y veremos como son y como usarlos.

Primero ocupamos mencionar que los modificadores public, private y friend son exactamente lo mismo en el caso de las clases derivadas o base. Un miembro public es accesible a cualquiera en el proyecto y fuera de el. Un miembro privado es accesible solamente dentro de la clase en la cual es declarada, pero no en cualquier clase derivada de esa clase! Los miembros amigos son visibles a cualquiera dentro del proyecto de donde la clase pertenece o es parte. Estos modificadores no cubren algunos casos especiales y por esa razón algunos modificadores nuevos tuvieron que ser añadidos.

Un campo private declarado en la clase base no puede ser accedido en cualquiera de los métodos de las propiedades de una clase derivada. En nuestro ejemplo, el campo m_nombre declarado en persona no podía ser accedido en un método de empleado, la clase empleado podía acceder a la propiedad nombre, el cual es declarado como publico. En general, podemos usar propiedades publicas para ofrecer acceso a los miembros privados, desafortunadamente, esto hará que las propiedades sean accesible a cualquiera. Alternativamente podríamos hacer las propiedades friend, de tal manera que puedan ser accedidas solamente de este proyecto. Pero en este caso no puedes usarlo de las clases de proyectos diferentes que deseas que herede de tu clase.

Habrá casos en los cuales en el que alguno de los miembros deban ser accedido por la clase por la que fueron declaradas y todas las clases derivadas de ella, pero no por cualquiera. Estos tipos de miembros deben de ser declarados como Protegidos (protected). Le da mas sentido declarar un miembro (normalmente un campo o una propiedad) como Protegido (protected) solamente si se intenta ser usada por clases derivadas de la clase en la cual es declarada. Si nadie va a heredar de la clase (si es una clase amiga, y no visible fuera del proyecto) Entonces los miembros protegidos funcionan igual que los miembros privados.

Si un miembro de la clase debiera de ser accedido por cualquiera en el proyecto y solo la clases derivadas fuera del proyecto, entonces los modificadores protegidos y los amigos pueden ser combinados. Los campos Protected Friend, propiedades, y metodos, son accesibles por cualquiera en el proyecto de la clase donde fue declarada y solamente de las clases derivadas de otros proyectos, los cuales extienden la clase en cuestión.

Public Class Persona
Protected m_nombre As String
Protected m_fecha As Date
Protected m_email As String

Public Property nombre() As String
Get
Return m_nombre
End Get
Set(ByVal Value As String)
m_nombre = Value
End Set
End Property

Public Property fecha() As Date
Get
Return m_fecha
End Get
Set(ByVal Value As Date)
m_fecha = Value
End Set
End Property

Public Property email() As String
Get
Return m_email
End Get
Set(ByVal Value As String)
m_email = Value
End Set
End Property

Public Sub New(Optional ByVal name As String = "", Optional ByVal fecha As Date = #1/1/1980#, Optional ByVal email As String = "")
m_nombre = name
m_fecha = fecha
m_email = email
End Sub

End Class


Hemos añadido un constructor con tres parámetros opcionales a la clase persona. Este es un constructor regular, el cual le asignara a los tres campos el valor del parámetro.

Public Class Empleado
Inherits Persona

Private m_salario As Decimal

Public Property salario() As Decimal
Get
Return m_salario
End Get
Set(ByVal Value As Decimal)
m_salario = Value
End Set
End Property

Public Sub New(Optional ByVal nombre As String = "", Optional ByVal fecha As Date = #1/1/1980#, Optional ByVal email As String = "", Optional ByVal salario As Decimal = 0)
MyBase.New(nombre, fecha, email)
m_salario = salario
End Sub

End Class

Hemos añadido un constructor tambien a la clase empleado, el cual llama el constructor MyBase (la clase persona) y asigna el salario.

MyBase puede estrictamente ser usado dentro de una clase derivada para acceder a la clase base. MyBase no es realmente un objeto. No se debe de usar si la clase base tiene miembros que pueden ser accedidos directamente. Sin embargo, esta no es el caso en este ejemplo, es por eso que lo necesitamos.
Ahora podemos construir un nuevo empleado.
Module Module1

Sub Main()
Dim e As Empleado
e = New Empleado("daniel", #12/19/1972#, "dgallo@univer.com", 154.25)

End Sub

End Module

Tarea 2 Modulo

Module Module1

Sub Main()
Dim Doc As docente
Doc = New docente

Dim Alu As alumno
Alu = New alumno

Dim Adm As Administrativo
Adm = New Administrativo

Dim x As Integer
Dim opc As Integer
Dim bec As String
Dim nmaterias As Integer

Do
Console.WriteLine("1.- Captura de Alumno")
Console.WriteLine("2.- Captura de Docente")
Console.WriteLine("3.- Captura de Administrativo")
Console.WriteLine("4.- Mostrar todos los datos")
Console.WriteLine("5.- Salir")
opc = Console.ReadLine()
Select Case (opc)
Case 1
Console.WriteLine("Matricula: ")
Alu.Matricula = Console.ReadLine()
'solo para restringir con una 's' o un 'n' en la captura
Do
Console.WriteLine("Becado s/n")
bec = Console.ReadLine()
If bec = "s" Then
Alu.Becado = True
ElseIf bec = "n" Then
Alu.Becado = False
End If
If bec <> "s" And bec <> "n" Then
Console.WriteLine("Tienes que teclear la letra s o la letra n minusculas")
End If
Loop While bec <> "s" And bec <> "n"
Console.WriteLine("Turno M / V ")
Alu.Turno = Console.ReadLine()


CapDatP(Alu)
Console.WriteLine("")
Console.WriteLine("")
Console.WriteLine("Mostrando todos los datos capturados: ")
MostDatP(Alu)
Console.WriteLine("Matricula {0}", Alu.Matricula)
Console.WriteLine("Becado s/n {0}", Alu.Becado)
Console.WriteLine("Turno {0}", Alu.Turno)
Console.ReadLine()


Case 2
Console.WriteLine("No. de Empleado")
Doc.NoEmpleado = Console.ReadLine
Console.WriteLine("Sueldo:")
Doc.Sueldo = Console.ReadLine
CapDatP(Doc)

'El sueldo total es = al numero de materias * sueldo
Do
Console.WriteLine("¿Cuantas materias imparte? < 12")
nmaterias = Console.ReadLine
Loop While nmaterias > 12
For x = 0 To nmaterias - 1
Console.WriteLine("Materia {0}:", x + 1)
Doc.Materias(x) = Console.ReadLine
Next
Console.WriteLine("")
Console.WriteLine("")
Console.WriteLine("Mostrando todos los datos capturados del Docente: ")
Console.WriteLine("No. de empleado {0}", Doc.NoEmpleado)

MostDatP(Doc)
Console.WriteLine("Sueldo {0}", Doc.Sueldo)
Console.WriteLine("Materias:")
For x = 0 To nmaterias - 1
Console.WriteLine("{0}.- {1}", x + 1, Doc.Materias(x))
Next
Console.ReadLine()

Case 3
Console.WriteLine("No. de empleado:")
Adm.NoEmpleado = Console.ReadLine
Console.WriteLine("Sueldo: ")
Adm.Sueldo = Console.ReadLine
Console.WriteLine("Puesto: ")
Adm.puesto = Console.ReadLine

CapDatP(Adm)

Console.WriteLine("")
Console.WriteLine("")
Console.WriteLine("Mostrando todos los datos capturados del Administrativo: ")
Console.WriteLine(" No. de empleado {0}", Adm.NoEmpleado)
MostDatP(Adm)

Console.WriteLine("Puesto {0} ", Adm.puesto)
Console.WriteLine("Sueldo {0}", Adm.Sueldo)
Console.ReadLine()
Case 4
Console.WriteLine("")
Console.WriteLine("")
Console.WriteLine("Mostrando todos los datos capturados Alumno: ")

Console.WriteLine(Alu.Matricula)
MostDatP(Alu)
Console.WriteLine("Becado s/n {0}", Alu.Becado)
Console.WriteLine("Turno {0}", Alu.Turno)

Console.WriteLine("")
Console.WriteLine("")
Console.WriteLine("Mostrando todos los datos capturados Académico: ")
Console.WriteLine(" No. de empleado {0}", Doc.NoEmpleado)
MostDatP(Doc)

Console.WriteLine("Sueldo {0}", Doc.Sueldo)
Console.WriteLine("Materias:")
For x = 0 To nmaterias - 1
Console.WriteLine("{0}.- {1}", x + 1, Doc.Materias(x))
Next

Console.WriteLine("")
Console.WriteLine("")
Console.WriteLine("Mostrando todos los datos capturados Administrativo : ")
Console.WriteLine(" No. de empleado {0}", Adm.NoEmpleado)
MostDatP(Adm)

Console.WriteLine("Sueldo {0}", Adm.Sueldo)
Console.WriteLine("Puesto {0} ", Adm.puesto)
Console.ReadLine()
End Select
Loop While opc <> 5
End Sub
Function CapDatP(ByRef tpersona As Object)
Console.WriteLine("Nombre:")
tpersona.Nombre = Console.ReadLine()
Console.WriteLine("Domicilio: ")
tpersona.domicilio = Console.ReadLine()
Console.WriteLine("Telefono: ")
tpersona.Telefono = Console.ReadLine()
Console.WriteLine("Fecha de Nacimiento: ")
tpersona.FechaNac = Console.ReadLine()
End Function

Function MostDatP(ByVal tpersona As Object)
Console.WriteLine("Nombre: {0}", tpersona.nombre)
Console.WriteLine("Domicilio: {0}", tpersona.domicilio)
Console.WriteLine("Telefono: {0}", tpersona.Telefono)
Console.WriteLine("Fecha de Nacimiento: {0}", tpersona.FechaNac)
End Function
End Module

Tarea 2 class persona (clase heredada)

Public Class Persona
Private m_nombre As String
Private m_domicilio As String
Private m_FechaNac As Date
Private m_Telefono As String

Public Property nombre() As String
Get
Return m_nombre
End Get
Set(ByVal Value As String)
m_nombre = Value
End Set
End Property

Public Property domicilio() As String
Get
Return m_domicilio
End Get
Set(ByVal Value As String)
m_domicilio = Value
End Set
End Property

Public Property FechaNac() As Date
Get
Return m_FechaNac
End Get
Set(ByVal Value As Date)
m_FechaNac = Value
End Set
End Property

Public Property Telefono() As String
Get
Return m_Telefono
End Get
Set(ByVal Value As String)
m_Telefono = Value
End Set
End Property
End Class

Tarea 2 class administrativo

Public Class Administrativo
Inherits Persona

Private m_NoEmpleado As String
Private m_sueldo As Double
Private m_puesto As String

Public Property NoEmpleado() As String
Get
Return m_NoEmpleado
End Get
Set(ByVal Value As String)
m_NoEmpleado = Value
End Set
End Property

Public Property Sueldo() As Double
Get
Return m_sueldo
End Get
Set(ByVal Value As Double)
m_sueldo = Value
End Set
End Property

Public Property puesto() As String
Get
Return m_puesto
End Get
Set(ByVal Value As String)
m_puesto = Value
End Set
End Property
End Class

Tarea 2 class docente

Public Class docente
Inherits Persona

Private m_NoEmpleado As String
Private m_Sueldo As Double
Private m_Materias(12) As String

Public Property NoEmpleado() As String
Get
Return m_NoEmpleado
End Get
Set(ByVal Value As String)
m_NoEmpleado = Value
End Set
End Property


Public Property Sueldo() As Double
Get
Return m_Sueldo
End Get
Set(ByVal Value As Double)
m_Sueldo = Value
End Set
End Property

Public Property Materias(ByVal indice As Integer) As String
Get
Return m_Materias(CInt(indice))
End Get
Set(ByVal Value As String)
m_Materias(indice) = Value
End Set
End Property



End Class

Tarea 2 class alumno

Public Class alumno
Inherits Persona

Private m_Matricula As String
Private m_Becado As Boolean
Private m_Turno As String

Public Property Matricula() As String
Get
Return m_Matricula
End Get
Set(ByVal Value As String)
m_Matricula = Value
End Set
End Property

Public Property Becado() As Boolean
Get
Return m_Becado
End Get
Set(ByVal Value As Boolean)
m_Becado = Value
End Set
End Property

Public Property Turno() As String
Get
Return m_Turno
End Get
Set(ByVal Value As String)
m_Turno = Value
End Set
End Property


End Class

Definicion Programacion Orientada a Objetos (Patricia Gonzalez)

Por Patrica Gonzalez Valdez

Sistemas de Procesamiento de Datos
Programación Orientada a Objetos

INTRODUCCION
Actualmente una de las áreas más candentes en la industria y en el ámbito académico es la orientación a objetos. La orientación a objetos promete mejoras de amplio alcance en la forma de diseño, desarrollo y mantenimiento del software ofreciendo una solución a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo de software: la falta de portabilidad del código y reusabilidad, código que es dificil de modificar, ciclos de desarrollo largos y tecnicas de codificacion no intuituvas.
Un lenguaje orientado a objetos ataca estos problemas. Tiene tres características basicas: debe estar basado en objetos, basado en clases y capaz de tener herencia de clases. Muchos lenguajes cumplen uno o dos de estos puntos; muchos menos cumplen los tres. La barrera más difícil de sortear es usualmente la herencia.
El concepto de programación orientada a objetos (OOP) no es nuevo, lenguajes clásicos como SmallTalk se basan en ella. Dado que la OOP. se basa en la idea natural de la existencia de un mundo lleno de objetos y que la resolución del problema se realiza en términos de objetos, un lenguaje se dice que está basado en objetos si soporta objetos como una característica fundamental del mismo.
El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos definir un objeto como un conjunto complejo de datos y programas que poseen estructura y forman parte de una organización.
Esta definición especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un dato simple, sino que contiene en su interior cierto número de componentes bién estructurados. En segundo lugar, cada objeto no es un ente aislado, sino que forma parte de una organización jerárquica o de otro tipo.

ESTRUCTURA DE UN OBJETO

Un objeto puede considerarse como una especie de cápsula dividida en tres partes:
1 - RELACIONES
2 - PROPIEDADES
3 - METODOS

Cada uno de estos componentes desempeña un papel totalmente independiente:
Las relaciones permiten que el objeto se insterte en la organización y están formadas esencialmente por punteros a otros objetos.
Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.
Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.


Encapsulamiento y ocultación

Como hemos visto, cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos relacionados entre sí, como si estuvieran encerrados conjuntamente en una cápsula. Esta propiedad (encapsulamiento), es una de las características fundamentales en la OOP.
Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores conozcan cómo está distribuída la información o qué información hay disponible. Esta propiedad de los objetos se denomina ocultación de la información.
Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un objeto y a lo que contiene. Si así fuera no se podría hacer gran cosa con él. Lo que sucede es que las peticiones de información a un objeto. deben realizarse a través de mensajes dirigidos a él, con la orden de realizar la operación pertinente. La respuesta a estas ordenes será la información requerida, siempre que el objeto considere que quien envía el mensaje está autorizado para obtenerla.
El hecho de que cada objeto sea una cápsula facilita enormemente que un objeto determinado pueda ser transportado a otro punto de la organización, o incluso a otra organización totalmente diferente que precise de él. Si el objeto ha sido bien construído, sus métodos seguirán funcionando en el nuevo entorno sin problemas. Esta cualidad hace que la OOP sea muy apta para la reutilización de programas.

Organización de los objetos

En principio, los objetos forman siempre una organización jerárquica, en el sentido de que ciertos objetos son superiores a otros de cierto modo.
Existen varios tipos tipos de jerarquías: serán simples cuando su estructura pueda ser representada por medio de un "arbol". En otros casos puede ser más compleja.

En cualquier caso, sea la estructura simple o compleja, podrán distinguirse en ella tres niveles de objetos.
-La raíz de la jerarquía. Se trata de un objeto único y especial. Este se caracteríza por estar en el nivel más alto de la estructura y suele recibir un nombre muy genérico, que indica su categoría especial, como por ejemplo objeto madre, Raíz o Entidad.
-Los objetos intermedios. Son aquellos que descienden directamente de la raíz y que a su vez tienen descendientes. Representan conjuntos o clases de objetos, que pueden ser muy generales o muy especializados, según la aplicación. Normalmente reciben nombres genéricos que denotan al conjunto de objetos que representan, por ejemplo, VENTANA, CUENTA, FICHERO. En un conjunto reciben el nombre de clases o tipos si descienden de otra clase o subclase.
-Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no tienen descendientes. Suelen llamarse casos particulares, instancias o ítems porque representan los elementos del conjunto representado por la clase o subclase a la que pertenecen.

Veamos ahora en detalle los tres elementos mencionados en "Estructura de un Objeto".

1. RELACIONES

Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto relacionarse con aquellos que forman parte de la misma organización.
Las hay de dos tipos fundamentales:

-Relaciones jerárquicas. Son esenciales para la existencia misma de la aplicación porque la construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer objeto se encuentra situado inmediatamente encima del segundo en la organización en la que ambos forman parte; asimismo, si un objeto es padre de otro, el segundo es hijo del primero (en la fig. 2, B es padre de D,E y F, es decir, D,E y F son hijos de B; en la fig. 3, los objetos B y C son padres de F, que a su vez es hijo de ambos).
Una organización jerárquica simple puede definirse como aquella en la que un objeto puede tener un solo padre, mientras que en una organizacion jerárquica compleja un hijo puede tener varios padres).

-Relaciones semánticas. Se refieren a las relaciones que no tienen nada que ver con la organización de la que forman parte los objetos que las establecen. Sus propiedades y consecuencia solo dependen de los objetos en sí mismos (de su significado) y no de su posición en la organización.
Se puede ver mejor con un ejemplo: supongamos que vamos a construir un diccionario informatizado que permita al usuario obtener la definición de una palabra cualquiera. Supongamos que, en dicho diccionario, las palabras son objetos y que la organización jerárquica es la que proviene de forma natural de la estructura de nuestros conocimientos sobre el mundo.
La raíz del diccionario podría llamarse TEMAS. De éste término genérico descenderán tres grandes ramas de objetos llamadas VIDA, MUNDO y HOMBRE. El primero (vida) comprenderá las ciencias biológicas: Biología y Medicina. El segundo (mundo), las ciencias de la naturaleza inerte: las Matemáticas, la Física, la Química y la Geología. El tercero (hombre) comprenderá las ciencias humanas: la Geografía, la Historia, etc.

Veamos un ejemplo: estableceremos la relación trabajo entre los objetos NEWTON y OPTICA y la interpretaremos diciendo que significa que Newton trabajó en óptica (véase la fig. 4). La relación es, evidentemente, semántica, pués no establece ninguna connotación jerárquica entre NEWTON y OPTICA y su interpretación depende exclusivamente del significado de ambos objetos.
La existencia de esta relación nos permitirá responder a preguntas como:
¿Quién trabajó en óptica?
¿En qué trabajó Newton?
¿Quien trabajó en Física?
Las dos primeras se deducen inmediatamente de la existencia de la relación trabajo. Para la tercera observamos que si Newton trabajó en óptica automáticamente sabemos que trabajó en Física, por ser óptica una rama de la Física (en nuestro diccionario, el objeto OPTICA es hijo del objeto FISICA). Entonces gracias a la OOP podemos responder a la tercera pregunta sin necesidad de establecer una relación entre NEWTON y FISICA, apoyandonos sólo en la relación definida entre NEWTON y OPTICA y en que OPTICA es hijo de FISICA. De este modo se elimina toda redundancia innecesaria y la cantidad de información que tendremos que definir para todo el diccionario será mínima.


2. PROPIEDADES

Todo objeto puede tener cierto número de propiedades, cada una de las cuales tendrá, a su vez, uno o varios valores. En OOP, las propiedades corresponden a las clásicas "variables" de la programación estructurada. Son, por lo tanto, datos encapsulados dentro del objeto, junto con los métodos (programas) y las relaciones (punteros a otros objetos). Las propiedades de un objeto pueden tener un valor único o pueden contener un conjunto de valores mas o menos estructurados (matrices, vectores, listas, etc.). Además, los valores pueden ser de cualquier tipo (numérico, alfabético, etc.) si el sistema de programación lo permite.
Pero existe una diferencia con las "variables", y es que las propiedades se pueden heredar de unos objetos a otros. En consecuencia, un objeto puede tener una propiedad de maneras diferentes:
-Propiedades propias. Están formadas dentro de la cápsula del objeto.
-Propiedades heredadas. Estan definidas en un objeto diferente, antepasado de éste (padre,"abuelo", etc.). A veces estas propiedades se llaman propiedades miembro porque el objeto las posee por el mero hecho de ser miembro de una clase.

3. METODOS

Una operación que realiza acceso a los datos. Podemos definir método como un programa procedimental o procedural escrito en cualquier lenguaje, que está asociado a un objeto determinado y cuya ejecución sólo puede desencadenarse a través de un mensaje recibido por éste o por sus descendientes.
Son sinónimos de 'método' todos aquellos términos que se han aplicado tradicionalmente a los programas, como procedimiento, función, rutina, etc. Sin embargo, es conveniente utilizar el término 'método' para que se distingan claramente las propiedades especiales que adquiere un programa en el entorno OOP, que afectan fundamentalmente a la forma de invocarlo (únicamente a través de un mensaje) y a su campo de acción, limitado a un objeto y a sus descendientes, aunque posiblemente no a todos.
Si los métodos son programas, se deduce que podrían tener argumentos, o parámetros. Puesto que los métodos pueden heredarse de unos objetos a otros, un objeto puede disponer de un método de dos maneras diferentes:
-Métodos propios. Están incluídos dentro de la cápsula del objeto.
-Métodos heredados. Estan definidos en un objeto diferente, antepasado de éste (padre,"abuelo", etc.). A veces estos métodos se llaman métodos miembro porque el objeto los posee por el mero hecho de ser miembro de una clase.

Polimorfísmo

Una de las características fundamentales de la OOP es el polimorfísmo, que no es otra cosa que la posibilidad de construir varios métodos con el mismo nombre, pero con relación a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos recibirían el mismo mensaje global pero responderían a él de formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significaría suma, mientras que para un objeto STRING significaría concatenación ("pegar" strings uno seguido al otro)

Demonios

Es un tipo especial de métodos, relativamente poco frecuente en los sistemas de OOP, que se activa automáticamente cuando sucede algo especial. Es decir, es un programa, como los métodos ordinarios, pero se diferencia de estos porque su ejecución no se activa con un mensaje, sino que se desencadena autmáticamente cuando ocurre un suceso determinado: la asignación de un valor a una propiedad de un objeto, la lectura de un valor determinado, etc.
Los demonios, cuando existen, se diferencian de otros métodos por que no son heredables y porque a veces están ligados a una de las propiedades de un objeto, mas que al objeto entero.
CONSIDERACIONES FINALES

Beneficios que se obtienen del desarrollo con OOP

Día a día los costos del Hardware decrecen. Así surgen nuevas áreas de aplicación cotidianamente: procesamiento de imágenes y sonido, bases de datos multimediales, automatización de oficinas, ambientes de ingeniería de software, etc. Aún en las aplicaciones tradicionales encontramos que definir interfases hombre-máquina "a-la-Windows" suele ser bastante conveniente.
Lamentablemente, los costos de producción de software siguen aumentando; el mantenimiento y la modificación de sistemas complejos suele ser una tarea trabajosa; cada aplicación, (aunque tenga aspectos similares a otra) suele encararse como un proyecto nuevo, etc.
Todos estos problemas aún no han sido solucionados en forma completa. Pero como los objetos son portables (teóricamente) mientras que la herencia permite la reusabilidad del código orientado a objetos, es más sencillo modificar código existente porque los objetos no interaccionan excepto a través de mensajes; en consecuencia un cambio en la codificación de un objeto no afectará la operación con otro objeto siempre que los métodos respectivos permanezcan intactos. La introducción de tecnología de objetos como una herramienta concepual para analizar, diseñar e implementar aplicaciones permite obtener aplicaciones más modificables, fácilmente extendibles y a partir de componentes reusables. Esta reusabilidad del código disminuye el tiempo que se utiliza en el desarrollo y hace que el desarrollo del software sea mas intuitivo porque la gente piensa naturalmente en términos de objetos más que en términos de algoritmos de software.


Problemas derivados de la utilización de OOP en la actualidad

Un sistema orientado a objetos, por lo visto, puede parecer un paraíso virtual. El problema sin embargo surge en la implementación de tal sistema. Muchas compañías oyen acerca de los beneficios de un sistema orientado a objetos e invierten gran cantidad de recursos luego comienzan a darse cuenta que han impuesto una nueva cultura que es ajena a los programadores actuales. Específicamente los siguientes temas suelen aparecer repetidamente:

Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una forma única. Involucra la conceptualización de todos los elementos de un programa, desde subsistemas a los datos, en la forma de objetos. Toda la comunicación entre los objetos debe realizarse en la forma de mensajes. Esta no es la forma en que están escritos los programas orientados a objetos actualmente; al hacer la transición a un sistema orientado a objetos la mayoría de los programadores deben capacitarse nuevamente antes de poder usarlo.
Dependencia del lenguaje. A pesar de la portabilidad conceptual de los objetos en un sistema orientado a objetos, en la práctica existen muchas dependencias. Muchos lenguajes orientados a objetos están compitiendo actualmente para dominar el mercado. Cambiar el lenguaje de implementación de un sistema orientado a objetos no es una tarea sencilla; por ejemplo C++ soporta el concepto de herencia multiple mientras que SmallTalk no lo soporta; en consecuencia la elección de un lenguaje tiene ramificaciones de diseño muy importamtes.
Determinacion de las clases. Una clase es un molde que se utiliza para crear nuevos objetos. En consecuencia es importante crear el conjunto de clases adecuado para un proyecto. Desafortunadamente la definición de las clases es más un arte que una ciencia. Si bien hay muchas jerarquías de clase predefinidas usualmente se deben crear clases específicas para la aplicación que se este desarrollando. Luego, en 6 meses ó 1 año se da cuenta que las clases que se establecieron no son posibles; en ese caso será necesario reestructurar la jerarquía de clases devastando totalmente la planificación original.
Performance. En un sistema donde todo es un objeto y toda interaccion es a través de mensajes, el tráfico de mensajes afecta la performance. A medida que la tecnología avanza y la velocidad de microprocesamiento, potencia y tamaño de la memoria aumentan, la situacion mejorará; pero en la situación actual, un diseño de una aplicación orientada a objetos que no tiene en cuenta la performance no será viable comercialmente.
Idealmente, habría una forma de atacar estos problemas eficientemente al mismo tiempo que se obtienen los beneficios del desarrollo de una estrategia orientada a objetos. Deberia existir una metodología fácil de aprender e independiente del lenguaje, y facil de reestructurar que no drene la performance del sistema .

Definicion Programacion Orientada a Objetos (Ernesto Alonso Aguilar Burgoin)

Por Ernesto Alonso Aguilar Burgoin
Programación Orientada a Objetos


La Programación Orientada a Objetos (POO ú según siglas en inglés) es una metodología de diseño de software y un paradigma de programación que define los programas en términos de "clases de objetos", objetos que son entidades que combinan estado (es decir, datos) y comportamiento (esto es, procedimientos o métodos). La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que se comunican entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar.

De esta forma, un objeto contiene toda la información, (los denominados atributos) que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases (e incluso entre objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos). A su vez, dispone de mecanismos de interacción (los llamados métodos) que favorecen la comunicación entre objetos (de una misma clase o de distintas), y en consecuencia, el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separan (ni deben separarse) información (datos) y procesamiento (métodos).
Dada esta propiedad de conjunto de una clase de objetos, que al contar con una serie de atributos definitorios, requiere de unos métodos para poder tratarlos (lo que hace que ambos conceptos están íntimamente entrelazados), el programador debe pensar indistintamente en ambos términos, ya que no debe nunca separar o dar mayor importancia a los atributos en favor de los métodos, ni viceversa. Hacerlo puede llevar al programador a seguir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen esa información por otro (llegando a una programación estructurada camuflada en un lenguaje de programación orientado a objetos).
Esto difiere de los lenguajes imperativos tradicionales, en los que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. Los programadores de lenguajes imperativos escriben funciones y después les pasan datos. Los programadores que emplean lenguajes orientados a objetos definen objetos con datos y métodos y después envían mensajes a los objetos diciendo qué realicen esos métodos en sí mismos.

Bibliografía

http://es.wikipedia.org/wiki/Programación_orientada_a_objetos

Definicion Programacion Orientada a Objetos (Vidal)

Por PINTO VILLARINO VIDAL ERNESTO
PROGRAMACION ORIENTADA A OBJETOS


Origen
Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. Según se informa, la historia es que trabajaban en simulaciones de naves, y fueron confundidos por la explosión combinatoria de cómo las diversas cualidades de diversas naves podían afectar unas a las otras. La idea ocurrió para agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamiento. Fueron refinados más tarde en Smalltalk, que fue desarrollado en Simula en Xerox PARC (y cuya primera versión fue escrita sobre Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar "en marcha" en lugar de tener un sistema basado en programas estáticos.
La programación orientada a objetos tomó posición como la metodología de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++ , una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas de usuario, para los cuales la programación orientada a objetos está particularmente bien adaptada. En este caso, se habla también de programación orientada a eventos.
Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, y otros. La adición de estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a menudo a problemas de compatibilidad y a la capacidad de mantenimiento del código. Los lenguajes orientados a objetos "puros", por otra parte, carecían de las características de las cuales muchos programadores habían venido a depender. Para saltar este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo algunas características imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet, y a la implementación de la máquina virtual de Java en la mayoría de navegadores.
Diferencias con la programación imperativa. Aunque la programación imperativa (a veces llamada procedural o procedimental) condujo a mejoras de la técnica de programación secuencial, tales como la programación estructurada y "refinamientos sucesivos", los métodos modernos de diseño de software orientado a objetos incluyen mejoras entre las que están el uso de los patrones de diseño, diseño por contrato, y lenguajes de modelado (ej: UML).

Las principales diferencias entre la programación imperativa y la orientada a objetos son:
• La programación orientada a objetos es más moderna, es una evolución de la programación imperativa que plasma en el diseño de una familia de lenguajes conceptos que existían previamente con algunos nuevos.

• La programación orientada a objetos se basa en lenguajes que soportan sintáctica y semánticamente la unión entre los tipos abstractos de datos y sus operaciones (a esta unión se la suele llamar clase).

• La programación orientada a objetos incorpora en su entorno de ejecución mecanismos tales como el polimorfismo y el envío de mensajes entre objetos.

Erroneamente se le adjudica a la programación imperativa clásica ciertos problemas como si fueran inherentes a la misma. Esos problemas fueron haciéndose cada vez más graves y antes de la programación orientada a objetos diversos autores (de los que podemos destacar a Jourdon) encontraron soluciones basadas en aplicar estrictas metodologías de trabajo. De esa época son los conceptos de cohesión y acoplamiento.

De esos problemas se destacan los siguientes:
• Modelo mental anómalo. Nuestra imagen del mundo se apoya en los seres, a los que asignamos nombres sustantivos, mientras la programación clásica se basa en el comportamiento, representado usualmente por verbos.
• Es difícil modificar y extender los programas, pues suele haber datos compartidos por varios subprogramas, que introducen interacciones ocultas entre ellos.
• Es difícil mantener los programas. Casi todos los sistemas informáticos grandes tienen errores ocultos, que no surgen a la luz hasta después de muchas horas de funcionamiento.
• Es difícil reutilizar los programas. Es prácticamente imposible aprovechar en una aplicación nueva las subrutinas que se diseñaron para otra.
• Es compleja la coordinación y organización entre programadores para la creación de aplicaciones de media y gran envergadura.

En la programación orientada a objetos pura no deben utilizarse llamadas de subrutinas, únicamente mensajes.

Por ello, a veces recibe el nombre de programación sin CALL, igual que la programación estructurada se llama también programación sin GOTO.
Sin embargo, no todos los lenguajes orientados a objetos prohíben la instrucción CALL (o su equivalente), permitiendo realizar programación híbrida, imperativa y orientada a objetos a la vez.

La Programación Orientada a Objetos (POO) como solución
La programación orientada a objetos es una nueva forma de programar que trata de encontrar solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

• Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad ("métodos"). Corresponden a los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa).
• Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.
• Método: algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, y/o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.
• Evento: un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente.
• Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.
• Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto, y cuyo valor puede ser alterado por la ejecución de algún método.
• Estado interno: es una propiedad invisible de los objetos, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos).

En comparación con un lenguaje imperativo, una "variable" no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.

Características de la POO
Hay un cierto desacuerdo sobre exactamente qué características de un método de programación o lenguaje le definen como "orientado a objetos", pero hay un consenso general en que las características siguientes son las más importantes (para más información, seguir los enlaces respectivos):
• Abstracción: cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción.
• Encapsulamiento: también llamado "ocultación de la información". Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.

• Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.
• Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que reimplementar su comportamiento. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto pertenece a más de una clase se llama herencia múltiple; esta característica no está soportada por algunos lenguajes (como Java).



Lenguajes orientados a objetos
Entre los lenguajes orientados a objetos destacan los siguientes:
• Ada
• C++
• C#
• Clarion
• Delphi
• Eiffel
• Java
• Lexico (en castellano)
• Objective-C
• Ocaml
• PHP
• PowerBuilder
• Python
• Ruby
• Smalltalk

No todos estos lenguajes de programación son igualmente puros (avanzados) en orientación a objetos.
Al igual que C++ otros lenguajes, como OOCOBOL, OOLISP, OOPROLOG y Object REXX, han sido creados añadiendo extensiones orientadas a objetos a un lenguaje de programación clásico.
Un nuevo paso en la abstracción de paradigmas de programación es la Programación Orientada a Aspectos (POA). Aunque es todavía una metodología en estado de maduración, cada vez atrae a más investigadores e incluso proyectos comerciales en todo el mundo.

Definicion Programacion Orientada a Objetos (Alfredo)

Por Alfredo Herrera Ruiz

INTRODUCCION


Actualmente una de las áreas más candentes en la industria y en el ámbito académico es la orientación a objetos. La orientación a objetos promete mejoras de amplio alcance en la forma de diseño, desarrollo y mantenimiento del software ofreciendo una solución a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo de software: la falta de portabilidad del código y reusabilidad, código que es dificil de modificar, ciclos de desarrollo largos y tecnicas de codificacion no intuituvas.
Un lenguaje orientado a objetos ataca estos problemas. Tiene tres características basicas: debe estar basado en objetos, basado en clases y capaz de tener herencia de clases. Muchos lenguajes cumplen uno o dos de estos puntos; muchos menos cumplen los tres. La barrera más difícil de sortear es usualmente la herencia.
El concepto de programación orientada a objetos (OOP) no es nuevo, lenguajes clásicos como SmallTalk se basan en ella. Dado que la OOP. se basa en la idea natural de la existencia de un mundo lleno de objetos y que la resolución del problema se realiza en términos de objetos, un lenguaje se dice que está basado en objetos si soporta objetos como una característica fundamental del mismo.

El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos definir un objeto como un conjunto complejo de datos y programas que poseen estructura y forman parte de una organización.
Esta definición especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un dato simple, sino que contiene en su interior cierto número de componentes bién estructurados. En segundo lugar, cada objeto no es un ente aislado, sino que forma parte de una organización jerárquica o de otro tipo.


ESTRUCTURA DE UN OBJETO

Un objeto puede considerarse como una especie de cápsula dividida en tres partes:

1 - RELACIONES
2 - PROPIEDADES
3 - METODOS

Cada uno de estos componentes desempeña un papel totalmente independiente:
Las relaciones permiten que el objeto se insterte en la organización y están formadas esencialmente por punteros a otros objetos.
Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.
Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.


Encapsulamiento y ocultación

Como hemos visto, cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos relacionados entre sí, como si estuvieran encerrados conjuntamente en una cápsula. Esta propiedad (encapsulamiento), es una de las características fundamentales en la OOP.
Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores conozcan cómo está distribuída la información o qué información hay disponible. Esta propiedad de los objetos se denomina ocultación de la información.
Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un objeto y a lo que contiene. Si así fuera no se podría hacer gran cosa con él. Lo que sucede es que las peticiones de información a un objeto. deben realizarse a través de mensajes dirigidos a él, con la orden de realizar la operación pertinente. La respuesta a estas ordenes será la información requerida, siempre que el objeto considere que quien envía el mensaje está autorizado para obtenerla.
El hecho de que cada objeto sea una cápsula facilita enormemente que un objeto determinado pueda ser transportado a otro punto de la organización, o incluso a otra organización totalmente diferente que precise de él. Si el objeto ha sido bien construído, sus métodos seguirán funcionando en el nuevo entorno sin problemas. Esta cualidad hace que la OOP sea muy apta para la reutilización de programas.




Organización de los objetos

En principio, los objetos forman siempre una organización jerárquica, en el sentido de que ciertos objetos son superiores a otros de cierto modo.
Existen varios tipos tipos de jerarquías: serán simples cuando su estructura pueda ser representada por medio de un "arbol". En otros casos puede ser más compleja.

En cualquier caso, sea la estructura simple o compleja, podrán distinguirse en ella tres niveles de objetos.
-La raíz de la jerarquía. Se trata de un objeto único y especial. Este se caracteríza por estar en el nivel más alto de la estructura y suele recibir un nombre muy genérico, que indica su categoría especial, como por ejemplo objeto madre, Raíz o Entidad.
-Los objetos intermedios. Son aquellos que descienden directamente de la raíz y que a su vez tienen descendientes. Representan conjuntos o clases de objetos, que pueden ser muy generales o muy especializados, según la aplicación. Normalmente reciben nombres genéricos que denotan al conjunto de objetos que representan, por ejemplo, VENTANA, CUENTA, FICHERO. En un conjunto reciben el nombre de clases o tipos si descienden de otra clase o subclase.
-Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no tienen descendientes. Suelen llamarse casos particulares, instancias o ítems porque representan los elementos del conjunto representado por la clase o subclase a la que pertenecen.

Veamos ahora en detalle los tres elementos mencionados en "Estructura de un Objeto".


1. RELACIONES

Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto relacionarse con aquellos que forman parte de la misma organización.
Las hay de dos tipos fundamentales:

-Relaciones jerárquicas. Son esenciales para la existencia misma de la aplicación porque la construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer objeto se encuentra situado inmediatamente encima del segundo en la organización en la que ambos forman parte; asimismo, si un objeto es padre de otro, el segundo es hijo del primero (en la fig. 2, B es padre de D,E y F, es decir, D,E y F son hijos de B; en la fig. 3, los objetos B y C son padres de F, que a su vez es hijo de ambos).
Una organización jerárquica simple puede definirse como aquella en la que un objeto puede tener un solo padre, mientras que en una organizacion jerárquica compleja un hijo puede tener varios padres).

-Relaciones semánticas. Se refieren a las relaciones que no tienen nada que ver con la organización de la que forman parte los objetos que las establecen. Sus propiedades y consecuencia solo dependen de los objetos en sí mismos (de su significado) y no de su posición en la organización.
Se puede ver mejor con un ejemplo: supongamos que vamos a construir un diccionario informatizado que permita al usuario obtener la definición de una palabra cualquiera. Supongamos que, en dicho diccionario, las palabras son objetos y que la organización jerárquica es la que proviene de forma natural de la estructura de nuestros conocimientos sobre el mundo.
La raíz del diccionario podría llamarse TEMAS. De éste término genérico descenderán tres grandes ramas de objetos llamadas VIDA, MUNDO y HOMBRE. El primero (vida) comprenderá las ciencias biológicas: Biología y Medicina. El segundo (mundo), las ciencias de la naturaleza inerte: las Matemáticas, la Física, la Química y la Geología. El tercero (hombre) comprenderá las ciencias humanas: la Geografía, la Historia, etc.

Veamos un ejemplo: estableceremos la relación trabajo entre los objetos NEWTON y OPTICA y la interpretaremos diciendo que significa que Newton trabajó en óptica (véase la fig. 4). La relación es, evidentemente, semántica, pués no establece ninguna connotación jerárquica entre NEWTON y OPTICA y su interpretación depende exclusivamente del significado de ambos objetos.
La existencia de esta relación nos permitirá responder a preguntas como:
¿Quién trabajó en óptica?
¿En qué trabajó Newton?
¿Quien trabajó en Física?
Las dos primeras se deducen inmediatamente de la existencia de la relación trabajo. Para la tercera observamos que si Newton trabajó en óptica automáticamente sabemos que trabajó en Física, por ser óptica una rama de la Física (en nuestro diccionario, el objeto OPTICA es hijo del objeto FISICA). Entonces gracias a la OOP podemos responder a la tercera pregunta sin necesidad de establecer una relación entre NEWTON y FISICA, apoyandonos sólo en la relación definida entre NEWTON y OPTICA y en que OPTICA es hijo de FISICA. De este modo se elimina toda redundancia innecesaria y la cantidad de información que tendremos que definir para todo el diccionario será mínima.


2. PROPIEDADES

Todo objeto puede tener cierto número de propiedades, cada una de las cuales tendrá, a su vez, uno o varios valores. En OOP, las propiedades corresponden a las clásicas "variables" de la programación estructurada. Son, por lo tanto, datos encapsulados dentro del objeto, junto con los métodos (programas) y las relaciones (punteros a otros objetos). Las propiedades de un objeto pueden tener un valor único o pueden contener un conjunto de valores mas o menos estructurados (matrices, vectores, listas, etc.). Además, los valores pueden ser de cualquier tipo (numérico, alfabético, etc.) si el sistema de programación lo permite.
Pero existe una diferencia con las "variables", y es que las propiedades se pueden heredar de unos objetos a otros. En consecuencia, un objeto puede tener una propiedad de maneras diferentes:
-Propiedades propias. Están formadas dentro de la cápsula del objeto.
-Propiedades heredadas. Estan definidas en un objeto diferente, antepasado de éste (padre,"abuelo", etc.). A veces estas propiedades se llaman propiedades miembro porque el objeto las posee por el mero hecho de ser miembro de una clase.



3. METODOS

Una operación que realiza acceso a los datos. Podemos definir método como un programa procedimental o procedural escrito en cualquier lenguaje, que está asociado a un objeto determinado y cuya ejecución sólo puede desencadenarse a través de un mensaje recibido por éste o por sus descendientes.
Son sinónimos de 'método' todos aquellos términos que se han aplicado tradicionalmente a los programas, como procedimiento, función, rutina, etc. Sin embargo, es conveniente utilizar el término 'método' para que se distingan claramente las propiedades especiales que adquiere un programa en el entorno OOP, que afectan fundamentalmente a la forma de invocarlo (únicamente a través de un mensaje) y a su campo de acción, limitado a un objeto y a sus descendientes, aunque posiblemente no a todos.
Si los métodos son programas, se deduce que podrían tener argumentos, o parámetros. Puesto que los métodos pueden heredarse de unos objetos a otros, un objeto puede disponer de un método de dos maneras diferentes:
-Métodos propios. Están incluídos dentro de la cápsula del objeto.
-Métodos heredados. Estan definidos en un objeto diferente, antepasado de éste (padre,"abuelo", etc.). A veces estos métodos se llaman métodos miembro porque el objeto los posee por el mero hecho de ser miembro de una clase.

Polimorfísmo

Una de las características fundamentales de la OOP es el polimorfísmo, que no es otra cosa que la posibilidad de construir varios métodos con el mismo nombre, pero con relación a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos recibirían el mismo mensaje global pero responderían a él de formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significaría suma, mientras que para un objeto STRING significaría concatenación ("pegar" strings uno seguido al otro)




Demonios

Es un tipo especial de métodos, relativamente poco frecuente en los sistemas de OOP, que se activa automáticamente cuando sucede algo especial. Es decir, es un programa, como los métodos ordinarios, pero se diferencia de estos porque su ejecución no se activa con un mensaje, sino que se desencadena autmáticamente cuando ocurre un suceso determinado: la asignación de un valor a una propiedad de un objeto, la lectura de un valor determinado, etc.
Los demonios, cuando existen, se diferencian de otros métodos por que no son heredables y porque a veces están ligados a una de las propiedades de un objeto, mas que al objeto entero.


CONSIDERACIONES FINALES

Beneficios que se obtienen del desarrollo con OOP

Día a día los costos del Hardware decrecen. Así surgen nuevas áreas de aplicación cotidianamente: procesamiento de imágenes y sonido, bases de datos multimediales, automatización de oficinas, ambientes de ingeniería de software, etc. Aún en las aplicaciones tradicionales encontramos que definir interfases hombre-máquina "a-la-Windows" suele ser bastante conveniente.
Lamentablemente, los costos de producción de software siguen aumentando; el mantenimiento y la modificación de sistemas complejos suele ser una tarea trabajosa; cada aplicación, (aunque tenga aspectos similares a otra) suele encararse como un proyecto nuevo, etc.
Todos estos problemas aún no han sido solucionados en forma completa. Pero como los objetos son portables (teóricamente) mientras que la herencia permite la reusabilidad del código orientado a objetos, es más sencillo modificar código existente porque los objetos no interaccionan excepto a través de mensajes; en consecuencia un cambio en la codificación de un objeto no afectará la operación con otro objeto siempre que los métodos respectivos permanezcan intactos. La introducción de tecnología de objetos como una herramienta concepual para analizar, diseñar e implementar aplicaciones permite obtener aplicaciones más modificables, fácilmente extendibles y a partir de componentes reusables. Esta reusabilidad del código disminuye el tiempo que se utiliza en el desarrollo y hace que el desarrollo del software sea mas intuitivo porque la gente piensa naturalmente en términos de objetos más que en términos de algoritmos de software.


Problemas derivados de la utilización de OOP en la actualidad

Un sistema orientado a objetos, por lo visto, puede parecer un paraíso virtual. El problema sin embargo surge en la implementación de tal sistema. Muchas compañías oyen acerca de los beneficios de un sistema orientado a objetos e invierten gran cantidad de recursos luego comienzan a darse cuenta que han impuesto una nueva cultura que es ajena a los programadores actuales. Específicamente los siguientes temas suelen aparecer repetidamente:

Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una forma única. Involucra la conceptualización de todos los elementos de un programa, desde subsistemas a los datos, en la forma de objetos. Toda la comunicación entre los objetos debe realizarse en la forma de mensajes. Esta no es la forma en que están escritos los programas orientados a objetos actualmente; al hacer la transición a un sistema orientado a objetos la mayoría de los programadores deben capacitarse nuevamente antes de poder usarlo.
Dependencia del lenguaje. A pesar de la portabilidad conceptual de los objetos en un sistema orientado a objetos, en la práctica existen muchas dependencias. Muchos lenguajes orientados a objetos están compitiendo actualmente para dominar el mercado. Cambiar el lenguaje de implementación de un sistema orientado a objetos no es una tarea sencilla; por ejemplo C++ soporta el concepto de herencia multiple mientras que SmallTalk no lo soporta; en consecuencia la elección de un lenguaje tiene ramificaciones de diseño muy importamtes.
Determinacion de las clases. Una clase es un molde que se utiliza para crear nuevos objetos. En consecuencia es importante crear el conjunto de clases adecuado para un proyecto. Desafortunadamente la definición de las clases es más un arte que una ciencia. Si bien hay muchas jerarquías de clase predefinidas usualmente se deben crear clases específicas para la aplicación que se este desarrollando. Luego, en 6 meses ó 1 año se da cuenta que las clases que se establecieron no son posibles; en ese caso será necesario reestructurar la jerarquía de clases devastando totalmente la planificación original.
Performance. En un sistema donde todo es un objeto y toda interaccion es a través de mensajes, el tráfico de mensajes afecta la performance. A medida que la tecnología avanza y la velocidad de microprocesamiento, potencia y tamaño de la memoria aumentan, la situacion mejorará; pero en la situación actual, un diseño de una aplicación orientada a objetos que no tiene en cuenta la performance no será viable comercialmente.

Idealmente, habría una forma de atacar estos problemas eficientemente al mismo tiempo que se obtienen los beneficios del desarrollo de una estrategia orientada a objetos. Deberia existir una metodología fácil de aprender e independiente del lenguaje, y facil de reestructurar que no drene la performance del sistema .



Bibliografía

Revista COMPU MAGAZINE, Número 51, Octubre '92
Revista COMPU MAGAZINE, Número 50, Septiembre '92

Definicion Programacion Orientada a Objetos (Laura)

Por LOPEZ CORONA ANA LAURA

INTRODUCCION
El desarrollo de la OOP empieza a destacar durante la década de lo 80 tomando en cuenta la programación estructurada, a la que engloba y dotando al programador de nuevos elementos para el análisis y desarrollo de software
Actualmente una de las áreas más candentes en la industria y en el ámbito académico es la orientación a objetos. La orientación a objetos promete mejoras de amplio alcance en la forma de diseño, desarrollo y mantenimiento del software ofreciendo una solución a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo de software: la falta de portabilidad del código y reusabilidad, código que es difícil de modificar, ciclos de desarrollo largos y técnicas de codificación no intuitivas.
Un lenguaje orientado a objetos ataca estos problemas. Tiene tres características básicas: debe estar basado en objetos, basado en clases y capaz de tener herencia de clases. Muchos lenguajes cumplen uno o dos de estos puntos; muchos menos cumplen los tres. La barrera más difícil de sortear es usualmente la herencia.
CONCEPTO
El concepto de programación orientada a objetos (OOP) se basa en la idea natural de la existencia de un mundo lleno de objetos y que la resolución del problema se realiza en términos de objetos, un lenguaje se dice que está basado en objetos si soporta objetos como una característica fundamental del mismo.
El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos definir un objeto como un conjunto complejo de datos y programas que poseen estructura y forman parte de una organización.
Esta definición especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un dato simple, sino que contiene en su interior cierto número de componentes bien estructurados. En segundo lugar, cada objeto no es un ente aislado, sino que forma parte de una organización jerárquica o de otro tipo.
El término de Programación Orientada a Objetos indica más una forma de diseño y una metodología de desarrollo de software que un lenguaje de programación, ya que en realidad se puede aplicar el Diseño Orientado a Objetos (En inglés abreviado OOD, Object Oriented Design), a cualquier tipo de lenguaje de programación.

OBJETOS
El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos definir un objeto como un conjunto complejo de datos y programas que poseen estructura y forman parte de una organización.
Esta definición especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un dato simple, sino que contiene en su interior cierto número de componentes bien estructurados. En segundo lugar, cada objeto no es un ente aislado, sino que forma parte de una organización jerárquica o de otro tipo

Un objeto puede considerarse como una especie de cápsula dividida en tres partes:
*Las relaciones permiten que el objeto se inceterte en la organización y están formadas esencialmente por punteros a otros objetos.
*Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.
*Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.

NIVELES DE OBJETOS
En cualquier caso, sea la estructura simple o compleja, podrán distinguirse en ella tres niveles de objetos.
-la raíz de la jerarquía. Se trata de un objeto único y especial. Este se caracteriza por estar en el nivel más alto de la estructura y suele recibir un nombre muy genérico, que indica su categoría especial, como por ejemplo objeto madre, raíz o entidad.
-los objetos intermedios. Son aquellos que descienden directamente de la raíz y que a su vez tienen descendientes. Representan conjuntos o clases de objetos, que pueden ser muy generales o muy especializados, según la aplicación. Normalmente reciben nombres genéricos que denotan al conjunto de objetos que representan, por ejemplo, ventana, cuenta, fichero. En un conjunto reciben el nombre de clases o tipos si descienden de otra clase o subclase.
-los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no tienen descendientes. Suelen llamarse casos particulares, instancias o ítems porque representan los elementos del conjunto representado por la clase o subclase a la que pertenecen.

CARACTERÍSTICAS DE LOS OBJETOS
Identidad del Objeto
La identidad expresa que aunque dos objetos sean exactamente iguales en sus atributos, son distintos entre sí. De esta forma incluso una serie de Objetos coches, recién fabricados son distintos los unos de los otros.
La afirmación anterior, aunque parece obvia, tiene importancia cuando descendemos al nivel de programación. En este ámbito cada uno de los objetos tiene un controlador por el cual se identifica. Este puede ser una variable, una estructura de datos, una cadena de caracteres, etc. El controlador será distinto para cada uno de los objeto, aunque las referencias a éstos sean uniformes e independientes del contenido, permitiendo crear agrupaciones de objetos con el mismo tratamiento.
Clasificación
Con la clasificación comienza la verdadera programación orientada a objetos. Ellos nos obliga a una abstracción del concepto de objeto denominada clase.
Las clases permiten la agrupación de objetos que comparten las mismas propiedades y comportamiento. Si bien clase y objeto suelen usarse como sinónimos, no lo son.
El esfuerzo del programador ante una aplicación orientada a objetos se centra en la identificación de las clases, sus atributos y operaciones asociadas
Las propiedades de cada clase deben cumplir una serie de premisas
Las propiedades deber ser significativas dentro del entorno de la aplicación es decir, deben servir para identificar claramente y de una manera única a cada uno de los objetos
El número de propiedades de un objeto debe ser el mínimo para realizar todas las operaciones que requiera la aplicación.
Definamos una clase rectángulo. Esta clase puede tener como atributos un punto (x,y), la anchura (a) y la longitud (l). Las operaciones a realizar son: mover, agrandar, reducir, et. ¿Es posible realizarlas con las propiedades de la clase?
Un análisis posterior nos indica que es posible la realización de estas operaciones con los atributos definidos. Pero si incluimos la operación girar, vemos que con las propiedades definidas para la clase esta operación no se puede realizar. Para incluir esta nueva operación debemos redefinir las propiedades del objeto, en este caso las coordenadas de los vértices.
Construcción de clases
Tal como hemos definido con anterioridad, una clase de objeto describe a un grupo de objetos con similares:
--Propiedades (atributos)
--Comportamientos (operaciones)
--Relaciones con otros objetos
La abreviatura clase es utilizada en lugar de clase de objetos. Los objetos difieren en los valores asociados a sus atributos definidos dentro de la clase. Cada objeto –conoce- cuál es su clase. La mayoría de los lenguajes orientados a objetos pueden determinar a que clase pertenece un objeto durante la ejecución del programa.

PASOS PARA DEFINIR UNA CLASE.
Identificar los objetos.
Para ello examine la aplicación e identifique las distintas estructuras de datos, algunos tips a tener en cuenta son los siguientes:
--El nombre de la aplicación a veces nos da la del nombre del objeto principal
--Los objetos software pueden imitar el mundo real, modelizando las propiedades de los objetos a través de variables Cualquier propiedad de un objeto puede ser identificada dentro del objeto correspondiente a través de variables.
--Los objetos no se han de corresponder siempre con objetos físicos, sino que también pueden ser entidades que se utilizan dentro de la construcción del programa.
--Piense en el objeto en -primera persona-. Este truco nos puede identificar claramente los atributos y sus operaciones asociadas: -Soy un cuadrado y me muevo, giro, agrando y reduzco. Las partes que me componen son los puntos de mis vértices-.
--Una clase es un tipo de dato que puede ser usado para declarar objetos, de la misma forma que una estructura es un tipo definido por el usuario que puede utilizarse para declarar variables.

Definir las operaciones
Defina las operaciones a partir de los objetos, examinando las distintas operaciones asociadas a un conjunto de datos. Los atributos del objeto se deben definir de tal manera que éstos satisfagan todos los requerimientos de cada una de las operaciones.
A estas operaciones añada dos más: Crear y Destruir. Estas operaciones nos servirán para inicializar y borrar el objeto dentro de la aplicación.
A partir de la definición de las propiedades, un objeto siempre debe ser capaz de responder a estas tres preguntas: ¿Qué soy? ¿Qué hago? ¿Qué dejo ver al resto del mundo?
Algunas de las operaciones sólo se aplicarán a determinados objetos pertenecientes a las clases. Hemos visto que a través de la herencia podemos –especializar- un sub conjunto de objetos creando una sub-clase.
Únicamente aquellas operaciones que sean comunes a todos los objetos de la clase deben incluirse dentro de las operaciones de la clase. El resto, que corresponden a las operaciones de sub-Grupos de objetos, se deben definir dentro de las especializaciones de la clase.
Definir los atributos de los objetos
Una vez identificados los objetos, defina los atributos de la clase. Un atributo es un valor almacenado en los objetos de la clase.

PILARES DE LA OOP

Identidad, clasificación, polimorfismo y herencia caracterizan a los lenguajes orientados a objetos. Cada uno de estos conceptos puede utilizarse aisladamente, incluso aparecen en otras metodologías de programación, pero juntos se complementan en una relación sinérgica. Los beneficios de la programación orientada a objetos son más que los que pueden verse a simple vista. El énfasis en las propiedades esenciales de un objeto, fuerza al desarrollador a pensar cuidadosamente que es un objeto y que es lo que hace con el resultado de que el sistema es normalmente más preciso, general y robusto que si pusiéramos el énfasis en los procedimientos y los datos por separado
Encapsulación y ocultación de datos
La capacidad de presentación de información dentro de un objeto se divide en dos partes bien diferenciadas:
Interna: La información que necesita el objeto para operar y que es innecesaria para los demás objetos de la aplicación. Estos atributos se denominada privados y tienen como marco de aplicación únicamente a las operaciones asociadas al objeto.
Externa La que necesitan el resto de los objetos para interactuar con el objeto que definimos. Estas propiedades se denominan públicas y corresponde a la información que necesitan conocer los restantes objetos de la aplicación respecto del objeto definido para poder operar.
Podemos imaginarla encapsulación como introducir el objeto dentro de una caja negra donde existen dos ranuras denominadas entrada y salida. Si introducimos datos por la entrada automáticamente obtendrá un resultado en la salida. No necesita conocer ningún detalle del funcionamiento interno de la caja.
El término encapsulación indica la capacidad que tienen los objetos de construir una cápsula a su alrededor, ocultando la información que contienen (aquélla que es necesaria para su funcionamiento interno, pero innecesaria para los demás objetos) a las otras clases que componen la aplicación.
Aunque a primera vista la encapsulación puede parecer superflua, tengamos en cuenta que existen muchas variables utilizadas de forma temporal: contadores y variables que contienen resultados intermedios, etc. De no ser por la encapsulación estas variables ocuparían memoria y podrían interferir en el funcionamiento del resto de los objetos.
La encapsulación no es exclusiva de los lenguajes de programación orientados a objetos. Aparece en los lenguajes basados en procedimientos (PASCAL, C, COBOL, ETC) como una forma de proteger los datos que se manipulan dentro de las funciones.
Los lenguajes OOP incorporan la posibilidad de encapsular también las estructuras de datos que sirven como base a las funciones. Aportan por tanto un nivel superior en cuanto a protección de información.
La encapsulación nos permite el uso de librerías de objetos para el desarrollo de nuestros programas. Recordemos que las librerías son definiciones de objetos de propósito general que se incorporan a los programas. Al ser el objeto parcialmente independiente en su funcionamiento del programa en donde está definido, ya que contiene y define todo lo que necesita para poder funcionar, es fácil utilizarlo en los mas variados tipos de aplicaciones. Si aseguramos, depurando las propiedades y las operaciones dentro de la clase que el objeto función bien dentro de una aplicación, con una correcta encapsulación el objeto podrá funcionar en cualquier otra.
Otra de las ventajas en cualquier momento podemos cambiar el contenido de las operaciones del objeto, de manera que no afecte al funcionamiento general del programa.
La encapsulación está en el núcleo de dos grandes pilares de la construcción de sistemas; mantenibilidad y reusabilidad.
Mantenibilidad- Cualidad que indica que un programa o sistema debe ser fácilmente modificable. Es decir que los cambios en las condiciones externas (como la definición de una nueva variable) implicarán modificaciones pequeñas en el programa sistema. El concepto de mantenibilidad implica que un programa, al igual que un ser vivo debe ser capaz de adaptarse a un medio ambiente siempre cambiante.
Reusabilidad- Cualidad que nos indica que partes del programa (en este caso objetos) pueden ser reutilizados en la confección de otros programas. Ello implica que los objetos definidos en un programa pueden ser extraídos del mismo e implantados en otro sin tener que realizar modificaciones importantes en el código del objeto. El objeto final es que el programador construya una librería de objetos que le permita realizar programas basándose en la técnica de cortar y pegar. Esta extrae (corta) código de otras aplicaciones ya realizadas y las implementa (pega) en la aplicación a realizar donde, tras algunos retoques, la nueva aplicación estará lista para funcionar. Como podrá observar el concepto de reusabilidad, permite reducir el tiempo de realización, ganando en claridad, mantenibilidad y productividad.
La encapsulación de datos se muestra como una herramienta poderosa que nos permite ganar en tiempo de desarrollo y claridad, con el único coste adicional de definir con precisión las entradas y salida de nuestras operaciones.
Poliformismo
El polimorfismo es una nueva característica aportada por la OOP. Esta propiedad indica la posibilidad de definir varias operaciones con el mismo nombre, diferenciándolas únicamente en los parámetros de entrada. Dependiendo del objeto que se introduzca como parámetro de entrada, se elegirá automáticamente cual de las operaciones se va a realizar.
Ya está habituado al operador -suma- que está presente en todos los lenguajes de programación. Sin embargo, los operadores -suma de fracciones- y -suma de números complejos- no existen en casi ningún lenguaje de programación.
Los lenguajes OOP permiten definir un operador –suma- tal que reconozca que tipo de objeto se le está aplicando, a través de operaciones de objetos. Previamente deberá definir la fracción y el número complejo como una clase y la operación suma como una operación de una clase.
Definiendo adecuadamente las operaciones suma de fracciones y suma de números imaginarios, el operador suma devolverá, en el caso que los operandos sean fracciones, una fracción y, en el caso de los números imaginarios, otros número imaginario.
Es posible extender el concepto e incluso definir operaciones como suma de bases de datos

El operador suma de base de datos. Aunque a primera vista la expresión C= A+B, siendo A y B bases de datos, nos pudiera parecer una extraordinaria simplificación, nos conduce a la pregunta: ¿Qué es la suma de una base d datos?
Consideremos varias posibilidades:
Introducción de registros: Lo que exige que A y B tengan la misma estructura.
Unión de campos: Aquellos campos que aparezcan en B pero no en A serán añadidos a C
¿Alguna de estas dos opciones es verdaderamente una suma? Es decir ¿Cumple las propiedades conmutativa, asociativa, de elemento neutro, etc.? ¿Qué ocurre si sumo dos bases de datos con estructuras distintas?
Como puede observar, la definición de un operador sobre un tipo complejo de datos, intentando utilizar identificadores de operadores de datos simples, puede tener resultados impredecibles.
Una de las ventajas más importantes, sin entrar en la redefinición de operadores es permitir la realización de las clases que definen un programa de forma totalmente independiente al programa donde se utilizan. Gracias a la encapsulación y el polimorfismo, aunque se utilicen los mismos nombres con las operaciones en dos clases distintas, el programa reconoce a que clase se aplica durante la ejecución.
Como se podrá observar el polimorfismo y la encapsulación de datos están íntimamente ligados y nos permiten un mayor grado de mantenibilidad y reusabilidad que los lenguajes tradicionales Esta ese precisamente una de las causas de la revolución que ha supuesto la introducción de los lenguajes orientados a objetos dentro de la programación.
Herencia
La herencia es la última de las propiedades relativas a la OOP. Consiste en la propagación de los atributos y las operaciones a través de distintas sub-clases definidas a partir de una clase común.
Introduce, por tanto, una posibilidad de refinamiento sucesivo del concepto de clase. Nos permite definir una clase principal y, a través de sucesivas aproximaciones, cualquier característica de los objetos. A partir de ahora definiremos como sub-clases todas aquellas clases obtenidas mediante refinamiento de una (o varias) clases principales.
La herencia nos permite crear estructuras jerárquicas de clases donde es posible la creación de sub-clases que incluyan nuevas propiedades y atributos. Estas sub-clases admiten la definición de nuevos atributos, así como crear, modificar o inhabilitar propiedades.
Para pensarlo de manera más fácil podemos abstraernos al siguiente ejemplo.
Pensemos en los distintos sub-modelo s asociados a un modelo básico de automóvil. A partir de este modelo básico, los fabricantes introducen distintas características (aire acondicionado, ABS, distintas tapicerías, acabados, etc.) que crean sub – clases. Todas estas sub-clases tienen en común la estructura básica (chasis , dirección , etc.) u varían sólo en algunos de sus componentes.
Asociemos a este tipo básico una clase cuyos atributos representen las piezas que componen el coche. Las sub-clases aportarán sus propios atributos (en el caso de vehículos con aire acondicionado, todos aquellas piezas que lo componen), permitiendo la definición de todos los posibles modelos.

Además, es posible que una sub-clase herede atributos y propiedades de más de una clase. Este proceso se denomina herencia múltiple y lo veremos con más detalle en capítulos posteriores.
La herencia es, sin duda alguna, una de las propiedades más importantes de la OOP, ya que permite, a través de la definición de una clase básica, ir añadiendo propiedades a medida que sean necesarias y, además, en el sub-conjunto de objetos que sea preciso.
La herencia permite que los objetos puedan compartir datos y comportamientos a través de las diferentes sub-clases, sin incurrir en redundancia. Más importante que el ahorro de código, es la claridad que aporta al identificar que las distintas operaciones sobre los objetos son en realidad una misma cosa.
DATOS SOBRE EL USO DE OOP
APLICACIONES
A lo largo de la historia de la programación, los lenguajes y las metodologías han pasado de una relativa simplicidad a una complejidad creciente. Los lenguajes de programación orientados a objetos pretenden aportar simplicidad a la tarea de programación de grandes aplicaciones.
Cuando se crearon las primeras computadoras todavía no existían los lenguajes de programación, tal como ahora los entendemos. El lenguaje ensamblador puede considerarse como el primer lenguaje de programación propiamente dicho. Permitía al usuario un diálogo más fluido con la máquina a través de instrucciones que tenían relación directa con el conjunto de operaciones que la máquina podía realizar.
A partir de este momento empezó la evolución de los lenguajes de programación. _cada uno tenía su entorno definido y aunque en realidad todos los lenguajes son polivalentes (en teoría, con cualquiera de ellos se puede desarrollar cualquier programa de gestión o científico). Pronto apareció la especialización funcional. Así, COBOL (Common Business Orientated Language) se introdujo como lenguaje mainframe para el diseño de aplicaciones de gestión.; FORTRAN (Formula Translator) para el diseño de aplicaciones científicas; APL (A Programming Language) para el cálculo matemático, etc.
A medida que el software tomaba importancia, aparecieron los primeros problemas relacionados con la programación. Al tiempo que aumenta el volumen de un programa, disminuye el control del mismo por parte del programador y la capacidad de este de dar mantenimiento.
En un intento de solucionar estos problemas aparecen las metodologías de programación. Una metodología es un conjunto de reglas destinadas a simplificar las tareas de diseño, estimación de costes, desarrollo y mantenimiento de un sistema informático. A menudo se ven acompañadas con unas herramientas (CASE: Computer Aided Software Engeneering) que permiten la elaboración estructurada y documentada de los sistemas informáticos.
VENTAJAS
La OOP proporciona las siguientes ventajas sobre otros lenguajes de programación
Uniformidad. Ya que la representación de los objetos lleva implica tanto el análisis como el diseño y la codificación de los mismos.

Comprensión. Tanto los datos que componen los objetos, como los procedimientos que los manipulan, están agrupados en clases, que se corresponden con las estructuras de información que el programa trata.
Flexibilidad. Al tener relacionados los procedimientos que manipulan los datos con los datos a tratar, cualquier cambio que se realice sobre ellos quedará reflejado automáticamente en cualquier lugar donde estos datos aparezcan.
Estabilidad. Dado que permite un tratamiento diferenciado de aquellos objetos que permanecen constantes en el tiempo sobre aquellos que cambian con frecuencia permite aislar las partes del programa que permanecen inalterables en el tiempo.
Reusabilidad. La noción de objeto permite que programas que traten las mismas estructuras de información reutilicen las definiciones de objetos empleadas en otros programas e incluso los procedimientos que los manipulan. De esta forma, el desarrollo de un programa puede llegar a ser una simple combinación de objetos ya definidos donde estos están relacionados de una manera particular.
Uno de los puntos clave a remarcar en esta introducción es que la programación orientada a objetos no sustituye a ninguna metodología ni lenguaje de programación anterior. Todos los programas que se realizan según OOD se pueden realizar igualmente mediante programación estructurada. Su uso en la actualidad se justifica porque el desarrollo de todas las nuevas herramientas basadas en un interface de usuario gráfico como Windows, OS/2, x-Windows, etc. Es mucho más sencillo
BENEFICIOS
Día a día los costos del Hardware decrecen. Así surgen nuevas áreas de aplicación cotidianamente: procesamiento de imágenes y sonido, bases de datos multimediales, automatización de oficinas, ambientes de ingeniería de software, etc. Aún en las aplicaciones tradicionales encontramos que definir interfases hombre-máquina "a-la-Windows" suele ser bastante conveniente.
Lamentablemente, los costos de producción de software siguen aumentando; el mantenimiento y la modificación de sistemas complejos suele ser una tarea trabajosa; cada aplicación, (aunque tenga aspectos similares a otra) suele encararse como un proyecto nuevo, etc.
Todos estos problemas aún no han sido solucionados en forma completa. Pero como los objetos son portables (teóricamente) mientras que la herencia permite la reusabilidad del código orientado a objetos, es más sencillo modificar código existente porque los objetos no interaccionan excepto a través de mensajes; en consecuencia un cambio en la codificación de un objeto no afectará la operación con otro objeto siempre que los métodos respectivos permanezcan intactos. La introducción de tecnología de objetos como una herramienta concepual para analizar, diseñar e implementar aplicaciones permite obtener aplicaciones más modificables, fácilmente extendibles y a partir de componentes reusables. Esta reusabilidad del código disminuye el tiempo que se utiliza en el desarrollo y hace que el desarrollo del software sea mas intuitivo porque la gente piensa naturalmente en términos de objetos más que en términos de algoritmos de software.
PROBLEMAS QUE SE DERIVAN EN LA ACTUALIDAD
Un sistema orientado a objetos, por lo visto, puede parecer un paraíso virtual. El problema sin embargo surge en la implementación de tal sistema. Muchas compañías oyen acerca de los beneficios de un sistema orientado a objetos e invierten gran cantidad de recursos luego comienzan a darse cuenta que han impuesto una nueva cultura que es ajena a los programadores actuales. Específicamente los siguientes temas suelen aparecer repetidamente:
Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una forma única. Involucra la conceptualización de todos los elementos de un programa, desde subsistemas a los datos, en la forma de objetos. Toda la comunicación entre los objetos debe realizarse en la forma de mensajes. Esta no es la forma en que están escritos los programas orientados a objetos actualmente; al hacer la transición a un sistema orientado a objetos la mayoría de los programadores deben capacitarse nuevamente antes de poder usarlo.
Dependencia del lenguaje. A pesar de la portabilidad conceptual de los objetos en un sistema orientado a objetos, en la práctica existen muchas dependencias. Muchos lenguajes orientados a objetos están compitiendo actualmente para dominar el mercado. Cambiar el lenguaje de implementación de un sistema orientado a objetos no es una tarea sencilla; por ejemplo C++ soporta el concepto de herencia múltiple mientras que SmallTalk no lo soporta; en consecuencia la elección de un lenguaje tiene ramificaciones de diseño muy importantes.
Determinación de las clases. Una clase es un molde que se utiliza para crear nuevos objetos. En consecuencia es importante crear el conjunto de clases adecuado para un proyecto. Desafortunadamente la definición de las clases es más un arte que una ciencia. Si bien hay muchas jerarquías de clase predefinidas usualmente se deben crear clases específicas para la aplicación que se este desarrollando. Luego, en 6 meses ó 1 año se da cuenta que las clases que se establecieron no son posibles; en ese caso será necesario reestructurar la jerarquía de clases devastando totalmente la planificación original.
Performance. En un sistema donde todo es un objeto y toda interacción es a través de mensajes, el tráfico de mensajes afecta la performance. A medida que la tecnología avanza y la velocidad de microprocesamiento, potencia y tamaño de la memoria aumentan, la situacion mejorará; pero en la situación actual, un diseño de una aplicación orientada a objetos que no tiene en cuenta la performance no será viable comercialmente.
Idealmente, habría una forma de atacar estos problemas eficientemente al mismo tiempo que se obtienen los beneficios del desarrollo de una estrategia orientada a objetos. Debería existir una metodología fácil de aprender e independiente del lenguaje, y fácil de reestructurar que no drene la performance del sistema.

DIFERENCIAS ENTRE PROGRAMACION EXTRUCTURADA Y OOP
Básicamente la OOP permite a los programadores escribir software, de forma que esté organizado en la misma manera que el problema que trata de modelizar. Los lenguajes de programación convencionales son poco más que una lista de acciones a realizar sobre un conjunto de datos en una determinada secuencia. Si en algún punto del programa modificamos la estructura de los datos o la acción realizada sobre ellos, el programa cambia.
La OOP aporta un enfoque nuevo, convirtiendo la estructura de datos en el centro sobre el que pivotan las operaciones. De esta forma, cualquier modificación de la estructura de datos tiene efecto inmediato sobre las acciones a realizar sobre ella, siendo esta una de las diferencias radicales respecto a la programación estructurada.
Para quienes no están familiarizados con la programación estructurada diré que una de las bases de esta escuela de programación parte del diseño arriba – abajo. En esta forma de diseño se descomponen los requerimientos del programa paso a paso, hasta llegar a un nivel que permite expresarlos mediante procedimientos y funciones. La OOP estructura los datos en objetos que pueden almacenar, manipular y combinar información.
En resumen, la programación estructurada presta atención al conjunto de acciones que manipulan el flujo de datos (desde la situación inicial a la final), mientras que la programación orientada a objetos presta atención a la interrelación que existe entre los datos y las acciones a realizar con ellos.
Muchos habrán oído comentarios sobre la incidencia de la OOP sobre la programación convencional. Se ha llegado a decir que el cambio introducido por la OOP es similar al producido por la aparición del ensamblador sobre el código de máquina.