Una pregunta para los expertos en POO. - página 15
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
¡es en serio!
Estoy a punto de patentar mi concepto. Hay inversores. Así que, es serio.
anoche leí el hilo de sonambulismo.... por alguna razón me imaginé una larga lista de desarrolladores de Windows - ¡como en los créditos de Star Wars!
¡y al final de la lista - en letras grandes ReTeg Konow !
@Peter Konow ¿puedes hacer un sprite de texto como este?)Recuerdas todo en el proyecto en el que estás trabajando en ese momento. ¿Qué pasa con los códigos anteriores? ¿Recuerdas igual de bien lo que escribiste hace un año? Donde las cosas han cambiado, etc. Ahora la tarea es ajustar o corregir su antiguo código.
Todo descansa en la fenomenal memoria de Peter.
Y estoy de acuerdo, si recuerdas todas las variables que se utilizan en todo tu proyecto, cuándo y dónde se modifican, encontrar fácilmente los lugares de modificación incorrecta - entonces este mismo OOP se convierte en un sin sentido de hecho. Peter, de hecho, trabaja a "nivel de ensamblador". Independientemente de los trucos de POO y de los patrones de diseño que se inventen, al final cualquier acceso a los datos son direcciones de memoria ordinarias, y dentro del espacio de direcciones asignado al proceso, todas las direcciones de memoria son totalmente accesibles. El propio procesador no sabe nada de encapsulación.
Así es como opera Peter. Hubo un tiempo en el que yo mismo me dedicaba al ensamblaje.
La única pregunta es cómo se las arregla para competir con el procesador en términos de capacidad de memoria.
Todo se debe a la fenomenal memoria de Peter
...
La única pregunta es cómo se las arregla para competir con el procesador en términos de capacidad de memoria.
Entonces, ¿qué es el fenómeno si estamos hablando del mismo proyecto en el que está trabajando todo el tiempo? Naturalmente, cualquier programador lo tendrá todo en su cabeza todo el tiempo.
Bueno, entonces, no soy cualquiera. Yo también trabajo principalmente en el mismo proyecto, sin embargo, sólo recuerdo la esencia. Tales detalles como qué y de qué procedimiento se modifica - veo sólo en el momento del desarrollo directo. Y luego, si vuelvo a este sitio, paso mucho tiempo tratando de entender por qué esto es así y no de otra manera. En consecuencia, soy partidario de recortar todos los derechos, de modo que, idealmente, en cualquier lugar del programa sólo tengas acceso a lo que se supone que debes hacer en ese lugar.
Recuerdas todo lo que hay en el proyecto en el que estás trabajando en ese momento. ¿Qué pasa con los códigos anteriores? ¿Recuerdas tan bien lo que escribiste hace un año? Donde las cosas han cambiado, etc. Ahora la tarea es ajustar o corregir su antiguo código.
Alexey Navoykov:
...
No, el kung fu aquí es exactamente OOP. Una gran cantidad de movimientos y técnicas, entre las que en una pelea el 10% de los útiles. ¡Pero qué estilos tan bonitos! Y dragón, y mono, y flamenco y sapo... Tengo un sambo específico. Cortas y obtienes el resultado.
No, es OOP lo que es kung fu aquí. Un montón de movimientos y trucos, entre los cuales el 10% serán útiles en una pelea. ¡Pero qué estilos tan bonitos! Dragón, mono, flamenco y sapo... Tengo un sambo específico. Cortas y obtienes el resultado.
No lo es.
Ya lo he dicho cientos de veces sobre la utilidad de la encapsulación y las restricciones de derechos.
La utilidad de la herencia y el polimorfismo puede verse claramente cuando se trata de listas de elementos en las que hay una interfaz virtual común, pero la implementación es significativamente diferente.
Esta es la situación más sencilla que he encontrado esta semana: hay una lista de estructuras, uno de cuyos campos es un valor doble. La idea surgió para aproximar estos valores utilizando la POO.
Sin OOP, o bien tengo que escribir enteramente procedimientos que creen los correspondientes SLAE y los resuelvan. O, si ya tengo un programa de este tipo para trabajar con un array de valores - escribir procedimientos que crearían dicho array, y lo pasarían a la función de la biblioteca.
Con OOP - heredo de la clase CLSMCore, y sobrecargo las funciones virtuales que devuelven valores puntuales. Inmediatamente puedo obtener los coeficientes del polinomio de aproximación.
Es decir, en igualdad de condiciones (cuando tenemos una función o clase de biblioteca), perdería sin OOP al introducir un array intermedio extra. Por no hablar de la necesidad de averiguar exactamente cómo llenarlo. (Hay que escribir funciones de recuperación de valores -con o sin POO-). La ventaja más importante, en mi opinión, exactamente en la simplicidad de soporte y modificación. Con la POO hay menos que entender. Y al principio gasté absolutamente la misma cantidad de esfuerzo en escribir la clase CLSMCore que habría gastado en la función de aproximación de la biblioteca sin OOP.
No lo es.
Ya lo he dicho cientos de veces sobre la utilidad de la encapsulación y las restricciones de derechos.
La utilidad de la herencia y el polimorfismo se ve claramente cuando se trabaja con listas de elementos que comparten una interfaz virtual común, pero la implementación es significativamente diferente.
Esta es la situación más sencilla que he encontrado esta semana: hay una lista de estructuras, uno de cuyos campos es un valor doble. La idea surgió para aproximar estos valores utilizando la POO.
Sin OOP, o bien tengo que escribir enteramente procedimientos que creen los correspondientes SLAE y los resuelvan. O, si ya tengo un programa de este tipo para trabajar con un array de valores - escribir procedimientos que crearían dicho array, y lo pasarían a la función de la biblioteca.
Con OOP - heredo de la clase CLSMCore, y sobrecargo las funciones virtuales que devuelven valores puntuales. Inmediatamente puedo obtener los coeficientes del polinomio de aproximación.
Es decir, en igualdad de condiciones (cuando tenemos una función o clase de biblioteca), perdería sin OOP al introducir un array intermedio extra. Por no hablar de la necesidad de averiguar exactamente cómo llenarlo. (Hay que escribir funciones de recuperación de valores -con o sin POO-). La principal ventaja, en mi opinión, es precisamente la sencillez del soporte y la modificación. Con la POO hay menos que entender. Y al principio gasté tanto esfuerzo en escribir la clase CLSMCore como habría gastado en la función de aproximación de la biblioteca sin POO.
Por ejemplo, nunca he entendido para qué sirve la sobrecarga de funciones. Es absurdo, ¿no? Hacemos una función sin parámetros, dentro escribimos todos los cálculos de las funciones sobrecargadas, hacemos las variables globales y tenemos acceso a los resultados desde cualquier otra función. Bueno, ¡qué bonito!
¡Pero no! Dividiremos todos los cálculos en funciones con el mismo nombre, pero con diferentes parámetros. Y haremos un montón de parámetros de entrada para cada función. No. Eso no es suficiente. Hagamos que los nombres de los parámetros sean ilegibles. Y haremos todo tipo de arrays para pasar en mezcla con ellos. Y haremos una docena de tales funciones para que tengamos que reflexionar sobre cada una de ellas. Y nos aseguraremos de que el acceso a ellos esté encriptado. Para que la sintaxis sea más sofisticada. ¡Eso es profesionalidad!
Lo siento, George. Ya he tenido suficiente.
ZS. Sólo un array global para los resultados de 10 funciones sobrecargadas y una función sin parámetros que hace su trabajo. ¿Cómo puede ser peor que eso? 10 veces menos sintaxis.
Yo, por mi parte, nunca he entendido por qué hay que sobrecargar las funciones. Es ridículo, ¿no? Haces una función sin parámetros, escribes todos los cálculos de las funciones sobrecargadas dentro, haces las variables globales y tienes acceso a los resultados de cualquier otra función. Bueno, ¡qué bonito!
¡Pero no! Dividiremos todos los cálculos en funciones con el mismo nombre, pero con diferentes parámetros. Y haremos un montón de parámetros de entrada para cada función. No. Eso no es suficiente. Hagamos que los nombres de los parámetros sean ilegibles. Y haremos todo tipo de arrays para pasar en mezcla con ellos. Y haremos una docena de tales funciones para que tengamos que reflexionar sobre cada una de ellas. Y nos aseguraremos de que el acceso a ellos esté encriptado. Para que la sintaxis sea más sofisticada. ¡Eso es profesionalidad!
Lo siento, George. Lo siento, George.
SZY. Sólo un array global para los resultados de 10 funciones sobrecargadas y una función sin parámetros que hace su trabajo. ¿Cómo puede ser peor que eso? 10 veces menos sintaxis.
Así es, cuéntame más sobre esta función. Tienes uno con un interruptor de tamaño monstruoso que selecciona una de una docena de funciones. En un cambio de este tipo, es muy fácil cometer un error escribiendo accidentalmente código perteneciente a una de las ramas que no está.
Las cosas son mucho más sencillas con una sobrecarga. Tenemos diez descendientes diferentes, y cada vez trabajamos con UNA clase, y tiene UNA función sobrecargable. No podemos escribirlo accidentalmente en otra clase, porque tenemos que abrir un archivo completamente diferente para ello.
Además, el análisis en sí mismo de este enorme interruptor es, en mi opinión, mucho más estresante que abrir la única clase que necesitamos y luego analizar sólo una función.
De hecho, en el código ensamblador todo el manejo de este interruptor se reduce de todos modos al mismo swich, dependiendo de este puntero. Pero en el caso de la POO todo esto queda oculto para el programador y no interfiere en su trabajo. Sin OOP - tienes que lidiar con ello.
A grandes rasgos, cuando caminas, acabas enviando señales a tus músculos en una determinada secuencia que los mueve. Sin embargo, en el nivel de la conciencia - sólo recuerdas qué movimiento hacer. Aquí, la OOP es exactamente ese tipo de "memoria de qué movimiento hacer". Usted "no entiende por qué necesitamos recordar el movimiento cuando tenemos un montón de músculos, y los nervios conectados a ellos". bueno... Ya he dicho muchas veces que, para los titanes de la memorización, basta con recordar qué músculos hay que tensar y en qué secuencia. No tiene sentido recordar todo el movimiento. Para otros, que no pueden recordar tanto, es mucho más razonable recordar todo el movimiento, y lo que ocurre con los músculos, en qué secuencia se tensan y en qué medida - es más razonable ocultarlo a la mente.
Реter Konow:
Yo, por mi parte, nunca he entendido por qué hay que sobrecargar las funciones. Es ridículo, ¿no? Haces una función sin parámetros, escribes todos los cálculos de las funciones sobrecargadas dentro, haces las variables globales y tienes acceso a los resultados de cualquier otra función. Bueno, ¡qué bonito!
Tremendo, estás haciendo algún tipo de construcción de bicicletas sin el estudio adecuado del enfoque común. Peter, busca algún buen libro, quizás Stroustrup, en algún libro escribió un editor de texto, sobre un problema real aprenderás algo, no recuerdo el contenido, pero es poco probable que te enseñe cosas malas.