¿Cómo se explica la separación de preocupaciones a los demás?

Si tuviera un colega que no entendía los beneficios de la Separación de preocupaciones, o no lo entendía lo suficiente como para aplicarlo consistentemente en su trabajo diario, ¿cómo se lo explicaría?

Imagine que tiene un programa que se ha lanzado. Llega un cliente y le ofrece pagarle por una mejora de una de sus características. Para obtener el dinero, deberá cambiar su programa para agregar la nueva función. Algunas de las cosas que influirán en su margen de beneficio son:

1. cuánto código tienes que cambiar
2. qué fácil es hacer los cambios
3. qué tan probable es que rompa las funciones existentes que están siendo utilizadas por otros clientes
4. cuánto puede reutilizar su modelo / arquitectura existente

La separación de preocupaciones le ayuda a obtener respuestas más positivas a estas preguntas.

1. Si se separa todo el código para un comportamiento particular de la aplicación, solo tendrá que cambiar el código directamente asociado con su nueva función. Que debería ser menos código para cambiar.
2. Si los comportamientos que le interesan están claramente separados del resto de la aplicación, es más probable que pueda intercambiar una nueva implementación sin tener que comprender o manipular completamente el resto del programa. También debería ser más fácil averiguar qué código necesita cambiar.
3. El código que no tiene que cambiar es menos probable que se rompa que el código que sí cambia. Por lo tanto, dividir las preocupaciones lo ayuda a evitar la rotura de funciones no relacionadas al evitar que tenga que cambiar el código al que podrían llamar. Si sus características se mezclan, puede cambiar el comportamiento de una por accidente mientras intenta cambiar otra.
4. Si su arquitectura es independiente de los detalles técnicos o de la lógica empresarial, es menos probable que los cambios en la implementación requieran nuevas características arquitectónicas. Por ejemplo, si su lógica de dominio principal es independiente de la base de datos, entonces admitir una nueva base de datos debería ser tan fácil como intercambiar una nueva implementación de la capa de persistencia.

Mire un hospital y piense en todas las diferentes funciones que intervienen en la atención de un paciente: enfermeras de triaje, médicos, asistentes médicos, técnicos, personal administrativo, cafetería, etc.

¿Hay alguna persona que sepa cómo todas esas personas hacen su trabajo? No, porque sería abrumador. Tienen que separar las diferentes responsabilidades en roles distintos y los puntos de contacto entre esos roles son muy específicos.

Si él / ella trabaja en una oficina, tómelo como ejemplo, explique el papel de cada personal en esa oficina y pregúntele, ¿qué pasaría si ese personal no se divide de acuerdo con su trabajo?

Vería cómo no pudo aplicar SoC en su código / diseño y convertirlo en un ejemplo del mundo real con el que puede relacionarse y que obviamente no es deseado.

Por ejemplo, si tiene una clase en la que el cliente necesita proporcionar varios datos que no son relevantes para esos clientes, entonces usaría la analogía de una panadería en la que tiene que traer sus propios granos y levadura si desea comprar un pan.

Un ejemplo podría ser un desarrollador html que quiera separar html, css y javascript en archivos separados. De esta manera, puede cambiar la apariencia de algo que se dice simplemente modificando el CSS o el comportamiento de algo cambiando el archivo javascript que se carga por separado. Si tiene un sitio receptivo o adaptable, este paradigma funciona bien, ya que puede cargar diferentes CSS o JavaScript dependiendo de la ventana gráfica de un usuario o agente de usuario. Sin embargo, si modifica el html o la plantilla, es probable que css o javascript se rompan. Estas preocupaciones separadas también pueden ser dependientes.

Otro enfoque es agrupar todos sus css javascript y html en un grupo de componentes o módulos. Esto significa que puede realizar cambios en un módulo y que no debería afectar a otros componentes o módulos en la página que se ejecuta junto con otros que no están relacionados. Aquí los archivos css, js y html se fusionan en un solo componente que puede probarse de forma unitaria. Por lo tanto, la separación de las preocupaciones viene en forma de componentes atómicos individuales que pueden ser probados en unidades en lugar de la separación de elementos de marcado, estilo y comportamiento. Este segundo enfoque es más adecuado para crear aplicaciones web más complejas.

editar. Como recibí una respuesta negativa a este comentario, pensé en volver a visitarlo e intentar calificar algunos de mis puntos de vista. Desafortunadamente, cualquier comentario aquí no es particularmente constructivo, pero vi una discusión interesante en otra parte que analiza React, la tecnología actual en desarrollo web, un ejemplo del mundo real, y pregunta si rompe la separación de preocupaciones o, en particular, si rompe uno de Los principios de la metodología de diseño orientado a objetos SÓLIDOS de Feather.

La perspectiva técnica del desarrollador de JavaScript

NO, because JSX is a view language. That's one responsibility.
BUT, this implies that the JS developer is self-enforcing SoC/SRP on his own      architecture by not mixing ViewModel concerns in his JSX. This type of vigilance "in the wild" is highly suspect because JSX involves the full JavaScript dialect.

La perspectiva del diseñador UX / UI

YES, because JSX mixes Semantic Content (Model) with Behavior (Controller)
YES, because the intrusion, specifically of JavaScript, into the Semantic Model makes it difficult or impossible for me to play my role and leverage my expertese and skills.

La perspectiva del equipo

NO, if both...
Separate files are used for the View (JSX) and ViewModel (JS).
Either there aren't UI/UX/Designers involved, or they are productive working    directly with JSX (not very common).
YES, if either...
Everything is in the same file, causing problems for version control or productive use of modern editors.
Members of the team who are comfortable with HTML/CSS but less capable with JavaScript are excluded because of mixture or roles.

https://hashnode.com/post/does-react-really-violate-separation-of-concern-by-putting-html-and-js-in-a-single-file-cil3bn5hj0011a65347rsdut0

También en la página hay un enlace a una presentación interesante de Pete Hunt, de Facebook, donde habla sobre componentes, no plantillas, y separa las preocupaciones en la aplicación del lenguaje en lugar de las preocupaciones del marco, es decir, plantillas, CSS y JavaScript. etc.

Con respecto a la separación de sus inquietudes en el idioma de su aplicación, esto podría implicar el uso de varios patrones para separar o desacoplar su código en forma modular que se pueda probar en la unidad, etc.

Para resumir, separar las preocupaciones puede depender de su rol o punto de vista, como se mencionó en otro lugar.