Discusión sobre el artículo "Gráficos en la biblioteca DoEasy (Parte 83): Clase de objeto gráfico abstracto estándar"

Nuevo comentario
 

Artículo publicado Gráficos en la biblioteca DoEasy (Parte 83): Clase de objeto gráfico abstracto estándar:

En el presente artículo, crearemos la clase de objeto gráfico abstracto. Este objeto constituirá la base para crear las clases de objetos gráficos estándar. Los objetos gráficos tienen muchas propiedades y hoy, antes de crear una clase de objeto gráfico abstracto, necesitaremos hacer mucho trabajo preparatorio: registrar estas propiedades en las enumeraciones de la biblioteca.

Compilamos el asesor nuevamente y lo ejecutamos.

Para realizar el test, añadiremos varios objetos gráficos al gráfico; el diario mostrará mensajes sobre cómo añadir un nuevo objeto y una breve descripción del mismo:


Como podemos ver, todo funciona como era esperado.

Autor: Artyom Trishkin

 
Buenas tardes,

He leído algunos de sus artículos, a veces se enumeran, en general bien, pero me confundió un par de cosas.....

1. Demasiados duplicados de código en su aplicación ... Por supuesto tal vez habrá una refactorización más tarde, o tal vez unos pocos)

2. Si trabajas con objetos estandar, por que no usar clases ya hechas que vienen con los terminales y cargarlas con funcionalidad adicional, ampliando asi las posibilidades, y asi resulta que no hay compatibilidad hacia atras y haces doble trabajo....
 
Daniil Kurmyshev #:
Buenas tardes,

He leído algunos de sus artículos, de vez en cuando se enumeran, en general bien, pero me confundió un par de cosas....

1. Demasiados duplicados de código en su implementación.... Por supuesto tal vez habrá una refactorización más tarde, y tal vez algunos)

2. Si trabajas con objetos estándar, por qué no usar clases ya hechas que vienen con los terminales y cargarlas con funcionalidad adicional, ampliando así las posibilidades, y así resulta que no hay compatibilidad hacia atrás y haces doble trabajo....
  1. ¿Puedes dar ejemplos de duplicidades para responder más concretamente?
  2. La estructura y el concepto de construcción de objetos de biblioteca no coinciden del todo con el concepto de biblioteca estándar. Pero si te has dado cuenta, la biblioteca está construida sobre el estándar CObject y CArrayObj.

De todos modos, estaré encantado de responder preguntas, aceptar críticas y sugerencias.

Gracias por su interés.

 
Artyom Trishkin #:
  1. ¿Puedes dar ejemplos de duplicados para ser más específico?
  2. La estructura y el concepto de construcción de objetos de la biblioteca no chocan del todo con el concepto de la biblioteca estándar. Pero si te fijas, la librería está construida sobre el estándar CObject y CArrayObj.

En cualquier caso, estaré encantado de responder preguntas, aceptar críticas y sugerencias.

Gracias por su interés.

1. Si específicamente me refería sobre la sección de donde comienza el código"Más adelante en el código de laclase escribir métodos para el acceso simplificado a establecer y devolver propiedades del objeto: ".

Según entiendo esto es una descripción de funciones de la clase base, es decir son exhaustivas para todos los objetos y tienen nivel de acceso public, si se crea un sucesor verá todas estas funciones, pero no todos los objetos tienen propiedades de control y salida de texto por ejemplo, etc.... y para usar este objeto siempre tirará de laclase base, y no de la propia directa de CObject , claro que puede tener sentido para obtener todas las funciones de la clase base, salida de log, etc pero entonces al crear herederos hay que virtualizar y ocultar todas las funciones que no se pueden aplicar a la clase del heredero en el nivel de acceso private.

Quizás este sea el truco de tu implementación, si es así ¡¡¡SUPER!))))))

Por cierto, quizás el nivel protected para algunas funciones sea más apropiado que public, pero aquí tú sabrás mejor, claro, dependiendo del sentido que se le ponga.

2. Sí, he vuelto a revisar tu código, tu concepto de crear una librería es diferente, estoy de acuerdo, lo principal es que cuando crees niveles superiores de clases, crees funciones públicas virtuales, para que otros desarrolladores puedan usar tu solución sin editar directamente las librerías.

3. También me di cuenta de que utiliza la fusión de cadenas con +, en algunas versiones de la terminal a grandes fusiones y con la operación de terminal de largo situaciones impredecibles en dicha aplicación)))

Yo uso StringFormat y StringAdd funciones, la fiabilidad del trabajo ha aumentado, y también visualmente el código se hace más legible.

