Está en la página 1de 77

Programacin Orientada

a objetos
Tema 3
ITECA
Contenido
Definicin de clases
Instanciacin de objetos
Constructores
Destructores
Herencias mltiples
Control de acceso a una clase
Palabra clave mutable
Mtodos
Encapsulamiento
Polimorfismo
Definicin de clases
Instanciacin de objetos
Una vez que tenemos una clase definida, lo nico de lo que disponemos es
de una especie de plantilla o molde a partir del cual podemos crear objetos en
memoria.
Para crear esos objetos en C# lo podemos hacer de dos formas, pero como
veremos siempre ser mediante la instruccin new que es la encargada de
crear el objeto en la memoria y asignar la direccin del mismo a la variable
usada en la parte izquierda de la asignacin.
Declarar primero la variable y despus instanciarla
Instanciacin de objetos
Lo primero que tenemos que hacer es declarar una variable del tipo que queremos
instanciar, esto lo hacemos de la misma forma que con cualquier otro tipo de datos:
Punto2d miPunto;
Con esta lnea de cdigo lo que estamos indicando a C# es que tenemos intencin
de usar una variable llamada miPunto para acceder a una clase de tipo Punto2d.
Esa variable, cuando llegue el momento de usarla, sabr todo lo que hay que saber
sobre una clase Punto2d, pero hasta que no tenga una "referencia" a un objeto de
ese tipo no podremos usarla.
Instanciacin de objetos
La asignacin de una referencia a un objeto Punto2d la haremos usando la
instruccin new seguida del nombre de la clase:
miPunto = new Punto2d();
A partir de este momento, la variable miPunto tiene acceso a un nuevo
objeto del tipo Punto2d, por tanto podremos usarla para asignarle valores y
usar cualquiera de los miembros que ese tipo de datos contenga:
miPunto.X=2;
miPunto.imprimirPunto();
Instanciacin de objetos
La otra forma de instanciar una clase es hacindolo al mismo tiempo que la
declaramos. En C# esto se hace como si uniramos la declaracin y la
instanciacin en una sola instruccin:
Punto2d miPunto1 = new Punto2d();
De esta forma se asignar a la variable miPunto1 una referencia a un nuevo
objeto creado en la memoria, el cual ser totalmente independiente del resto
de objetos creados con esa misma clase.
Constructores
Cada vez que creamos un nuevo objeto en memoria estamos llamando al constructor de la
clase. En C# el constructor es una especie de mtodo que se llama de la misma forma que la
clase.
En el constructor de una clase podemos incluir el cdigo que creamos conveniente, pero
realmente solamente deberamos incluir el que realice algn tipo de inicializacin, en caso de
que no necesitemos realizar ningn tipo de inicializacin, no es necesario definir el
constructor, ya que el propio compilador lo har por nosotros. Esto es as porque todas las
clases deben implementar un constructor, por tanto si nosotros no lo definimos, lo har el
compilador de C#.
Si definimos una clase Cliente que tiene un campo para almacenar la fecha de creacin del
objeto podemos hacer algo como esto:
Constructores
class Cliente
{
public string Nombre;
public string Apellidos;
public DateTime FechaCreacion;

public Cliente()
{
FechaCreacion = DateTime.Now;
}
}
Constructores
De esta forma podemos crear un nuevo Cliente y acto seguido comprobar el
valor del campo FechaCreacion para saber la fecha de creacin del objeto.
En los constructores tambin podemos hacer las inicializaciones que, por
ejemplo permitan a la clase a conectarse con una base de datos, abrir un
fichero o cargar una imagen grfica, etc.
Constructores
De la misma forma que podemos tener mtodos sobrecargados, tambin podemos
tener constructores sobrecargados, ya que en C# el constructor es como una
funcin con un tratamiento especial que devuelve un nuevo objeto.
La ventaja de tener constructores que admitan parmetros es que podemos crear
nuevos objetos indicando algn parmetro, por ejemplo un fichero a abrir o, en el
caso de la clase Cliente, podemos indicar el nombre y apellidos del cliente o
cualquier otro dato que creamos conveniente.
Para comprobarlo, podemos ampliar la clase definida anteriormente para que
tambin acepte la creacin de nuevos objetos indicando el nombre y los apellidos
del cliente.
Constructores
class Cliente;
{
public string Nombre;
public string Apellidos;
public DateTime FechaCreacion;
public Cliente()
{
FechaCreacion = DateTime.Now;
}

public Cliente(string elNombre, string losApellidos)
{
Nombre = elNombre;
Apellidos = losApellidos;
FechaCreacion = DateTime.Now;
}
}
Constructores
Teniendo esta declaracin de la clase Cliente, podemos crear nuevos clientes
de dos formas:
Cliente c1 = new Cliente();
Cliente c2 = new Cliente("Jose", "Snchez");
Como podemos comprobar, en ciertos casos es ms intuitiva la segunda
forma de crear objetos del tipo Cliente, adems de que as nos ahorramos de
tener que asignar individualmente los campos Nombre y Apellidos.
Constructores
Esta declaracin de la clase Cliente la podramos haber hecho de una forma
diferente.
Por un lado tenemos un constructor "normal" (no recibe parmetros) en el
que asignamos la fecha de creacin y por otro el constructor que recibe los
datos del nombre y apellidos.
En ese segundo constructor tambin asignamos la fecha de creacin, ya que,
se instancie como se instancie la clase, nos interesa saber siempre la fecha de
creacin.
Constructores
En este ejemplo, por su simpleza no es realmente un problema repetir la
asignacin de la fecha, pero si en lugar de una inicializacin necesitramos
hacer varias, la verdad es que nos encontraramos con mucha "duplicidad" de
cdigo.
Por tanto, en lugar de asignar los datos en dos lugares diferentes, podemos
hacer esto otro:

