OOP vs. programación procedimental - página 26
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
No hay mucho que pensar.
La POO es un mecanismo que nos permite pasar muchas comprobaciones y aprobaciones al compilador. Sin embargo, tenemos que hacer un esfuerzo adicional para utilizarlo.
Pero si no necesitamos todas esas comprobaciones y ajustes, no tiene sentido usar OOP.
Por ejemplo, yo desconfiaría de trabajar con una matriz multidimensional de núcleo gráfico, porque tiene demasiadas entidades innecesarias que no se necesitan en ese momento. Distraen y provocan errores difíciles de calcular. Lo sustituiría por un conjunto de objetos, a los que accedería con simples interfaces compactas. Al obtener una interfaz -no tengo que recordar nada-, la propia interfaz me limita y me impide, por ejemplo, acceder al campo u objeto equivocado. En el caso de una matriz gráfica del núcleo, este manejo es muy posible.
Es decir, en el caso de que un bloque reciba una interfaz, el propio compilador "corta" todas las entidades innecesarias y evita que el usuario se equivoque. Pero en el caso de una matriz gráfica del núcleo, el usuario tiene mucha información innecesaria en la que puede equivocarse fácilmente.
En mi experiencia sé que estoy mucho mejor cuando el propio compilador lleva la cuenta de las cosas que no debería ir donde no debería ir en el bloque actual. Y con una matriz gráfica del núcleo - tengo que recordarlo. Lo negativo de mi sistema es una extensión de lo positivo. Si de repente necesito algo en un bloque que va más allá de la tarea actual, con un kernel array gráfico es fácil: sólo hay que coger los datos necesarios y trabajar con ellos. Pero con las interfaces OOP, tendrá que solicitar los datos necesarios en una interfaz adicional, o (lo que es mucho más desagradable) modificar la interfaz existente.
No hay mucho que pensar.
La POO es un mecanismo que nos permite pasar muchas comprobaciones y aprobaciones al compilador. Sin embargo, tenemos que hacer un esfuerzo adicional para utilizarlo.
Pero si no necesitamos todas esas comprobaciones y ajustes, no tiene sentido la OOP.
Pero, ¿por qué simplificarlo tanto? ¿Y qué hay de la claridad y la legibilidad? ¿Y la sencillez en la detección y corrección de errores? ¿Y la portabilidad? ¿Y la facilidad de actualización? etc., etc. ....
Entonces el tema debería sonar diferente. Algo así como: "Un nuevo conjunto de herramientas de programación" o "Un nuevo paradigma de programación"...
Si es cierto que has creado algo más genial que la OOP, ¿automografiarás la tuya cuando te hagas famoso?
No hay problema. No se han escatimado gastos para conseguir un autógrafo para sus amigos. ))))
Es una broma, pero en mi imaginación, tengo tal perspectiva de este planteamiento que es un verdadero fastidio. Parece que con el tiempo podré poner en marcha el mecanismo de auto-mejora del sistema. Si hago un núcleo lógico y hago que genere aleatoriamente diferentes mecanismos. Entonces, sólo hay que hacer una selección y elegir los adecuados. Luego, molerlos un poco... Gracias al núcleo, se pueden hacer cosas increíbles.
Por qué simplificar tanto las cosas. ¿Y la claridad y legibilidad? ¿Y la facilidad para detectar y corregir errores? ¿Y la portabilidad? ¿Y la facilidad de actualización? etc., etc. ....
bonito banner publicitario :-) "comprar nuestros elefantes".
todas estas tesis son igualmente aplicables a la OOP y a la no OOP y a la FP y a todo lo demás
No hay mucho que pensar.
La POO es un mecanismo que nos permite pasar muchas comprobaciones y aprobaciones al compilador. Sin embargo, tenemos que hacer un esfuerzo adicional para utilizarlo.
Pero si no necesitamos todas esas comprobaciones y ajustes, no tiene sentido usar OOP.
Por ejemplo, yo desconfiaría de trabajar con una matriz multidimensional de núcleo gráfico, porque tiene demasiadas entidades innecesarias que no se necesitan en ese momento. Distraen y provocan errores difíciles de calcular. Lo sustituiría por un conjunto de objetos, a los que accedería con simples interfaces compactas. Al obtener una interfaz -no tengo que recordar nada-, la propia interfaz me limita y me impide, por ejemplo, acceder al campo u objeto equivocado. En el caso de una matriz gráfica del núcleo, este manejo es muy posible.
Es decir, en el caso de que un bloque reciba una interfaz, el propio compilador "corta" todas las entidades innecesarias y evita que el usuario se equivoque. Pero en el caso de una matriz gráfica del núcleo, el usuario tiene mucha información innecesaria en la que puede equivocarse fácilmente.
Según mi experiencia, me va mucho mejor cuando el propio compilador se encarga de controlar las cosas que no debería hacer en el bloque actual. Y con una matriz gráfica del núcleo - tengo que recordarlo. Lo negativo de mi sistema es una extensión de lo positivo. Si de repente necesito algo en un bloque que va más allá de la tarea actual, con un kernel array gráfico es fácil: sólo hay que coger los datos necesarios y trabajar con ellos. Pero con las interfaces OOP, tendrá que solicitar los datos necesarios en una interfaz adicional, o (lo que es mucho más desagradable) modificar la interfaz existente.
Se equivoca al pensar que hay algo innecesario en el núcleo. Y es muy fácil recordar sus entidades porque están revestidas de palabras humanas a través de definiciones. Todo está recogido allí, pero este contenido tiene un orden claro e invariable. Las propiedades de los objetos, ventanas y elementos son directamente accesibles en cualquier punto del programa. Y puedes hacer maravillas con el núcleo en los bucles.
Estás completamente equivocado al pensar que hay algo extra en el núcleo. Y recordar sus entidades es muy fácil, porque están revestidas de palabras humanas a través de definiciones. Todo está recogido allí, pero este contenido tiene un orden claro e invariable. Las propiedades de los objetos, ventanas y elementos son directamente accesibles en cualquier punto del programa. Y qué maravillas puedes hacer gracias al núcleo en bucles...
No he dicho que "el núcleo es redundante", he dicho "innecesario por el momento". Si estoy trabajando con una línea gráfica, no debería poder acceder a las propiedades de la ventana.
Sólo el hecho de que todas estas propiedades sean directamente accesibles en cualquier parte del programa es la principal desventaja de su enfoque. En cualquier lugar del programa, debe tener acceso sólo a los elementos que se necesitan en ese lugar concreto en ese momento. Todo lo demás no debería estar disponible. Esto - permite evitar automáticamente muchos errores.
Todas las "maravillas que se pueden hacer gracias a la accesibilidad de todo el núcleo" son, en mi opinión, una fuente potencial de errores difíciles de encontrar y de problemas de comprensión del código. Hay que intentar evitar todos estos trucos.
Este enfoque me recuerda a tareas muy tontas cuando se escriben punteros, incrementos y referencias en una línea en un batiburrillo que quizás sea correcto desde el punto de vista del lenguaje pero ilegible en absoluto. He citado mi propia función más arriba, que también parece una locura, pero pensé que la compacidad es más importante en este caso.
¿Por qué simplificarlo tanto? ¿Y la claridad y la legibilidad? ¿Y la facilidad para detectar y corregir errores? ¿Y la portabilidad? ¿Y la facilidad de actualización? etc., etc. ....
¡Fantástico!
1. Antes de la oop, todos construíamos todo a partir de componentes a medida con herramientas excepcionalmente complejas
2. Antes de la POO, los programas eran una compota excepcionalmente bien mezclada
3. Antes de la POO NO habíamos oído hablar de la localización de los datos y del código y eso provocaba un mantenimiento terrible.
4. La protección de datos entre diferentes partes del mismo programa era una pesadilla.
5. Antes de la POO, nadie ampliaba los sistemas.
Esto es un completo fracaso.
Me siento y pienso que tal vez esta misma OOP surgió de mí porque apliqué todo esto a finales de los 70 y muchas otras cosas relacionadas con la cultura de la programación.
No he dicho "hay algo innecesario en el núcleo", he dicho "innecesario en este momento". Si estoy trabajando con una línea gráfica, no debería poder acceder a las propiedades de la ventana.
Sólo el hecho de que todas estas propiedades sean directamente accesibles en cualquier parte del programa es la principal desventaja de su enfoque. En cualquier lugar del programa, sólo deben ser accesibles los elementos que se necesiten en ese momento. Todo lo demás no debería estar disponible. Esto - le permite evitar automáticamente muchos errores.
Todas las "maravillas que se pueden realizar gracias a la accesibilidad de todo el núcleo" son, en mi opinión, una fuente potencial de errores difíciles de encontrar y de problemas de comprensión del código. Hay que intentar evitar todos estos trucos.
Este enfoque me recuerda a las tareas más tontas cuando se escriben punteros, incrementos y referencias en una sola línea en un lío que puede ser correcto desde el punto de vista del lenguaje pero es absolutamente ilegible. He citado mi propia función más arriba, que también parece una locura, pero pensé que la compacidad es más importante en este caso.
Estás razonando sobre el núcleo basándote en nociones teóricas momentáneas basadas en tu experiencia, que no tiene nada que ver con la tecnología de la que hablas. De ahí algunos problemas de acceso, recordando las entidades...
Estoy razonando desde la experiencia práctica con esta tecnología, y digo que no hay esos problemas de acceso o limitación. Sinceramente, no sé de qué problemas de acceso hablas en absoluto. No existen esos problemas y nunca los ha habido.
Por favor, explique a qué problemas de acceso se refiere.
¿Qué le hace pensar que hay que restringir el acceso si eso provoca errores? Esto es algo nuevo para mí.
¿Puede el acceso directo a una matriz global en un código de procedimiento causar errores difíciles de encontrar por sí mismo?
Hablas del núcleo basándote en nociones teóricas inmediatas basadas en tu experiencia, que no tiene nada que ver con la tecnología de la que hablas. De ahí algunos problemas de acceso, recordando las entidades...
Estoy razonando desde la experiencia práctica con esta tecnología, y digo que no hay esos problemas de acceso o limitación. Sinceramente, no sé de qué problemas de acceso hablas en absoluto. No hay ni ha habido nunca tales dificultades.
¿Qué quiere decir "sin problemas" cuando afirma que "se puede acceder a todo desde cualquier lugar"?
Ese es el principal problema. No debería ser accesible.
Se trata de trasladar la tarea del control de acceso al compilador. Todo está abierto y el programador controla el acceso.
No hubo complicaciones porque se recuerda todo. Ya estás acostumbrado. Bueno, con el tiempo te darás cuenta de que tu memoria empieza a fallar, y entonces apreciarás la capacidad del compilador para controlar el acceso. No lo recuerdo. Y sospecho que la mayoría de la gente también olvida periódicamente cómo funciona algo escrito hace meses. Es en estas circunstancias cuando el control de acceso se convierte en una ventaja.
Por ejemplo, si estás dentro del bloque que se encarga de hacer pedidos, sólo tienes la posibilidad de hacerlos. Y no tiene la capacidad de dibujar un gráfico. Si está en un bloque que se encarga de dibujar un gráfico, no puede hacer un pedido desde allí. Esto simplifica enormemente el trabajo. Y cuando en la función de dibujar un gráfico veas de repente una solicitud para hacer un pedido, tendrás que recordar durante mucho tiempo por qué lo hiciste. Estaría bien que hubiera un comentario detallado que explicara por qué se tomó esta decisión... Pero es mejor cuando los pedidos se hacen en un solo bloque dedicado.
¿Cómo puede haber "ningún problema" si dice que "todo es accesible desde cualquier lugar"?
Ese es el principal problema. ¡No debe ser accesible!
Se trata simplemente de trasladar la tarea del control de acceso al compilador. Y todo está abierto, y el programador controla el acceso.
No hubo complicaciones porque se recuerda todo. Ya estás acostumbrado. Bueno, con el tiempo te darás cuenta de que tu memoria empieza a fallar, y entonces apreciarás la capacidad del compilador para controlar el acceso. No lo recuerdo. Y sospecho que la mayoría de la gente también olvida periódicamente cómo funciona algo escrito hace meses. Es en estas circunstancias cuando la delimitación del acceso se convierte en una ventaja.
Por ejemplo, si estás dentro del bloque que se encarga de hacer pedidos, sólo tienes la posibilidad de hacerlos. Y no tiene la capacidad de dibujar un gráfico. Si está en un bloque que se encarga de dibujar un gráfico, no puede hacer un pedido desde allí. Esto simplifica enormemente el trabajo. Y cuando en la función de dibujar un gráfico veas de repente una solicitud para hacer un pedido, tendrás que recordar durante mucho tiempo por qué lo hiciste. Estaría bien que hubiera un comentario detallado que explicara por qué se tomó esta decisión... Pero es mejor cuando los pedidos se hacen en un solo bloque dedicado.