OOP vs. programación procedimental - página 36
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
1. No en cualquier medida. La rentabilidad no depende de la AOP.
2. En mi opinión, por un orden de magnitud (diez veces). Pero la principal ganancia de la POO está en el soporte del código. Ahora puedo distinguir muy rápidamente el código que escribí hace un año o más. Recuerdo bien cómo entendía mis primeros programas ANSI C en estilo puramente procedimental. Era mucho más difícil.
1. esta es la principal respuesta a la necesidad de OOP.
2. es una cuestión de experiencia en los equipos. Escribí todo lo que necesitaba. Hace un par de años decidí escribir un poco más: todo se lee, sin problemas.
De vuestras respuestas he entendido una cosa: la POO es un cierto estándar que introduce la disciplina de la programación, introduce la uniformidad y sobre esta base se reducen los errores inicialmente y, sobre todo, los problemas durante la modificación. Pero el mismo resultado se obtuvo con una cuidadosa observancia de las GOST, etapas de desarrollo, documentadas.
No puedo entender por qué NUNCA me he encontrado con algo así en mi trabajo. ¿Por qué habría un problema de diferenciación de acceso variable para UN desarrollador en un programa no tan grande? Habría 100 desarrolladores, cada uno escribiendo 100 funciones. En teoría, se podría inventar. Pero prácticamente, la programación ha evolucionado hacia la POO desde hace casi 40 años, se han escrito montañas de código y nunca he oído nada parecido.
Bueno, al principio los programas se escribían en código en absoluto.
La POO no es más que una tecnología que permite escribir programas más complejos con mayor rapidez y mantenerlos con mayor eficacia.
Pero esto no significa que la POO sea la panacea de todos los males. Yo digo que si tienes memoria como Pedro, no necesitas OOP en absoluto - declara todo globalmente y se acabó, ya que lo recuerdas todo y permite fácilmente evitar colisiones o mezcla de variables. Pero, tengo una memoria mucho peor. Y la delimitación - la uso mucho. En los últimos años me ha gustado mucho el modificador const - antes lo usaba poco. Ahora lo uso muy a menudo. Sólo para tener acceso a lo que necesito y no más. Para que este acceso sea de sólo lectura en los lugares donde no se pretende cambiar.
George Merts:
Sí, efectivamente, hay situaciones en las que de repente resulta casi imposible conseguir los datos que se necesitan. Se esconden detrás de varias interfaces virtuales. Sin embargo, esta situación demuestra claramente que el sistema no estaba diseñado correctamente en un principio, no preveía la transferencia de estos datos. Esta situación es muy desagradable. O bien tenemos que construir apresuradamente "muletas" en forma de interfaces adicionales, o bien reestructurar todo el sistema. Bueno... motiva al programador a pensar más cuidadosamente en la arquitectura del sistema.
Si el programador es un profeta y clarividente, que ve por adelantado y en todos los detalles de la estructura de datos necesaria para todas las posibles variantes de la idea principal, entonces probablemente tenga sentido actuar a su manera. O hacerlo en la fase final, cuando todo esté ya funcionando y el código esté depurado sin usar estos complementos, pero de nuevo, siempre que no haya que cambiar y reordenar nada...
1. esta es la principal respuesta a la necesidad de OOP.
2. es una cuestión de experiencia en equipos. Escribí todo lo que necesitaba. Hace un par de años me decidí a escribir algo más: todo se lee, sin problemas.
De vuestras respuestas he entendido una cosa: la POO es un cierto estándar que introduce la disciplina de la programación, introduce la uniformidad y sobre esta base se reducen los errores inicialmente y, sobre todo, los problemas durante la modificación fundamentalmente. Pero el mismo resultado se obtuvo con una cuidadosa observancia de los GOST, las fases de desarrollo y la documentabilidad.
1. No. La OOP no es una herramienta para garantizar la rentabilidad. Y no se puede hablar de la necesidad de la OOP mientras se mira la rentabilidad. La POO es una herramienta para simplificar el desarrollo y el mantenimiento del código.
2. Es genial que los CT de hace diez años sigan funcionando. No puedo vivir así, regularmente dejan de funcionar para mí, constantemente tengo que modificarlas. Y la OOP es una gran ayuda para mí en eso.
Y sobre la OOP: algunas normas, sí, todas ciertas. Y es cierto que puedes obtener el mismo resultado si lo mantienes escalonado y documentado. Pero me parece que requiere más esfuerzo que en el caso de la POO.
Al principio, los programas se escribían en código.
La POO es simplemente una tecnología que permite escribir programas más complejos con mayor rapidez y mantenerlos con mayor eficacia.
Pero eso no significa que la OOP sea una cura para todo. Yo digo que si tienes memoria como Pedro, no necesitas OOP en absoluto - declara todo globalmente y listo, ya que lo recuerdas todo y permite fácilmente evitar colisiones o mezcla de variables. Pero, tengo una memoria mucho peor. Y la delimitación - la uso mucho. En los últimos años me ha gustado mucho el modificador const - antes lo usaba poco. Ahora lo uso muy a menudo. Sólo para tener acceso a lo que necesito y no más. Para que este acceso sea de sólo lectura en aquellos lugares en los que no se pretende modificar.
Al principio, los programas se escribían en código.
No tergiversemos las cosas, ¿de acuerdo?
La POO es simplemente una tecnología que permite escribir programas más complejos con mayor rapidez y mantenerlos con mayor eficacia.
Eso es cuestionable, y muy cuestionable.
Los programas más rápidos se escriben y se mantienen con eficacia si tienen una buena documentación de diseño. Se pueden encontrar ecos de este problema en el mercado, donde se presta mucha atención a la RPT. Si la RPT es pésima, ninguna OOP ayudará.
Los programas que cuentan con una buena documentación de proyecto se redactan y mantienen con mayor rapidez y eficacia. Se pueden encontrar ecos de este problema en el mercado, donde se presta mucha atención a la RPT. Si la RPT es pésima, ninguna OOP ayudará.
Si el programador es un profeta y clarividente, que ve con antelación y en todos los detalles la estructura de datos necesaria para todas las posibles variantes de la implementación de la idea principal, entonces probablemente tenga sentido actuar a su manera. O hacerlo en la fase final, cuando todo esté ya funcionando y el código esté depurado sin usar estos complementos, pero de nuevo, siempre que no haya que cambiar y reordenar nada...
La POO es simplemente una tecnología que permite escribir programas más complejos con mayor rapidez y mantenerlos con mayor eficacia.
Como ya se ha explicado, la POO no está pensada originalmente para escribir y depurar código con rapidez debido a la gran cantidad de envoltorios, superestructuras intermedias y adaptadores... Sólo tiene sentido en la fase final, cuando todo está funcionando y depurado y la estructura de datos ha adquirido su forma definitiva... Es decir, se trata de un procedimiento puramente cosmético de embalaje de código listo para su posterior almacenamiento...
Pero otra cosa es más importante para mí - Igor dijo correctamente arriba - cada clase es responsable sólo de sus propias variables, es imposible "entrar" en las variables de otra persona desde ella. Como resultado, la mayoría de los problemas se cortan en la etapa de compilación.
Una clase sólo tiene variables internas y no variables de entrada o salida... ¿Dónde has visto el uso en la programación de un objeto que no tiene contacto con el mundo exterior y que hierve en su propio jugo?
.... Los programas modernos prácticamente no necesitan documentación: todo está en la palma de la mano en las interfaces de clase.
Explíquenlo a los metacitas: por qué escribieron enormes manuales para el terminal, para el lenguaje y en general, de dónde salió esta montaña de documentación para productos de software sobre, por ejemplo, Cp... De hecho, ¿hay algún producto de software sin documentación? Es extraño que no puedas ver eso.