¿La programación orientada a objetos que se cumpla la promesa de la reutilización de código?Qué alternativas existen para lograr la reutilización de código?

Question

Tal vez la mayor promesa de la utilización de paradigma orientado a objetos es la reutilización de código.Algunos disputa en que esto se logró.¿Por qué era (no) ha logrado?

¿Reutilización de código como la programación orientada a objetos define, hacer proyectos más productivos?

O más manejable?O más fácil de mantener?O con más calidad?

Probablemente todos estamos de acuerdo en que la reutilización de código es una buena cosa, pero hay varias formas de lograr este objetivo.La pregunta es sobre el método de reutilización de código ofrecidos por la programación orientada a objetos.Fue una buena cosa? Hay mejores métodos para lograr la reutilización de código de la orientación a objetos, sub-classing, polimorfismo, etc.?¿Qué formas son mejores? Por qué?

Cuéntanos tu experiencia con la programación orientada a objetos reutilización o de otros paradigmas de la reutilización.

Answer 1

La reutilización del código es una idea bastante buena. No es genial.

Tengo una perspectiva de aproximadamente 30 años de ingeniería de software, tratando de "reutilizar".

Comencé a investigar "reutilización de código" como un tema de investigación en los años 80, después de descubrir que había reutilizado el diseño de un sistema operativo que construí a principios de los 70, para otro sistema operativo que construí a fines de los 70.

La buena parte de la reutilización del código es la capacidad de reutilizar el código preexistente de honestidad a Dios. Pero el mundo es completo de código; ¿Cómo puede encontrar lo que quieres? Esto es lo que yo llamo el Reutilización de la maldición:

Soy Santa Claus (OK Open Source), y tengo una bolsa de mil millones de componentes de software. Puedes tener cualquiera de ellos.

Buena suerte eligiendo.

Para resolver bien el problema de reutilización:

• El reutilizador necesita especificar de alguna manera lo que necesita (funcionalidad, rendimiento, lenguaje de destino, supuestos del entorno, ...)
• Debe haber una biblioteca de código "reutilizable" que haya sido indexado de varias maneras por estos criterios potenciales
• Debe existir algún mecanismo para elegir elementos candidatos (a mil millones de elementos, no puede mirarlos a todos personalmente)
• Debe haber una forma de caracterizar cuán lejos de la especificación están los candidatos elegidos
• Debe existir algún proceso regular para permitir que el reutilización modifique el código reutilizable elegido (aquí está la mayor contribución de OOP: puede editar un componente/objeto existente anulando sus ranuras. OOP no proporciona ninguna otra ayuda).
• Todo esto debe ser claramente más barato que simplemente recodificarlo

Principalmente lo que se ha descubierto a lo largo de los años es que para que el código sea reutilizable, debe diseñarse para ese propósito, o contiene demasiados supuestos implícitos. Las bibliotecas de reutilización de código más exitosas han sido bastante pequeñas. Podría decirse que las bibliotecas y los marcos son código "reutilizable" y son extremadamente exitosos; Java y C# tienen éxito no porque sean bastante buenos lenguajes de computadora, sino porque tienen enormes bibliotecas bien diseñadas, implementadas y documentadas disponibles. Pero la gente no mira el código fuente en las bibliotecas; Simplemente llaman a una API bien documentada (diseñada para ser generalmente utilizable).

Lo que la reutilización del código no ha hecho (OOP tampoco) es proporcionar órdenes de mejora de magnitud en nuestra capacidad para codificar los sistemas.

Creo que la falla clave es que Cualquier tipo de reutilización de código es fundamentalmente limitado porque el código tiene demasiadas suposiciones incorporadas. Si hace el código pequeño, minimiza las suposiciones, pero el costo de construir desde cero no es muy grande y las ganancias de reutilización no son efectivas. Si hace que los fragmentos de código sean enormes, son bastante inútiles en un nuevo contexto. Al igual que Gulliver, están atados a la playa por un millón de hilos pequeños, y simplemente no puedes permitirte cortarlos a todos.

En lo que deberíamos estar trabajando es reutilización del conocimiento para construir código. Si podemos hacer esto, entonces podemos aplicar ese conocimiento para construir el código que necesitamos, manejando el conjunto actual de supuestos.

