#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;
-
+/**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.
+*/
+/**Acá se definen los comportamientos comunes de todo los
+ * 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á 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( FILE archivo).
+ *
+ * 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 esta conectado.
+ *
+ * Al ser esta clase abstracta, no puede ser instanciada,
+ * con lo cual existirá una clase derivada de esta para
+ * cada item que se quiera agregar en la aplicación.
+*/
+
class CItem:public Gtk::DrawingArea {
public:
///Constructor
* ya que cada item verifica sus conexione de manera difenrente y todos deben
* hacerlo.
*/
+/**Las clases que heredan de CItem son las siguientes:
+
+ * 1. Conduct: representa un tubo.
+ *
+ * 2. Splitter: representa un codo.
+ *
+ * 3. Union: representa un empalme ( UNION ó DIVISION).
+ *
+ * 4. Cistern: representa un tanque,
+ *
+ * 5. Exclusa: representa una exclusa.
+ *
+ * 6. Drain: representa un drenaje.
+ *
+ * 7. 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 ckeck_connection.png
+ *
+ * Donde bomba0 y tubo0 son los de la izquiera y bomba1 y
+ * 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 bomba0, este debe
+ * preguntar con quién esta conectado en su salida pero ya
+ * sabe, por ser bomba que tendrá una salida, luego el
+ * 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 bomba0 y el
+ * tubo0 se setean sus conectores y se establecen como "conectados".
+ * Continuando con la iteración, es el turno del 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
+ * bomba1 y el 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