Como você explica Separação de Preocupações para outras pessoas?

Imagine que você tem um programa que foi lançado. Um cliente chega e se oferece para pagar por uma melhoria em um de seus recursos. Para receber o dinheiro, você precisará alterar seu programa para adicionar o novo recurso. Algumas das coisas que irão influenciar sua margem de lucro são:

1. quanto código você tem que mudar
2. quão fácil é fazer as mudanças
3. a probabilidade de você quebrar recursos existentes que estão sendo usados por outros clientes
4. o quanto você pode reutilizar seu modelo / arquitetura existente

A separação de interesses ajuda para obter respostas mais positivas a essas perguntas.

1. se todo o código para um comportamento específico do aplicativo for separado, você só terá que alterar o código diretamente associado ao seu novo recurso . O que deve ser menos código para mudar.
2. se os comportamentos em que você está interessado estão nitidamente separados do resto do aplicativo, é mais provável que você seja capaz de trocar por uma nova implementação sem ter que entender completamente ou manipular o resto do programa. Também deve ser mais fácil descobrir qual código você precisa alterar.
3. O código que você não precisa alterar tem menos probabilidade de quebrar do que o código que você altera. Portanto, dividir as preocupações ajuda a evitar a quebra de recursos não relacionados, evitando que você tenha que alterar o código que eles poderiam chamar. Se seus recursos estiverem misturados, você pode mudar o comportamento de um por acidente enquanto tenta mudar outro.
4. Se sua arquitetura for agnóstica em relação aos detalhes técnicos ou de lógica de negócios, é menos provável que as alterações na implementação exijam novos recursos arquitetônicos. Por exemplo, se sua lógica de domínio principal for agnóstica de banco de dados, o suporte a um novo banco de dados deve ser tão fácil quanto trocar em uma nova implementação da camada de persistência.

Comentários

• Adorei que você deu a resposta firmemente ancorada na realidade financeira. Os gerentes não têm desculpa para ser descuidados e ignorar este conceito fundamental.

Olhe para um hospital e pense em todas as diferentes funções envolvidas na prestação de cuidados a um paciente: enfermeiras de triagem, médicos, assistentes médicos, técnicos, equipe de escritório, refeitório, etc.

Há alguém que saiba todas essas pessoas realizam seus trabalhos? Não, porque seria opressor. Eles têm que separar as diferentes responsabilidades em funções distintas e os pontos de contato entre essas funções são muito específicos.

Se ele / ela trabalha em um escritório, tome isso como um exemplo, explique o papel de cada equipe naquele escritório e pergunte a ele, o que aconteceria se essas equipes não fossem divididas de acordo com suas funções?

Gostaria de ver como ele falhou em aplicar SoC em seu código / design e transformar isso em um exemplo do mundo real com o qual ele pode se relacionar e isso é obviamente indesejado.

Por exemplo, se ele tem uma aula em que o cliente precisa fornecer várias informações que não são relevantes para esses clientes, eu usaria a analogia de uma padaria onde você tem para trazer seus próprios grãos e fermento se você quiser comprar um pão.

Um exemplo pode ser um desenvolvedor de HTML pode deseja separar html, css e javascript em separa arquivos te. Desta forma, você pode alterar a aparência de algo dito simplesmente modificando o css ou o comportamento de algo alterando o arquivo javascript que é carregado separadamente. Se você tem um site responsivo ou adaptável, este paradigma funciona bem, pois você pode carregar diferentes css ou javascript dependendo da janela de visualização do usuário ou do agente do usuário. No entanto, se você modificar o html ou o modelo, é provável que o css ou o javascript não funcione. Essas preocupações separadas também podem ser dependentes.

Outra abordagem é agrupar todos os seus css javascript e html em um grupo de componentes ou módulos. Isso significa que você pode fazer alterações em um módulo e não deve afetar outros componentes ou módulos na página que ele executa e que não estão relacionados. Aqui, os arquivos css, js e html são mesclados em um único componente que pode ser testado na unidade.Portanto, a separação de interesses vem na forma de componentes atômicos individuais que podem ser testados em unidades, em vez da separação de marcação, estilo e elementos comportamentais. Essa segunda abordagem é mais adequada para criar aplicativos da web mais complexos.

editar. Visto que recebi uma resposta negativa a este comentário, pensei em revisitá-lo e tentar qualificar parte do meu pov. Infelizmente, qualquer feedback aqui não é particularmente construtivo, mas eu vi uma discussão interessante em outro lugar que olha para React, a tecnologia atual em desenvolvimento web, um exemplo do mundo real, e pergunta se quebra a separação de interesses ou, em particular, se quebra uma das os princípios da metodologia de projeto de orientação de objeto SOLID da Feather.

A perspectiva técnica do desenvolvedor 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. 

A perspectiva do designer 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. 

A perspectiva da equipe

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

Também na página há um link para uma apresentação interessante de Pete Hunt, do Facebook, onde ele fala sobre componentes, não modelos, e separa as preocupações no aplicativo de linguagem ao invés de separando as preocupações da estrutura, ou seja, modelos, css e javascript etc.

Com relação à separação das suas preocupações na linguagem do seu aplicativo, isso pode envolver o uso de vários padrões para separar ou desacoplar seu código em uma forma modular que podem ser testados em unidades, etc.

Então, para resumir, separar as preocupações pode depender de sua função ou ponto de vista, conforme mencionado em outro local.

Comentários

• isso não ‘ não parece oferecer nada de substancial em relação aos pontos feitos e explicados anteriormente 7 respostas
• Estou apenas apontando que separar as preocupações pode ter abordagens diferentes, dependendo do contexto. Isso está mais próximo de uma situação do mundo real em termos de engenharia de software e estou destacando que existem diferentes abordagens que você pode adotar ao trabalhar em páginas html que podem à primeira vista parecer contraditórias.