}
};
-/**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.
+/**
+ * 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 {
*/
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.
- */
-/**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.
-*/
+ /**
+ * 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;
///Setea los conectores en su estado inicial.
projects / z.facultad / 75.42 / plaqui.git / blobdiff