Constructores
class Cliente
{
public string Nombre;
public string Apellidos;
public DateTime FechaCreacion;
public Cliente()
{
FechaCreacion = DateTime.Now;
}

public Cliente(string elNombre, string losApellidos) : this()
{
Nombre = elNombre;
Apellidos = losApellidos;
}
}
Constructores
Es decir, desde el constructor con parmetros llamamos al constructor que no los
tiene, consiguiendo que tambin se asigne la fecha.
La instruccin this se emplea para acceder a la instancia actual, es decir al objeto
que est en la memoria, y cuando lo usamos de la forma mostrada en el cdigo,
realmente llama al constructor, en este caso sin parmetros, aunque de haberlo
necesitado podemos indicarle los argumentos que creamos conveniente, siempre
que exista un constructor con ese nmero de parmetros.
La llamada a otros constructores de la misma instancia, solo podemos hacerla desde
un constructor y esa llamada debe estar antes del inicio del cdigo de la clase, es
decir, antes de la llave de apertura.
Constructores
Tal como hemos comentado, si nosotros no definimos un constructor, lo
har el propio compilador de C#, y cuando lo hace automticamente,
siempre es un constructor sin parmetros.
Pero hay ocasiones en las que nos puede interesar que no exista un
constructor sin parmetros, por ejemplo, podemos crear una clase Cliente
que solo se pueda instanciar si le pasamos, por ejemplo el nmero de
identificacin tributaria, (NIT), en caso de que no se indique ese dato, no
podremos crear un nuevo objeto Cliente; de esta forma nos aseguramos de
que el NIT siempre est especificado.
Constructores
Seguramente por ese motivo, si nosotros definimos un constructor con
parmetros, C# no lo crea automticamente sin parmetros.
Por tanto, si definimos un constructor con parmetros en una clase y
queremos que tambin tenga uno sin parmetros, lo tenemos que definir
nosotros mismos, aunque no es necesario que el constructor sin parmetros
ejecute cdigo, puede estar declarado sin ms.

