¿Por qué es malo el "acoplamiento estrecho entre funciones y datos"?

En teoría, el acoplamiento de datos y funciones suelto facilita agregar más funciones para trabajar con los mismos datos. La desventaja es que hace que sea más difícil cambiar la estructura de datos en sí misma, por lo que en la práctica, el código funcional bien diseñado y el código OOP bien diseñado tienen niveles de acoplamiento muy similares.

Tome un gráfico acíclico dirigido (DAG) como una estructura de datos de ejemplo. En la programación funcional, todavía necesita algo de abstracción para evitar que se repita, así que va a crear un módulo con funciones para agregar y eliminar nodos y bordes, encontrar nodos accesibles desde un nodo determinado, crear una clasificación topológica, etc. Esas funciones se acoplan de manera efectiva a los datos, aunque el compilador no los aplique. Puede agregar un nodo de la manera más difícil, pero ¿por qué querría hacerlo? La cohesión dentro de un módulo evita el acoplamiento apretado en todo el sistema.

A la inversa, en el lado de la programación orientada a objetos, cualquier otra función que no sea las operaciones básicas del DAG se realizará en clases de "vista" separadas, con el objeto DAG pasado como parámetro. Es tan fácil agregar tantas vistas como desee que operen en los datos del DAG, creando el mismo nivel de desacoplamiento de datos de función que encontraría en el programa funcional. El compilador no evitará que abarrotes todo en una clase, pero tus colegas lo harán.

Cambiar los paradigmas de programación no cambia las mejores prácticas de abstracción, cohesión y acoplamiento, solo cambia las prácticas que el compilador le ayuda a aplicar. En la programación funcional, cuando se desea un acoplamiento de datos de función, se hace cumplir por acuerdo de los caballeros en lugar del compilador. En la POO, la separación del modelo de vista se aplica mediante un acuerdo entre caballeros y no por el compilador.

En caso de que no lo supiera, tome esta información: Los conceptos de orientados a objetos y cierres son dos caras de la misma moneda. Dicho esto, ¿qué es un cierre? Toma variables o datos del ámbito circundante y se enlaza con ella dentro de la función, o desde una perspectiva OO, hace lo mismo cuando, por ejemplo, pasa algo a un constructor para que luego pueda usarlo. pieza de datos en una función miembro de esa instancia. Pero tomar las cosas desde el alcance del entorno no es algo bueno, ya que cuanto mayor sea el alcance del entorno, más mal es hacerlo (aunque de manera pragmática, a menudo es necesario algo del mal para hacer el trabajo). El uso de variables globales está llevando esto al extremo, donde las funciones de un programa están usando variables en el alcance del programa, lo que es realmente malo. Hay buenas descripciones sobre por qué las variables globales son malas.

Si sigues las técnicas de OO, básicamente ya aceptas que cada módulo de tu programa tendrá un nivel mínimo de maldad. Si adopta un enfoque funcional de la programación, apunta a un ideal donde ningún módulo de su programa contenga el mal de cierre, aunque es posible que tenga algunos, pero será mucho menos que OO.

Esa es la desventaja de OO: fomenta este tipo de mal, el acoplamiento de datos para funcionar a través de hacer cierres estándar (un tipo de Teoría de la ventana rota de la programación).

El único aspecto positivo es que, para empezar, si sabía que iba a utilizar muchos cierres, al menos OO le brinda un marco idealógico para ayudarlo a organizar ese enfoque de modo que el programador promedio pueda entenderlo. En particular, las variables que se cierran son explícitas en el constructor, en lugar de simplemente tomadas implícitamente en el cierre de una función. Los programas funcionales que usan muchos cierres suelen ser más crípticos que el programa OO equivalente, aunque no necesariamente menos elegantes :)

Se trata de tipo de acoplamiento:

Una función integrada en un objeto para trabajar en ese objeto no se puede usar en otros tipos de objetos.

En Haskell, usted escribe funciones para trabajar contra el tipo clases , por lo que hay muchos tipos diferentes de objetos contra los que cualquier función puede funcionar, siempre que sea un tipo de la clase dada esa función funciona.

Las funciones independientes permiten el desacoplamiento que no obtiene cuando se enfoca en escribir sus funciones para que funcionen dentro del tipo A porque entonces no puede usarlas si no tiene una instancia del tipo A, aunque de lo contrario, la función podría ser lo suficientemente general para ser utilizada en una instancia de tipo B o en una instancia de tipo C.

En Java y en encarnaciones similares de OOP, los métodos de instancia (a diferencia de las funciones gratuitas o los métodos de extensión) no se pueden agregar desde otros módulos.

Esto se convierte más en una restricción cuando se consideran interfaces que solo pueden implementarse mediante los métodos de instancia. No puede definir una interfaz y una clase en diferentes módulos y luego usar el código de un tercer módulo para unirlos. Un enfoque más flexible, como las clases de tipos de Haskell, debería poder hacer eso.

La orientación a objetos se basa fundamentalmente en la abstracción de datos de procedimiento (o la abstracción de datos funcionales si elimina efectos secundarios que son un problema ortogonal). En cierto sentido, Lambda Cálculo es el lenguaje más antiguo y puro orientado a objetos, ya que solo proporciona la abstracción de datos funcionales (porque no tiene ninguna construcción aparte de las funciones).

Solo las operaciones de un objeto único pueden inspeccionar la representación de datos de ese objeto. Ni siquiera otros objetos del mismo tipo pueden hacer eso. (Esta es la principal diferencia entre la abstracción de datos orientada a objetos y los tipos de datos abstractos: con los ADT, los objetos del mismo tipo pueden inspeccionar la representación de datos de cada uno, solo se oculta la representación de objetos de otros . )

Lo que esto significa es que varios objetos del mismo tipo pueden tener diferentes representaciones de datos. Incluso el mismo objeto puede tener diferentes representaciones de datos en diferentes momentos. (Por ejemplo, en Scala, Map s y Set s cambian entre una matriz y un hash trie dependiendo del número de elementos porque para números muy pequeños, la búsqueda lineal en una matriz es más rápida que la búsqueda logarítmica en un árbol de búsqueda porque de los factores constantes muy pequeños.)

Desde el exterior de un objeto, no debería, no puede conocer su representación de datos. Ese es el opuesto del acoplamiento apretado.

El acoplamiento estrecho entre los datos y las funciones es malo porque quiere poder cambiar cada uno independientemente del otro y el acoplamiento apretado lo dificulta porque no puede cambiar uno sin conocer y posiblemente cambiar al otro.

Desea que se presenten diferentes datos a la función para que no requieran ningún cambio en la función y, de manera similar, desea poder realizar cambios en la función sin que sea necesario realizar ningún cambio en los datos en los que está operando para admitir dichos cambios.