Cuando, por así decirlo, caminé por Internet, noté una característica interesante. Todos los paradigmas de programación discutidos en otros lugares son percibidos por la gente con bastante calma. Si, por ejemplo, hablan de programación de procedimientos, lo hacen con absoluta calma. Lo mismo se trata de la programación modular. Programación declarativa: sin tormentas, disturbios ni holivarov. La programación funcional es la misma.
Y solo alrededor de la OOP no calmar las tormentas.
Algunos le gritan de alegría, otros, por el contrario, encuentran defectos en lo que se basa la luz. Y para ser honesto, es completamente incomprensible para mí por qué todo el mundo se unió en OOP.
Puede que hayas pensado que soy más un adversario que un defensor de la OOP. Este no es el caso (sin embargo, puedes entenderlo por el título). No Soy más bien un oponente de las balas de plata, la exageración, la entronización de una determinada metodología o persona, y todo tipo de bailes redondos. No maneja bailes alrededor, digamos, una llave inglesa o una cortadora de césped. Y no escriba, espero, publicaciones por las que un taladro o un martillo apestan.
Pero hoy en día todo Internet está repleto de artículos pomposos, hiperemotionales y radicales sobre OOP: si uno dice que OOP es "zer gut" y, en general, todo el intestino, entonces el otro necesariamente transmite que OOP debe tirarse a la basura con urgencia (aunque solo sea él no comparte los puntos de vista de la primera). No hay un tercero.
Solo quiero traer el tercer elemento. Es tranquilo, sin exageraciones y abusos, decir por qué la POO no es un elixir de todas las enfermedades, sino que también, como PP, AF o PL, tiene derecho a existir.
Entonces, un artículo tranquilo en defensa de la OOP. En él, trataré de considerar los principales argumentos de los oponentes de la OLP y justificar su fracaso.
1. Todo lo que existe en OOP ha estado en otros paradigmas.
Casi todos los lenguajes de programación están completos, con la excepción de los lenguajes de marcado, como HTML, XML, CSS, etc. Hablando en un idioma campesino, Turing es un idioma completo, un idioma en el que puede escribir absolutamente cualquier programa concebible. De esto se desprende una tesis bastante general: lo que está en cualquier idioma aleatorio elegido está en todos los demás idiomas. Lo mismo puede decirse de los paradigmas. Todas las diferencias en lenguajes (y paradigmas) son formas diferentes de implementar ciertos comandos, sin contar las características léxicas individuales.
Por cierto, esta misma tesis (todo lo que está en N, está en M, y en K, y en R, etc.) puede formularse de la siguiente manera: el martillo ya está hecho de hierro y madera, ¿por qué también necesitamos alicates? Pero nadie lo dirá.
2. OOP mezcla datos y acciones sobre ellos. Es malo
El argumento es sacado del dedo. Primero, ¿dónde combina OOP datos y funciones? En segundo lugar, la afirmación de que esto es malo también se toma de una linterna, de un barril "un hombre de verdad no hace eso", y por qué, debido al gladiolo. OOP de alguna manera modela el mundo real donde los datos son inherentes al objeto: nadie argumentará que a la silla le falta color y no tiene cuatro patas. Y aquí no se realiza ninguna mezcla de datos y operaciones, el objeto no es una función ni un operador.
Esto es una abstracción.3. La herencia esclaviza el programa, dificulta los cambios.
Aquí puedes frenar un poco. La herencia no implica en absoluto la construcción de árboles de un kilómetro de largo para frenar el desarrollo. La herencia se inventó para distinguir propiedades y métodos comunes en una superclase, y esto debe hacerse con clases que representan objetos del mismo tipo. Será un error crear, por ejemplo, dos clases, una de las cuales es la heredera de la otra, porque no hay asignación de un código común a una superclase simplemente porque
no hay nada en común .
Si no se pretende extender la clase padre a una tercera clase, dicha herencia simplemente no tiene sentido. Si está creando una licorería, entonces las clases de cerveza, vodka y vid se pueden heredar de la clase de alcohol, pero no es necesario que cree la clase de bebidas, a menos que quiera vender, por ejemplo, té paraguayo.
Además, será un error crear jerarquías en las que las clases no se relacionen entre sí. Bueno, ¿por qué, dime, hacer una torre donde las clases Fly y Cutlet se hereden de la superclase Cheese, que, a su vez, se hereda de la superclase el viernes? Pero esto ya no es un defecto de OOP, sino las manos torcidas de quien lo compone.
4. La encapsulación no tiene sentido
Aquí estoy parcialmente de acuerdo. Desde el punto de vista del programa, la encapsulación realmente no afecta nada. Si cierro la variable usando private, ¿y qué? Todavía puedo abrirla simplemente eliminando private y luego cambiar todo lo que me gusta.
Pero esto es cierto solo técnicamente. La filosofía OOP es que una clase adecuadamente organizada y encapsulada puede verse como una caja negra. Imagine una caja en un lado de la cual hay varios botones, ranuras para suministrar datos, y en el otro, una ranura de salida que devuelve información. Tome, por ejemplo, una pila. Imagine una caja en un lado de la cual hay una ranura para insertar datos y un botón al lado. En la parte posterior está el botón emergente. Envía una nota con el número 8 y presiona el botón. Luego le das otra hoja de papel y presionas push por segunda vez. Y entonces N veces, y luego presione pop. Un trozo de papel sale del cajón con el número 76 (u otro, en general, el que envió). ¿Necesitas otro número? Presione pop por segunda vez. Y así sucesivamente hasta la
conspiración de la
zanahoria hasta que la caja esté vacía. Y si continúa presionando pop, el mecanismo de la caja conquistará: ¡la pila está vacía! Así es exactamente como se ve el objeto.
Pero después de haber creado y configurado la clase, ya es violeta cómo funciona allí, simplemente funciona correctamente, pero no necesita desear más. Y encapsulando todas estas estructuras, no guarda todo en la memoria. Ellos (muchas cajas) simplemente se hablan entre sí de la forma en que lo configuran.
La encapsulación es una especie de muleta que soporta los cientos de pilares de su programa mientras está construyendo ciento primero. En proyectos grandes (es decir, para crearlos, se inventó OOP) sin esto, por desgracia, nada.
Aunque, apenas es "ay" generalmente apropiado aquí.
5. No existen jerarquías de relación en el mundo real, solo jerarquías de inclusión en todas partes
¿Es realmente así? Pero nadie se molesta en crear, por ejemplo, una jerarquía donde todos los ríos del mundo (Congo, Sena, Támesis, Amazonas, Kolyma, etc.) sean objetos de un "Río" integral, que tiene propiedades inherentes (por ejemplo, consiste en agua) y acciones (por ejemplo, flujos), y ya se heredará del "Estanque", que también consiste en agua, y del "Estanque" también puede heredar el "Lago", cuyos objetos serán lagos separados (Baikal, Mar Caspio, Titicaca, etc. .d.). El esquema es bastante rudo. Pero las jerarquías de relaciones también son una
abstracción . Algo a la idea platónica, si quieres. En el mundo real no están allí, existen solo en la mente, esto es una generalización, y nada más. Pero así es precisamente como una persona piensa muy a menudo. Podemos decir "calcetín" sin especificar de qué color es, de qué material está tejido, etc., pero ¿existe realmente este "calcetín"?
Sin embargo, no deberíamos avergonzarnos de que no haya un "objeto" o "calcetín".
6. La metodología OOP es inicialmente errónea
Un argumento absolutamente infundado. OOP fue creado para simular un tipo de mundo virtual que consiste en objetos, como nuestro mundo. Por ejemplo: una persona es un objeto del mundo real. Se puede caminar, correr, comer, dormir
a la mierda, jugar al fútbol, fútbol reloj, pero, por desgracia, yo estoy aquí, no puedo lista todo, y, francamente, toda la lista sería repugnante. Esta misma persona tiene las siguientes propiedades: presencia / ausencia de cabello, color del cabello, si lo hay, color de ojos,
si son del color de la piel, número de dedos, etc. Si construye correctamente todos los campos y métodos, como escribí anteriormente, el objeto del programa podrá modelar ciertas propiedades de un objeto real. Una persona piensa muy bien en tales categorías, es por eso que la POO se ha generalizado. Ayuda mucho al escribir proyectos grandes, ya que presenta modularidad y le permite dividir un paquete de software en componentes separados que interactúan entre sí.
7. Pero incluso millones de moscas no nos convencerán de que el estiércol es delicioso.
El argumento más popular contra OOP. Al igual, las masas son en su mayoría estúpidas (aunque no creo que esto se aplique también a los programadores), corren alrededor de la "ropa de moda" y las admiran.
Pero piénselo, y si no PLO, pero, digamos, LP, ¿había entrado en el pedestal? ¿Crees que sería diferente? ¡Nada de eso! Habría habido fanáticos y oponentes maliciosos, y habrían visto a la OLP como un instrumento (para esto, en realidad lo pido), y no como una píldora creada por Dios mismo y, por lo tanto, insustituible.
¿Por qué es este artículo en defensa de la OLP?
Toda la conversación moderna sobre paradigmas de programación, según lo veo, se reduce a dos premisas diametrales: dejaremos OOP y tiraremos el resto, o tiraremos OOP y ... bueno, me entiendes.
No quiero que un paradigma completamente adecuado sea considerado un basurero digno, pero no quiero un baile redondo, pero olvidé todo lo demás. Creo que el segundo es más fácil de hacer, pero este artículo está dirigido contra el primero.
Si no te gusta la POO
A quién - OOP, a quién - FP, a quién - PP. Y para alguien, quizás, en general, el cartílago de cerdo es sobre todo dulce. Si no te gustan los gatos, probablemente no sepas cómo cocinarlos.