OOP vs. programación procedimental - página 27
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
En la programación funcional-procedimental, los problemas de acceso que describes no existen. Sin funciones de sobrecarga, sin campos y objetos, sin punteros y demás, cuando sólo tienes una memoria para todas las variables globales a la que puedes acceder desde cualquier lugar, ¿cómo se puede llamar a la función equivocada? ¿Qué tipo de errores de acceso pueden producirse? Y es mucho más fácil recordar todo.
Se trata de un simple error: hacer referencia a la variable equivocada que contiene un valor cercano.
¡Un error de este tipo puede pasar desapercibido durante mucho tiempo, pero, por la ley de la mezquindad, "aparece" justo en el momento en que el trabajo sin errores en este lugar sería muy necesario!
Y va a ser muy difícil de entender... Usted está tratando de entender por qué el Asesor Experto ha cerrado una operación en una buena tendencia cuando TS no debería haberla cerrado - y no puede. Todo parece funcionar correctamente.
Este es exactamente uno de los errores más desagradables - la no inicialización de las variables, o el direccionamiento de la incorrecta, pero cerca por el valor. Y cuantas más variables estén disponibles en tal o cual parte del programa, mayor será la probabilidad de este error.
Sí, por supuesto, si tienes un núcleo gráfico accesible globalmente, y trabajas con órdenes, es realmente difícil acceder a la variable equivocada. Pero en un bloque anterior en el que se detecta la necesidad de abrir una orden y se dirigen indicadores para este fin y probablemente según las acciones del usuario - es bastante real mezclar las variables.
Si hay más estructuras, y los detalles importantes desaparecen periódicamente de la memoria - se llega a la conclusión de que el acceso global - es una fuente de problemas, y se debe evitar su uso a toda costa. Y que el código debe estar escrito de forma que se recuerde lo menos posible. Lo ideal es no guardar nada en la memoria - cada bloque tiene un nombre, indicando su función, en la entrada recibe los datos necesarios y suficientes para esta función, todo lo que queda es implementar la función sin involucrar ningún otro conocimiento "desde el exterior".
Se trata de un simple error: hacer referencia a la variable equivocada que contiene un valor cercano.
¡Un error de este tipo puede pasar desapercibido durante mucho tiempo, pero, por la ley de la mezquindad, "aparece" justo en el momento en que el trabajo sin errores en este lugar sería muy necesario!
Y va a ser muy difícil de entender... Usted está tratando de entender por qué el Asesor Experto ha cerrado una operación en una buena tendencia cuando TS no debería haberla cerrado - y no puede. Todo parece funcionar correctamente.
Este es exactamente uno de los errores más desagradables - la no inicialización de las variables, o el direccionamiento de la incorrecta, pero cerca por el valor. Y cuantas más variables estén disponibles en tal o cual parte del programa, mayor será la probabilidad de este error.
Sí, por supuesto, si tienes un núcleo gráfico accesible globalmente, y trabajas con órdenes, es realmente difícil acceder a la variable equivocada. Pero en un bloque anterior en el que se detecta la necesidad de abrir una orden y se dirigen indicadores para este fin y probablemente según las acciones del usuario - es muy posible mezclar las variables.
Si hay más estructuras, y los detalles importantes desaparecen periódicamente de la memoria - se llega a la conclusión de que el acceso global - es una fuente de problemas, y se debe evitar su uso a toda costa. Y que el código debe estar escrito de forma que se recuerde lo menos posible. Idealmente - no almacenar nada en absoluto en la memoria - cada bloque tiene un nombre, indicando su función, en la entrada que recibe los datos necesarios y suficientes para esta función, sólo queda para poner en práctica la función, no involucrar a ningún otro conocimiento "desde el exterior".
¿Cómo se puede llamar a la variable equivocada, si todas tienen nombres diferentes? ¿Cómo se puede llamar a una función errónea si tiene un nombre único y no hay sobrecarga? Dentro de la matriz del núcleo, todos los índices de las celdas se nombran con palabras humanas. ¿Qué puede confundirse aquí? Entiende que los problemas de los que hablas no existen en absoluto.
Sólo mantengo en memoria la estructura del núcleo, que es muy sencilla. También conozco la lista de propiedades de los objetos. Todos los objetos tienen las mismas propiedades, sólo los valores son diferentes. Tengo un total de 140 propiedades, pero sólo guardo en la memoria las más importantes, unas 30. Del resto me acuerdo cuando los necesito. Para ello, abro un archivo con defines y miro la lista completa de propiedades. Nada complicado. Las variables globales en foco, como por ejemplo "OBJECT" o "WINDOW" no necesitan ser recordadas en absoluto. Y es imposible mezclarlo con otra cosa.
Mis variables tienen nombres significativos en ruso. Sólo se pueden confundir las cosas después de una fiesta salvaje).Mis variables globales son las variables utilizadas en el enfoque, que se "apuntan" al núcleo y se mueven a medida que el cursor se mueve.
Por ejemplo: la variable "WINDOW" lleva constantemente el número de la ventana en la que se encuentra el cursor. La variable "OBJECT" es el número de ese objeto donde se encuentra el cursor.
A través de ellos me dirijo a una ventana, un objeto y una propiedad en particular del kernel - G_CORE[WINDOW][OBJECT][_NAME] o G_CORE[WINDOW][OBJECT][_OBJECT_GROUP]. En cualquier función, si necesito la coordenada X de un objeto, la obtengo de G_CORE[WINDOW][OBJECT][_X], si la altura del objeto - de G_CORE[WINDOW][OBJECT][_Y_SIZE] etc...
En total, tengo un centenar de variables globales declaradas por separado, pero hay miles de ellas en el array global del núcleo, porque cada celda del array es una variable. Sin embargo, es muy fácil manejar este número de variables, porque están ordenadas. Cada ventana del núcleo es un campo de matriz; cada fila es un objeto, que consta de 140 propiedades. Los elementos, en este caso, son conjuntos de objetos. Cada elemento tiene un objeto maestro, que contiene las principales propiedades de todo el elemento. Los objetos que pertenecen a cada elemento están vinculados por índices especiales, de modo que, sea cual sea el objeto que se enfoque, también se enfocará el elemento al que pertenece. También lo hace el lienzo sobre el que se dibuja. Gracias al arquetipo explícito del núcleo y al acceso directo desde cualquier función, puedo gestionar miles de variables que están representadas por celdas de matriz del núcleo sin olvidar nada y sin tener que navegar por ellas.
Una conversación completamente inútil: no hay ningún criterio para clasificar el código como "bueno" o "malo". Por eso no está claro lo de OOP.
Para mí, dicho criterio es la VIABILIDAD del código, que se manifiesta en el hecho de que el autor o un tercero pueda leer el código y utilizarlo para modificarlo, buscando los errores después de un periodo de tiempo bastante largo.....
Aquí arriba Fedoseyev ha sustituido el interruptor OOP. Este ejemplo en particular, tal vez desafortunado, para mí es una prueba de la vileza de la POO: un código claro con un interruptor de 100 posiciones es reemplazado por una sola línea. Para entender esta línea hay que ir a algún sitio. No es permisible para mí.
El segundo ejemplode George Merts
Cuando el código claro fue reemplazado por el código NO claro después de la depuración. Según mi criterio, el código de calidad (fácil de leer) fue sustituido por el código que no es aceptable para mí.
Por eso tengo una pregunta para todos los partidarios de la POO: ¿un programa se vuelve más vívido cuando se aplica la P OO y el ejemplo dado por Fedoseyev sobre el cambio es un fracaso o, por el contrario, el ejemplo de Fedoseyev caracteriza con mucha precisión la POO y ésta casi siempre conduce a una pérdida de vivacidad?
Bueno, todo está claro con CC. Todo lo que está por encima de su nivel de comprensión es antiestético. Pero conoce la letra R ))))))))))))))
Bueno, el CC está claro. Todo lo que esté por encima de su nivel de comprensión es poco atractivo. Pero conoce la letra R ))))))))))))))
Añadiré el chino, tal vez el japonés...
¿Por qué la OLP? ¿Por qué sería mejor?
La visibilidad consiste en simplificar la depuración, la modificación. La visibilidad proviene de un diseño cuidadoso del programa, de la estructuración en FUNCIONES y no en OBJETOS, porque todo el mundo se basa en acciones sobre objetos, pero no al revés.
Cuando el desglose en funciones se deriva de la secuencia de conversión de entradas en salidas. Por ejemplo, convertir una entrada BUY|SELL en una salida sólo es posible especificando una ACTION.
Así es como funciona el pensamiento humano.
PS.
En cuanto a su comentario sobre R.
¿Quieres ponerte sarcástico?
Respondo muy pocas veces, pero puedo hacerlo.
¿Cómo diablos puedes llamar a la variable equivocada si todas tienen nombres diferentes? ¿Cómo se puede llamar a la función equivocada si tiene un nombre único y no hay sobrecarga? Dentro de la matriz del núcleo, todos los índices de las celdas se nombran con palabras humanas. ¿Qué puede confundirse aquí? Entiende que los problemas de los que hablas no existen en absoluto.
Bueno, he tenido un par de casos así.
Lo más frecuente es que estos errores se produzcan al copiar un fragmento de código de otro lugar y "corregirlo", según el bloque actual. Si tiene acceso global, es muy posible que se le escape cambiar una de las variables. Si sólo tienes acceso a lo que tienes que trabajar en este caso - entonces después de copiar - el propio compilador te da una lista de todas las variables y ubicaciones que necesitan ser cambiadas.
Etiqueta Konow:
Sólo tengo la estructura del núcleo en mi memoria, que es muy simple. También conozco la lista de propiedades de los objetos. Las propiedades de todos los objetos son las mismas, sólo los valores son diferentes. Tengo un total de 140 propiedades, pero sólo guardo en la memoria las más importantes, unas 30. Del resto me acuerdo cuando los necesito. Para ello, abro un archivo con defines y miro la lista completa de propiedades. Nada complicado.
30 propiedades... Bueno, eso es inaceptable para mí. No es que no pueda recordarlos, pero no quiero confiar en mi memoria. Mucho mejor, cuando en cada bloque - siempre tiene exactamente esas variables, que en este bloque debe ser procesado, y no hay acceso a los demás.
Pero, me estresa tener que recordar... Y ya que no es difícil para ti - es comprensible que no tiene sentido hacer innecesarios chanchullos OOP.
Bueno, he tenido un par de estos casos.
La mayoría de los errores de este tipo se producen cuando se copia un trozo de código de otro lugar y se "arregla" para que coincida con el bloque actual. Si tiene acceso global, es muy posible que se le escape cambiar una de las variables. Si sólo tiene acceso a lo que tiene que trabajar en este caso - a continuación, después de copiar - el propio compilador le da una lista de todas las variables y ubicaciones que deben ser modificados.
30 propiedades... Bueno, eso no es aceptable para mí. No es que no pueda recordarlos, pero no quiero confiar en mi memoria. Mucho mejor, cuando en cada bloque - siempre tiene exactamente esas variables, que en este bloque debe ser procesado, y simplemente no hay acceso a los demás.
Pero, me estresa tener que recordar... Y ya que no es difícil para usted - es comprensible que no hay necesidad de hacer OOP-transacciones innecesarias.
Bueno, hablando con franqueza, recuerdo muchas cosas. Basta con mirar las abreviaturas de los objetos de encaje _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C etc... cada uno de ellos define la posición de un objeto en relación con el otro. Se encuentran en los parámetros A1,B1,C1,A2,B2,C2,A3,B3,C3,A4,B4,C4,A5... También recuerdo un par de docenas de nombres de categorías y subcategorías de objetos, un par de docenas de propiedades de ventanas (más de 100). Hay docenas de funciones en el bloque de construcción, por ejemplo, y ocupan más de 4000 líneas de código. Hay que navegar y recordar muchos de ellos. Pero recordar viene de una larga práctica, no de una vez, sino gradualmente. Mi cabeza solía ponerse pesada por la cantidad de entidades y el tamaño del código, pero luego todo se empantanó y se volvió sencillo.
Bueno, hablando con franqueza, recuerdo muchas cosas. Las abreviaturas de las referencias de los objetos _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C, etc. Cada uno define una determinada posición de un objeto a otro, están en los parámetros A1,B1,C1,A2,B2,C2,A3,B3,C3,A4,B4,C4,A5... También recuerdo un par de docenas de nombres de categorías y subcategorías de objetos, un par de docenas más de propiedades de ventanas (más de 100). Hay docenas de funciones en el bloque de construcción, por ejemplo, y ocupan más de 4000 líneas de código. Hay que navegar y recordar muchos de ellos. Pero recordar viene de una larga práctica, no de una vez, sino gradualmente. Mi cabeza solía hincharse con el número de entidades y el tamaño del código, pero luego todo se empantanaba y se volvía simple.
Para distraerme, olvidarme de todo, irme un mes de vacaciones sin pensar en el código. Luego vuelve, ve todos estos a1, b1, etc. y se pone histérico :)
distraerse, olvidarse de todo, irse de vacaciones por un mes, sin pensar en el código. Después de venir, vea todos estos a1, b1, etc. y ponte histérica :)
Por ejemplo, así es como se ve el elemento "casilla de verificación" en el proto-núcleo: