Mi enfoque. El núcleo es el motor. - página 18
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
No, mientras discutimos sobre la programación casual, yo arrastro la manta a la POO, ¡el iniciador del tema sigue aguantando! Escribe que todo se puede guardar en la cabeza - bueno, la programación casual)))
Motor central
Programación casual )))
Programación informal :)
Programación informal :)
Tal vez tengas razón, recuerdo el término - hace un par de meses en otro foro un tipo se autodenominó programador casual, incluso traté de aclarar lo que podría significar, mi conocimiento de la palabra casual se asocia sólo con el juego de Android - "Zuma", resultó que es un programador que programa al azar - de ocasión en ocasión ))))
La POO es una metodología muy flexible, por lo que no tiene ideas a priori como el concepto de "núcleo". Sin embargo, el modelo de núcleo en cuestión aquí puede muy bien ser construido usando OOP. Por tanto, la afirmación no es del todo correcta.
No, la OOP no tiene nada que ver en absoluto. El núcleo es Unix, montamos todo alrededor del núcleo; el shell es todo lo que es como Windows, quitamos lo superfluo y trabajamos con el resto. En general, se trata de un sistema operativo.
Programación cajún :)
Cajual, no te preocupes.
Lo que me repugna de la POO es el formato rígido de escribir código. Como has visto, suelo hacer tablas de datos grandes y me resulta muy práctico. En la programación orientada a objetos (OOP) tengo que cumplir un montón de reglas, que personalmente encuentro muy restrictivas.
En resumen, programo con una OOP diferente. La mía. Hay pocas reglas y mucha libertad. La funcionalidad propiamente dicha se apila en grandes bloques, y los datos se organizan en núcleos. Ni siquiera pienso especialmente en su estructura. Todo se desarrolla por sí mismo. A nivel intuitivo.Peter, esas reglas son las que tú mismo necesitas. Por eso te "endurecen". Para que no te equivoques accidentalmente y vayas a un lugar que no debes. De hecho, el estilo OOP es "reglas de la carretera" - por supuesto, restringen al conductor. Y en un pueblo con tres patios - nadie los mira, es más fácil y rápido (más eficiente). Sin embargo, en una gran ciudad ocurre lo contrario: son las normas de tráfico las que permiten las conexiones de transporte más eficientes. Lo mismo ocurre con el AOP. Son las reglas que permiten construir grandes sistemas complejos de la manera más eficiente.
En su sistema - no ha habido ningún cambio todavía, es de uso muy limitado, y no necesita modificaciones. Por eso puedes mantenerlo en tu cabeza. No pasa nada si el sistema recibe usuarios y necesita modificaciones: la falta de control y encapsulación será bastante estresante.
Todo lo demás - no hay diferencia, la POO y su estilo (como se ha dicho, también tiene estilo procedimental - también sufre de los mismos defectos - variables globales, la falta de control de tipos, y así sucesivamente) son por lo demás cerca.
En defensa de tu estilo tienes que demostrar lo único: que mantener todo el sistema en una enorme matriz global con acceso arbitrario es mejor que dividir el programa en un montón de pequeñas partes anidadas en cadenas de herencia con acceso polimórfico, y ocultas por la encapsulación.
Por cierto, hay gente en el foro a la que no le gusta la herencia, creo que pueden apoyarte.
Otra ventaja de utilizar la POO, frente al método de Peter. En POO, el programador no necesita el código fuente de la clase base y no necesita entender cómo funciona. Para extender o cambiar la funcionalidad de la clase base, es suficiente con crear un heredero de esta clase.
Si se utiliza el método de Peter, el programador tiene que entender todo el código largo, y si no hay código fuente, tendrá que escribirlo desde cero.
Todo lo demás - no hay diferencia, la POO y tu estilo (como ya se ha mencionado, tienes un estilo procedimental - también sufre los mismos inconvenientes - variables globales, falta de control de tipos, etc.) son por lo demás cercanos.
Podría estar equivocado, y buscar en Google es demasiado perezoso, pero el estilo procedimental implica una compleción lógica de un procedimiento (función) - "desatornillarlo" de la fuente y utilizarlo en otro código, es decir, las funciones MQL incorporadas toman datos como parámetros y devuelven el resultado.... y aquí, Piotr ha caído sobre ambos pies )))) - El intercambio a través de variables declaradas globalmente reduce la portabilidad del código y permite que se produzcan bugs difíciles de rastrear ;)
Muy bien. Digamos que estoy convencido.
En principio, he entendido todo esto desde hace mucho tiempo. Y estoy de acuerdo con ello. Sin embargo, al mismo tiempo, prefiero mi propio enfoque. ¿Por qué?
Hay una razón en particular:
DESARROLLO DE PROGRAMAS.
//---------------------------------------
¿Cómo de rápido se desarrollará el programa con la POO y con mi enfoque? ¿Qué enfoque es más favorable para el crecimiento y la complicación de los mecanismos?
He llegado a la conclusión de que mi enfoque + lengua materna en el código (60% de ruso y 40% de inglés), dan un crecimiento rápido máximo del programa.
Precisamente este rápido crecimiento es lo que necesito. No se ha profundizado en los detalles. No sólo pasar por encima de cada línea de código. No es un enfoque profesional.
Quería que el programa se desarrollara rápidamente y se hiciera más complejo. Que se crearan mecanismos para realizar las funciones que se les asignan. Rápido y sencillo.
Para poder añadir nuevas funciones con unas pocas líneas de código.
Mi enfoque es superior a la POO para resolver esta tarea en particular.