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?
Respuestas:
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:
La separación de preocupaciones le ayuda a obtener respuestas más positivas a estas preguntas.
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.
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.