Hablando de la OLP en el salón - página 19

[---]

Volchanski, y también puedes escribirte un tema de coro llamado "¿Necesitas goto?"

[Alexey Volchanskiy]

Andrei:
Verilog

Bueno, eso es un buen agarre que tienes ahí). Es para diseñar circuitos electrónicos.

[Alexey Volchanskiy]

o_o:

Volchansky, y escribe tú mismo otro tema de la algarabía "¿Necesitas goto?"

¿Estoy en lo cierto al suponer que tiene sentimientos negativos? ¿Por qué?

[fxsaber]

Комбинатор:

¿Qué diferencia hay?

Tienes que argumentar tu afirmación (OOP apesta) - ve a Google, escribe "OOP" y un par de cualidades negativas, coge un artículo y sin leerlo, lánzalo al foro.

Cierto o no, no importa. No importa si lo soy o no. Si hay personas atentas como tú que se molestan en leerlo y comprobarlo, podemos lanzar otro artículo en el mismo sentido.

Soy un principiante en POO, así que admito con alta probabilidad que no me he dado cuenta de alguna desventaja seria de la POO. Tomé este artículo como uno de los mejores porque me pareció un recurso de programación serio. Quizá no sea así, pero tampoco soy programador.

Como resultado, probablemente debería realizar un estudio sociológico (o psicológico) de por qué una parte de la sociedad (un individuo) desarrolla una aversión casi agresiva y persistente a ciertas cosas.

[Alexey Volchanskiy]

George Merts:

Bueno, a mí tampoco me gustan las chicas... Y muchos más... Lo normal, Alexey, es que sean animales, no todos consiguen entrenarlos, así que tendrás muchos envidiosos.

Pero será mejor que me digas: ¿dónde está tu curso? Yo también echaré un vistazo...

No lo necesitas, te lo envié en persona.

[TheXpert]

fxsaber:

Una seria desventaja de la POO es que algo complejo es difícil de diseñar, es decir, es muy difícil hacer una arquitectura que funcione bien y encaje sin muletas, por lo que la refactorización es muy, muy común. Cuanta menos experiencia tengas en el diseño, más infierno puedes hacer con él. La cuestión es que en la programación orientada a objetos la estructura de un modelo de objetos normalmente diseñado tiene a menudo poco en común con los objetos reales (tal como los imaginamos)

Entonces depende del apoyo de ciertos paradigmas por parte de ciertos lenguajes, para que podamos hablar de "bueno/malo", "aplicable/aplicable"

Por ejemplo, el gorila mencionado anteriormente con el plátano no es un problema de POO, es un problema de uso sin sentido de los gestores de paquetes sin seguimiento de las dependencias. Especialmente en la web hoy en día

[Koldun Zloy]

fxsaber:

¡El artículo miente!

Cuando leí esta afirmación, me entraron muchas dudas. Rápidamente le di la vuelta para comprobar que no estaba mal de la cabeza:

He destacado las líneas que el autor del artículo sugiere cambiar. El resultado no se ve afectado por su sustitución. No he leído el resto del artículo. Lo más probable es que se haya señalado este disparate del autor en los comentarios.

El artículo no miente. Hay funciones virtuales allí, así que todo funciona como dice el autor.

Pero espero que no lo tomes como un argumento serio contra la OOP.

Los cambios en una clase base pueden ser tan grandes como se quiera, y esperar que no afecten al trabajo de las clases derivadas es una tontería.

[fxsaber]

Koldun Zloy:

El artículo no miente. Hay funciones virtuales allí, así que todo funciona como el autor escribe.

Pero espero que no pienses que esto es un argumento serio contra la OOP.

Los cambios en la clase base pueden ser tan grandes como se quiera, y esperar que no afecten al trabajo de las clases derivadas es una tontería.

Si es virtual, tiene sentido y el autor es simplemente incompetente en los temas y desafíos de las funciones virtuales.

Además, si tenía que conseguir la independencia, debería haber hecho

virtual void Array::addAll( const int &elements[] )
{
  for (int i = 0; i < ArraySize(elements); i++)
//      this.a.add(elements[i]);
    Array:: add(elements[i]);
}

Pero el ejemplo me parece bueno para los principiantes. Tienes que entender lo que estás haciendo.

[fxsaber]

Комбинатор:

Una seria desventaja de la POO es que algo complejo es difícil de diseñar, es decir, es muy difícil hacer una arquitectura que funcione bien y encaje sin muletas, por lo que la refactorización es muy, muy común. Cuanta menos experiencia tengas en el diseño, más infierno puedes hacer con él. La cuestión es que en la programación orientada a objetos la estructura de un modelo de objetos normalmente diseñado tiene a menudo poco en común con los objetos reales (tal como los imaginamos)

Entonces, depende del apoyo de ciertos paradigmas por parte de ciertos lenguajes, para que podamos hablar de "bueno/malo", "aplicable/aplicable"

Por ejemplo, el gorila mencionado anteriormente con el plátano no es un problema de POO, es un problema de uso sin sentido de los gestores de paquetes sin seguimiento de las dependencias. Especialmente en la web hoy en día.

Sí, me he encontrado con algunas situaciones en las que la arquitectura estaba mal elegida. A veces era más fácil reescribir desde cero que editar.

En la codificación procedimental, casi siempre se puede crear la arquitectura de un programa mientras se escribe el código. Porque la libertad y la flexibilidad son totales, pero el riesgo es enorme.

En cambio, en la POO es aconsejable escribir toda la arquitectura en la pizarra ANTES de escribir la primera línea de código. Cuando esté listo, es muy fácil escribir el código. Y si la arquitectura tiene éxito (aquí sólo ayudan la experiencia y las habilidades individuales), es igual de fácil perfeccionarla/ampliarla, incluso si ya se ha olvidado todo el proyecto.

[Andrei01]

Alexey Volchanskiy:

Bueno, eso es un buen agarre que tienes ahí). Es para diseñar circuitos electrónicos.

Y no sólo eso.