En informática , la separación de intereses (a veces abreviada como SoC ) es un principio de diseño para separar un programa informático en secciones distintas. Cada sección aborda un interés independiente , un conjunto de información que afecta al código de un programa informático. Un interés puede ser tan general como "los detalles del hardware para una aplicación", o tan específico como "el nombre de la clase a instanciar ". Un programa que incorpora bien el SoC se denomina programa modular [1] . La modularidad, y por lo tanto la separación de intereses, se logra encapsulando la información dentro de una sección de código que tiene una interfaz bien definida. La encapsulación es un medio de ocultar información . [2] Los diseños en capas en los sistemas de información son otra forma de realización de la separación de intereses (por ejemplo, capa de presentación, capa de lógica empresarial, capa de acceso a datos, capa de persistencia). [3]
La separación de las preocupaciones da como resultado más grados de libertad para algunos aspectos del diseño, la implementación o el uso del programa. Una de ellas es una mayor libertad para la simplificación y el mantenimiento del código. Cuando las preocupaciones están bien separadas, hay más oportunidades para la actualización, la reutilización y el desarrollo independiente de los módulos. Ocultar los detalles de implementación de los módulos detrás de una interfaz permite mejorar o modificar una sección de código de una sola preocupación sin tener que conocer los detalles de otras secciones y sin tener que realizar los cambios correspondientes en esas otras secciones. Los módulos también pueden exponer diferentes versiones de una interfaz, lo que aumenta la libertad para actualizar un sistema complejo de manera gradual sin pérdida intermedia de funcionalidad. [ cita requerida ]
La separación de intereses es una forma de abstracción . Como ocurre con la mayoría de las abstracciones, separar intereses significa agregar interfaces de código adicionales, lo que generalmente crea más código para ejecutar. El código adicional puede generar costos computacionales más altos en algunos casos, pero en otros casos también puede llevar a la reutilización de código más optimizado. Por lo tanto, a pesar de los muchos beneficios de tener intereses bien separados, puede haber una penalización de ejecución asociada. [ cita requerida ]
Los mecanismos para la programación modular u orientada a objetos que proporciona un lenguaje de programación son mecanismos que permiten a los desarrolladores proporcionar SoC. [4] Por ejemplo, los lenguajes de programación orientados a objetos como C# , C++ , Delphi y Java pueden separar las preocupaciones en objetos , y los patrones de diseño arquitectónico como MVC o MVP pueden separar la presentación y el procesamiento de datos (modelo) del contenido . El diseño orientado a servicios puede separar las preocupaciones en servicios . Los lenguajes de programación procedimental como C y Pascal pueden separar las preocupaciones en procedimientos o funciones . Los lenguajes de programación orientados a aspectos pueden separar las preocupaciones en aspectos y objetos .
La separación de preocupaciones es también un principio de diseño importante en muchas otras áreas, como la planificación urbana , la arquitectura y el diseño de información . [5] El objetivo es comprender, diseñar y gestionar de forma más eficaz sistemas interdependientes complejos, de modo que las funciones puedan reutilizarse, optimizarse independientemente de otras funciones y aislarse del posible fallo de otras funciones.
Algunos ejemplos comunes incluyen la separación de un espacio en habitaciones, de modo que la actividad en una habitación no afecte a las personas en otras habitaciones, y mantener la estufa en un circuito y las luces en otro, de modo que la sobrecarga de la estufa no apague las luces. El ejemplo con habitaciones muestra la encapsulación, donde la información dentro de una habitación, como lo desordenada que está, no está disponible para las otras habitaciones, excepto a través de la interfaz, que es la puerta. El ejemplo con circuitos demuestra que la actividad dentro de un módulo, que es un circuito con consumidores de electricidad conectados, no afecta la actividad en un módulo diferente, por lo que cada módulo no se preocupa por lo que sucede en el otro.
El término separación de intereses fue probablemente acuñado por Edsger W. Dijkstra en su artículo de 1974 "Sobre el papel del pensamiento científico". [6]
Permítanme tratar de explicarles lo que, a mi entender, es característico de todo pensamiento inteligente: que uno esté dispuesto a estudiar en profundidad un aspecto de su materia de estudio de forma aislada en aras de su propia coherencia, sabiendo en todo momento que se está ocupando sólo de uno de los aspectos. Sabemos que un programa debe ser correcto y sólo podemos estudiarlo desde ese punto de vista; también sabemos que debe ser eficiente y podemos estudiar su eficiencia otro día, por así decirlo. Desde otro punto de vista, podemos preguntarnos si el programa es deseable y, en caso afirmativo, por qué. Pero no se gana nada, ¡al contrario!, abordando simultáneamente estos diversos aspectos. Es lo que a veces he llamado "la separación de intereses", que, aunque no sea perfectamente posible, es sin embargo la única técnica disponible para ordenar eficazmente los pensamientos que conozco. Esto es lo que quiero decir con "centrar la atención en algún aspecto": no significa ignorar los otros aspectos, es simplemente hacer justicia al hecho de que, desde el punto de vista de este aspecto, el otro es irrelevante. Se trata de tener una mentalidad unidireccional y múltiple al mismo tiempo.
Quince años después, era evidente que el término separación de intereses se estaba convirtiendo en una idea aceptada. En 1989, Chris Reade escribió un libro titulado Elements of Functional Programming [7] que describe la separación de intereses:
El programador tiene que hacer varias cosas al mismo tiempo, a saber,
- describir lo que se va a calcular;
- organizar la secuencia de cálculo en pequeños pasos;
- Organizar la gestión de la memoria durante el cálculo.
Reade continúa diciendo:
Lo ideal sería que el programador pudiera concentrarse en la primera de las tres tareas (describir lo que se debe calcular) sin distraerse con las otras dos, más administrativas. Evidentemente, la administración es importante, pero al separarla de la tarea principal es probable que obtengamos resultados más fiables y podamos facilitar el problema de programación automatizando gran parte de la administración.
La separación de intereses también tiene otras ventajas. Por ejemplo, la prueba de programas se vuelve mucho más factible cuando los detalles de secuenciación y gestión de memoria están ausentes del programa. Además, las descripciones de lo que se debe calcular deben estar libres de descripciones detalladas paso a paso de cómo hacerlo, si se van a evaluar con diferentes arquitecturas de máquinas. Las secuencias de pequeños cambios en un objeto de datos almacenado en una memoria pueden ser una descripción inadecuada de cómo calcular algo cuando se utiliza una máquina altamente paralela con miles de procesadores distribuidos por toda la máquina e instalaciones de almacenamiento locales en lugar de globales.
Automatizar los aspectos administrativos significa que el implementador del lenguaje tiene que lidiar con ellos, pero tiene muchas más oportunidades de utilizar mecanismos de cálculo muy diferentes con diferentes arquitecturas de máquinas.
La separación de preocupaciones es crucial para el diseño de Internet. En el conjunto de protocolos de Internet , se han hecho grandes esfuerzos para separar las preocupaciones en capas bien definidas . Esto permite a los diseñadores de protocolos centrarse en las preocupaciones de una capa e ignorar las otras capas. El protocolo de capa de aplicación SMTP, por ejemplo, se ocupa de todos los detalles de la realización de una sesión de correo electrónico a través de un servicio de transporte fiable (normalmente TCP ), pero no se preocupa en lo más mínimo de cómo el servicio de transporte hace que ese servicio sea fiable. De forma similar, TCP no se ocupa del enrutamiento de paquetes de datos, que se gestiona en la capa de Internet .
El lenguaje de marcado de hipertexto (HTML), las hojas de estilo en cascada (CSS) y JavaScript (JS) son lenguajes complementarios que se utilizan en el desarrollo de páginas web y sitios web. HTML se utiliza principalmente para la organización del contenido de las páginas web, CSS se utiliza para definir el estilo de presentación del contenido y JS define cómo interactúa el contenido y se comporta con el usuario. Históricamente, este no era el caso: antes de la introducción de CSS, HTML cumplía las funciones de definir la semántica y el estilo.
La programación orientada a sujetos permite abordar cuestiones distintas como construcciones de software independientes, cada una en pie de igualdad con las demás. Cada cuestión proporciona su propia estructura de clases en la que se organizan los objetos en común y aporta estado y métodos al resultado compuesto en los puntos en los que se cruzan. Las reglas de correspondencia describen cómo se relacionan entre sí las clases y los métodos de las distintas cuestiones en los puntos en los que interactúan, lo que permite derivar un comportamiento compuesto para un método a partir de varias cuestiones. La separación multidimensional de las cuestiones permite manipular el análisis y la composición de las cuestiones como una "matriz" multidimensional en la que cada cuestión proporciona una dimensión en la que se enumeran diferentes puntos de elección, y las celdas de la matriz están ocupadas por los artefactos de software adecuados.
La programación orientada a aspectos permite abordar cuestiones transversales como preocupaciones principales. Por ejemplo, la mayoría de los programas requieren algún tipo de seguridad y registro . La seguridad y el registro suelen ser preocupaciones secundarias, mientras que la preocupación principal suele ser lograr objetivos comerciales. Sin embargo, al diseñar un programa, su seguridad debe incorporarse al diseño desde el principio en lugar de tratarse como una preocupación secundaria. Aplicar la seguridad después a menudo da como resultado un modelo de seguridad insuficiente que deja demasiados huecos para futuros ataques. Esto se puede resolver con la programación orientada a aspectos. Por ejemplo, se puede escribir un aspecto para hacer cumplir que las llamadas a una determinada API siempre se registren, o que los errores siempre se registren cuando se lanza una excepción, independientemente de si el código de procedimiento del programa maneja la excepción o la propaga. [8]
En el campo de la ciencia cognitiva y la inteligencia artificial , es habitual hacer referencia a los niveles de análisis de David Marr . En un momento dado, un investigador puede centrarse en (1) qué necesita calcular algún aspecto de la inteligencia, (2) qué algoritmo emplea o (3) cómo se implementa ese algoritmo en el hardware. Esta separación de preocupaciones es similar a la distinción entre interfaz e implementación en la ingeniería de software y hardware.
En los sistemas normalizados, la separación de preocupaciones es uno de los cuatro principios rectores. La adhesión a este principio es una de las herramientas que ayuda a reducir los efectos combinatorios que, con el tiempo, se introducen en el software que se está manteniendo. En los sistemas normalizados, la separación de preocupaciones cuenta con el apoyo activo de las herramientas.
La separación de preocupaciones se puede implementar y aplicar a través de clases parciales . [9]
clase Oso def cazar bosque . seleccionar ( & :comida? ) fin fin clase Oso def comer ( comida ) raise " #{ comida } no es comestible!" a menos que comida . respond_to? :valor_nutricional comida . valor_nutricional fin fin clase Oso attr_accessor :hambre def monitor_hambre si hambre > 50 comida = cazar hambre -= comer ( comida ) fin fin fin