OOP vs. programación procedimental - página 40

 
Andrei:

Exactamente, de una persona concreta. ¿Por qué un programador que no sufre de esquizofrenia ocultaría enérgicamente el acceso a una parte de su propio código que está depurando? ¿No prefieres atarte las manos tú mismo? :)

Bueno, como ya he dicho, intenta trabajar con el archivo de estructura que ha dado Pedro más arriba. "Busca" los datos que necesitas desde allí, y luego vuelve a colocarlos en el lugar correcto.

Y compáralo con la obtención de los datos que necesitas de una interfaz "recortada" que te da una mínima parte de la misma estructura. Con una interfaz, simplemente no hay forma de conseguir otra cosa, o de escribir algo "incorrecto".

No, es comprensible que si eres un titán de la memoria con una capacidad de olvido atrofiada - entonces tienes suerte, y no necesitas OOP. Pero no todos tienen tanta suerte.

SanSanych ofrece sustituir la POO por la documentación - en principio, también es una opción, de hecho, se acerca mucho más a las estructuras propuestas por Peter. Pero con Peter toda la documentación está "en la mente" y con SanSanych - en papel (o en medios electrónicos).

 
Andrei:

Me pregunto qué es ese "horror".

Por cierto, Renat Fatkhullin, sería interesante ver ejemplos...

 
George Merts:

No, es comprensible que si eres un titán de la memorización con una capacidad de olvido atrofiada, tengas suerte y no necesites OOP. Pero no todo el mundo tiene tanta suerte.

Así, SanSanych sugiere sustituir la POO por la documentación, que también es una opción, en principio, mucho más cercana a las estructuras propuestas por Peter. Pero la documentación de Peter está toda "en la mente", mientras que la de SanSanych está en papel (o en un soporte electrónico).

El significado de una variable debe ser conocido en cualquier caso, pero no es necesario recordarlo - se puede escribir un comentario, si no está claro por el contexto. Parece obvio.

Con OOP hay que recordar y documentar mucho más, a saber, qué se crea y se destruye cuándo y en qué momento, a través de qué interfaces fluye en qué momento y otros líos de ratones absolutamente inútiles para el resultado final - sólo de eso cualquier persona cuerda puede volverse loca y romperse el cerebro.

 

Por cierto, a todos los que se oponen a la POO: sería bueno recordar los tiempos en que los programas se escribían en lenguaje ensamblador.

Y, en particular, el trabajo con archivos mediante BIOS y DOS.

En mi opinión, la diferencia entre los enfoques procedimentales y de POO es la misma que en el manejo de discos con herramientas BIOS y DOS.

Tanto BIOS como DOS tienen todas las funciones necesarias para trabajar con el disco.

Sin embargo, crear un archivo con las características de la BIOS y escribir "¡Hola, mundo!" allí es un problema bastante grande incluso para las unidades FAT. Yo lo hacía por un reto, y no era fácil para mí. En DOS es fácil hacerlo con una sola función.

Me imagino lo difícil que sería crear un archivo de este tipo para un sistema NTFS utilizando la BIOS...

 
Andrei:

Lee con atención, se trata de la clase, no del constructor de la clase.

Además, vuelves a sugerir hacer un trabajo de mono - plantar un campo en una parcela, si podemos tener acceso a los parámetros sin hacer NADA en el caso de las variables externas o pasarlas directamente, sin ningún dolor de cabeza innecesario con constructores-destructores y todas las fugas de memoria concomitantes.


Sí, necesito entrar y me estás mostrando la puerta aquí. Probablemente no sepas lo que es un constructor de clase.

Sólo los parámetros generales - que ya son visibles dentro de la clase, pero su uso no es bueno, OOP es bueno para la capacidad de escapar del espacio común.