Para hacer esto, uno necesita la misma capacidad de especificación para caracterizar los componentes del software (¡aún tiene que decir lo que quiere!). Pero luego aplica este conocimiento de "construcción" a las especificaciones a generar el código que desea.

Como comunidad, todavía no somos muy buenos en esto. Pero la gente lo hace todo el tiempo; ¿Por qué no podemos automatizarlo? Hay mucha investigación, y esto muestra que se puede hacer en muchas circunstancias.

Una pieza clave de maquinaria necesaria para esto son las herramientas mecánicas para aceptar "descripciones de componentes" (estos son solo documentos formales y se pueden analizar como lenguajes de programación) y aplicar Transformaciones de programas a ellos.

Los compiladores ya hacen esto:-} Y son realmente buenos en la clase de problemas que abordan.

Los modelos UML con generación de código son un intento de hacer esto. No es un muy buen intento; Más o menos lo que uno dice en la mayoría de los modelos UML es "Tengo datos que se ven así". Bastante difícil generar un programa real si la funcionalidad se deja fuera.

Estoy tratando de construir Sistemas prácticos de transformación de programas, una herramienta llamada DMS. Se ha distraído bastante bien aplicando las transformaciones del programa no tanto para abstracto de las especificaciones para generar código, sino a un código heredado para limpiarlo. (¡Estos son el mismo problema en abstracto!). (Desarrollar tales herramientas lleva mucho tiempo; he estado haciendo esto durante 15 años y, mientras tanto, tienes que comer).

Pero DMS tiene las dos propiedades clave que describí anteriormente: la capacidad de procesar especificaciones formales arbitrarias y la capacidad de capturar el "conocimiento de la generación de códigos" como se transforma y aplicarlas a pedido. Y notablemente, generamos en algunos casos especiales, algún código bastante interesante a partir de especificaciones; DMS se construye en gran medida utilizándose para generar su implementación. Eso nos ha logrado al menos algunas de las promesas de reutilización (conocimiento): ganancias de productividad extremadamente significativas. Tengo un equipo de aproximadamente 7 personas técnicas; Probablemente hemos escrito 1-2 MSLOC de "especificaciones" para DMS, pero tenemos unos 10MSLOC de código generado.

Resumen: reutilización del conocimiento de la generación es la victoria, no reutilización del código.

Answer 2

La reutilización del código se logra en OOP, pero también se logra en la programación funcional. Cada vez que tome un bloque de código y lo haga llamar por el resto de su código de manera que pueda usar esta funcionalidad en otro lugar, la reutilización del código.

Este tipo de reutilización de código también hace que el código sea más manejable porque cambiar este bloqueo llamable cambia todos los lugares de los que se llama. Diría que este resultado también aumentó la calidad y la legibilidad.

No estoy seguro de que OOP simplemente esté allí para proporcionar la reutilización de código. Considero que OOP es más una forma de interactuar con los objetos y abstrae los detalles de la estructura de datos.

De Wikpedia:

La programación orientada a objetos tiene raíces que se pueden rastrear hasta la década de 1960. A medida que el hardware y el software se volvieron cada vez más complejos, la capacidad de administración a menudo se convirtió en una preocupación. Los investigadores estudiaron formas de mantener la calidad del software y desarrollaron la programación orientada a objetos en parte para abordar los problemas comunes al enfatizar fuertemente las unidades discretas y reutilizables de la lógica de programación [Cita necesaria]. La tecnología se centra en los datos en lugar de los procesos, con programas compuestos de módulos autosuficientes ("clases"), cada instancia de los cuales ("objetos") contiene toda la información necesaria para manipular su propia estructura de datos ("miembros"). Esto contrasta con la programación modular existente que había sido dominante durante muchos años que se centró en la función de un módulo, en lugar de específicamente los datos, pero que se proporcionan por igual para la reutilización de código y unidades reutilizables autosuficientes de la lógica de programación, permitiendo la colaboración de la colaboración mediante el uso de módulos vinculados (subrutinas). Este enfoque más convencional, que aún persiste, tiende a considerar los datos y el comportamiento por separado.

Answer 3

Si y no

La reutilización del código es un término todo para muchas actividades diferentes.

