SEMANA 1
CONTENIDO CONCEPTUAL
Explicación del sílabo.
Introducción a la Programación Orientada a Objetos: Precursores de la POO, Programación
Orientada a Objetos, Relación de la POO con el pasado. Beneficios de la POO. Pilares de la
POO.
Introducción a la Programación Orientada a Objetos
La POO es una etapa en la evolución del desarrollo de software, combina las practicas
probadas para hacerlas más eficientes a lo largo del tiempo.
La OO es una abreviación de orientación a objetos, en la cual es un concepto que abarca
cualquier tipo de desarrollo basado en la idea de objetos, referente a una entidad que tiene
características y comportamiento. Es posible aplicar este enfoque en la programación en
análisis y diseño.
James Martín, en su libro “enfoque y diseño de un sistema, Orientado a Objetos”, señala que
en el mundo orientado a objetos, el análisis se realiza al estudiar los objetos en un ambiente y
los eventos que interactúan con dichos objetos. Por tal razón, hace referencia que una
herramienta útil para la descripción de tales eventos son los Diagramas de flujo de Objetos
(DFO), porque permiten mostrar las actividades que interactúan con otras en un sistema
cualquiera. Los DFO a diferencia de los DFD permiten mostrar no solo la transferencia de
datos, si no también representar cualquier cosa que se transfiera de una actividad a otra; es
decir, indicar los objetos que se producen y las actividades que producen e intercambian.
El Enfoque Orientado a Objetos
El contexto del Enfoque Orientado a Objetos (EOO) un objeto es una entidad que encapsula
datos (atributos) y acciones o funciones que los manejan (métodos). También para el EOO un
objeto se define como una instancia o particularización de una clase.
Los objetos de interés durante el desarrollo de software no sólo son tomados de la vida real
(objetos visibles o tangibles), también pueden ser abstractos. En general son entidades que
juegan un rol bien definido en el dominio del problema. Un libro, una persona, un carro, un
polígono, son apenas algunos ejemplos de objeto.
Cada objeto puede ser considerado como un proveedor de servicios utilizados por otros
objetos que son sus clientes. Cada objeto puede ser a la vez proveedor y cliente. De allí que un
programa pueda ser visto como un conjunto de relaciones entre proveedores clientes. Los
servicios ofrecidos por los objetos son de dos tipos:
Los datos, que llamamos atributos.
Las acciones o funciones, que llamamos métodos.
Fundamentos del Enfoque Orientado a Objeto
El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base de todo
desarrollo orientado a objetos.
Estos principios son: la Abstracción, el Encapsulamiento, la Modularidad y la Herencia.
Otros elementos a destacar (aunque no fundamentales) en el EOO son: Polimorfismo, Enlace
dinámico (o binding), Concurrencia y Persistencia.
El análisis orientado a objetos (AOO) y el diseño orientado a objetos (DOO) constituyen un
enfoque distinto de desarrollo de sistemas. Estas técnicas se basan en los conceptos de la
programación orientada a objetos, que han sido codificados en UML (Lenguaje Unificado de
Modelación), un lenguaje estandarizado de modulación en el cual los objetos generados no
solo incluyen código referente a los datos sino también instrucciones acerca de las operaciones
que se realizaran sobre los datos.
EL Paradigma Orientado a Objetos es una disciplina de ingeniería de desarrollo y modelado de
software que permite construir más fácilmente sistemas complejos a partir de componentes
individuales.
Objetos + Mensajes = Programa
El proceso Orientado a Objetos se mueve a través de una espiral evolutiva que comienza con la
comunicación con el usuario. Es en esta parte donde se define el dominio del problema y se
identifican las clases básicas del problema. La planificación y el análisis de riesgos establecen
una base para el plan de proyecto OO. El trabajo técnico asociado con la ingeniería del
software OO sigue las siguientes tareas:
1. Identificar clases candidatas
2. Buscar clases en biblioteca
3. Extraer nuevas clases si existen
4. Desarrollar las clases sino existen
5. Añadir las nuevas clases a la biblioteca
6. Construir n-esima iteración del sistema
La ingeniería de software hace hincapié en la reutilización. Por lo tanto las clases se buscan en
una biblioteca (de clases existentes) antes de construirse
Las Características del Enfoque Orientado a Objetos son:
a) Objeto: Los datos están cuantificados en entidades discretas y distinguibles llamadas
objetos.
b) Clase: Significa que los objetos con la misma estructura de datos (atributos) y
comportamiento (operaciones) se agrupa para formar una clase.
c) Atributo: Describen la clase o el objeto de alguna manera
d) Mensajes: Medio por el cual interactúan los objetos
e) Polimorfismo: Significa que una misma operación puede comportarse de modos distintos en
distintas clases.
f) Herencia: Compartir atributos y operaciones entre clases tomando como base una relación
jerárquica.
Precursores de la POO
En los principios de la programación, este de consideraba como ingeniosa, los programadores
incorporaban el código directamente a la memoria principal de la computadora, mediante
bancos de interruptores. Los desarrolladores escribían sus programas en lenguaje binario
comprensibles para las maquinas. Este tipo de programación era susceptible a errores y la falta
de una estructura era muy difícil de mantener. Además, el código maquina era muy difícil de
comprender.
Conforme las computadoras de popularizaban, empezaron a aparecer los lenguajes
procedurales, también conocidos como imperativos (foltran, algol). La característica de este
tipo de lenguajes era que los datos y los procedimientos estaban separados (no existía
encapsulamiento de datos)
Luego apareció la programación modular, que divide un programa en gran cantidad de
componentes (módulos). Los módulos ocultan los datos internos del resto del programa
(encapsulamiento).
Programación Orientada a Objetos (POO)
La POO da el paso a la programación modular a través de la herencia y polimorfismo.
La POO estructura un programa dividiendo en cantidad determinada de objetos de alto
nivel. Cada objeto le da forma algún aspecto del problema que se intenta resolver. Una
secuencia de llamadas a procedimiento para controlar el flujo del programa no es el
enfoque de POO. En vez de ell0o, los objetos interactúan entre si para dar lugar al flujo
total del programa de cierta forma, un programa OO se convierte en una simulación
real del problema que se intenta resolver.
Enfoque orientado a objetos Adoptamos el enfoque de objeto primero para enseñar
programación orientada a objetos con énfasis en el diseño adecuado orientado a
objetos. El concepto de objetos se ilustra claramente desde el mismo primer programa
de muestra.
Enfoque Orientada a Objetos (EOO)
El contexto del Enfoque Orientado a Objetos (EOO) un objeto es una entidad que
encapsula datos (atributos) y acciones o funciones que los manejan (métodos).
También para el EOO un objeto se define como una instancia o particularización de
una clase.
Los objetos de interés durante el desarrollo de software no sólo son tomados de la
vida real (objetos visibles o tangibles), también pueden ser abstractos. En general son
entidades que juegan un rol bien definido en el dominio del problema. Un libro, una
persona, un carro, un polígono, son apenas algunos ejemplos de objeto.
Cada objeto puede ser considerado como un proveedor de servicios utilizados por
otros objetos que son sus clientes. Cada objeto puede ser a al vez proveedor y cliente.
De allí que un programa pueda ser visto como un conjunto de relaciones entre
proveedores clientes. Los servicios ofrecidos por los objetos son de dos tipos:
Los datos, que llamamos atributos.
Las acciones o funciones, que llamamos métodos.
Tabla de diferencias
Enfoque y Diseño Estructurado Enfoque y Diseño Orientado a Objetos
Se consideran los elementos o Se consideran los conceptos básicos
perspectivas básicas del análisis como el Objeto y el Atributo, el todo y
(Entrada-Proceso-Salida), en función sus partes (software), clases y
del Software. miembros. Modela los objetos que
son parte de él.
Utiliza el diagrama estructurado Utiliza el diagrama orientado a
como represetación gráfica del objetos como representación gráfica
sistema. del sistema.
Consta de 5 Fases (Análisis, Diseño, Consta de 4 Fases (Análisis, Diseño,
Codificación, Pruebas e Integración). Evolución y Modificación).
No enfoca apropiadamente el Une a los usuarios y a los diseñadores.
diseño de familias de programas. Permite proporcionar una descripción
Asume una progresión relativa completa del problema, legible y
uniforme de pasos de elaboración.
revisable por las partes interesadas y
verificable contra la realidad.
No acomoda el tipo de desarrollo Si están correctamente definidas las
evolutivo. No enfoca los posibles jerarquías de clase, hacer
modos futuros de desarrollo de modificaciones no es tan costoso
software. como en el caso de programación
tradicional. Sólo hay que entrar en la
parte de Evolución para hacer
modificaciones.
El Diseño inicia una vez que ha El Diseño inicia aún antes de concluir
culminado la fase de análsis de con la etapa de análisis. Se
sistema. recomienda analizar un poco y
diseñar. Esta etapa debe concluir una
vez que se establecieron claves y
mecanismos importantes.
En este análisis se llega solo a la fase Un programa que se usa en un
de integración y no toma en ambiente real necesariamente debe
consideración los cambios que cambiar. Los cambios difieren un poco
ocurren dentro del sistema en el de los requeridos en evolución, pues
proceso de análisis y diseño de contemplan la introducción de nuevas
sistemas. funcionalidades no previstas en el
problema original.
Las herramientas utilizadas son: Las herramientas utilizadas son:
Diagrama de Flujo de Datos, Diagramas de Clases, Diagrama de
Diagramas de Entidad-Relación, Objetos, Diagramas de Módulos,
Diagrama de Transición de Estados. Diagramas de Procesos, Diagramas de
Transición de Estados, Diagramas de
Tiempo.
El análisis está orientado a los El análisis está orientado a los
Procesos del sistema. Objetos.
Requiere traducir el dominio del Es una forma de pensar acerca de un
problema en una serie de funciones problema en términos del mundo real
y subfunciones. El analista debe en vez de en términos de un
comprender primero el dominio del ordenador. El AOO permite analizar
problema y a continuación mejor el dominio del problema, sin
documentar las funciones y pensar en términos de implementar el
subfunciones que debe sistema en un ordenador. El AOO
proporcionar el sistema. No existe permite pasar directamente el
un mecanismo para comprobar si la dominio del problema al modelo del
especificación del sistema expresa sistema.
con exactitud los requisitos del
sistema.
Este enfoque se adapta bien al uso El concepto OO es más simple y está
de sistemas informáticos para menos relacionado con la informática
implementar el sistema, pero no es que el concepto de flujo de datos.
nuestra forma habitual de pensar. La Esto permite una mejor comunicación
comunicación entre el analista y la entre el analista y el experto en el
Organización está limitada, por las dominio del problema (es decir, el
fases. cliente).
La relación entre los modelos es Los objetos encapsulan tanto
muy débil, y hay muy poca atributos como operaciones. Debido a
influencia de un modelo en otro. En esto, el AOO reduce la distancia entre
la práctica, los modelos de procesos el punto de vista de los datos y el
y de datos de un mismo sistema se punto de vista del proceso, dejando
parecen muy poco. En muchos casos menos lugar a inconsistencias o
son visiones irreconciliables, no del disparidades entre ambos modelos.
mismo sistema, sino de dos puntos
de vista totalmente diferentes de
organizar la solución.
POO en el pasado
Origen
Los conceptos de la POO 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. En este centro se trabajaba en simulaciones de naves, que fueron
confundidas por la explosión combinatoria de cómo las diversas cualidades de
diferentes naves podían afectar unas a las otras. La idea surgió al agrupar los diversos
tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos
de definir sus "propios" datos y comportamientos. Fueron refinados más tarde en
Smalltalk, desarrollado en Simula en Xerox PARC (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 "sobre la marcha" (en tiempo de ejecución) en
lugar de tener un sistema basado en programas estáticos.
La POO se fue convirtiendo en el estilo de programación dominante a mediados de los
años 1980, 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 las cuales la POO está particularmente bien adaptada. En este
caso, se habla también de programación dirigida por eventos.
Las características de orientación a objetos fueron agregadas a muchos lenguajes
existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp más Pascal, entre 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 en la capacidad de
mantenimiento del código. Los lenguajes orientados a objetos "puros", por su 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 lenguaje de programación 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 Java en la
mayoría de navegadores web. PHP en su versión 5 se ha modificado; soporta una
orientación completa a objetos, cumpliendo todas las características propias de la
orientación a objetos.
Beneficios de la POO
Reusabilidad. Cuando hemos diseñado adecuadamente las clases, se pueden usar en
distintas partes del programa y en numerosos proyectos.
Mantenibilidad. Debido a las sencillez para abstraer el problema, los programas
orientados a objetos son más sencillos de leer y comprender, pues nos permiten
ocultar detalles de implementación dejando visibles sólo aquellos detalles más
relevantes.
Modificabilidad. La facilidad de añadir, suprimir o modificar nuevos objetos nos
permite hacer modificaciones de una forma muy sencilla.
Fiabilidad. Al dividir el problema en partes más pequeñas podemos probarlas de
manera independiente y aislar mucho más fácilmente los posibles errores que puedan
surgir.
La programación orientada a objetos presenta también algunas desventajas como
pueden ser:
Cambio en la forma de pensar de la programación tradicional a la orientada a objetos.
La ejecución de programas orientados a objetos es más lenta.
La necesidad de utilizar bibliotecas de clases obliga a su aprendizaje y entrenamiento.
Los 4 pilares de la Programación Orientada a Objetos
Existen muchos conceptos en programación orientada a objetos, como clases y
objetos, sin embargo, en el desarrollo de software con programación orientada a
objetos, existen un conjunto de ideas fundamentales que forman los cimientos del
desarrollo de software. A estos 4 conceptos que vamos a ver les llamamos los 4 pilares
de la programación orientada a objetos.
Esto no quiere decir que fuera de estos 4 pilares no existan otras ideas igual de
importantes, sin embargo, estos 4 pilares representan la base de ideas más avanzadas,
por lo que es crucial entenderlos.
Estos pilares son: abstracción, encapsulamiento, herencia y polimorfismo.
public class Carro
{
public string Marca;
public int AñoSalidaAlMercado { get; set; }
public void Acelerar()
{
}
}
Abstracción
De acuerdo a la RAE, una de las acepciones de abstraer es:
“Hacer caso omiso de algo, o dejarlo a un lado.” Y ofrece como ejemplo: “Centremos la
atención en lo esencial abstrayendo DE consideraciones marginales.”
El ejemplo dado captura la esencia del concepto de abstraer. Cuando hacemos una
abstracción, queremos omitir detalles que no son necesarios para nosotros, y
queremos solamente mostrar lo que sí es relevante.
Desde el punto de vista del desarrollo de software, podemos ver que con una clase
podemos realizar una abstracción de una entidad del mundo real. Tomemos por
ejemplo la clase carro que hicimos, esta tiene la posibilidad de guardar datos
relacionados a la marca y al año de salida al mercado del carro, pero, ¿Por qué
solamente estas dos informaciones? Un carro del mundo real tiene más propiedades,
como el color y el modelo. Sin embargo, debemos preguntarnos, ¿Son estas
informaciones relevantes para nuestro software?
Nuestra clase abstrae todo lo que representa un carro, tomando solamente lo que nos
interesa, descartando todo lo demás.
Encapsulamiento
Ya sabes que puedes utilizar clases para modelar entidades las cuales son relevantes
para tu aplicación, sabes además que puedes guardar datos dentro de objetos, y
también ejecutar funcionalidad. La pregunta que debemos hacernos es, ¿Debe
cualquiera poder modificar de manera directa estos datos? ¿Debe cualquiera ejecutar
cualquier funcionalidad de nuestros objetos en cualquier momento? Normalmente
esto no es algo que queremos, nosotros queremos poder controlar la manera en que
se asignen los datos, queremos poder controlar quién ve la data interna de nuestros
objetos, e incluso quizás queramos controlar la ejecución de funcionalidad de nuestros
objetos. Para esto tenemos el concepto de encapsulamiento.
El encapsulamiento nos permite controlar quien puede ver y utilizar los distintos
módulos internos de nuestro sistema. En términos de clases, con el encapsulamiento
definimos el acceso a los miembros de la clase.
En C# podemos utilizar modificadores de acceso para definir el control de agentes
externos a distintas partes de nuestro sistema, como clases, miembros de las clases,
interfaces, entre otros. Supongamos que tenemos una variable, llamada velocidad, la
cual queremos colocar en nuestra clase Carro, para indicar la velocidad en la cual se
desplaza un vehículo en particular. Sin embargo, queremos que solamente dentro de
la clase podamos ver y modificar el valor de dicha variable. Esto lo podemos hacer o
con un campo o con una propiedad. Hagámoslo con una propiedad:
public class Carro
{
public string Marca;
public int AñoSalidaAlMercado { get; set; }
private int Velocidad { get; set; }
public void Acelerar()
{
Velocidad += 10;
}
}
Cuando hagamos una instancia de la clase Carro, no podremos acceder al valor de la
propiedad Velocidad, ni tampoco podemos alterarlo desde afuera. Lo que sí podemos
hacer es utilizar la función acelerar para aumentar el valor de la velocidad en 10
unidades. Esta es una de las ventajas del encapsulamiento: Nos permite controlar la
manera en que se va a alterar la data interna de nuestro objeto.
Si quisiéramos que agentes externos puedan ver el valor la propiedad Velocidad, pero
que no puedan alterar libremente dicho valor, podemos utilizar la siguiente sintaxis:
public int Velocidad { get; private set; }
Herencia
Compartir código es una importante y crucial característica de cualquier proyecto de
software. Compartir código permite ahorrar trabajo cuando queremos hacer un
cambio en nuestro sistema; permite que un solo algoritmo pueda procesar distintas
clases de entidades; entre otras cosas.
Hay varias maneras de compartir código, una de ellas es utilizando herencia. La
herencia es una relación especial entre dos clases, la clase base y la clase derivada,
en donde la clase derivada obtiene la habilidad de utilizar ciertas propiedades y
funcionalidades de la clase base, incluso pudiendo sustituir funcionalidad de la clase
base. La idea es que la clase derivada “hereda” algunas de las características de la
clase base.
Podemos ver un ejemplo de la clase Carro. Un carro es un tipo de vehículo, además,
queremos procesar otro tipo de vehículos, cada uno con su entidad, como camión.
Un carro y un camión comparten el concepto de velocidad, además, ambos tienen la
capacidad de acelerar, y ambos tienen la capacidad de ir de reversa, sin embargo,
cuando un camión va de reversa, este debe emitir un sonido. Finalmente, un carro
debe poder encender la radio. Vamos entonces a modelar esto:
public class Vehículo
{
public string Marca;
public int AñoSalidaAlMercado { get; set; }
public int Velocidad { get; private set; }
public void Acelerar()
{
Velocidad += 10;
}
public virtual void Reversa()
{
Console.WriteLine("Voy de reversa!");
}
}
public class Carro: Vehículo
{
public void EncenderRadio()
{
Console.WriteLine("Encendiendo la radio");
}
}
public class Camión: Vehículo
{
public override void Reversa()
{
base.Reversa();
Console.WriteLine("BEEP BEEP BEEP!");
}
}
Vemos que tenemos 3 clases: Vehículo, Carro y Camión. Carro y Camión heredan de
la clase Vehículo. La relación de herencia se representa de esta manera:
class Carro: Vehículo
Con esta sintaxis decimos que Carro es una clase derivada de Vehículo.
Vemos además que la función Acelerar está definida en la clase Vehículo, esto hace
que todas las clases derivadas pueden hacer uso de dicha función. Lo mismo sucede
con los campos y propiedades.
Ciertamente las clases Carro y Camión pueden definir sus propios miembros que no
se relacionan con la clase Vehículo. Por ejemplo, la clase Carro tiene el método
EncenderRadio el cual solo esta lo tiene.
Podemos también modificar funcionalidad de la clase base. Para esto, en la clase
base, el método debe estar marcado como virtual. Y cuando se quiera sobrescribir,
es decir, cambiar o agregar funcionalidad, esto lo podemos hacer haciendo un
override, tal cual vemos en la clase Camión. Dentro del método Reversa de la clase
Camión, tenemos el código base.Reversa(); el cual sirve para invocar el método
reversa de la clase base.
Podemos utilizar el código anterior de la siguiente manera:
Carro miCarro = new Carro();
miCarro.AñoSalidaAlMercado = 2018;
miCarro.Acelerar();
Console.WriteLine(miCarro.Velocidad);
miCarro.Reversa();
Console.WriteLine("-------");
Camión miCamion = new Camión();
miCamion.Acelerar();
miCamion.AñoSalidaAlMercado = 2012;
miCamion.Reversa();
Clases Abstractas
¿Qué tal si quisiéramos que la clase Vehículo no pudiera ser instanciada? Podemos
marcarla como una clase abstracta. Una clase abstracta es aquella que no puede ser
instanciada. Es útil en situaciones de herencia donde no queremos que los usuarios
instancien la clase base, sino que queremos que instancien solamente las clases
derivadas. Para marcar la clase Vehículo como abstracta utilizamos abstract:
public abstract class Vehículo
¿Qué tal si quisiéramos obligar a las clases derivadas a implementar una función
específica, sin que la clase base dé una implementación por defecto? Para esto
podemos marcar el método como abstract. Ejemplo:
public abstract void MetodoObligatorio();
Interfaces
Las interfaces nos ayudan a realizar otro tipo de herencia. Mientras que una clase
base nos ofrece implementación por defecto de algunos métodos, como el método
reversa de la clase Vehículo, las interfaces nos ofrecen un conjunto de miembros que
las clases que implementan la interfaz deben implementar. Las interfaces no pueden
ser instanciadas, igual que las clases abstractas.
Históricamente, una diferencia fundamental entre interfaces y clases abstractas es
que las clases abstractas nos permiten crear implementaciones por defecto de
métodos y las interfaces no. Sin embargo, es posible que en C# 8 eso cambie con la
introducción de implementaciones por defecto en interfaces.
Nota: Aunque las interfaces son un tipo de herencia, es normal referirse a herencia
solamente al caso en el que tenemos una clase base.
Polimorfismo
Cuando empezamos a hablar de herencia, dijimos que la herencia “permite que un
solo algoritmo pueda procesar distintas clases de entidades”. La idea es que
podemos tener una función la cual reciba un parámetro, como una clase base, y
podemos pasarle a ese método objetos que sean instancias de las clases derivadas
de dicha clase base. Lo mismo ocurre si el método recibe como parámetro una
interfaz. Podemos pasarle a dicho método cualquier clase que implemente dicha
interfaz.
Polimorfismo significa de muchas formas. En nuestro caso llamamos polimorfismo
cuando un método recibe un parámetro que abarca varios tipos.
Veamos un ejemplo de polimorfismo donde pasamos a un método la clase base
Vehículo:
static void Reparar(Vehículo vehículo)
Console.WriteLine("Iniciando reparación");
Console.WriteLine("Probando acelerador");
Console.WriteLine($"Velocidad inicial {vehículo.Velocidad}");
vehículo.Acelerar();
Console.WriteLine($"Velocidad final {vehículo.Velocidad}");
Console.WriteLine("Probando reversa");
vehículo.Reversa();
Console.WriteLine("Listo!");
}
Este método invoca los métodos Acelerar y Reversa del vehículo que se le envíe
como parámetro. La ventaja que esto ofrece es que podemos generalizar algoritmos
para que funcionen con distintos tipos. En este caso, este método va a funciona con
cualquier clase que herede de Vehículo, en tal sentido, incluso si en el futuro
agregamos la clase Motocicleta, la cual hereda de Vehículo, podemos utilizar esta
nueva clase con el método Reparar, y va a funcionar perfectamente. De esta manera
se da el polimorfismo, pues el método reparar puede trabajar con varios tipos
distintos.
En el método reparar no podemos hacer uso del método EncenderRadio de la clase
Carro, pues la clase Vehículo no implementa dicho método. Lo que podríamos hacer
es utilizar el operador is para castear a Carro en caso de que el Vehículo sea un carro:
if (vehículo is Carro miCarro)
miCarro.EncenderRadio();
}
Esta sintaxis es una manera resumida de decir:
if (vehículo is Carro)
Carro miCarro = vehículo as Carro;
miCarro.EncenderRadio();
}
Conclusión
En esta entrada vimos los 4 pilares de la programación orientada a objetos:
Abstracción, encapsulamiento, herencia y polimorfismo. También hablamos acerca
de las clases abstractas e interfaces.
