Hablando de la OLP en el salón - página 11
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
La cantidad de gestos en POO no puede ser menor en principio, porque todas estas interfaces son una sobrecarga adicional, que a menudo supera el coste de escribir la propia lógica. Y esto a pesar de que cualquier función ya tiene una interfaz, es decir, se propone construir otro jardín, que es esencialmente sin sentido.
Al mismo tiempo, cualquier cambio en el código, tanto en la interfaz como en la función, se vuelve mucho más complicado, ya que una está enganchada a la otra, lo que significa que tenemos al menos un aumento cuadrático en el posible número de errores y en la intensidad del trabajo... Es algo obvio, ¿no?
La cantidad de gestos en POO no puede ser menor en principio, porque todas estas interfaces son una sobrecarga adicional, que a menudo supera el coste de escribir la propia lógica. Y esto a pesar de que cualquier función ya tiene una interfaz, es decir, tenemos que hacer otra cobertura que es esencialmente inútil.
En este caso, cualquier cambio de código tanto en la interfaz como en la función se vuelve mucho más complicado, ya que una está enganchada a la otra, es decir, tenemos al menos un aumento cuadrático de posibles bugs y de trabajo... Es un poco obvio, ¿no?
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
Hablar de OOP en el patio trasero
fxsaber, 2018.01.14 11:35
La programación en sí misma es un caso especial de producción. El enfoque OOP es un enfoque de principios para producir cualquier cosa. Así que hablar de programación es muy limitado. La POO se aplicó con éxito ANTES de que apareciera en la programación.
La historia de la industria llegó a la PRODUCCIÓN orientada a los objetos como la siguiente etapa de la transportación. Así que hablar de programación OO es una visión estrecha. Como hablar de las botas de costura OO. Estamos hablando de enfoques algorítmicos para la organización de cualquier producción, incluyendo, como caso muy especial, la creación de software.
La producción OOP ha demostrado ser competitivamente superior a las líneas de montaje convencionales. Hay una planificación a corto plazo de la producción, cuando es necesario hacerla funcionar ahora. Y está el largo plazo: cuando se pone mucho "extra" en el momento, pero esa base es propicia para aumentar simplemente la producción. De nuevo, no se trata de programación, sino de enfoques generales en la creación de la producción.
Los enfoques OOP pueden verse incluso en las instituciones modernas de poder.
El terminal es una clase en relación con su código. ¿Con qué frecuencia tiene que cambiar algo en el código del terminal?
Este ejemplo es incorrecto. Estamos hablando de interfaces dentro de su programa...
La historia de la industria llegó a la PRODUCCIÓN orientada a los objetos como el siguiente paso de la transportación.
La programación OO también tiene sus tuberías de procesamiento y la OOP introduce otra capa de abstracción que sólo aumenta la sobrecarga de cada transportador individual y de toda la producción.
La programación OO también tiene sus propios transportadores de procesamiento, y la OOP introduce otro nivel de abstracción que sólo aumenta la sobrecarga de cada transportador individual y de toda la producción.
Eres estúpido, por desgracia. Te hablan de la historia de la industria y de la OOP como una de las etapas de esa historia, que ha jugado un papel enorme en todo lo material (y no sólo) que te rodea. Y sigues hablando de un caso especial de programación.
Desconocimiento de la historia del desarrollo humano. No dejarás rastro en la memoria de tus descendientes directos.
Te hablan de la historia de la industria y de la OOP como una etapa de esa historia, que ha jugado un papel enorme en todo lo material (y no sólo) que te rodea.
Su ingenuo intento de arrastrar a la OLP a la historia de la industria es divertido, pero tristemente analfabeto.
Este ejemplo es incorrecto. Estamos hablando de interfaces dentro de su programa...
¿Por qué es "incorrecto"?
¿En qué se diferencia un programa de TODO el software que se ejecuta en un ordenador?
Al fin y al cabo, se trata de la misma serie de instrucciones y conjuntos de datos que en cualquier programa de usuario. ¿Por qué es incorrecto que, aquí o allá, una parte del software no tenga acceso a otra parte del software más que a través de los protocolos de intercambio establecidos?
No pasa nada, si programas en serio - tarde o temprano llegarás a la necesidad de diferenciar los derechos de acceso.
Yo también, en la época en que pasaba del modo real al seguro, odiaba no poder acceder a ninguna dirección de memoria física. Incluso llegué a hacer giros con un controlador DMA que copiaba los datos de la zona protegida del sistema a la mía (aunque era bastante difícil distinguir lo que se copiaba allí, así que no lo hice). En mi juventud me indignaba - cómo podía no tener acceso directo - era casi una violación de mis derechos... ¿Y en el programa para permitirme no tener acceso a algo?
Pues bien, a medida que fui adquiriendo experiencia, a menudo comprobé que la diferenciación de los derechos de acceso es una ventaja para el propio programador, porque a menudo me salvaba de cometer errores en los módulos escritos. Coges una clase, quieres usarla, y no tiene acceso a algunos datos... Te indignas, cómo puede ser, te pones a investigar... y oops... Hay cosas que hay que tener en cuenta y no se puede acceder a los datos directamente, hay "caminos indirectos", la arquitectura del sistema es tal que accediendo directamente puedo obtener datos no válidos. Pero también puedo obtener datos válidos, todo depende del momento. Y un error así es muy difícil de detectar.
En este caso, la cuestión más sencilla es acceder a los datos de una caché. Si necesita datos en caché y accede a ellos directamente, ¿está seguro de que obtendrá los datos correctos? En el enfoque procedimental sin diferenciación, hay que entender cuándo se puede usar, cuándo no, cuándo los datos son válidos, cuándo no... En el enfoque OOP - todo es muy simple, usted no tiene acceso a los datos de la caché, sólo se puede llamar a la función, que devuelve los datos requeridos, y si es inválido, se obtiene datos válidos. ¿Es "más complicado"? Ahora imagina que utilizas esta caché un año después de escribirla. Cuando se han olvidado por completo los principios de refresco de caché y definición de validez. En el enfoque OOP no te importa. La función de la clase le proporcionará todo. Pero en el enfoque funcional - usted tiene que recordar en los detalles, cuando y cómo se actualiza la caché, cuando los datos en ella son válidos y cuando no.
Este ejemplo es incorrecto. Estamos hablando de interfaces dentro de su programa...
El terminal es una clase en relación con su código. Cuántas veces necesitas cambiar algo en el código del terminal que está oculto para ti y que sólo cuenta con métodos públicos - funciones para implementar tus programas.
+++ )))
El terminal es una clase en relación con su código. ¿Cuántas veces necesitas cambiar algo en el código del terminalque está oculto para ti, y sólo se proporcionan métodos públicos - funciones para implementar tus programas.
Esta necesidad surge regularmente. Lo deseable es que los promotores lo hagan.
Un ejemplo sencillo. Por alguna razón, los desarrolladores no consideraron necesario proporcionar una cuadrícula de coordenadas horizontales para los gráficos de indicadores. Y, por supuesto, no han proporcionado un método adecuado para ello).