1. Reutilización de código dentro de un solo proyecto. OO es perfectamente adecuado para esto, una aplicación bien diseñada habrá mapeado las relaciones del mundo modelado de cerca, eliminando así el código duplicado tanto como sea posible y aconsejable. Sin embargo, puede argumentar que las tecnologías pre-OO podrían lograr lo mismo, lo cual es cierto, pero OO es en muchos sentidos más conveniente.
2. Bibliotecas de terceros Esto parece funcionar igualmente bien con o sin OO.
3. Reutilización de código cruzado La promesa de reutilización de código más grande de OO fue ese código, una vez escrito para una aplicación, más tarde se puede reutilizar para otra, para la que no había sido diseñado específicamente. Esto estaba de moda cuando la noción de OO se filtró a través de las puertas de las oficinas de gestión de mayor gestión, y OO no logró lograrla. Resultó que el propósito era un aspecto crucial del diseño OO (y posiblemente todo el código de procedimiento, pero esa es solo mi teoría) y los intentos de reutilizar el código finalizaron en los desastres de mantenimiento. (El conocido antipatrino de un antiguo marco que nadie se atreve a modificar y su amigo, el frameworks de frameworks ligeramente diferencial por la aplicación que generalmente surge de aquí).

Answer 4

Publicaría una respuesta larga, pero ¿por qué? Udi Dahan lo explica mucho mejor de lo que puedo.

http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

Aquí está el comienzo de la publicación:

Esta industria está preocupada por la reutilización.

Existe la creencia de que si acabamos de reutilizar más código, todo sería mejor.

Algunos incluso llegan a decir que todo el objetivo de la orientación de objetos era la reutilización: no lo fue, la encapsulación fue lo más importante. Después de esa orientación de componentes fue lo que se suponía que debía hacer que la reutilización ocurriera. Aparentemente, eso tampoco funcionó tan bien porque aquí estamos fijando nuestras reutilizaciones reutilizadas en la orientación del servicio.

Se han escrito libros completos de patrones sobre cómo lograr la reutilización con la orientación del día. Los servicios se han clasificado en todos los sentidos al tratar de lograr esto, desde servicios de entidad y servicios de actividad, a través de servicios de procesos y servicios de orquestación. La composición de los servicios ha sido promocionado como la clave para reutilizar y crear servicios reutilizables.

También podría dejarte entrar en el secreto sucio:

La reutilización es una falacia

Answer 5

Estoy de acuerdo con Chris, la programación funcional es una buena forma de reutilizar el código.

Muchos de los programas ha estructuras de código que se repite.Para esto patrones de diseño se utilizan en la programación orientada a objetos en el mundo, pero esto puede ser logrado por funciones recursivas y la coincidencia de patrón en lenguajes de programación funcional.Para más información sobre esto ver el primer capítulo en Mundo Real De Programación Funcional.

Creo que en lo profundo de la herencia en la programación orientada a objetos puede ser engañoso, en muchos de los casos.Usted tiene una clase y muchos de los estrechamente relacionados con los métodos son implementados en diferentes archivos.Como Joe Armstrong dijo acerca de la programación orientada a objetos:

El problema con lenguajes orientados a objetos es que tenemos todo esto implícita medio ambiente que llevan alrededor de ellos.Usted quería un plátano, pero lo que obtuve fue un gorila de la celebración de la banana y la selva entera.

De orden superior funciones también son muy útiles cuando se trata de la reutilización de código por ejemplo, map y foldr que es la fundación para Google MapReduce.

El paso de mensajes asíncrono también es una buena manera de organizar software complejo, y algunos de equipo de científicos del estado de que los objetos que se asumió para comunicarse con simpatia asincrónica como en el Digo, no pregunte La programación orientada a objetos principio.Ver más sobre esto en Programación Orientada A Objetos:El Camino Equivocado? fueron Joe Armstrong se citó:

Empecé a preguntarme acerca de lo que la programación orientada a objetos y pensé Erlang no estaba orientado a objetos, fue un lenguaje de programación funcional.Entonces, mi director de tesis dijo: "Pero usted está equivocado, Erlang es extremadamente orientado a objetos".Él dijo que los lenguajes orientados a objetos no orientado a objetos.Yo podría pensar, aunque no estoy muy seguro de si creo o no, pero Erlang podría ser el único lenguaje orientado a objetos porque los 3 principios de la programación orientada a objetos se basa en el paso de mensajes, que tiene aislamiento entre los objetos y los han polimorfismo.

