Herencia y cosas varias

Soy libre. La semana fatídica de fin de cuatrimestre y entrega de prácticas ha terminado y por delante se asoma un nuevo horizonte navideño y un enero cargadito de examenes, pero por ahora, soy libre. Tras echar horas delante del ordenador para entregar la segunda práctica de la asignatura de “Programación Orientada a Objetos”, más conocida como POO (no, no es el teletubbie), he aprendido unas cuantas cosas, de las cuales, la que más interesante me ha parecido ha sido la herencia.

La herencia es un método orientado a objetos que permite ahorrar la escritura de código, así como implementar una funcionalidad de la manera más óptima posible. En herencia existen dos clases básicas, la clase padre y la clase derivada. La clase padre implementa funcionalidades que comparten las clases derivadas, de este modo, si tenemos una clase “vehículo” como padre, podemos tener varias clases derivadas como “moto”, “coche” o “avión” como derivadas o hijas. En este caso y, fijándonos en un posible método que nos cuenta el número de ruedas de cada uno de ellos, esta funcionalidad se implementaría en la clase vehículo, ya que todas las clases derivadas comparten esta característica. Otro posible ejemplo de herencia sería el de “figuras”, teniendo como clases derivadas “círculo” o “rectangulo” y compartiendo funcionalidades como una posible función de color de relleno o de grosor de borde.

De este modo conseguimos asociar distintas clases a una única clase que comparte características y nos ahorramos la reescritura de código. A la hora de implementar la herencia, tendremos que tener en cuenta que los constructores de las clases derivadas llamarán automáticamente a los contructores de la clase heredada o padre, por lo que en el caso de constructores sobrecargados de clases derivadas, tendremos que tener en cuenta los parámetros que pasamos a la clase padre. Un ejemplo sencillito:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

class Figura
{
	public:
		Figura2D(); // constructor por defecto
		Figura2D(int borde, int color); //constructor sobrecargado de Figura2D, recibe la llamada del mismo en Circulo
		virtual ~Figura2D(); // hacemos el destructor virtual al tratarse de una clase abstracta que tendrá implementación vacía
		void setBorde(); // método de seteo del grosor del borde
		void setColorFondo(); // método de seteo del fondo de la figura
		int getBorde(); // método de get del borde
		int getColor(); // método de get del color
 
	private:
		int bordeLinea;
		int colorFondo;
}
 
class Circulo: public Figura // implementamos la herencia, en este caso pública
{
	public:
		Circulo() // llamada automática al constructor por defecto de figura
		Circulo(float radio, int borde, int fondo);
		/*
		*	En la librería de Circulo tendremos que implementar el constructor de la siguiente forma:
		*	Circulo(float radio, int borde, int fondo) : Figura(borde,fondo) { ... }
		*	Esto enviará los dos atributos indicados al constructor sobrecargado de la clase padre.
		*/
		~Circulo() // destructor
		void setRadio(float); // método para setear el radio
		float getRadio(); // método de get para radio
 
	private:
		float radio;
 
}

Dejar un comentario 19 Diciembre, 2009

Definición de clases C++

Con todo esto de la orientación a objetos se van aprendiendo cosas nuevas y dejando atrás el paradigma “imperativo” al que tan acostumbrado estaba. La verdad es que de momento me resulta algo extraño este tipo de programación, demasiadas dependencias de un lugar y de otro, pero realmente es bastante efectivo y cómodo, eso una vez definidas las clases necesarias, porque antes es un verdadero jaleo.

Bueno, hablo de clases pero no digo lo que es, voy mejorando. Las clases son, y cito, una “abstracción de los atributos (características), operaciones, relaciones y
semántica comunes a un conjunto de objetos“, vamos, que nos hemos quedado igual. Se trata de una definición de un tipo propio, es decir, un contenedor de variables y de funciones propias solo utilizables una vez introducida la clase en el programa. Para comprenderlo debemos hacer caso a la siguiente teoría: “No hay noción de programa principal, y los subprogramas no existen como unidades modulares independientes, sino que forman siempre parte de alguna clase.” Y así, nos cargamos casi en su totalidad el paradigma imperativo.

Una clase está compuesta por un nombre o identificador, atributos o variables, roles de relación con otras clases y operaciones propias. Y como lo mejor para comprender lo que es una clase es un ejemplo, a continuación os expongo uno:

class TClase
{
	public: // Interfaz y operaciones públicas que se le permite manejar al usuario.
		setY(float);
		setX(float);
		getY();
		getX();
 
	private: // Formada normalmente por atributos o variables, no pueden ser modificadas directamente por el usuario.
		int x, y;
 
};

Una vez definida la clase, podremos crearla dentro de nuestro programa definiendo TClase p; por ejemplo, y de este modo acceder a las funciones de public que deberemos de haber definido en el archivo .cc correspondiente y con las que manejaremos los atributos de private.

Y de momento poco más. Según vayamos avanzando las clases de Programación Orientada a Objetos y Programación y Estructura de Datos iré comentando más cosas interesantes y corrigiendo fallos que vaya encontrando.

2 comentarios 6 Octubre, 2009