X-Git-Url: https://git.llucax.com/z.facultad/75.42/plaqui.git/blobdiff_plain/663eccb7e27110aba6c79648c38254a7a5737bca..44617167ac216781537290dce9cc097df89dc3d2:/Constructor/include/item.h?ds=sidebyside

diff --git a/Constructor/include/item.h b/Constructor/include/item.h
index 845bd64..7400167 100644
--- a/Constructor/include/item.h
+++ b/Constructor/include/item.h
@@ -12,12 +12,6 @@
 #include "itemptywnd.h"
 #include "workplace.h"
 
-/**Esta es la clase padre de todos los items que puedan aparecer
-  *Aca estan definidos todos los comportamientos en comun y en 
-  *algunos casos hay funciones abstractas para que cada item defina
-  * su propio comportamiento.
-*/
-
 ///Tipo de estado en el que pueden estar los conectores de un item
 typedef enum { UNDEF, IN, OUT } ConnectorType;
 
@@ -25,6 +19,7 @@ typedef enum { UNDEF, IN, OUT } ConnectorType;
 typedef struct {
 	ConnectorType type;
 	Glib::ustring name_dest;
+	int cistern_connector;
 }t_logic_connector;
 
 ///Clase que define un conector del item
@@ -42,8 +37,43 @@ class Connector {
 		}
 };
 