El paso de mensajes asíncrono como en el caso de sistemas impulsados y en Erlang es también una muy buena manera de disociar los sistemas y acoplamiento flexible es importante en los sistemas complejos.Con una suficientemente desacoplado del sistema puede evolucionar el sistema mientras se está ejecutando, tal vez en diferentes nodos.Unibet hizo una gran presentación acerca de esto: Dominio Evento Impulsado Por La Arquitectura

Sin embargo, creo que la mayoría de la reutilización de código se realiza mediante el uso de librerías y frameworks.

Answer 6

La humilde Pipe Unix ha hecho más por la reutilización de código que cualquier otra cosa que haya ido y venido. Los objetos resultaron ser una forma intuitiva de estructurar el código cuando vinieron y luego las personas comenzaron a agregar cualquier cosa y todo lo que contiene. En general, los objetos son para la encapsulación y no para la reutilización del código, la reutilización del código requiere algo más y la jerarquía de herencia de clase es un sustituto deficiente de lo que realmente debería ser un mecanismo de reutilización de código.

Answer 7

OOP no es especial; Puede hacer un código reutilizable con o sin OOP. Las funciones puras son particularmente reutilizables: por ejemplo, java.lang.math.sqrt(double) toma un número y da un número. No OOP, pero definitivamente más reutilizable que la mayoría de los códigos que existen.

Answer 8

Desde una vista de programación funcional, OOP se trata principalmente de administrar el estado.

En la programación funcional, puede tener fácilmente cientos de funciones útiles para listas: http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/data-list.html.

¿Tendrías cientos de métodos en una clase de lista? Los métodos públicos se consideran una interfaz para el estado interno que desea mantener pequeño.

Lamentablemente, en lugar de (re) usando muchas funciones pequeñas, algunas personas duplican la funcionalidad. Para mi eso es porque oop no fomenta la reutilización del código Tanto como lo hace la programación funcional.

Answer 9

Para mí, sí, pero no todo el tiempo, y podría haberse hecho de otras maneras.

La mayoría de las veces creando una clase base abstracta y creando implementaciones concretas de esa clase.

Además, muchos marcos utilizan la herencia para proporcionar la reutilización de código (Delphi, Java, .NET son solo algunos que vienen a la mente al instante).

Eso no quiere decir que muchas bibliotecas de servicios públicos y fragmentos de código también no puedan haber hecho el trabajo, pero hay algo agradable en una jerarquía de objetos bien diseñada.

Answer 10

En mi experiencia, he tenido más éxito aprovechando el código "reutilizable" a través de instalaciones de programación genérica (como las plantillas C ++) de lo que he tenido utilizando principios OOP como las jerarquías de herencia.

Answer 11

OOP está demasiado abierto para una reutilización efectiva.

Hay demasiadas formas de reutilizar. Cada clase pública pregunta: "¡Haz una nueva instancia mía!", cada método público dice: "¡llámame!", cada método protegido produce: "¡Anuleme!" - y todas estas formas de reutilización son diferente, tienen diferentes parámetros, aparecen en un contexto diferente, todos tienen sus diferentes reglas, cómo llamar/extender/anularlo.

API es mejor, es un subconjunto estricto de puntos OOP (o no OPO), pero en la vida real, las API son sobrealimentadas y crecientes para siempre, todavía hay demasiados puntos de conexión. Además, una buena API puede facilitar la vida, es la mejor manera de proporcionar interfaz para OOP.

---

Paradigma de datadlow Proporciona una interfaz estricta para los componentes, tienen puertos de los siguientes tipos:

• consumidores (insumos) y
• productores (salidas).

Depende del dominio, hay algunos tipos de paquetes, por lo que los consumidores y los productores pueden conectarse, tienen los mismos puertos (o compatibles). La parte más bella de ella, que puede hacer visualmente, porque no hay parámetros ni ajustes en las conexiones, realmente solo conecta a un consumidor y un productor.

Estaba un poco poco claro, puedes echar un vistazo Etiqueta "Dataflow" en Stackoverflow, o Wikipedia "Programación de DataFow" o Wikipedia "Programación basada en el flujo".