¿Y directamente cómo? Si no es a través de una puerta, ¿entonces de una pared? A través del constructor es como pasar directamente. Se pueden pasar parámetros inmediatamente al crear un objeto, incluso sin new. ¿Así que te da pereza describir los parámetros que debe aceptar la clase? ¿No te da pereza escribir funciones y declarar variables?

Es evidente que no has entendido nada de lo que he escrito)).

 

Dmitry Fedoseev:

¿No te da pereza escribir funciones y declarar variables?

Hay que escribir funciones y declarar variables en todas partes y en OOP también. Sólo con la POO habrá mucho más lío con ella, y eso si se prevé de antemano todo proféticamente, cuál será la estructura de datos al final del proyecto, para no tener que reescribirla cien veces. Parece obvio.

 
Andrei:

Hay que escribir funciones y declarar variables en todas partes y en OOP también. Sólo en OOP será mucho más quisquilloso, y eso si prevés de antemano todo proféticamente, qué estructura de datos habrá al final del proyecto, para no tener que reescribirlo cien veces. Parece obvio.


Es más complicado, pero hay muchos casos en los que merece la pena. En general, no es mortal.

 
Dmitry Fedoseev:

Es más complicado, pero hay muchos casos en los que merece la pena. No es fatal en general.

Ya sabes, cuando merece la pena: cuando se paga por horas, porque entonces cuanto más jaleo más rentable. :)
 
Dmitry Fedoseev:

¿Cuánto tiempo lleva trabajando en esta biblioteca suya?

Dos años de trabajo ininterrumpido.

El núcleo de la interfaz gráfica de usuario (por cierto, también hay un proto-núcleo que contiene elementos prototipo. Ocupa 2 megabytes. Consta de tablas como la que he citado) y contiene miles de variables. ¿Crees que si no utilizara el núcleo como centro y dispersara las variables en clases y estructuras y estableciera la comunicación entre ellas a través de diversas restricciones de acceso, habría cumplido con mi tarea? - Nunca por mi cuenta. Habría multiplicado el número de entidades en mi programa. Los enlaces dentro del código entre funciones y clases se volverían tan complejos que simplemente no podría seguir trabajando por mi cuenta. La eficacia de todo el mecanismo habría caído en picado.

Habría llegado a mi límite mucho antes y me habría detenido.

Muchas veces me he preguntado "¿qué habría conseguido si hubiera utilizado la POO?" y cada vez, basándome en la práctica diaria, me he dado cuenta de que no habría sido capaz de llegar tan lejos por mí mismo.

Además, mi pensamiento ya está estructurado y, por lo tanto, no necesito la POO en este sentido.

 
Renat Fatkhullin:

Por si acaso, R está escrito en un modo absolutamente asqueroso de "todo en un cubo de basura sin diferenciación de acceso". Un enfoque de la vieja escuela de hace veinte años sin áreas de visibilidad, protección o multisesión. Escribo como si fuera el único. Sí, el proyecto nació bajo una persona por desarrolladores poco profesionales. Hay que reescribirlo desde cero. Al menos una vez.

Tenía la idea de hacer una interfaz normal en R a partir de MQL5, pero después de profundizar en ella decidí inmediatamente no integrarla. El sistema es categóricamente incapaz de proteger los datos y las sesiones.

Hasta que un programador no trabaje en equipos de desarrollo normales con requisitos estrictos (golpeando sus manos durante un par de años como mínimo) no se convertirá en un desarrollador en el sentido normal. Nos agarramos la cabeza el 90% de las veces cuando miramos los trabajos de prueba al considerar los candidatos. Horror total en toda la industria del desarrollo.

Así que, una vez más, los que se oponen a la OOP hacen gala de una especie de bufonada.

Lo siento de nuevo.


Renat, por favor, no te pongas nervioso. Yo mismo no soy partidario de R. Eres un excelente gestor y programador, no te tomes a pecho los gritos del foro.

Le deseo a usted, a Rashid y a su equipo buena salud y éxito creativo.

Razón de la queja: