Discusión sobre el artículo "Implementación de un modelo de tabla en MQL5: Aplicación del concepto MVC (Modelo-Vista-Controlador)"
Hola, Artem.
Aquí tienes una pregunta:
Tu código lee el tipo de objeto.
//--- Leer tipo de objeto this.m_element_type=(ENUM_OBJECT_TYPE)::FileReadInteger(file_handle,INT_VALUE);
Pero no se comprueba como en SB
bool CList::Load(const int file_handle) { uint i,num; CObject *node; bool result=true; //--- comprobar if(file_handle==INVALID_HANDLE) return(false); //--- lectura y comprobación del marcador de inicio - 0xFFFFFFFFFFFFFFFFFFFFF if(FileReadLong(file_handle)!=-1) return(false); //--- lectura y comprobación de tipo if(FileReadInteger(file_handle,INT_VALUE)!=Type()) return(false); //--- tamaño de la lista de lectura num=FileReadInteger(file_handle,INT_VALUE); //--- creación secuencial de los elementos de la lista mediante la llamada al método Load() Clear(); for(i=0;i<num;i++) { node=CreateElement(); if(node==NULL) return(false); Add(node); result&=node.Load(file_handle); } //--- con éxito return(result); }
Como podemos ver, el método Type() simplemente devuelve un valor
virtual int Type(void) const { return(0x7779); }
¿Cuál es la necesidad de tal comprobación en SB? ¿Es realmente suficiente leer el tipo y crear un elemento del tipo correspondiente?
Bien, si no se lee el tipo, ¿qué sigue?
Aquí está el código:
//--- Recrea secuencialmente los elementos de la lista llamando al método Load() de los objetos nodo this.Clear(); for(uint i=0; i<num; i++) { //--- Leer y comprobar el marcador de inicio de datos del objeto - 0xFFFFFFFFFFFFFFFFFFFFFFF if(::FileReadLong(file_handle)!=MARKER_START_DATA) return false; //--- Leer tipo de objeto this.m_element_type=(ENUM_OBJECT_TYPE)::FileReadInteger(file_handle,INT_VALUE); node=this.CreateElement(); if(node==NULL) return false; this.Add(node); //--- Ahora el puntero del fichero se desplaza respecto al inicio del marcador del objeto en 12 bytes (8 - marcador, 4 - tipo). //--- Pongamos un puntero al principio de los datos del objeto y carguemos las propiedades del objeto desde el fichero usando el método Load() del elemento nodo. if(!::FileSeek(file_handle,-12,SEEK_CUR)) return false; result &=node.Load(file_handle); } //--- Resultado return result; } //+------------------------------------------------------------------+ //| Método para crear un elemento de lista| //+------------------------------------------------------------------+ CObject *CListObj::CreateElement(void) { //--- Dependiendo del tipo de objeto en m_element_type, crear un nuevo objeto switch(this.m_element_type) { case OBJECT_TYPE_TABLE_CELL : return new CTableCell(); case OBJECT_TYPE_TABLE_ROW : return new CTableRow(); case OBJECT_TYPE_TABLE_MODEL : return new CTableModel(); default : return NULL; } }
Leer el tipo del objeto en una variable. Luego intentamos crear este objeto en CreateElement(), y hay casos. ¿Qué devolverá este método si no se lee del fichero el tipo del objeto que se está creando?
Bueno, si no se lee el tipo, ¿qué sigue?
Aquí está el código:
Leemos el tipo del objeto en una variable. Luego intentamos crear este objeto en CreateElement(), y hay casos. ¿Qué devolverá este método si no se lee del fichero el tipo del objeto que se está creando?
Artem, no estoy hablando de eso. Estoy hablando de que hay una comprobación de tipo en SB. Exactamente la comprobación.
//--- lectura y comprobación de tipo if(FileReadInteger(file_handle,INT_VALUE)!= Type()) return(false);
¿Coincide el tipo leído del fichero con el tipo del método Type()Read y la comprobación de tipo. ¿Es así como se traduce?
Y simplemente se lee el tipo sin comprobarlo.
Así que la pregunta es: ¿Cuál es el significado profundo de esta comprobación?
He aquí la pregunta: ¿Cuál es el significado profundo de esta comprobación?
Cuando se carga una clase de CiertoObjeto desde un fichero llamando al método Load() de este mismo CiertoObjeto, se comprueba "¿realmente me leí desde el fichero?" (eso es lo que estás preguntando). Si no, significa que algo salió mal, así que no tiene sentido seguir cargando.
Lo que tengo aquí es una LISTA (CListObj) leyendo un tipo de objeto de un archivo. La lista no sabe qué hay (qué objeto) en el fichero. Pero debe conocer este tipo de objeto para crearlo en su método CreateElement(). Por eso no comprueba el tipo del objeto cargado desde el fichero. Después de todo, habrá una comparación con Type(), que en este método devuelve el tipo de una lista, no de un objeto.
Cuando se carga una clase de SomeObject desde un fichero llamando al método Load() de este mismo SomeObject, se comprueba "¿realmente me he leído desde el fichero?" (eso es lo que está preguntando). Si no es así, significa que algo ha ido mal, por lo que no tiene sentido seguir cargando.
Lo que tengo aquí es una LISTA (CListObj) leyendo un tipo de objeto de un archivo. La lista no sabe qué hay (qué objeto) en el fichero. Pero debe conocer este tipo de objeto para crearlo en su método CreateElement(). Por eso no comprueba el tipo del objeto cargado desde el fichero. Después de todo, habrá una comparación con Type(), que en este método devuelve el tipo de una lista, no de un objeto.
Gracias, ya lo he entendido.
Lo leí y lo volví a releer.
es cualquier cosa que no sea un "modelo" en MVC. Algún ListStorage por ejemplo
Me pregunto. ¿Es posible obtener algún análogo de python y R dataframes de esta manera? Se trata de tablas en las que diferentes columnas pueden contener datos de diferentes tipos (de un conjunto limitado de tipos, pero incluyendo string).
Se puede. Si estamos hablando de diferentes columnas de una tabla, entonces en la implementación descrita cada celda de la tabla puede tener un tipo de datos diferente.
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Artículo publicado Implementación de un modelo de tabla en MQL5: Aplicación del concepto MVC (Modelo-Vista-Controlador):
En programación, la arquitectura de las aplicaciones desempeña un papel fundamental a la hora de garantizar la fiabilidad, la escalabilidad y la facilidad de soporte. Uno de los enfoques que ayuda a alcanzar dichos objetivos es aprovechar el patrón de arquitectura denominado MVC (Modelo-Vista-Controlador).
El concepto MVC permite dividir una aplicación en tres componentes interrelacionados: modelo (gestión de datos y lógica), vista (visualización de datos) y controlador (procesamiento de las acciones del usuario). Esta separación simplifica el desarrollo, las pruebas y el mantenimiento del código, haciéndolo más estructurado y flexible.
En este artículo, analizamos cómo aplicar los principios MVC para implementar un modelo de tabla en el lenguaje MQL5. Las tablas son una herramienta importante para almacenar, procesar y mostrar datos, y organizarlas adecuadamente puede facilitar mucho el trabajo con la información. Crearemos clases para trabajar con tablas: celdas de tabla, filas y un modelo de tabla. Para almacenar celdas dentro de filas y filas dentro del modelo de tabla, utilizaremos las clases de lista enlazada (CList) de la biblioteca estándar MQL5, que permiten un almacenamiento y uso eficientes de los datos.
Autor: Artyom Trishkin