(Además, he escrito un sistema de flujo de datos, en C ++. Por lo tanto, OOP y DF no son enemigos, DF es una forma de organización de nivel superior).

Answer 12

En común hay muchos medios para lograr la reutilización:

• tipificación dinámica, que su código sea genérico de forma predeterminada

• Abstracciones imperativas, es decir, subrutinas

• orientación de objetos, con herencia múltiple y envío múltiple

• sintaxis-abstracción, la capacidad de definir nuevas construcciones sintácticas o abreviar el código de placa de caldera

• Abstracciones funcionales, cierres y funciones de alto orden

Si intenta comparar la experiencia común con otros idiomas, verá que la característica principal que facilita la reutilización del código es la presencia de ambas cosas Abstracciones funcionales y orientadas a objetos. Son más complementarios que la alternativa: sin uno de ellos, estás obligado a reimplarar las características faltantes de una manera torpe. Vea, por ejemplo, las clases de functores utilizadas como cierres y coincidencia de patrones para obtener un envío de métodos no extensibles.

Answer 13

Realmente no hay tal cosa como "reutilizar" la forma en que las personas lo describen. La reutilización es un accidental propiedad de cualquier cosa. Es difícil planificarlo. Lo que la mayoría de la gente quiere decir cuando hablan de "reutilizar" es "usar". Es un término mucho menos atractivo y emocionante. Cuando usa una biblioteca, la está utilizando para lo que estaba destinada, normalmente. Usted está no Reutilizarlo a menos que estés haciendo algo realmente loco con eso.

En ese sentido, la reutilización en el mundo real se trata de reutilizar las cosas. Puedo reutilizar estos asientos aquí y reorganizarlos para que formen ... ¡una cama! No es una cama muy cómoda, pero puedo hacer eso. Ese no es su uso principal. Los estoy reutilizando fuera de su dominio original de aplicabilidad. [...] Mañana, volaré de regreso al Reino Unido. voy a no reutilizar el avión. Solo lo usaré para el propósito para el que estaba destinado, no hay nada elegante o emocionante en eso.

- Kevlin Henney

Answer 14

Voy a arriesgarme y confesar que solo he estado usando OOP muy recientemente. No me llega automáticamente. La mayor parte de mi experiencia implica bases de datos relacionales, por lo que creo que en tablas y uniones. Hay afirmaciones de que es mejor aprenderlo desde el principio, lo que evita tener que volver a cablear su pensamiento cuando se trata de programación. No tengo ese lujo y me niego a desechar mi carrera por la teoría de la torre de marfil. Como todo lo demás, lo resolveré.

Al principio pensé que todo el concepto no tenía sentido. Simplemente parecía innecesario y demasiados problemas. Lo sé, esta es una locura. Obviamente, se necesita un cierto nivel de comprensión antes de que pueda apreciar los beneficios de cualquier cosa o descartarlo para obtener mejores métodos.

La reutilización del código toma la voluntad de no repetir el código, una comprensión de cómo lograrlo, la planificación por adelantado. ¿Debería evitar reutilizar el código cuando haya decidido que tiene un caso en el que no vale la pena? Y ningún lenguaje es tan estrictamente OO que arrojará un error cuando cree que debería haber heredado el código de otra clase. En el mejor de los casos, proporcionan un entorno propicio para implementarlo.

Creo que el mayor beneficio de OOP es la aceptación general de cómo se debe organizar el código. Todo lo demás es salsa. Es posible que un equipo de programadores no esté completamente de acuerdo en cómo se deben estructurar todas las clases, pero deberían poder encontrar el código.

He visto suficiente código de procedimiento para saber que podría estar en cualquier lugar, y a veces está en todas partes.

Answer 15

Oop te da más formas de reutilizar el código. Eso es todo.

Answer 16

Reutilización horizontal: aspectos, rasgos, injertos

El oo clásico a veces se queda corto en la reutilización del código, especialmente cuando se vuelve loco por la falta de una mejor manera de compartir la funcionalidad real entre las clases. Para este problema, se han creado mecanismos de reutilización horizontal, como AOP, rasgos e injertos.

Programación Orientada a Aspectos

Considero a AOP como la mitad naranja que falta de OOP. AOP no es realmente tan conocido, pero ha llegado al código de producción.

