En informática , la separación de preocupaciones es un principio de diseño para separar un programa de computadora en distintas secciones. Cada sección aborda una preocupación separada , un conjunto de información que afecta el código de un programa de computadora. Una preocupación puede ser tan general como "los detalles del hardware de una aplicación" o tan específica como "el nombre de qué clase crear una instancia ". Un programa que incorpora bien SoC se denomina programa modular [1] . La modularidad, y por tanto la separación de preocupaciones, se logra encapsulando información dentro de una sección de código que tiene una interfaz bien definida. La encapsulación es un medio para ocultar información . [2] Los diseños en capas en los sistemas de información son otra realización de la separación de preocupaciones (por ejemplo, capa de presentación, capa de lógica de negocios, capa de acceso a datos, capa de persistencia). [3]
La separación de preocupaciones da como resultado más grados de libertad para algún aspecto del diseño, implementación o uso del programa. Entre ellos es común 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, reutilización y 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 de actualizar un sistema complejo de forma gradual sin pérdida temporal de funcionalidad. [ cita necesaria ]
La separación de preocupaciones es una forma de abstracción . Como ocurre con la mayoría de las abstracciones, separar preocupaciones significa agregar interfaces de código adicionales, lo que generalmente crea más código para ejecutar. El código adicional puede generar costos de cálculo más altos en algunos casos, pero en otros también puede llevar a la reutilización de código más optimizado. Entonces, a pesar de los muchos beneficios de preocupaciones bien separadas, puede haber una penalización de ejecución asociada, aunque con el potente hardware actual esa penalización puede ser insignificante en la mayoría de los casos prácticos. [ cita necesaria ]
Los mecanismos de 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 de procedimientos 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 un principio de diseño importante también en muchas otras áreas, como la planificación urbana , la arquitectura y el diseño de la 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.
Los ejemplos comunes incluyen separar 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 encapsulación, donde la información dentro de una habitación, como por ejemplo qué tan desordenada 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 a cada módulo no le preocupa lo que sucede en el otro.
El término separación de preocupaciones probablemente fue acuñado por Edsger W. Dijkstra en su artículo de 1974 "Sobre el papel del pensamiento científico". [6]
Permítanme intentar explicarles lo que, a mi gusto, es característico de todo pensamiento inteligente. Es decir, que uno está dispuesto a estudiar en profundidad un aspecto de su tema de forma aislada en aras de su propia coherencia, sabiendo todo el tiempo 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. En otro estado de ánimo podemos preguntarnos si el programa es deseable y, en caso afirmativo, por qué. Pero no se gana nada (¡al contrario!) abordando estos diversos aspectos simultáneamente. Es lo que a veces he llamado "la separación de preocupaciones", que, aunque no sea perfectamente posible, es todavía la única técnica disponible, que yo sepa, para ordenar eficazmente los propios pensamientos. Esto es lo que quiero decir con "centrar la atención en algún aspecto": no significa ignorar los otros aspectos, sino 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 única y múltiple simultáneamente.
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 Elementos de programación funcional [7] que describe la separación de preocupaciones:
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,
Idealmente, el programador debería poder concentrarse en la primera de las tres tareas (describir lo que se va a calcular) sin distraerse con las otras dos tareas, más administrativas. Claramente, la administración es importante, pero al separarla de la tarea principal es probable que obtengamos resultados más confiables y podemos aliviar el problema de programación al automatizar 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 la memoria están ausentes del programa. Además, las descripciones de lo que se va a calcular deben estar libres de descripciones detalladas paso a paso de cómo hacerlo, si se van a evaluar con diferentes arquitecturas de máquina. Las secuencias de pequeños cambios en un objeto de datos almacenado en un almacén pueden ser una descripción inapropiada 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 ocuparse de ellos, pero tiene muchas más oportunidades de hacer uso de mecanismos de cálculo muy diferentes con diferentes arquitecturas de máquina.
La separación de preocupaciones es crucial para el diseño de Internet. En Internet Protocol Suite , 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 preocupa por todos los detalles de realizar una sesión de correo electrónico a través de un servicio de transporte confiable (generalmente TCP ), pero no se preocupa en lo más mínimo por cómo el servicio de transporte hace que ese servicio sea confiable. De manera similar, TCP no se preocupa por el enrutamiento de paquetes de datos, que se maneja 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 organizar el contenido de la página web, CSS se utiliza para definir el estilo de presentación del contenido y JS define cómo el contenido interactúa y se comporta con el usuario. Históricamente, este no fue el caso: antes de la introducción de CSS, HTML cumplía ambas funciones: definir la semántica y el estilo.
La programación orientada a temas permite abordar inquietudes separadas como construcciones de software separadas, cada una en pie de igualdad con las demás. Cada preocupación proporciona su propia estructura de clases en la que se organizan los objetos en común, y contribuye con estados y métodos al resultado compuesto donde se cruzan unos con otros. Las reglas de correspondencia describen cómo las clases y los métodos de las diversas preocupaciones se relacionan entre sí en los puntos donde interactúan, permitiendo que el comportamiento compuesto de un método se derive de varias preocupaciones. La separación multidimensional de preocupaciones permite manipular el análisis y la composición de las preocupaciones como una "matriz" multidimensional en la que cada preocupación proporciona una dimensión en la que se enumeran diferentes puntos de elección, con las celdas de la matriz ocupadas por las personas apropiadas. artefactos de software.
La programación orientada a aspectos permite abordar las preocupaciones transversales como preocupaciones primarias. 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 los objetivos comerciales. Sin embargo, al diseñar un programa, su seguridad debe integrarse en el diseño desde el principio en lugar de tratarse como una preocupación secundaria. La aplicación posterior de la seguridad suele dar lugar a un modelo de seguridad insuficiente que deja demasiadas lagunas para futuros ataques. Esto se puede resolver con programación orientada a aspectos. Por ejemplo, se puede escribir un aspecto para exigir 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 ciencia cognitiva e inteligencia artificial , es común referirse a los niveles de análisis de David Marr . En cualquier momento dado, un investigador puede centrarse en (1) qué aspecto de la inteligencia necesita calcular, (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 interfaz /implementación en ingeniería de software y hardware.
En los sistemas normalizados, la separación de preocupaciones es uno de los cuatro principios rectores. Adherirse 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 mantiene. En los sistemas normalizados, las herramientas apoyan activamente la separación de preocupaciones.
La separación de preocupaciones se puede implementar y hacer cumplir a través de clases parciales . [9]
clase Oso def cazar bosque . seleccione ( & :comida? ) fin fin class Bear definitivamente come ( comida ) levanta " #{ comida } no es comestible!" a menos que sea comida . ¿responder a? : alimento con valor_nutricional . valor_nutricional fin fin clase Bear attr_accessor : hambre def monitor_hunger si hambre > 50 comida = cazar hambre - = comer ( comida ) fin fin fin