Destructores
De la misma forma que una clase tiene su punto de entrada o momento de
nacimiento en el constructor, tambin tienen un sitio que se ejecutar cuando el
objeto creado en la memoria ya no sea necesario, es decir, cuando acabe la vida del
objeto creado.
El destructor de C# se llama igual que la clase pero precedida del carcter ~ y no
puede tener ningn modificador de visibilidad. Y solo es necesario definirlo si
nuestra clase utiliza algn tipo de recurso, por tanto no es necesario definirlo si no
tenemos que liberar expresamente algn recurso asignado en el constructor.
La definicin del destructor de nuestra clase Cliente poda ser algo como esto:
Destructores
~Cliente()
{
}
El que un destructor no sea accesible externamente es por la sencilla razn
de que es el propio CLR el que se encarga de gestionar la destruccin de los
objetos que ya no son utilizados.
Destructores
La destruccin de un objeto es realizada por el recolector de basura cuando
realiza una recoleccin de basura y detecta que no existen referencias a ese
objeto ni en pila, ni en registros ni desde otros objetos s referenciados.
Las recolecciones se inician automticamente cuando el recolector detecta
que queda poca memoria libre o que se va a finalizar la ejecucin de la
aplicacin, aunque tambin puede forzarse llamando al mtodo Collect() de
la clase System.GC

