Hablando de la OLP en el salón - 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
No es necesario imponer, pero es obvio que en una forma procedimental la lógica del código ya es visible sin gestos extra, y cada gesto de un programador contratado cuesta una cuota al empleador. Por lo tanto, si un empresario es inteligente, no se dejará engañar por la POO, pero un programador astuto puede tergiversar un cuento sobre la POO progresiva para sacarle más dinero aprovechándose de su baja alfabetización. :)
¡Ja!
Hay una lógica de "no esfuerzo adicional" para moverse a pie, pero por alguna razón todo el mundo quiere tomar el transporte. Llega al punto de la idiotez: se suben a un coche, conducen dos kilómetros hasta un centro de fitness y luego "hacen" cinco kilómetros en una cinta de correr.
Hablando de programación, en DOS una ventana se crea simplemente escribiéndola en un buffer de vídeo. Pero para crear una simple ventana en Windows - es necesario registrar una clase de ventana, crearla y ejecutar un bucle de procesamiento de mensajes - pero por alguna razón, todo el mundo hace estos mismos "pasos extra".
En este caso, la OOP se elige no por su "progresividad", sino por los beneficios que proporciona esta metodología y porque, en última instancia, es más barata para el empresario. Porque habiendo escrito algo en estilo procedimental no se puede mantener con la misma eficiencia que escrito en estilo OOP.
Una buena ilustración - código de Peter Konov - por un lado, bastante normal código orientado a los procedimientos, pero por otro lado, para trabajar con él siempre hay que tener en cuenta una gran cantidad de información sobre la estructura del sistema, que personalmente no voy a emprender una tarea de este tipo, incluso por mucho dinero. Al mismo tiempo, el SB escrito en estilo OOP es muy fácil de mantener y cambiar. La arquitectura de objetos en el patrón TC de la Biblioteca Estándar es mucho más intrincada que en el código de Peter, sin embargo es mucho más fácil de entender y modificar.
Todo lo que se dice sobre "un estilo procedimental sin trabajo extra" es sólo hasta el momento en que se necesita escribir una estructura realmente compleja, y sobre todo hacer modificaciones en ella. Por eso la POO está tan extendida: es más fácil para los programadores y más barata para los clientes. Aunque, para hacer algo bastante sencillo en él se requieren "gestos innecesarios". Sencillamente, nadie necesita esto "simple", todos necesitan "complejo", que es mejor que se haga con el uso de OOP.
P.D. Y sigo sin entender, ¿cómo propones (hablemos de "Tú") limitar el acceso a las funciones, que no deberían usarse en ningún sitio sin modificadores de acceso OOP?
George Merts:
Porque si escribes algo en estilo procedimental, no podrás mantenerlo con la misma eficiencia que algo escrito en estilo OOP.
P.D. Y sigo sin entender, ¿cómo propones (hablemos de "tú") limitar el acceso a las funciones, que no deberían usarse en ningún sitio sin modificadores de acceso OOP?No, no. Es justo al revés.
Se trata de un código OOPeshe que es difícil de mantener y modificar ya que hay un montón de giros y vueltas en él que más tarde es más fácil de escribir el código una vez más. De hecho, se dice, que el propósito de la OOP es ocultar la lógica, por lo que la han ocultado, y si de repente es necesario abrirla, este es un servicio con pago adicional.
El envoltorio de la función permite ocultar las funciones internas, pero si de repente te apetece añadir esta función interna para lo que quieras, puedes ocultarla en una DLL, o el código fuente en un archivo separado, y el archivo en el directorio más lejano, para que no se encuentre aunque lo intentes, quizás haya más opciones para los programadores especialmente furiosos. :)
No, no lo es. Es justo al revés.
El código OOP es igual de difícil de mantener y modificar, porque la lógica allí está escondida con un montón de trucos diferentes, que luego es más fácil reescribir el código. De hecho se dice que el propósito de la POO es ocultar la lógica, por lo que la han ocultado, y si de repente es necesario destaparla, este es un servicio con cargo adicional.
La función Wrapper permite ocultar las funciones internas, pero si de repente quieres añadir esta función interna para cualquier cosa, puedes ocultarla en una DLL, o el código fuente en un archivo separado, y el archivo en el directorio más lejano, para que en el mejor de los casos no se pueda encontrar, tal vez hay opciones para los programadores particularmente furiosos. :)
¿Por qué sería "difícil de modificar" si la lógica está oculta? Por eso la lógica está oculta, para evitar que se modifique algo donde no se puede hacer.
Es que en el enfoque procedimental quieres cambiar algo, lo cambias, y luego no entiendes por qué no funciona (o peor - a veces obtienes errores incomprensibles). Y en el enfoque OOP quieres cambiarlo - y no tienes ningún acceso a los internos de la clase. Y si no hay acceso, significa que se hace por una razón, hay algo complicado ahí, unas condiciones de uso implícitas. Respectivamente, si quieres cambiar algo, puedes tomar esa misma clase, heredar su propia clase y cambiar allí lo que necesites, puesto que ya tienes acceso a los métodos de protección en la descendiente.
E incluso si se hereda, se puede tropezar con un método o campo privado que no está disponible ni siquiera en el descendiente, y una vez más, por una razón, significa que este campo no está destinado a ser cambiado incluso en el descendiente.
Hablando de "ocultar en DLL" - el problema es que sólo se puede ocultar TODO en una DLL. No es una parte del objeto. Y para eso está el modificador de acceso, para ocultar sólo una parte del objeto. Por eso todo está concebido - para que el programador en cada lugar del programa tenga acceso sólo a lo que necesita, y nada "desde arriba" - esto permite no tener miedo de que pueda cambiar accidentalmente no lo que necesita, sino que pueda cambiar la parte, que es permisible para la modificación. ¿Qué sentido tiene entonces la DLL? Abrir el código DLL - entonces se abre todo el código, no partes. Cerrar - de nuevo, todo el acceso está cerrado.
No sé cómo limitar el acceso en estilo procedimental sin usar secciones privadas-protegidas-públicas. Y esta restricción me ayuda mucho.
¿Por qué iba a ser "difícil de modificar" si la lógica está oculta? La lógica está oculta para que no se pueda modificar nada donde no se puede.
Es que en el enfoque procedimental quieres cambiar algo, lo cambias, y luego no entiendes por qué no funciona (o peor - a veces obtienes errores incomprensibles). Y en el enfoque OOP quieres cambiarlo - y no tienes ningún acceso a los internos de la clase. Y si no hay acceso, significa que se hace por una razón, hay algo complicado ahí, unas condiciones de uso implícitas. Respectivamente, si quieres cambiar algo, puedes tomar esa misma clase, heredar su propia clase y cambiar allí lo que necesites, pues ya tienes acceso a los métodos de protección en la descendiente.
E incluso si se hereda, se puede tropezar con un método o campo privado que no está disponible ni siquiera en el descendiente, y una vez más, por una razón, significa que este campo no está destinado a ser cambiado incluso en el descendiente.
Hablando de "ocultar en DLL" - el problema es que sólo se puede ocultar TODO en una DLL. No es una parte del objeto. Y para eso está el modificador de acceso, para ocultar sólo una parte del objeto. Por eso todo está concebido - para que el programador en cada lugar del programa tenga acceso sólo a lo que necesita, y nada "desde arriba" - esto permite no tener miedo de que pueda cambiar accidentalmente no lo que necesita, sino que pueda cambiar la parte, que es permisible para la modificación. ¿Qué sentido tiene entonces la DLL? Abrir el código DLL - entonces se abre todo el código, no partes. Ciérralo - de nuevo, todo el acceso está cerrado.
No sé cómo se puede limitar el acceso en estilo procedimental sin usar secciones privadas-protegidas-públicas. Y esta restricción me ayuda mucho.
George, estás tocando el tambor de nuevo )))) Esto no tiene sentido.
Georges, te estás yendo por las ramas otra vez )))) No tiene ningún sentido.
Tal vez, tal vez.
Pero eres un Casanova a tiempo parcial... Y soy tutor a tiempo parcial. Veo que "el cliente no está perdido". Así que sigo explicando. Como "deformación profesional".
Tal vez, tal vez.
Pero tú eres el Casanova a tiempo parcial... Y soy tutor a tiempo parcial. Veo que "el cliente no está perdido". Así que sigo dando explicaciones. Como "deformación profesional".
Estoy harto de los Casanovas. Te has inventado un cuento de hadas y te lo has creído) como un niño cree en Papá Noel, por el amor de Dios).
No es necesario imponerlo, pero es obvio que en la forma procedimental la lógica del código ya se ve sin gestos extra, y cada gesto de un programador contratado le cuesta dinero al empresario.
El número de gestos en el código de procedimiento anterior necesitará más si hay que hacer cambios.
Es posible escribir código sin funciones (procedimientos). Pero la codificación acabó dejando de escribirse "echando hormigón" y empezó a construirse a partir de "ladrillos". De ahí surgió la programación procedimental.
La POO es un paso más para dividir el trabajo global en componentes más simples.
La división del trabajo y, como consecuencia, la transportación de la producción de cualquier cosa crearon la revolución industrial, que condujo a la industrialización de la humanidad.
Hacer a mano es "escribir código sin procedimientos".
Conveyor es una "escritura de código procedimental", en la que muchos elementos del transportador dependen de los demás. Es decir, cambiar un elemento puede requerir cambiar otro.
La "programación OOP" es una tubería con dependencia reducida entre elementos. Es decir, un elemento puede ser sustituido por otro y es menos probable que la tubería deje de funcionar. Ser capaz de desglosar cualquier producción en partes independientes, introducir normas, etc. - es la fabricación orientada a objetos (no la programación).
La programación en sí misma es un caso especial de producción. El enfoque OOP es un enfoque de principios para producir cualquier cosa. Por lo tanto, es muy estrecho hablar de programación. La POO se aplicó con éxito ANTES de que apareciera en la programación.
Estoy harto de los Casanovas. Te has inventado un cuento de hadas y te lo has creído tú mismo ) como un niño que cree en Papá Noel, por el amor de Dios )
¡Te envidio, Lech!
Muy en serio. Bueno, déjame el derecho a un poco de hipérbole artística...
El número de movimientos corporales en el procedimiento anterior...
¡О ! Bien dicho.
Apoyo total.
La cantidad de esfuerzo corporal en el código de procedimiento anterior tendrá que ser mayor si hay que hacer cambios.
En principio, la cantidad de esfuerzo corporal en POO no puede ser menor, ya que todas estas interfaces son una sobrecarga adicional, que a menudo supera el coste de escribir la propia lógica. Y esto a pesar de que cualquier función ya tiene una interfaz, es decir, se propone hacer otra cobertura, que es esencialmente sin sentido.
Al mismo tiempo, cualquier cambio en el código, tanto en la interfaz como en la función, se vuelve mucho más complicado, ya que una está enganchada a la otra, lo que significa que tenemos al menos un aumento cuadrático en el posible número de errores y en la intensidad del trabajo... Es un poco obvio, ¿no?