C/Visual C - Preguntitas

Hola a todos,

me dirijo a vosotros a ver si me podeis ayudar con dudas de concepto que tengo. Estoy programando en VC++ y lo del método de clases, aunque ya lo voy entendiendo, me lleva por el camino de la amargura. Mi proyecto se llama FPS (lo digo por poner los mismos nombres que uso). El programa es complicado y demasiado largo como para preguntar cosas del codigo (con eso ya me las apaño yo como puedo, antes o despues siempre lo hago funcionar) pero me gustaria preguntaros cosas de la metodica en MFC.

** 1) Los eventos originados al pulsar algo en el menu o toolbar, es decir, los ID_xxx:COMMAND, donde es mejor implementarlos? en FPSDoc o en FPSView?

Por ahora los estaba haciendo en el FPSDoc y, en caso de necesitar algo especifico, lo unia con el FPSView mediante variables. Es decir, el evento lo disparo en FPSDoc y si es evento tiene que desencadenar algo en el FPSView (como añadir un bmp) entonces activo una variable en el FPSDoc y la evaluo en el FPSView. Lo empecé así por ser actualizarse más a menudo el view que el doc, pero ahora que tengo algunos conflictos de prioridades dudo del método.

** 2) Si tengo que guardar datos especificos a cada tipo de elemento, pero cada tipo consta de distintos elementos... como se haría de la forma mas correcta?

Hasta ahora, lo estoy haciendo creando una clase para cada tipo de elemento con sus correspondientes datos, y luego en el FPSDoc la traigo en forma de Array y accedo a sus contenidos con funciones de tipo Get... y Set... programadas en la clase, es decir:
CInputData m_aInputArray [MAXIN] (y lo mismo para Outputs y Reglers).
m_aInputArray[m_nInIDNum].GetInName( ) (por ejemplo)

Es correcto el planteamiento? Aun cuando dentro de CReglerData haya otros dos arrays (InConnectionArr y OutConnectionArr) para saber a que elementos esta conectado?
m_aRegDataArray[m_nRegIDNum].SetInputName (int pos, CString inName)

** 3) A raiz de un hilo un poco más abajo que hace referencia a "extern tipo_var nombre_var", esto sirve solo para publicas? o tambien para privadas? y... para variables que hay que comprobar en muchos sitios distintos... cual es el metodo correcto?

Hasta el momento las tengo Publicas en el FPSDoc y luego accedo mediante el puntero pDoc->variable, pero que es mejor, desde el punto de vista de las Clases? Lo dejo como lo estoy haciendo hasta ahora?, Las hago privadas y creo funciones de Get y Set como en los otros casos menos habituales? Las llamo y accedo a ellas mediante el "extern..." como se dice en el mensaje de abajo?

Ante todo, muchas gracias a todo aquel que me conteste. Siento que el mail sea tan largo.

Me olvide de una cosa.

**4) Desde donde es mejor (siempre desde el punto de vista del método MFC en VC++) llamar a las ventanas de Dialogo? Desde el FPSDoc? o desde el FPSView?

Hasta el momento lo estaba haciendo en el FPSDoc, peusto que es ahi donde tengo los metodos de guardar o leer los datos que se recogen de la ventana de dialogo. Deberia dejarlo como lo tengo? o llamar a los dialogos desde el FPSView y a la hora de guardar llamar a pDoc-> Save_Data ( ) ????

4. Como te expliqué en 1), cualquier interacción del usuario debe ser a través de la vista. Es más, así de sencillo: el documento <<_*_*_*SOLO*_*_*_>> puede interaccionar con la vista. ¿Por qué es esto? Porque si después quieres que el mismo documento se despliegue de diferentes formas (i.e. en la vista preliminar a la hora de imprimir), sólo tienes que cambiar la vista, y no el documento. Si añades interacción de usuario (i.e. un diálogo) con el documento, no podrías hacer transparente nuevas formas de visualizar el docuemento (i.e. tu vista preliminar se vería llena de los cuádros de diálogo que sólo deberían aparecer en tu vista principal...).

En lo personal, yo repudio la arquitectura documento/vista de MFC. De hecho, sólo MFC proveé soporte para esta arquitectura. Ni WTL ni C++/CLI/.NET proveén esta arquitectura por los problemas que se generan. Y no es la arquitectura en sí, sino la forma en que MFC la implementó. En WTL o NET no la incluyen porque es mejor tener una clase que represente al documento, pero que éste sea un "contenido" o "agregado" de la clase vista, en lugar de que estén separados y al mismo nivel. Esta variación de la arquitectura es mucho más fácil de desarrollar y mantener, y por ello ni es necesario un marco de trabajo que soporte la arquitectura, como en MFC. Por eso tecnologías más recientes como WTL o NET incluyen plataforma, simplemente porque no es necesario.