Herencias mltiples
Definicin de herencia:
En orientacin a objetos la herencia es el mecanismo fundamental para
implementar la reutilizacin y extensibilidad del software. A travs de ella los
diseadores pueden construir nuevas clases partiendo de una jerarqua de
clases ya existente (comprobadas y verificadas) evitando con ello el rediseo,
la remodificacin y verificacin de la parte ya implementada. La herencia
facilita la creacin de objetos a partir de otros ya existentes, obteniendo
caractersticas (mtodos y atributos) similares a los ya existentes.
Herencias mltiples
class Vehiculo
{
public int Velocidad { get { ... } }
public void Acelerar (int delta) { ...}
public void Frenar (int vf) { ... }
public void Girar (int angulos) { ... }
}
Herencias mltiples
La clase Vehculo representa un concepto de algo que tiene una determinada
Velocidad y que puede Acelerar, Frenar y Girar.
Ahora bien, si nos aparece el concepto de Coche y lo modelamos como una
nueva clase, es de esperar que un Coche tambin tenga una Velocidad, pueda
Acelerar, pueda Frenar y pueda Girar
Para que vamos a codificar de nuevo todos esos mtodos si ya los hemos
definido (codificado, recordar que una clase implementa un concepto) para
Vehculo?
Herencias mltiples
Este es un punto importante: la herencia no es herencia slo de interfaz sino
tambin de implementacin. Es decir, si tengo mi clase:
class Coche : Vechiculo
{
public string Marca { get { ... } }
public string Modelo { get { ... } }
}
Herencias mltiples
Un Coche es un Vehculo que adems tiene una Marca y un Modelo. As yo puedo
hacer:
Coche c = new Coche();
c.Acelerar(100);
// A que velocidad va mi coche?
int velocidad = c.Velocidad;
// Es un SEAT?
if (c.Marca == "SEAT") { ... }
Herencias mltiples
Herencia mltiple
C# (al igual que Java) es un lenguaje con herencia simple. Eso significa que una clase
slo puede derivar de una clase base a la vez. P.ej. esto en C# no es vlido:
class VehiculoAereo { ... }
class VehiculoMaritimo { ... }
// Error: Herencia mltiple no soportada en C# (no lo est en .NET en general)
class Hidroavion : VehiculoAereo, VehiculoMaritimo { ... }
Herencias mltiples
Existen otros lenguajes (como C++) que soportan herencia mltiple y donde
lo anterior seria vlido.
La teora de programacin orientada a objetos no pone restricciones al
respecto En muchos libros se menciona esa limitacin aduciendo
simplemente que la herencia mltiple es peligrosa pero, por que?
Es difcil contar exactamente el problema en el que puede incurrir la herencia
mltiple, pero el motivo por el cual la herencia mltiple es peligrosa se llama
Herencia en diamante.
Herencias mltiples
Bsicamente el problema de la herencia en diamante se produce cuando
una clase D, hereda de dos clases B y C, las cuales ambas heredan de A.
Que pasa si:
La clase A define un mtodo FooA()
La clase B (que hereda de A) obtiene una copia del mtodo FooA()
La clase C (que hereda de A) obtiene una copia del mtodo FooA()
La clase D que hereda de B y de C obtiene dos copias del mtodo
FooA (el de B y el de C). Pero una clase no puede tener dos mtodos
FooA() con el mismo nombre y parmetros as que eso da error.
Herencias mltiples
Los lenguajes que soportan herencia mltiple (como C++) abordan ese
problema mediante la llamada herencia virtual pero otros lenguajes optan por
eliminar el problema de raiz impidiendo la herencia mltiple.
Entre estos lenguajes estn todos los de .NET (C#, VB.NET, ) o Java
entre ellos.

Herencias mltiples
No tener herencia mltiple puede suponer una limitacin y en algn momento
puede serlo, pero nunca es muy grave:
Muchos diseos que requieren herencia mltiple pueden repensarse para usar slo
herencia simple.
La clave est en que la mayora de veces realmente no queremos herencia mltiple
sino polimorfismo mltiple.
El polimorfismo mltiple est soportado en C# (y en .NET en general) mediante el
uso de interfaces: Una clase puede implementar uno o ms interfaces.
Herencias mltiples
Que es un interfaz?
En teora de orientacin a objetos, la interfaz de una clase es todo lo que
podemos hacer con ella.
A efectos prcticos: todos los mtodos, propiedades y variables pblicas
(aunque no deberan haber nunca variables pblicas, debemos usar
propiedades en su lugar) de la clase conforman su interfaz.
Herencias mltiples
Dada la siguiente clase:
class Contenedor
{
public int Quitar();
public void Meter(int v);
private bool EstaRepetido(int v);
}
Herencias mltiples
Su interfaz est formada por los mtodos Quitar y Meter.
El mtodo EstaRepetido no forma parte de la interfaz de dicha clase, ya que
es privado.
En orientacin a objetos decimos que la interfaz de una clase define el
comportamiento de dicha clase, ya que define que podemos y que no
podemos hacer con objetos de dicha clase: dado un objeto de la clase
Contenedor yo puedo llamar al mtodo Quitar y al mtodo Meter pero no
puedo llamar al mtodo EstaRepetido.
Herencias mltiples
As: toda clase tiene una interfaz que define que podemos hacer con los
objetos de dicha clase.

Herencias mltiples
class Contenedor
{
public int Quitar() { ... }
public void Meter (int v) { ... }
}

class OtroContenedor
{
public int Quitar() { ... }
public void Meter (int v) { ... }
}
Herencias mltiples
Ahora imagina que:
public void main()
{
Contenedor c = new Contenedor();
// Hacer cosas con c como p.ej:
int i = c.Quitar();
c.Meter(10);
}
Si incluyo estas lneas :
Contenedor oc = new
OtroContenedor();
oc.Meter(2);
Compilara este cdigo????????
Herencias mltiples
Pero esto no va a compilar, Por que?
Pues aunque nosotros somos capaces leyendo el cdigo de comparar la
interfaz de ambas clases, el compilador no puede hacer esto.
Para el compilador Contenedor y OtroContenedor son dos clases totalmente
distintas sin ninguna relacin.
Por lo tanto un mtodo que espera un Contenedor no puede aceptar un
objeto de la clase OtroContenedor.
Herencias mltiples
Hay que recalcar que el hecho de que el compilador no compare las
interfaces de las clases no se debe a una imposibilidad tcnica ni nada
parecido: se debe a que no tiene sentido hacerlo.
Por que?, Pues simplemente porque las interfaces son idnticas por pura
casualidad.
Supnganos que fuese legal definir oc con un objeto OtroContenedor
Herencias mltiples
Entonces podra pasar lo siguiente:
Alguien aade un mtodo pblico a la clase Contenedor.
Se modifica el mtodo main para que llame a dicho mtodo nuevo. Eso es
legal porque oc es un Contenedor;
Como debe comportarse oc ahora? OtroContenedor no tiene el mtodo
nuevo que se aadi a Contenedor!
Herencias mltiples
As pues: dos clases con la misma interfaz no tienen relacin alguna entre
ellas y por lo tanto no se deberan intercambiar.
El ejemplo anterior ejemplifica un caso muy comn:
Tener dos clases que hacen lo mismo pero de diferente manera.
P.ej. imagina que Contenedor est implementado usando un array en
memoria y OtroContenedor est implementando usando lista enlazada.

Herencias mltiples
La funcionalidad (la interfaz) es la misma, lo que vara es la implementacin.
Es por ello que en programacin orientada a objetos decimos que las
interfaces son funcionalidades (o comportamientos) y las clases representen
implementaciones.
Ahora bien, si dos clases representan dos implementaciones distintas de la
misma funcionalidad, es muy raro que no las podamos intercambiar
Herencias mltiples
Para que dicho intercambio sea posible C# (y en general cualquier lenguaje
orientado a objetos) permite explicitar la interfaz
Es decir separar la declaracin de la interfaz de su implementacin (de su
clase).
Para ello usamos la palabra clave interface
Herencias mltiples
interface IContenedor
{
int Quitar();
void Meter(int i);
}
Herencias mltiples
Este cdigo declara una interfaz IContenedor que declara los mtodos
Quitar y Meter.
Fjarse que los mtodos no se declaran como public (en una interfaz la
visibilidad no tiene sentido, ya que todo es public) y que no se implementan
los mtodos.
Las interfaces son un concepto ms terico que real. No se pueden crear
interfaces.
Herencias mltiples
El siguiente cdigo NO compila:
IContenedor c = new IContenedor();
// Error: No se puede crear una interfaz!
Es lgico que NO podamos crear interfaces, ya que si se nos dejara, y luego
hacemos c.Quitar()
Que mtodo se llamara si el mtodo Quitar() no est implementado?
Herencias mltiples
Aqu es donde volvemos a las clases: podemos indicar explcitamente que una clase
implementa una interfaz, es decir proporciona implementacin (cdigo) a todos y
cada uno de los mtodos (y propiedades) declarados en la interfaz:
class Contenedor : IContenedor
{
public int Quitar() { ... }
public void Meter(int i) { ... }
}
Herencias mltiples
La clase Contenedor declara explcitamente que implementa la interfaz IContenedor.
As pues la clase debe proporcionar implementacin para todos los mtodos de la interfaz.
El siguiente cdigo p.ej. no compila:
class Contenedor : IContenedor
{
public void Meter(int i) { ... }
// Error: Y el mtodo Quitar()???
}
Herencias mltiples
Es por esto que en orientacin a objetos decimos que las interfaces son
contratos, porque si yo creo la clase la interfaz me obliga a implementar
ciertos mtodos y si yo uso la clase, la interfaz me dice que mtodos puedo
llamar.
Y ahora viene lo bueno: Si dos clases implementan la misma interfaz son
intercambiables.
Herencias mltiples
Dicho de otro modo, en cualquier sitio donde se espere una instancia de la interfaz puede
pasarse una instancia de cualquier clase que implemente dicha interfaz.
Podramos declarar nuestro mtodo foo anterior como sigue:
void main()
{
IContenedor c = new Contenedor();
c.Quitar();
c.Meter(10);
}
Herencias mltiples
Fjarse que la clave es que c est declarado como IContenedor, no como
Contenedor o OtroContenedor, con esto indicamos que el mtodo main()
trabaja con cualquier objeto de cualquier clase que implemente IContenedor.
Y ahora, si sabemos que tanto Contenedor como OtroContenedor
implementan la interfaz Icontenedor
El siguiente cdigo es vlido:
Herencias mltiples
Contenedor c = new Contenedor();
OtroContenedor oc = new OtroContenedor();
// Incluso esto es vlido:
IContenedor ic = new Contenedor();
IContenedor ic2 = new OtroContenedor();
Herencias mltiples
Cuando usar interfaces?
En general siempre que tengas, o preveas que puedes tener ms de una clase
para hacer lo mismo: usa interfaces.
Es mejor pecar de exceso que de defecto en este caso.
No te preocupes por penalizaciones de rendimiento en tu aplicacin porque
no las hay.
Herencias mltiples
Imagina que tenemos un sistema que debe trabajar con varios vehculos, entre ellos aviones y coches, as que
declaramos la siguiente interfaz:
interface IVehiculo
{
void Acelerar(int kmh);
void Frenar();
void Girar(int angulos);
void Despegar();
void Aterrizar();
}
Herencias mltiples
Luego implementamos la clase avin:
class Avion : IVehiculo
{
public void Acelerar(int kmh) { ... }
public void Frenar() { ... }
public void Girar (int angulos) { ... }
public void Despegar() { ... }
public void Aterrizar() { ... }
}
Herencias mltiples
Y luego vamos a por la clase coche y aqu surge el problema:
class Coche : IVehiculo
{
public void Acelerar(int kmh) { ... }
public void Frenar() { ... }
public void Girar (int angulos) { ... }
public void Despegar() {throw new NotImplementedException("Coches no vuelan"); }
public void Aterrizar(){throw new NotImplementedException("Coches no vuelan"); }
}
Herencias mltiples
La interfaz IVehiculo tiene demasiados mtodos y no define el
comportamiento de todos los vehculos, dado que no todos los vehculos
despegan y aterrizan.
En este caso es mejor dividir la interfaz en dos:
Herencias mltiples
interface IVehiculo
{
void Acelerar(int kmh);
void Frenar();
void Girar (int angulos);
}
interface IVehiculoVolador :
IVehiculo
{
void Despegar();
void Aterrizar();
}
Herencias mltiples
Ntese adems que IVehiculoVolador deriva de IVehiculo (en orientacin a
objetos decimos que hay una relacin de herencia entre IVehiculoVolador y
IVehiculo)
Eso significa que una clase que implemente IVehiculoVolador debe
implementar tambin IVehiculo forzosamente.
Por lo tanto podemos afirmar que todos los vehculos voladores son tambin
vehculos.
Herencias mltiples
Ahora si que la clase Coche puede implementar IVehiculo y
La clase Avion puede implementar IVehiculoVolador (y por lo tanto tambin
IVehiculo).
Si un mtodo main() crea un objeto IVehiculoVolador puede usar mtodos
tanto de IVehiculoVolador como de IVehiculo:
Herencias mltiples
void main ()
{
IVehiculoVolador vv = new Avion();
vv.Acelerar(10); // Ok. Acelerar es de IVehiculo y IVehiculoVolador
deriva de IVehiculo
vv.Despegar(); // Ok. Despegar es de IVehiculoVolador
}
Herencias mltiples
Al reves no! Si un mtodo foo recibe un IVehiculo no puede llamar a
mtodos de IVehiculoVolador.
Lgico: todos los vehculos voladores son vehculos pero al revs no no
todos los vehculos son vehculos voladores!
Imagina el caso de que adems de vehculos debemos tratar con Armas de
guerra
Herencias mltiples
Tenemos otra interfaz:
interface IArmaDeGuerra
{
void Apuntar();
void Disparar();
}
Herencias mltiples
Ahora podran existir clases que implementen IArmaDeGuerra como p.ej.
una torreta defensiva:
class TorretaDefensiva : IArmaDeGuerra
{
public void Apuntar() { ... }
public void Disparar() { ... }
}
Herencias mltiples
Pero claro tambin tenemos vehculos que pueden ser a la vez armas de
guerra, p.ej. un tanque!
Que hacemos? Ningn problema: una clase puede implementar ms de una
interfaz a la vez!
Para ello debe implementar todos los mtodos de todas la interfaces:
Herencias mltiples
class Tanque : IVehiculo, IArmaDeGuerra
{
public void Acelerar(int kmh) { ... }
public void Frenar() { ... }
public void Girar (int angulos) { ... }
public void Apuntar() { ... }
public void Disparar() { ... }
}
HERENCIA MULTIPLE
Control de acceso a una clase
public
Accesible a todos los elementos
private
Accesible solo a esa misma clase
protected
Accesible solo a la misma clase y mtodos de sus clases derivadas. No accesible desde el exterior.
internal
Accesible solo a ese ensamblado
protected internal
Accesible desde el mismo ensamblado, la misma clase y mtodos de sus clases derivadas
Control de acceso a una clase
ACCESIBLE DESDE
Modificador
de acceso
Clase donde se
declaro
Subclase(Mism
o assembly)
Subclase
(distinto
assembly)
Externamente
(mismo
assembly)
Externamente
(distinto
assembly)
private SI NO NO NO NO
internal SI SI NO SI NO
protected SI SI SI NO NO
protected
internal
SI SI SI SI NO
public SI SI SI SI SI
Palabra clave mutable
En programacin orientada a objetos y un objeto inmutable es un objeto
cuyo estado no puede ser modificado una vez creado.
Un objeto mutable es un objeto cuyo estado puede ser cambiado