Lo intentaré para explicar en términos simples: imagine que puede inyectar y filtrar la funcionalidad con una estructura especial llamada aspecto, estos aspectos tienen "métodos" que definen qué y cómo se verá afectado reflexión, pero en el momento de la compilación, este proceso se llama Costura.

Un ejemplo sería un aspecto que indica "para todos los métodos de ciertas clases que comienzan con Get, su programa escribirá en un archivo de registro los datos que se obtuvieron y el tiempo que se obtuvo".

Mira estas dos charlas si quieres entender mejor a AOP:

• Uso de la programación orientada a los aspectos para evitar ataques de aplicación 1/6
• Programación orientada a los aspectos: investigación radical en modularidad por Gregor Kiczales (El hombre principal detrás de AOP)

Rasgos e injertos

Rasgos son otra construcción para definir el código reutilizable que complementa la OOP, son similares a mezcla, pero más limpio.

En lugar de explicarlos, hay un gran PHP RFC que explica ambos. Los rasgos están llegando a PHP por cierto, ya están comprometidos a la troncal.

En resumen

OOP es clave en modularidad, aún así, en mi opinión y, como comúnmente, lo sabemos hoy OOP todavía está incompleto.

Answer 17

OOP proporciona un conjunto de herramientas útiles que le permiten escribir código que se puede usar en más lugares de los que podría tener sin esas herramientas. Si escribes un PrintIt función que toma cualquier objeto antiguo y llame .toString() En él, habrá reutilizado ese código tan pronto como lo llame con más de un tipo de objeto. Con estas herramientas, Cada línea de código hace más.

La programación funcional está muy caliente en este momento entre los hipsters. Te proporciona un entero separado Conjunto de herramientas para que cada línea de código haga más. Probablemente no sea mejor o funciona, pero proporciona otra herramienta en la caja de herramientas.

(Había una idea loca para un nivel adicional de reutilización orientada a objetos: la idea era que podíamos definir un solo Customer clase y úselo en cada aplicación que escribimos. Entonces las aplicaciones serían un poco de pegamento aquí y allá. Esto no funcionó. Pero eso no significa que el OO falló, o incluso esa reutilización falló. Los tipos básicos de reutilización de código dentro de las aplicaciones permitieron escribir aplicaciones que hicieron más y escribirlas más rápido).

Answer 18

Leyendo las publicaciones anteriores, algunos comentarios:

• Muchos piensan que la reutilización del código en OOP implica herencia. No estoy de acuerdo. Las interfaces y los contratos son el núcleo de la reutilización de código en los sistemas OOP. OOP es un intento de caja gris en la creación de una tecnología de componentes.
• La diferencia entre los "marcos" genéricos específicos y genéricos como sujeto de reutilización me considera demasiado abstracto. En mi opinión sobre las cosas, un componente (un contrato de interfaz conciso, mínimo y reutilizable y la implementación detrás) solo se puede hacer, si el problema que aborda se entiende bien. Un componente específico de dominio, que permite a los expertos en no dominio hacer su trabajo con menos conocimiento sobre el dominio es un (re) componente útil. Los usuarios necesitan comprender la interfaz, menos para las complejidades del dominio del problema.
• Niveles de reutilización a menudo olvidado: reutilización de la idea, reutilización de especificaciones, reutilización de arquitectura/diseño, reutilización de interfaz, reutilización de casos de prueba. La reutilización del código no siempre es favorable. Pero es un gran ahorro de tiempo a menudo para seguir una arquitectura específica para abordar un producto nuevo y similar.
• Los patrones de diseño de OOP (Gamma et. Al) a mis ojos elaboraron sobre las técnicas de implementación táctica en lugar de ser significativos en el contexto de la reutilización del código a mayor escala. Ayudan a escribir una aplicación con elementos OOP, pero no los vería como una solución a la pregunta de "reutilización del código" más allá de una sola aplicación.
• Tal vez no sea justo: 20 años de experiencia C/C ++/C# y 6 meses de programación funcional (F#). Un elemento importante de la reutilización habilitadora es: las personas deben encontrar fácilmente "la interfaz", estudiarla, comprenderlo y luego usarlo. La programación funcional pura no me facilita ver la estructura, los candidatos para la reutilización o dónde comienza todo y dónde termina todo. El "azúcar sintáctico" tan elogiado a menudo es la sal en mis ojos, evitando que vea fácilmente lo que sucede. Por lo tanto, es menos probable que trate de reutilizar un funcional (¿qué es-un montón de funciones?), Que pueden tener efectos secundarios ocultos que ni siquiera puedo ver (evaluación perezosa, mónadas, ...). No me malinterpreten, la programación funcional tiene lados muy geniales, pero todas las fortalezas proclamadas que veo con una buena duda. Tengo mucha curiosidad por saber qué trae el futuro poscuncional y espero verlo antes de retirarme;)
• La especificación, el diseño, la implementación son vistas acopladas, pero no fácilmente traversables sobre lo "mismo". Mucho más vital para una mayor productividad futura que un nuevo paradigma de programación es, para cerrar la brecha, aumentar (razonamiento automatizado, trazabilidad) los beneficios mutuos entre esas opiniones. Los lenguajes de especificación formalizados, las anotaciones de pruebas estandarizadas (por ejemplo, TTCN3) y los lenguajes de programación que respaldan la verificación de interfaces y contratos contra las especificaciones sin camarear de comentarios podrían ser lo que necesitamos con más urgencia.

