#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;
}
};
-//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
///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; }
*/
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.
projects / z.facultad / 75.42 / plaqui.git / blobdiff