Si tenía un colega que no entendía los beneficios de la Separación de preocupaciones o no los entendía lo suficiente como para aplicar de manera constante en su trabajo diario , ¿cómo se lo explicaría?
Comentarios
- Encontré algunos buenos ejemplos en Wikipedia: en.wikipedia.org/wiki/Separation_of_concerns
Responder
Imagina que tienes un programa que ha sido lanzado. Un cliente llega y se ofrece a pagarle por una mejora de una de sus funciones. 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:
- cuánto código tiene que cambiar
- qué tan fácil es hacer los cambios
- qué tan probable es que rompa las características existentes que están siendo utilizadas por otros clientes
- cuánto puede reutilizar su modelo / arquitectura existente
La separación de preocupaciones ayuda para obtener respuestas más positivas a estas preguntas.
- 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 . Lo que debería ser menos código para cambiar.
- 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 completamente o manipular el resto del programa. También debería ser más fácil averiguar qué código necesita cambiar.
- 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 funciones están mezcladas, puede cambiar el comportamiento de una por accidente mientras intenta cambiar otra.
- 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 la lógica de su dominio principal es independiente de la base de datos, entonces admitir una nueva base de datos debería ser tan fácil como cambiar una nueva implementación de la capa de persistencia.
Comentarios
- Me encanta que haya dado la respuesta firmemente anclada en la realidad financiera. Los gerentes no tienen excusa para ser descuidados e ignorar este concepto fundamental.
Responder
Mire un hospital y Piense en todos los diferentes roles involucrados 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.
Responder
Si él / ella trabaja en una oficina, tómelo como ejemplo, explique el papel de cada miembro del personal en esa oficina y pregúntele, ¿qué pasaría si ese personal no estuviera dividido según sus trabajos? >
Respuesta
Me gustaría ver cómo no aplicó SoC en su código / diseño y convertirlo en un ejemplo del mundo real con el que se pueda relacionar y eso es obviamente no deseado.
Por ejemplo, si tiene una clase en la que el cliente necesita proporcionar varias piezas de información que no son relevantes para esos clientes, entonces usaría la analogía de una panadería donde tienes traer sus propios cereales y levadura si quiere comprar un pan.
Respuesta
Un ejemplo podría ser un desarrollador html desea separar html, css y javascript en separa te archivos. De esta manera, puede cambiar la apariencia de algo, 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 los usuarios o el 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 consiste en 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 no debería afectar a otros componentes o módulos en la página que se ejecuta junto con los que no están relacionados. Aquí, los archivos css, js y html se fusionan en un solo componente que se puede probar unitariamente.Entonces, la separación de preocupaciones viene en forma de componentes atómicos individuales que pueden ser probados por unidades en lugar de 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 he recibido una respuesta negativa a este comentario, pensé en volver a visitarlo y tratar de calificar algunos de mis puntos de vista. Desafortunadamente, cualquier comentario aquí no es particularmente constructivo, pero vi una discusión interesante en otro lugar que analiza React, la tecnología actual de moda en el desarrollo web, un ejemplo del mundo real, y pregunta si rompe la separación de preocupaciones o, en particular, si rompe una de las los principios de la metodología de diseño de orientación de objetos SOLID 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 de 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 de lenguaje en lugar de separar las preocupaciones del marco, es decir, plantillas, css y javascript, etc.
Con respecto a separar sus preocupaciones en el lenguaje de su aplicación, esto podría implicar el uso de varios patrones para separar o desacoplar su código en forma modular eso puede ser probado por unidad, etc.
Entonces, para resumir, separar las preocupaciones puede depender de su rol o punto de vista, como se mencionó en otro lugar.
Comentarios
- esto no ‘ t parece ofrecer algo sustancial sobre los puntos hechos y explicados anteriormente 7 respuestas
- Solo estoy señalando que separar las preocupaciones puede tomar diferentes enfoques según el contexto. Esto está más cerca de una situación del mundo real en términos de ingeniería de software y estoy destacando que hay diferentes enfoques que puede tomar cuando se trabaja en páginas html que al principio pueden parecer contradictorios.