Answer 19

El problema es más sutil en mi humilde opinión:

1. Oop es un Gran método para estructurar código con estado mutable. Al encapsular el estado en objetos, el código de estado imperativo se vuelve más comprensible porque, por ejemplo, si una pieza de estado se expresa como campos privados de una clase, usted sabe que Al menos esta pieza de estado en particular solo puede modificarse mediante métodos de esta clase. (Y puede romper fácilmente este beneficio abusando de la herencia, por cierto). Esto ahora es suficiente, pero Muy mejor que no tener ni siquiera esto.
2. El código con estado mutable es inherentemente difícil de reutilizar. Mucho más duro que el código utilizando estructuras de datos inmutables.

Asi que OOP en sí mismo no es malo por POV de hacer un código reutilizable, pero Los tipos de código que se escriben usando OOP son inherentemente difíciles de reutilizar.

También, programación funcional puede dar como resultado más código reutilizable. Pero obtener las abstracciones correcta para escribir un código funcional sano al cumplir con una fecha límite puede no ser factible. Y las abstracciones de "mitad derecha" serán más fáciles de expresar el estilo OOP. Y no tenderá a dar como resultado más fácil de reutilizar el código - Un mayor nivel de abstracciones significa que la comprensión del código requerirá una mayor inversión inicial de la capacidad cognitiva limitada de los programadores.

Como ejemplo práctico: El código de juego implica mucho estado mutable, porque esta es la forma natural de pensar en codificar un juego, a menos que sea muy rompecabezas/algorítmico, por lo que obviamente termina siendo estructurado usando OO. Y, por supuesto, es difícil reutilizar. Pero el mismo código, que contiene el mismo conocimiento, sería aún más difícil de reutilizar sin OOP. Y reescribirlo como un estilo funcional puede necesitar Cambiando totalmente la forma en que piensas sobre ese código, el conocimiento detrás de él. Sí, el resultado Conocimiento detrás del código Sería mucho más claro después de la reescritura de FP para reescribir a FP ... pero El costo podría ser enorme y podría ser El tipo de costo que también tendría que ser pagado por personas que deseen reutilizar el código increíblemente inteligente y bien abstracto con el que termina, tan paradójicamente, las personas terminarían no reutilizando el código, incluso si técnicamente es más reutilizable.

... que conduce a la última sutileza: la reutilización del código se trata de la Gente | Código interfaz, no solo sobre el código. OOP hace un trabajo decente al servir esta interfaz porque se mapea bien con cuántas personas piensan sobre muchos tipos de código escritos hoy en día. FP puede ser mejor para la reutilización del código, pero en mi humilde opinión Reutilizando fácilmente el tipo de código que las personas realmente necesitan escribir hoy en día. Esto cambiará como el tipo de código que necesitamos para escribir cambios.

PD y si alguien quiere decir que "OO no se trata de un estado mutable, también puede tener OO con estado inmutable" ... Yo llamo "FP usando clases como espacios de nombres". Es genial cuando funciona para usted y evita algunas deficiencias de los sistemas de módulos de algún lenguaje y puede dar lugar a un código más reutilizable. Pero eso no es oo;)