Una pregunta para los expertos en POO. - página 10
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
Y yo también, poco a poco... y la comprensión total sólo llega después de 4-5 años (y esto es normal para una persona normal)
En mi opinión, no es necesaria la "plena comprensión". Lo principal es "captar la esencia". Yo, cuando conocí la meodología OOP, era 1995.
Ya tenía algo de experiencia con el "C normal" en el espíritu de K&R (los oldfags deben recordarlo), además de que usaba funciones de ensamblador con bastante frecuencia. Al principio era bastante escéptico con respecto a las ideas de POO, no tanto porque el programador tuviera que realizar algunas acciones extra, sino por la pura "sobrecarga" de la CPU. Pero pronto me convencí de la utilidad de esta tecnología y laclase CString fue el principal "interruptor" en mi mente.
No sólo eso, sino que trabajar con cadenas era mucho más sencillo: en aquel momento estábamos escribiendo un empaquetador de datos y mi parte era el analizador de texto de entrada. En consecuencia, parecía muy conveniente crear una jerarquía de varias cadenas sobre la base de la clase CString, que tenía importantes diferencias para nuestro empaquetador.
Me gustó especialmente el hecho de que después de escribir el empaquetador de datos, la tarea parecía utilizarlo para cadenas, que tenían mucha información digital, para la que el empaquetador no había sido diseñado originalmente. Ciertamente empaquetó tales datos, sin embargo, lo hizo considerando el alfabeto de entrada como sólo caracteres, pero sabiendo que la cadena consiste en algunas palabras y dígitos - mejoró significativamente el empaquetador sin pérdida de velocidad. Así, se escribió una clase que representa tales cadenas con dígitos (y también un compresor específico para los dígitos), todo fue añadido a las clases existentes y el empaquetador comenzó a trabajar con los nuevos datos, aunque esta funcionalidad no se esperaba inicialmente.
Fue entonces cuando aprecié realmente el potencial de la POO para modificar y mantener el código. Por supuesto, hay cierta sobrecarga de la CPU, pero se compensa con creces con la reducción del trabajo de los programadores.
Por eso recomiendo a todos los que empiezan a aprender POO que comiencen con este tipo de tareas, donde la ventaja de la POO sería bien y claramente visible. Es decir, con las tareas de procesamiento de diferentes objetos en listas, que representarían instancias de clases con un ancestro común.Mira, tengo este canal en mis suscripciones, en general tengo una opinión positiva del autor, e incluso se repite el tema de tu vídeo por el que empezó la discusión:
Estoy casi completamente de acuerdo con todas las ideas del vídeo. Hay un par de pequeñas objeciones, pero aclaraciones (por ejemplo, considero que NULL es un puntero muy útil, que indica un error, sólo hay que tener en cuenta que la función puede devolver este puntero nulo, y, por supuesto, el vídeo dice correctamente - no se puede trabajar con él como con un objeto).
Y todo lo demás sobre las imprecisiones, el orden de desarrollo, los getter-setters y el mismo NULL es correcto.
Felicitaciones al autor.
Es extraño que siendo una persona filosófica y bien abstraída, esté tan desesperada por rechazar el amado enfoque profesional de la programación. Aunque fue diseñada para ser práctica, la POO se ha convertido en algo excesivo con las entidades y redundante para sus tareas. La "redundancia" de herramientas dificulta la solución, así como la escasez. Y esta redundancia es sin duda una consecuencia del marketing. Pensándolo bien, una mínima OOP es suficiente para resolver todo en el campo de los problemas informáticos. Al igual que todo se puede crear con funciones simples y un manejo adecuado de la memoria. En el nivel inicial, adopté la POO de inmediato. Entonces me di cuenta de que algunas entidades no podían justificar la necesidad de su existencia y vivían sus propias vidas, abstraídas de las tareas, dentro del concepto creciente. Sí, están integrados en las soluciones, pero son parásitos de la inteligencia de los desarrolladores. Ralentizan el proceso de trabajo, reduciendo su eficacia. Dificultan el flujo de trabajo por la ofuscación, la sintaxis, las reglas... Eso es lo que no me gusta de esta opcionalidad dentro de la solución.
Por lo tanto, voy a utilizar la más mínima OOP. La que se creó antes de comercializarla.
Es extraño que siendo una persona filosófica y bien abstraída, esté tan desesperada por rechazar el amado enfoque profesional de la programación. Aunque fue diseñada para ser práctica, la POO se ha convertido en algo excesivo con las entidades y redundante para sus tareas. La "redundancia" de herramientas dificulta la solución, así como la escasez. Y esta redundancia es sin duda una consecuencia del marketing. Piénsalo, una mínima OOP es suficiente para resolver todo en el campo de los problemas informáticos. Al igual que todo se puede crear con funciones simples y un manejo adecuado de la memoria. En el nivel inicial, adopté la POO de inmediato. Entonces me di cuenta de que algunas entidades no podían justificar la necesidad de su existencia y vivían sus propias vidas, abstraídas de las tareas, dentro del concepto creciente. Sí, se integran en las soluciones, pero parasitan la inteligencia del desarrollador. Ralentizan el proceso de trabajo, reduciendo su eficacia. Dificultan el flujo de trabajo por la ofuscación, la sintaxis, las reglas... Eso es lo que no me gusta de esta opcionalidad dentro de la solución.
Por lo tanto, voy a utilizar la más mínima OOP. La que se creó antes de comercializarla.
Sí. Creas una clase, por ejemplo, para trabajar con un archivo. Empiezas a usarlo y te salen bichos. Se cierra una parte del código y se intenta hacer algo con ella en la otra parte. Hay dos enfoques. La primera es tratar de recordar siempre dónde se fabrica algo, e incluso con un desarrollador esto puede no ser muy bueno. El segundo - antes de la acción de comprobar las operaciones a realizar. Bien, el siguiente fallo: en las operaciones de verificación, que están repartidas por todo el código, aquí y allá hay erratas, signo equivocado, corregido en un sitio, olvidado en otro, etc. Como resultado, has pasado de una eficiencia de código tan querida a una cosa trivial y simple: cada método de Lectura/Escritura y demás tiene una llamada a un método de comprobación con una opción para deshacer esta llamada, que casi nunca usarás. Y entonces te das cuenta de que esto es algo bueno, porque el hardware moderno te permite no contar los ciclos de reloj y el consumo de memoria en el 98% de las tareas resueltas.
Sí. Creas una clase, por ejemplo, para trabajar con un archivo. Empiezas a usarlo y te salen bichos. Se cierra una parte del código y se intenta hacer algo con ella en la otra parte. Hay dos enfoques. La primera es tratar de recordar siempre dónde se fabrica algo, e incluso con un desarrollador se puede fallar en ello.
Peter es bueno en eso.
Ese es el problema: Peter se siente cómodo utilizando una enorme tabla con todas las variables, que siempre está disponible en todo el programa, y de la que toma lo que necesita en cualquier momento. Para el titán de la memorización, esto es bastante útil.
En la POO la encapsulación es una característica de archivo, que sólo se utiliza para asegurar que el usuario en cualquier parte del código sólo tiene acceso a las variables que necesita y no a otras. Pero para Pedro es un punto negativo, ya recuerda dónde, qué y cómo lo ha utilizado. Quiere poder acceder a cualquier variable en cualquier parte del programa y en cualquier momento. No le gusta mi enfoque, cuando para acceder a una variable hay que obtener primero un puntero a la interfaz, y desde la interfaz hay que obtener la función, y sólo entonces devuelve el valor que necesitas. Y en cualquiera de estos pasos, puede encontrarse con una restricción de acceso. Creo que esto es algo bueno, porque si hay una restricción - se pone por una razón, significa que no he considerado algunos detalles importantes. Y para Peter, es un obstáculo, porque siempre tiene en cuenta todo.
Sí, has creado una clase para manejar, por ejemplo, un archivo. Empiezas a usarlo y te da errores. Se cierra una parte del código y se intenta hacer algo con ella en la otra parte. Hay dos enfoques. La primera es tratar de recordar siempre dónde se fabrica algo, e incluso con un desarrollador esto puede no ser muy bueno. El segundo - antes de la acción de comprobar las operaciones a realizar. Bien, el siguiente fallo: en las operaciones de verificación, que están repartidas por todo el código, aquí y allá hay erratas, signo equivocado, corregido en un sitio, olvidado en otro, etc. Como resultado, has pasado de una eficiencia de código tan querida a una cosa trivial y simple: cada método de Lectura/Escritura y demás tiene una llamada a un método de comprobación con una opción para deshacer esta llamada, que casi nunca usarás. Y entonces te das cuenta de que esto es algo bueno, porque el hardware moderno te permite no contar los ciclos de reloj y el consumo de memoria en el 98% de las tareas resueltas.
Imaginemos la situación contraria. Bueno, no tienes bichos. En absoluto y casi nunca, porque se recuerda TODO y se tiene en cuenta TODO.¿Utilizarías la OOP sólo por tu "deber profesional"? No lo creo. ¿Qué te importaría entonces? - Sólo la eficacia de sus códigos. Intentará eliminar toda la sobrecarga, para que el código funcione lo más rápidamente posible. También intentará crear su código de forma que se desarrolle rápidamente.
Cuando la gente me habla de bugs que ocurren aquí y allá los entiendo, pero cuando se asocian al uso o no uso de la POO no estoy de acuerdo. El número de fallos depende del conocimiento y la comprensión del código de cada uno. Quien escribe el código lo conoce mejor que quien lo enchufa. Quien lo escribe siempre tiene menos fallos. Como comprenderás, la POO promueve la portabilidad del código cuyo reverso es la mala comprensión por parte de otros programadores. Esa es la fuente de los errores.
Lo escribo todo yo mismo y encuentro bugs en bloques de 2000 líneas sin funciones de perfilador y comprobador. Simplemente, conozco mi código. La mejor cura para los bichos)).
Funciona para Peter.
Ese es el problema: Peter se siente cómodo utilizando una enorme tabla con todas las variables, que siempre está disponible en todo el programa, y de la que toma lo que necesita en cada momento. Para el titán de la memorización - es bastante útil.
La encapsulación en la POO es una característica de archivo, que se utiliza precisamente para asegurar que el usuario tenga acceso sólo a las variables que necesita y no más. Pero para Pedro es un punto negativo, ya recuerda dónde, qué y cómo lo ha utilizado. Quiere poder acceder a cualquier variable en cualquier parte del programa y en cualquier momento. No le gusta mi enfoque, cuando para acceder a una variable hay que obtener primero un puntero a la interfaz, y desde la interfaz hay que obtener la función, y sólo entonces devuelve el valor que necesitas. Y en cualquiera de estos pasos, puede encontrarse con una restricción de acceso. Creo que esto es algo bueno, porque si hay una restricción - se pone por una razón, significa que no he considerado algunos detalles importantes. Y para Peter, es un obstáculo, porque siempre tiene en cuenta todo.
George, no se trata sólo de la memoria. He creado un entorno de desarrollo cómodo para mí, utilizando mi lengua materna y también el inglés. El código bilingüe es MUCHO mejor de recordar que el monolingüe. Especialmente cuando no te quedas con las palabras estándar y llamas a las variables por el nombre que quieras. Probado. Simplemente ignoré la profesionalidad en la programación y empecé a escribir a mi antojo. Como resultado, empecé a navegar rápidamente por mi código y a leerlo, recordarlo y desarrollarlo con facilidad. Además, ya sabes...
ZS. Que no piensen que les insto a que les importe el profesionalismo. No, en absoluto. Lo escupí por mi ego sobreinflado. Resulta que no sólo puede ser malo, sino también bueno. :)
Peter, tu pensamiento sugiere que nunca has trabajado en un equipo. No has visto cómo cada uno hace su parte de una gran tarea, y cómo todo se une al final.
Por ejemplo, sin la POO era imposible crear y desarrollar Windows.
Si no fuera necesario, trataría de no aplicar clases tampoco. Pero cuando decidí convertir mi robot en un robot multidivisa, inmediatamente apliqué clases, porque ya estaba claro lo que pasaría sin OOP.
Al aplicar las clases, es obvio que los pares de objetos utilizados son de la misma clase y trabajar con ellos simultáneamente ya es muy fácil.
Peter, tu pensamiento sugiere que nunca has trabajado en un equipo. No has visto cómo cada uno hace su parte de una gran tarea y cómo todo se une al final.
Por ejemplo, sin la POO, era imposible crear y desarrollar Windows.
Si no fuera necesario, trataría de no usar clases tampoco. Pero cuando decidí convertir mi robot en un robot multidivisa, inmediatamente apliqué clases, porque ya estaba claro lo que pasaría sin OOP.
Al aplicar las clases, es obvio que los pares de objetos utilizados son de la misma clase y trabajar con ellos simultáneamente ya es muy fácil.
Sí, no formaba parte del equipo. Mi enfoque debe considerarse como un experimento de un desarrollador. No estoy persuadiendo para que lo sigan. Hay demasiada impertinencia en mi enfoque).
Si un programador se adentra en el mundo del forex, no es necesario que sea un profesional y que conozca la POO.
Es mejor aprender los entresijos del mercado y desarrollar una estrategia de negociación rentable. Y no importa si se utiliza OOP o no. La rentabilidad del Asesor Experto no se verá afectada por ello.
No tienes que desperdiciar tu energía.