Saludos.

Hola,

1. La semántica de la arquitectura documento/vista -que es la que empleas, asumo- implica la separación total de los datos del documento de su presentación e interaccíon del usuario. Por lo tanto, es semánticamente incorrecto que tu documento ande procesando mensajes de la interfaz de usuario. De que lo puedes hacer, lo puedes hacer, pero es incorrecto en cuanto a la arquitectura se refiere, y ciertamente es un error de diseño que te puede acarrear muchos problemas, sobre todo si trabajas con MDI.

2. Tu planteamiento, si te entendí bien, es correcto, aunque te recomiendo lo siguiente. Cuando serialices un documento a binario, incluye siempre un bloque de bytes dedicados a describir el documento. Por ejemplo, cuántos elementos tienes en el array 1, cuántos en el 2, etc. Porque si trabajas con arrays dinámicos o listas, nunca sabrás cuántos elementos guardaste, y no sabrás cómo deserializar el documento. Si pones un header nunca tendrás ese problema. Por otro lado, la serialización a documentos XML se está volviendo muy popular... quizás te convenga.

3. Vamos por partes. No entiendo eso de "esto sirve solo para publicas? o tambien para privadas?" ¿Te refieres a variables de una clase? Asumiré eso. Pero no sé qué relación tienen con extern. El extern le indica al compilador que una variable fué instanciada en algún lugar del código que está fuera de alcance actual, y que no se preocupe, el enlazador la encontrará. Así, el extern se usa usualmente con variables globales. Con variables miembro de clase no tiene sentido, porque siempre necesitas la declaración de la clase -ergo la de la variable miembro- antes de poder usarla. Y el extern sólo funciona para instancias.

Siguiendo las buenas prácticas de programación orientada a objetos, deberías ser fiel al encapsulamiento de datos y crearte métodos Get/Set en lugar de tener variables públicas. Aunque en el Get sólo hagas un return del miembro tienes mayor control... ¿qué pasa si después tienes que hacer alguna validación antes de hacer el return del miembro? Tendrías que cambiar todo tu código...

Con el extern no accedes a nada ni nada de nada.

Finalmente, si tienes variables que son accesadas desde diferentes hilos, es altamente recomendable que las declares como volátiles (volatile) para evitar problemas de sincronización de sus valores entre los hilos.

Saludos.

Hola Fernando,

en primer lugar... muchas gracias por tu aclaracion, es lo que me temía, seguramente tenga que modificar el codigo desde el principio, aunque al menos voy a poder copiar y pegar muchisimas cosas de lo que ya tengo, a pesar de hacerlo mal desde el punto de vista semántico tengo relativa experiencia en la programación. Estoy de acuerdo contigo en que, aunque puede que sea mejor, la manera de plantear las cosas de VC++ me parece demasiado enrevesada. Yo en C, Borland C++, MatlabScript y ActionScript siempre me he creado un modulo "datos.cpp" que es donde guardaba y leia todas las variables que fueran necesarias, accendiendo a ellas desde cualquier otro modulo; luego me hacia otro modulo que llevaba todo el tema de interfaz (labels, graficas....), otro todas las interacciones con el proceso a controlar (soy de automatizacion) y alguno que otro mas si necesitaba hacer calculos u otras cosas varias.

Gracias por el consejo de lo del header, es buena idea, pero no se si para mi proyecto sera necesario. Por suerte tengo definidos todos los valores maximos de posibles elementos a todos los niveles. El programa es un simulador de Fuzzy-Logik para un determinado tipo de automata, asi que tengo las fronteras de las uniones fisicas del automata, 24 entradas con 7 atributos, 12 salidas con 7 atributos y 12 reguladores con 2 tipos de relaciones de datos. Y los elementos a guardar de cada cosa son tambien fijos, coordenadas, atributos, valores, nombres... el resto ya se hace de forma dinamica, calculando y presentando graficas a partir de ellos.

Para lo de las variables a las que tengo que acceder desde diferentes sitios, creo que aunque tenga mas codigo voy a usar el metodo de get,set y me evitare problemas o posibles confusiones. Y a las que me sirven de paso las declarare como locales dentro de las funciones metodo y me evito complicaciones.

Una vez mas, gracias. Supongo que aun volvere a molestarte en alguna ocasion. Una pregunta, si por alguna de aquellas dejo un post con dudas y no son contestadas, podria escribirte al mail de tus mensajes?

Que tengais un buen dia en general.

Sí, me puedes escribir a [email protected] o a [email protected].

Saludos.