class Program
{
class a
{
int prop;
public int Prop { get; set; }
}
static void Main(string[] args)
{
string s = "word";
string t = s;
s += " hola";
Console.WriteLine("Inmutables:");
Console.WriteLine(s);
Console.WriteLine(t);
Console.WriteLine("mutables:");
a obj = new a();
a obj1 = obj;
obj.Prop = 4;
Console.WriteLine(obj.Prop);
Console.WriteLine(obj1.Prop);
Console.ReadKey();
}
}
Mtodos
Contienen instrucciones para ejecutar al momento de ser invocados.
Un mtodo contiene:
Modificador de Acceso (Determina su visibilidad)
Tipo de dato (Devuelto al finalizar su ejecucin)
Identificador (Nombre con el cual se invoca)
Parmetros (Cero o mas variables que recibe el mtodo)
Metodos
class Carro
{
public void Encender()
{
System.Console.WriteLine("El Auto se ha encendido!");
}
}
Modificador
de acceso
Tipo de dato del
valor regresado
Identificador
Parmetros
Encapsulamiento
class rectangulo
{
int ancho, alto;
public int Ancho
{
get { return ancho; }
set { ancho = value; }
}

public int Alto
{
get { return alto; }
set { alto = value; }
}
}

Polimorfismo
Es la habilidad que poseen los objetos para reaccionar de modo diferente
ante los mismos mensajes.
El polimorfismo se refiere a la posibilidad de definir mltiples clases con
funcionalidad diferente, pero con mtodos o propiedades denominados de
forma idntica, que pueden utilizarse de manera intercambiable mediante
cdigo cliente en tiempo de ejecucin.
En C# el polimorfismo est ntimamente relacionado con la sobrecarga y
mtodos virtuales.
Polimorfismo
Conceptos relacionados con el polimorfismo:
Sobrecarga (overload)
Herencia
Sobre-escritura (override)

También podría gustarte