OOP vs. programación procedimental - página 13
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
¿Qué quiere decir la eficiencia de la solución?
Por eficiencia de la solución me refiero a la calidad de la solución en la que el mecanismo -y el software es sin duda un mecanismo- funcionará de la manera más estable. El mecanismo debe ser claro, coherente y productivo. La funcionalidad del motor debe implementar todas las tareas que se le asignen. El mecanismo no acepta nada superfluo y en el desarrollo de este mecanismo, todo lo superfluo debe ser cortado.
De lo contrario, no habrá desarrollo o no habrá eficiencia.
Esta es sólo mi opinión y no la estoy imponiendo a nadie.
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.
No quiero crear un coro aquí, pero me pregunto si los partidarios de la POO pueden presentar algún código que resuelva un problema, donde se vea claramente que esta solución es más eficiente que una solución sin POO.
Soy un maestro en la resolución de problemas sin POO y me gustaría luchar contra un maestro en la resolución de problemas con POO.
Trataré de explicarte, digamos que eres un hacedor y tienes un cliente que siempre te da trabajo para hacer. Y luego, después de 5-6 pedidos, te das cuenta de que todas sus tareas son similares de alguna manera... Y que puedes combinarlos en un patrón... Y al cliente también le gusta combinar estas plantillas entre sí en grandes cantidades... Y cuando el cliente vuelva a pedir un trabajo difícil, sólo hay que crear el número necesario de instancias (digamos, 10) de esta plantilla (clase) y a cada una de ellas ponerle las propiedades (en el constructor) que se le ocurrieron al cliente... Al final, la decisión de abrir una orden se basará simplemente en un bucle que verá el resultado en cada una de las 10 instancias, y eso es todo... Puede remachar esos pedidos en 5 minutos...
Pero no podrás hacer una instancia sin OOP y tendrás que rehacer casi todo, esperando que los cambios no rompan lo que tienes... Como resultado, pasarás mucho más tiempo...
Conclusión: un programador que conozca la POO será capaz de resolver problemas (que se adapten a la POO) mucho más rápido y con menos errores...
Déjeme intentar explicarlo, digamos que usted es un artista y tiene un cliente que siempre le da trabajo... Y después de cinco o seis pedidos te das cuenta de que todas sus tareas son, en cierto sentido, las mismas... Y que puedes combinarlos en un patrón... Y al cliente también le gusta combinar estas plantillas entre sí en grandes cantidades... Y cuando el cliente vuelva a pedir un trabajo difícil, sólo hay que crear el número necesario de instancias (digamos, 10) de esta plantilla (clase) y a cada una de ellas ponerle aquellas propiedades (en el constructor) que se le ocurrieron al cliente... Al final, la decisión de abrir una orden se basará simplemente en un bucle que verá el resultado en cada una de las 10 instancias, y eso es todo... Puede remachar esos pedidos en 5 minutos...
Pero no podrás hacer una instancia sin OOP y tendrás que rehacer casi todo, esperando que los cambios no rompan lo que tienes... Como resultado, pasarás mucho más tiempo...
Conclusión: Un programador que domine la POO será capaz de resolver problemas (que se adapten a la POO) mucho más rápido y con menos errores...
Puede que tengas razón. Nunca he hecho pedidos y no sé lo que quieren los clientes. Lo que usted describe parece más bien un trabajo rutinario, mientras que yo hablo de desarrollo. Probablemente para el trabajo rutinario (que también se realiza en equipo), la POO es insustituible. No tengo esa experiencia y simplemente no lo sé.
¿Y puedes dar un ejemplo específico de estas tareas de tipo único, que es mejor no hacer sin OOP?
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.
Creo firmemente que todo programador debe trabajar en equipo, idealmente más de 4 personas, sólo para entender que la eficiencia y generalidad del código no significa que el código sea bueno.
Oh, ¡trabajar en equipo es un tema aparte! Y dirigir un equipo de programadores es un canto a la medida del número de participantes.
Te contaré una historia de un sábado por la noche. Sobre los tiempos en que nuestra empresa solía entrar y salir del hierro. Si está repetido, pido disculpas, puede que ya haya rastreado la historia hace tiempo.
Mi jefe me llamó y me preguntó: "¿Estás muy ocupado en el trabajo? Le dije: "En realidad, no.
-¿A qué te dedicas ahora? El jefe nunca supo lo que hacía, porque me hice un horario personal, que incluía constantes ausencias)).
Le dije: "Sí, sólo estoy escribiendo un paquete de pruebas para nuestro equipo. El jefe se alegró mucho: "Genial, justo a tiempo para probarlo en Siberia". Alexey, tenemos que volar, los chicos están atascados allí, no pueden resolverlo. Me encantaban los viajes de negocios, tenía total libertad.
Vuelo a Krasnoyarsk, mis chicos se reúnen conmigo y me miran, todos parecen culpables. Fuimos a una cafetería, tomamos algo y nos pusimos a hablar. Le pregunté qué te pasaba. El jefe se quedó perplejo, llevaba tres meses de viaje de negocios y se quedó atascado en un punto. Sólo tiene tiempo para enviarle dinero por transferencia.
Bueno, están al descubierto. Se dirigieron a una aldea siberiana, se alojaron en una casa de huéspedes y allí había dos jóvenes hermanas. Así que el amor hiló y los amigos se involucraron, para que nadie se ofendiera.
Les dije que no te entregaría, yo soy igual. Pero tenemos que mantener el ritmo. Vamos a ajustar toda la corona, sólo faltan unos pocos kilómetros, 500 kilómetros, entonces te daré un bono, le retorceré el dinero al jefe y tú y estos amigos celebrarán el Año Nuevo, ¿de acuerdo?
Ahora las mujeres se escandalizarán, pero Lekha fue la primera en estar de acuerdo, diciendo que mi mujer debe dar a luz, ¡prefiero quedarme aquí un tiempo! Todos estaban casados y, por alguna razón, ninguno quería volver a casa).
Por otro lado, comprendí en mis entrañas lo mucho que podían trabajar los chicos cuando les esperaban chicas jóvenes y hermosas de Siberia).
Esto no es un argumento en absoluto.
Cualquier tarea puede resolverse con o sin POO. Sin OOP también se pueden crear fácilmente funciones unificadas, que se utilizarán muchas veces y todo el programa no se romperá por los cambios que se introduzcan en él. Hay un poco más de código con OOP. ¿Mejora la legibilidad gracias al uso de la POO? No lo sé.
Tengo cada clase almacenada en un archivo separado y cada función también en un archivo separado. Es una cuestión de costumbre y de comodidad.
Otro ejemplo muy sencillo, que está en la superficie... Generador de EA en el MetaEditor... Cualquiera, incluso si no sabe programar, puede crear un EA con un gran número de indicadores y condiciones en 10 segundos )))) Y todo esto es OOP ))
No hay nada que discutir en absoluto.
Cualquier tarea puede resolverse con o sin POO. También puedes crear fácilmente funciones unificadas sin POO que se utilizarán muchas veces y todo el programa no se romperá por los cambios que introduzcas en él. Hay un poco más de código con OOP. ¿Mejora la legibilidad gracias al uso de la POO? No lo sé.
Tengo cada clase almacenada en un archivo separado y cada función también en un archivo separado. Es una cuestión de costumbre y de comodidad.
Aquí en este hilo había un ejemplo de un problema que se puede resolver sin OOP, pero de una manera muy irracional.
Esto no es un argumento en absoluto.
Cualquier tarea puede resolverse con o sin POO. Sin OOP también se pueden crear fácilmente funciones unificadas, que se utilizarán muchas veces y todo el programa no se romperá por los cambios que se introduzcan en él. Hay un poco más de código con OOP. ¿Mejora la legibilidad gracias al uso de la POO? No lo sé.
Tengo cada clase almacenada en un archivo separado y cada función también en un archivo separado. Es una cuestión de costumbre y de comodidad.
Puedo decir con seguridad que no necesito la POO en el desarrollo personal, pero no estoy seguro del trabajo en equipo en un proyecto grande. El desarrollo y la comunicación del código creado por diferentes programadores nunca se me ha ocurrido y no sé cómo lo implementaría a mi manera. Este es el único argumento a favor de la POO en el desarrollo que actualmente acepto.
Este no es el argumento principal.
No existe un equivalente al polimorfismo en la programación procedimental.