Realización de un proyecto crowdsourced en Canvas - página 24
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
Si dos programadores con la misma experiencia e inteligencia compiten creandograndes proyectos similares. Pero el primero sólo utiliza funciones, y el segundo utiliza funciones y clases. Definitivamente, la victoria será para el segundo. Pero, repito, si se trata de un proyecto voluminoso, esto último lo hará más rápido porque habrá menos errores y más orden. Y el producto de la segunda será más legible, fácil de mantener y de actualizar y complementar. Esto ni siquiera es mi imho, es sólo una declaración de hechos. Es más fácil cavar un agujero con una pala que con una paleta. Si implementaras tu mecanismo no sólo en las funciones, sino también en las clases, sería más eficiente. Esta es mi opinión.
Comencemos con la cuestión de la necesidad de las clases en la implementación de grandes mecanismos. Una clase es un caparazón para un conjunto de algunas funciones, y un "gran mecanismo" es un bloque de código que implementa un conjunto de tareas. En mi aplicación, un "gran mecanismo" es casi siempre una función muy grande y un conjunto de otras pequeñas que le sirven. El llamado "motor". Si lo metes con funciones de servicio en una clase, nada cambiará, y si lo metes en diferentes clases, el acceso entre ellas se complicará y la eficiencia del mecanismo bajará.
Si el tamaño del mecanismo aumenta, hay que optimizar su código o dividir la funcionalidad en archivos. ¿No es suficiente? Además, la optimización periódica del código en un bloque conduce a milagros de eficiencia. Se comprime constantemente y cada vez requiere más funciones para ser implementado. Es decir, el número de funciones disminuye al contrario. Se generalizan en un bloque, cuyo código se mejora constantemente. Este es un camino directo hacia la eficiencia .
Además, si hacemos que las variables importantes sean globales, serán visibles en todas partes del mecanismo, y será fácil trabajar con ellas, y si definimos ámbitos para ellas, se creará una tarea superflua desde el punto de vista de la eficiencia del mecanismo. De nuevo, la complicación del acceso. Creación de objetos de clase, etc... La tendencia a fragmentar el mecanismo en un gran número de funciones arruina no sólo la eficiencia, sino también la universalidad de los bloques de código. Resulta que cada tarea concreta necesita una función separada, y la universalidad de los bloques de código simplemente no se mejora. El número de llamadas y parámetros pasados también crece. Esto no contribuye a la eficiencia del mecanismo, pero esta tendencia es en realidad promovida por la POO.
La POO es más eficiente cuando un proyecto es trabajado por un grupo de programadores. En este caso no se puede prescindir de él. Aunque, si lo piensas, aquí también puedes prescindir de él...
Pero, por supuesto, todo esto son palabras. En la práctica, demostraría rápidamente lo que estoy diciendo.
Nikolai Semko:
Y, Peter, he echado un vistazo rápido a tu código y me he dado cuenta de que estás utilizando canvas en toda su extensión (no la clase CCanvas, pero a quién le importa). Entonces, ¿por qué todas estas preguntas sobre el lienzo y por qué estoy tratando de explicar todas estas cosas aquí? :)).
)))), me sorprenden un poco tus explicaciones sobre los principios de dibujo de los kanvas. Ya te he dicho antes y te he mostrado que todo en mis kanvas está dibujado)). (Bueno, casi todo. :))
Comenzó este tema porque no puedo entender por qué hasta ahora nadie no ha dibujado el mismo botón que el mío. Al fin y al cabo, y según tus palabras, es fácil.
)), también me ha sorprendido un poco tu explicación de los principios del dibujo en el lienzo, porque ya te he dicho y mostrado antes que todo se dibuja)). (Bueno, casi todo. :))
Comenzó este tema porque no puedo entender por qué hasta ahora nadie no ha dibujado el mismo botón que el mío. Al fin y al cabo, y según tus palabras, es fácil.
Si no lo has visto, no significa que nadie más que tú no pueda hacerlo. Es tan insignificante que ni siquiera necesitas publicarlo - un evento demasiado insignificante - creando sólo un botón - para publicar su código, no porque seas el mejor ;)
Estáis compitiendo, y con razón, Anatoly, con molinos de viento.
Si no lo has visto, eso no quiere decir que nadie más que tú sea capaz de hacerlo. Es tan insignificante que no hay necesidad de publicarlo - un evento demasiado insignificante - sólo crear un botón - para publicar su código, no porque usted es el mejor ;)
Todos compiten, y con razón, con los molinos de viento.
Cálmate, Artem. Ya me he dado cuenta de que no te gusto. Aparentemente, también lo hacen muchos otros en este recurso. Tal vez esté justificado, pero es demasiado cambiar de personalidad de la nada cuando se discuten cuestiones técnicas.
Estoy tranquilo, ¿qué te hace pensar lo contrario?
Me gusta/no me gusta una persona - no es un foro técnico para discutir. Para mí eres neutral, nada más. Igualmente, como para el resto de nosotros me parece.
Pero para que te mencionen no al estilo de "ah-ah-ah..., es que Don Quijote..., me acuerdo, me acuerdo...", tienes que hacer algo útil al menos.
Puedes o no hacer lo que quieras: estás en tu derecho y nadie lo discute. Nadie necesita tu palabra aquí - deberías dártela a ti mismo en primer lugar ;)
El ambiente es muy amigable - la gente te dice lo bueno que es usar OOP en algunas situaciones, un hombre se crucifica ante ti, tratando de ayudarte en algo, codificando para que te lo enseñen, para que sea más comprensible. Pero resulta -por tus propias palabras- que ni siquiera lo necesitas: simplemente no sabes con quién competir y tratas de desafiar a la gente "débilmente".
Y lo que también me parece - no es porque decidiste no escribir y no estudiar OOP, que has sopesado todo y entendido que tú, usando la programación procedimental, escribes código mucho mejor y optimizado (como lo presentaste a todo el mundo aquí), sino simplemente porque no entiendes nada allí, e inventaste una excusa, que anunciaste a todo el mundo, apoyándola con palabras y desafío "cree sólo el que me gana".
¿Recuerdas el chiste de "Elusive Joe"?
...
¿Recuerdas el chiste de "Elusive Joe"?
Absolutamente de acuerdo.
El escurridizo letrista/filósofo... :-) la misma mierda que "Joe", sólo que en la "otra mano"... :-)
Empecemos con el tema de la necesidad de clases en la implementación de grandes mecanismos. Una clase es un caparazón para un conjunto de funciones, y un "gran mecanismo" es un bloque de código que implementa un conjunto de tareas. En mi aplicación, una "Gran Máquina" es casi siempre una función muy grande y un conjunto de pequeñas que le sirven. El llamado "motor". Si lo metes con funciones de servicio en una clase, nada cambiará, y si lo metes en diferentes clases, el acceso entre ellas se complicará y la eficiencia del mecanismo bajará.
Si el tamaño del mecanismo aumenta, hay que optimizar su código o dividir la funcionalidad en archivos. ¿No es suficiente? Además, la optimización periódica del código en un bloque conduce a milagros de eficiencia. Se comprime constantemente y cada vez requiere más funciones para ser implementado. Es decir, el número de funciones disminuye al contrario. Se generalizan en un bloque, cuyo código se mejora constantemente. Este es un camino directo hacia la eficiencia .
Además, si hacemos que las variables importantes sean globales, serán visibles en todas partes del mecanismo, y será fácil trabajar con ellas, y si definimos ámbitos para ellas, se creará una tarea superflua desde el punto de vista de la eficiencia del mecanismo. De nuevo, la complicación del acceso. Creación de objetos de clase, etc... La tendencia a fragmentar el mecanismo en un gran número de funciones arruina no sólo la eficiencia, sino también la universalidad de los bloques de código. Resulta que cada tarea concreta necesita una función separada, y la universalidad de los bloques de código simplemente no se mejora. El número de llamadas y parámetros pasados también crece. Esto no contribuye a la eficiencia del mecanismo, pero esta tendencia es en realidad promovida por la POO.
La POO es más eficiente cuando un proyecto es manejado por un equipo de programadores. En este caso no se puede prescindir de él. Aunque, si lo piensas, también puedes encontrar una forma de evitarlo aquí...
Pero, por supuesto, todo esto son palabras. En la práctica, demostraría rápidamente lo que estoy diciendo.
Pedro, es que yo antes programaba sólo con funciones y razonaba casi igual que tú ahora, y luego casi a la fuerza (pues la fuerza de la costumbre es increíble) empecé a programar con clases. Ahora puedo comparar los dos estados, mientras que tú, que no has probado a aplicar las clases, no puedes. No te ofendas. Me recuerda a otra situación. Soy vegetariano desde hace muchos años. Y con envidiable regularidad hay personas que nunca han sido vegetarianas y tratan de restregarme lo de las proteínas, los aminoácidos esenciales, etc. Les digo: no estamos en igualdad de condiciones, yo era carnívoro y ahora soy vegetariano, así que puedo comparar estas dos condiciones en términos de práctica. No lo eres y tus conocimientos son sólo teóricos que no tienen nada que ver con la práctica.
No pierda el tiempo: domine la POO.
Estás completamente vetado en este foro, amigo mío. :)) Incluido yo. :( No desesperes, lo que no nos mata nos hace más fuertes, ¡¡¡creo en ti!!! :))
No pierda el tiempo: domine la POO.
Estás completamente vetado en este foro, amigo mío. :)) Yo también. :( No desesperes, lo que no nos mata nos hace más fuertes, ¡¡¡creo en ti!!! :))
Empecemos con el tema de la necesidad de clases en la implementación de grandes mecanismos. Una clase es un caparazón para un conjunto de funciones, y un "gran mecanismo" es un bloque de código que implementa un conjunto de tareas. En mi aplicación, una "Gran Máquina" es casi siempre una función muy grande y un conjunto de pequeñas que le sirven. El llamado "motor". Si lo metes con funciones de servicio en una clase, nada cambiará, y si lo metes en diferentes clases, el acceso entre ellas se complicará y la eficiencia del mecanismo bajará.
Si el tamaño del mecanismo crece, es necesario optimizar su código o dividir la funcionalidad en archivos. ¿No es suficiente? Además, la optimización periódica del código en un bloque conduce a milagros de eficiencia. Se comprime constantemente y cada vez requiere más funciones para ser implementado. Es decir, el número de funciones disminuye al contrario. Se generalizan en un bloque, cuyo código se mejora constantemente. Este es un camino directo hacia la eficiencia .
Además, si hacemos que las variables importantes sean globales, serán visibles en todas partes del mecanismo, y será fácil trabajar con ellas, y si definimos ámbitos para ellas, se creará una tarea superflua desde el punto de vista de la eficiencia del mecanismo. De nuevo, la complicación del acceso. Creación de objetos de clase, etc... La tendencia a fragmentar el mecanismo en un gran número de funciones arruina no sólo la eficiencia, sino también la universalidad de los bloques de código. Resulta que cada tarea concreta necesita una función separada, y la universalidad de los bloques de código simplemente no se mejora. El número de llamadas y parámetros pasados también crece. Esto no contribuye a la eficiencia del mecanismo, pero esta tendencia es en realidad promovida por la POO.
La POO es más eficiente cuando un proyecto es manejado por un equipo de programadores. En este caso no se puede prescindir de él. Aunque, si lo piensas, también puedes encontrar una forma de evitarlo aquí...
Pero, por supuesto, todo esto son palabras. En la práctica, demostraría rápidamente lo que estoy diciendo.
Y hay algo de eso. Alan Kay, el creador de la P OO, tenía en realidad una idea muy diferente de lo que se entiende hoy por POO. Es aún más similar a su visión. Tengo la idea de crear un proyecto con un núcleo y servicios que lo llamen para algunas funcionalidades. Y la comunicación entre los elementos se producirá únicamente a través de eventos-mensajes. Tan pronto como se envía una solicitud de evento con los datos, se recibe la respuesta de evento con el resultado. No hay herencia, polimorfismo ni inclusión.
Por cierto, con este enfoque el multithreading es más fácil de organizar porque todos los elementos, por definición, trabajan independientemente unos de otros.
Hay algo en él. Alan Kay, el creador de la POO, tenía una idea diferente de lo que se entiende hoy por POO. Es aún más similar a su visión. Tengo la idea de crear un proyecto con un núcleo y servicios que lo llamen para algunas funcionalidades. Y la comunicación entre los elementos se producirá únicamente a través de eventos-mensajes. Tan pronto como se envía una solicitud de evento con los datos, se recibe la respuesta de evento con el resultado. No hay herencia, polimorfismo ni inclusión.
Por cierto, con este enfoque, el multithreading es más fácil de organizar, ya que todos los elementos están, por definición, trabajando independientemente unos de otros.