4. También quería advertir sobre la limitación de la longitud de los objetos creados al renderizar, téngalo en cuenta, es mejor generar un hash a partir del nombre y sobre su base crear un objeto, la limitación tiene una función estándar, no recuerdo exactamente, pero probablemente ResourceCreate....

 
Daniil Kurmyshev #:

1. Si específicamente me refería a la sección donde el código comienza"Más adelante en el código de laclase escribiremos métodos para el acceso simplificado a las propiedades set y return del objeto: ".

Según entiendo esto es una descripción de funciones de la clase base, es decir son exhaustivas para todos los objetos y tienen nivel de acceso public, si se crea un sucesor verá todas estas funciones, pero no todos los objetos tienen propiedades de control y salida de texto por ejemplo, etc.... y para usar este objeto siempre tirara de la clase base, y no de la propia directamente de CObject , claro que a lo mejor tiene sentido para obtener todas las funciones de la clase base, salida de log, etc. pero entonces al crear herederos hay que virtualizar y ocultar todas las funciones que no se pueden aplicar a la clase del heredero en el nivel de acceso private.

Tal vez este es el truco de su implementación, si es así entonces SUPER!)))))))

Por cierto, quizás el nivel protected para algunas funciones sea más apropiado que public, pero claro tu sabrás mejor dependiendo del significado de la misma.

2. Sí, he vuelto a revisar tu código, tu concepto de construcción de librerías es diferente, estoy de acuerdo, lo principal es que cuando crees niveles superiores de clases, crees funciones públicas virtuales, para que otros desarrolladores puedan usar tu solución sin necesidad de editar directamente las librerías.

3. También me di cuenta de que utiliza la combinación de cadenas con +, en algunas versiones de la terminal en grandes combinaciones y con la operación del terminal de largo situaciones impredecibles en dicha aplicación se obtuvieron))))

Uso StringFormat y StringAdd funciones, la fiabilidad del trabajo ha aumentado, y también visualmente el código se hace más legible

4. También quería advertir sobre la limitación de la longitud de los objetos creados al renderizar, tenga esto en cuenta, es mejor generar una caché del nombre y sobre su base crear un objeto, la limitación tiene una función estándar, no recuerdo exactamente, pero probablemente ResourceCreate....

1. La publicidad de los métodos y su redundancia es el costo de querer hacer muchas maneras diferentes de acceder a las mismas propiedades. Pero algunos métodos serán efectivamente virtuales o prescritos sólo en los herederos. Pero, de nuevo, esto sólo se aplica a los objetos de la propia biblioteca. Al heredar de ellos, por desgracia, todos los métodos públicos serán heredados.

2. Lo pensaré. Pero en realidad el nivel superior de acceso será otro punto de entrada a las librerías, y serán funciones definidas por el usuario, de nuevo, repitiendo características ya implementadas de la librería, pero serán más comprensibles para el usuario medio - simplemente usa la función para obtener el resultado, y no para inventar lógica y manejadores - todo esto se hará dentro de la librería, y la salida serán funciones usercase para simplemente obtener la información necesaria.

3. No he optimizado nada (excepto la lógica pensada de antemano) y no he perfilado nada. Esto es para el último momento.

4. Lo he comprobado a mi manera. Ahí nombre de objeto largo es posible. Pero gracias, lo tendré en cuenta y le echaré un ojo.

 
Artyom Trishkin #:

1. Hacer que los métodos sean públicos y redundantes es el coste de querer hacer muchas formas diferentes de acceder a las mismas propiedades. Pero algunos métodos serán efectivamente virtuales, o prescritos sólo en los herederos. Pero, de nuevo, esto sólo se aplica a los objetos de la propia biblioteca. Al heredar de ellos, por desgracia, todos los métodos públicos serán heredados.

2. Me lo pensaré. Pero en realidad, el nivel superior de acceso será otro punto de entrada en las bibliotecas, y será funciones definidas por el usuario, de nuevo, repitiendo características ya implementadas de la biblioteca, pero será más comprensible para el usuario medio - sólo tiene que utilizar la función para obtener el resultado, y no inventar la lógica y los manipuladores - todo esto se hará dentro de la biblioteca, y la salida será usercase-funciones para obtener simplemente la información necesaria.

3. No he optimizado nada (excepto la lógica pensada de antemano) y no he perfilado nada. Esto es para el último momento.

4. Lo he comprobado a mi manera. Ahí nombre de objeto largo es posible. Pero gracias, lo tendré en cuenta y le echaré un ojo.

4. Este error puede haber sido eliminado, pero no estoy seguro ... la función parece funcionar, pero el objeto no se crea, este es el comportamiento cuando la longitud es grande

 
Eso es una cuestión de hecho, voy en esto, que elijo curso de Tecnología de la Información para hacer eso para siempre.
Nuevo comentario