-//class WorkPlace;
-	
+/**
+ * Clase padre de todos los items que puedan aparecer.
+ * En esta clase están definidos todos los comportamientos en común
+ * y en algunos casos hay funciones abstractas para que cada item
+ * defina su propio comportamiento.
+ * Comportamientos comunes que se definen son, por ejemplo,
+ * items de la aplicación, como puede ser la imagen 
+ * actual, la posición en la grilla, el caudal máximo,el 
+ * número único de identificación y diferentes punteros a 
+ * otros objetos.
+ * 
+ * Por cuestiones de diseño los elementos de la planta 
+ * además de tener un número único que los identifica, 
+ * también deben tener nombres difrerentes.
+ * 
+ * También esta definida en esta clase la estuctura que 
+ * representa los conectores físicos, y otra que 
+ * representa a los conectores lógicos.
+ * 
+ * Esta clase contiene métodos abstractos ya que cualquier 
+ * elemento que descienda de ella debería poder implementar 
+ * los mismos porque, por ejemplo, ningún item se guarda 
+ * en un archivo de la misma manera; este es el caso del 
+ * método save().
+ * 
+ * Existe otro método abstracto dentro de esta clase que 
+ * es check_connection(). Del mismo modo que un item se 
+ * guarda de forma diferente que otro, también verifica su 
+ * conexión de distinta forma, es por eso que cada item 
+ * debe implementar su manera de verificar como y con 
+ * quién está conectado.
+ * 
+ * Al ser esta clase abstracta, no puede ser instanciada, 
+ * con lo cual existiría una clase derivada de esta para 
+ * cada item que se quiera agregar en la aplicación.
+*/
+
 class CItem:public Gtk::DrawingArea {
 public:
 	///Constructor
@@ -68,9 +98,6 @@ public:
 	
 	///Elimina el Item al seleccionarse la opcion en el menu flotante
 	virtual void on_menu_popup_eliminar();
-	
-	///TODO: conectar los items con lineas!!!
-	virtual void on_menu_popup_conectar();
 		
 	///Retorna un puntero a la imagen actual.
 	Glib::RefPtr<Gdk::Pixbuf> get_image() { return image; }
@@ -100,14 +127,88 @@ public:
 	*/
 	virtual void save(FILE *archivo) = 0;
 	
-	/**Funcion abstracta que debe ser implementada en las clases descendientes
-	  * ya que cada item verifica sus conexione de manera difenrente y todos deben
-	  * hacerlo.
-	*/
+	/**
+	 * Verifica que el ítem esté bien conectado.
+	 * Las clases que heredan de CItem son las siguientes:
+	 *
+	 *	-# Conduct: representa un tubo.
+	 *		
+	 *	-# Splitter: representa un codo.
+	 *		
+	 *	-# Union: representa un empalme ( UNION ó DIVISION).
+	 *	
+	 *	-# Cistern: representa un tanque,
+	 *	
+	 *	-# Exclusa: representa una exclusa.
+	 *	
+	 *	-# Drain: representa un drenaje.
+	 *	
+	 *	-# Pump: representa una bomba.
+	 *	
+	 *	Para las clases Conduct, Splitter y Exclusa, este 
+	 *	método es bastante similar, sobre todo teniendo en 
+	 *	cuenta que una exclusa es un tubo con una propiedad mas 
+	 *	(abierto/cerrado) y el codo es un tubo que en la 
+	 *	aplicación representa un curva.
+	 *	
+	 *	Estos tres elementos tienen la particularidad que sus 
+	 *	conectores físicos no estan definidos en el momento de 
+	 *	su creación, sino que se definen una vez que pertenecen 
+	 *	a un circuito.
+	 *	
+	 *	La verificación se realiza recorriendo la lista de 
+	 *	items y preguntandole a cada uno que posee en sus extremos.
+	 *	
+	 *	El tanque, la bomba, el empalme y el drenaje, tiene 
+	 *	definidos sus conectores en el momento de la creación.
+	 *	
+	 *	Supongamos que el circuito es el siguiente:
+	 *	 \image html check_connection.png
+	 *	 \image latex check_connection.eps "Planta de ejemplo." width=10cm
+	 *	 
+	 *	Donde \c bomba0 y \c tubo0 son los de la izquiera y \c bomba1 y 
+	 *	\c tubo1 son los de la derecha, para poder diferenciarlos.
+	 *	Cabe aclarar que no importa con cual de los items se 
+	 *	comience la iteración.
+	 *	Según la imagen actual de la \c bomba0, este debe 
+	 *	preguntar con quién esta conectado en su salida pero ya 
+	 *	sabe, por ser bomba que tendrá una salida, luego el 
+	 *	\c tubo0 que en ese momento no esta definido, debe 
+	 *	averiguar como definirse, para hacerlo pregunta en su 
+	 *	otro extremo el cual esta conectado con una unión, que 
+	 *	por ser unión posee dos entradas (horizontales en este 
+	 *	caso) y una salida (vertical). La unión le responde que 
+	 *	posee una entrada, por lo tanto el extremo derecho del 
+	 *	tubo será una salida, lo cual implica que el extremo 
+	 *	izquierdo tiene que ser una entrada, y esto es 
+	 *	compatible con la bomba. De esta forma la \c bomba0 y el 
+	 *	\c tubo0 se setean sus conectores y se establecen como \e conectados.
+	 *
+	 * 	Continuando con la iteración, es el turno del \c tubo0 
+	 *	(por el orden de incersión en la lista), pero este ya 
+	 *	está conectado, por lo tanto no se realizan verificaciones.
+	 *	
+	 *	Lo mismo ocurre del lado derecho del circuito con la 
+	 *	\c bomba1 y el \c tubo1.
+	 *	
+	 *	Algo similar ocurre cuando la unión pregunta que tiene 
+	 *	en su salida, la exclusa debe preguntarle al tanque y 
+	 *	este le responderá que posee una entrada, luego la 
+	 *	exculsa tendrá una entrada en el extremo superior y una 
+	 *	salida en el inferior; nuevamente el circuito es 
+	 *	compatible. Por último el tanque le solicita al codo 
+	 *	que le informe su estado y el proceso se repite con el 
+	 *	drenaje que posee solamente una salida.
+	 *	
+	 *	Así todos los elementos han quedado conectados y 
+	 *	conocen también con quién o quienes lo estén.
+	 */
 	virtual bool check_connection()=0;
 	
-	///TODO: hacer abstractas estas funciones... en item no hacen nada....
+	///Setea los conectores en su estado inicial.
 	virtual void set_default_connector();	
+	
+	///Devuelve el tipo de conector que tiene el item en la posicion (_a,_b).
 	virtual ConnectorType get_connector_type( int _a, int _b );
 	
 	/**Devuelve en _a y _b la posicion de los conectores logicos del item segun su posicion.
@@ -126,7 +227,8 @@ public:
 	virtual void set_out_connected(bool _o);
 	virtual void set_in_connected(bool _o);
 	
-	/**Dibuja los conectores logicos del Item, AZUL == ENTRADA, ROJO == SALIDA.
+	virtual bool get_out_logic_connect();
+	/**Dibuja los conectores logicos del Item, AZUL == SALIDA, ROJO == ENTRADA.
 	*/
 	virtual void draw_connectors();