OOP vs. programación procedimental - página 12
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
¿Cómo puedo utilizar la POO si ni siquiera puedo meter las clases? Simplemente no los necesito. No necesito estructuras. Es una división artificial, que no se justifica por el desarrollo propio de mi programa. Exactamente: el autodesarrollo. No hay otro nombre para ello.
Así, en este proceso, los propios bloques de código se dividen por la necesidad que nace en el proceso de mejorarlos y añadir nuevas funciones. Primero se crean las funciones y luego se combinan gradualmente en bloques más grandes, que se van puliendo y actualizando con nuevas características. Con el tiempo, estos bloques se desintegran y surgen otros nuevos. Todo sucede de forma natural. Simplemente "doy vueltas" a la nueva funcionalidad para que adquiera nuevas características, y luego la trituro hasta conseguir un estado de calidad. Al mismo tiempo, la estructura del código cambia y se transforma constantemente. No mantengo ningún esquema claro y todo se desarrolla en direcciones imprevisibles. De repente, en este proceso, encuentro oportunidades para dar un salto cualitativo. Y doy este salto.
Así es como evoluciona mi programa. Se expande, luego se encoge, se desmorona y emerge transformado. Hay cambios globales, saltos cualitativos, pero también hay estados estables a largo plazo.
En este proceso, cualquier regla innecesaria y la sintaxis de un lenguaje ajeno sólo ralentizarán las cosas.
¿Cómo puedo utilizar la POO si ni siquiera puedo meter las clases? Simplemente no los necesito. No necesito estructuras. Es una división artificial, que no se justifica por el desarrollo propio de mi programa. Exactamente: el autodesarrollo. No hay otra palabra para definirlo.
Así, en este proceso, los propios bloques de código se dividen por la necesidad que nace en el proceso de mejorarlos y añadir nuevas funciones. Primero se crean las funciones y luego se combinan gradualmente en bloques más grandes, que se pulen y actualizan con nuevas características. Con el tiempo, estos bloques se desintegran y surgen otros nuevos. Todo sucede de forma natural. Sólo le doy "vueltas" a la nueva funcionalidad para que adquiera nuevas características, y luego la trituro hasta que sea de calidad. Al mismo tiempo, la estructura del código cambia y se transforma constantemente. No mantengo ningún esquema claro y todo se desarrolla en direcciones imprevisibles. De repente, en este proceso, encuentro oportunidades para dar un salto cualitativo. Y doy este salto.
Así es como evoluciona mi programa. Se expande, luego se encoge, se desmorona y emerge transformado. Hay cambios globales, saltos cualitativos, pero también hay estados estables a largo plazo.
En este proceso, cualquier regla y sintaxis innecesaria con un idioma extranjero sólo ralentizará las cosas.
Sin embargo, podría valer la pena pasar una semana para ordenar las estructuras. La afirmación "no necesito estructuras" parece realmente estúpida. La única conclusión es que no sabes lo que es en absoluto.
Hay tareas que no pueden resolverse de forma óptima por procedimientos.
Depende de lo que se entienda por "óptimo" )
En lo que a mí respecta, la POO es sólo una envoltura conveniente, no una solución a ningún problema. Por eso la discusión está estancada aquí.
En general, todo el mundo parece estar de acuerdo en que cualquier tarea se resolverá mucho más rápido y de forma más compacta utilizando un enfoque estructurado-procedimental. Y se invierte más tiempo en envolver las clases que en la propia codificación. A veces te dejas llevar, estropeas un montón de clases y luego piensas, para qué molestarse con todo...
Una cosa más sobre la "programación procedimental con punteros de función": ¿por qué debería ponerse en una categoría aparte? Creo que los punteros de función son un estilo estructural-procedimental.
Depende de lo que se entienda por "forma óptima" )
En lo que a mí respecta, la POO es sólo una envoltura conveniente, no una solución a ningún problema. Por eso la discusión está estancada aquí.
En general, todo el mundo parece estar de acuerdo en que cualquier tarea se resolverá mucho más rápido y de forma más compacta utilizando un enfoque estructurado-procedimental. Y se invierte más tiempo en envolver las clases que en la propia codificación. A veces te dejas llevar, estropeas un montón de clases y luego piensas, para qué molestarse con todo...
Una cosa más sobre la "programación procedimental con punteros de función": ¿por qué debería ponerse en una categoría aparte? Creo que los punteros de función son sólo de estilo estructural-procedimental.
El polimorfismo noes posible de ninguna manera por medios procedimentales, excepto para los punteros de función. La POO es definitivamente polimorfismo, mientras que en la programación procedimental no hay necesariamente punteros a funciones.
No hay que envolver todo en clases.
¿No deberíamos dedicar una semana al menos a las estructuras? La afirmación "no necesito estructuras" parece realmente estúpida. La única conclusión es que no sabes lo que es en absoluto.
La estructura es algo que se explica por sí mismo. Combina un conjunto nombrado de variables de diferentes tipos. El tipo principal de mi programa es int. El doble se utiliza sólo en algunos lugares. cadena sólo en un bloque concreto.
¿Por qué necesito estructuras en el contexto de la POO?
Tengo una estructura que pertenece al núcleo. Es decir, la estructura del propio núcleo dentro de él. Eso es todo lo que necesito.
La estructura se explica por sí misma. Combina un conjunto nombrado de variables de diferentes tipos. El tipo principal de mi programa es int. Sólo utilizo el doble en algunos lugares. cadena sólo en un bloque concreto.
¿Por qué necesito estructuras en el contexto de la POO?
Tengo una estructura que pertenece al núcleo. Es decir, la estructura del propio núcleo dentro de él. Eso es todo lo que necesito.
Debes haber estado escribiendo un programa para ti durante tres años.
Se puede, pero con diferentes eficiencias de funcionamiento. El apoyo no es la cuestión aquí, es demasiado relativo.
Hay tareas que procedimentalmente no se pueden resolver de forma óptima.
Soy partidario de la POO, pero de hecho, el procesador no sabe nada de la existencia de la POO, puede ejecutar código máquina, eso es todo. En los albores del ordenador se escribían los programas de esta manera, directamente en código máquina.
Por eso había tantas mujeres programadoras. Porque los hombres se emborrachaban y se volvían locos por este trabajo).
Al fin y al cabo, de acuerdo, lo que cuenta es la eficacia de la solución.
La sobrecarga de la sintaxis y la complejidad de las reglas nunca han contribuido a mantener la eficacia de las soluciones. La simplicidad y la brevedad expresadas en la concisión, la universalidad y la legibilidad de los bloques de código fueron de gran ayuda.
¿Y qué se entiende por soluciones eficaces?
Mis reglas de programación son: menos código, menos reglas, menos sintaxis...
No soy un fanático de la OOP.
Pero en términos de mantenibilidad, escalabilidad y facilidad de uso por parte de terceros, lo que TC (Peter, no Karputov) está impulsando es simplemente la edad de piedra.
Tengo la firme opinión de que todo programador debería trabajar en equipo, idealmente más de 4 personas, sólo para entender que la eficiencia y la universalidad del código no significa que éste sea bueno.
Soy partidario de la POO, pero de hecho, el procesador no sabe nada de la existencia de la POO, puede ejecutar código máquina, eso es todo. En los primeros tiempos del ordenador, así es como se escribían los programas, directamente en código máquina.
Por eso había tantas mujeres programadoras. Porque los hombres bebían mucho y se volvían locos por este trabajo).
¿Y qué? Hasta ahora una conclusión es que al principio había que escribir muchos programas en código máquina))