O design responsivo da web vai contra o princípio das separações de preocupações?

Pergunto-me como o design responsivo é compatível com o princípio Separações de Preocupação, no que diz respeito ao modo como estamos permitindo que uma única implementação se comporte para vários dispositivos de apresentação (dispositivos móveis, tablets, tamanhos de navegadores etc.). Está quebrando o princípio?

Se eu fizer alterações em uma página da Web que eu sei que está se comportando de maneira responsiva e deve funcionar em 5 dispositivos, por exemplo, não estou dificultando o desenvolvimento devido a uma possível regressão que pode ocorrer a partir de um único local no software?

É claro que isso me faz escrever menos código e trabalhar muito mais rápido em vários dispositivos, mas agora cada uma das minhas páginas requer testes potencialmente muito mais detalhados, que é o custo que eu poderia passar para não usar uma estrutura da web responsiva e manter implementações separadas de um página.

Como você está vendo a capacidade de resposta atualmente vai de encontro ao princípio da separação de preocupações. Sua pergunta pressupõe que a capacidade de resposta é uma responsabilidade única que pertence apenas a um componente.

Eu sugeriria que a capacidade de resposta é um atributo / responsabilidade que pode ser aplicada a vários componentes. Para o bem do meu exemplo, estou assumindo um MVC genérico | MVP Padrão de tipo MVVM.

O View certamente tem uma mão na capacidade de resposta do aplicativo. Os elementos da interface do usuário e a lógica que você usa determinam o desempenho da exibição. Portanto, o View é responsável pela capacidade de resposta dos elementos da interface do usuário.

O Controller também tem uma mão na capacidade de resposta do aplicativo. Os tipos de estruturas de dados e como a lógica de negócios é criada afetarão o desempenho. Então aqui, o controlador | Apresentador O ViewModel também é responsável pela capacidade de resposta. Mas essa responsabilidade é sobre elementos diferentes daqueles pelos quais a View é responsável.

Por fim, o Modelo é responsável pelas chamadas de acesso / serviço de dados. Existem considerações óbvias de desempenho sobre como os dados são recuperados e apresentados à camada intermediária. Mas, novamente, este é um elemento diferente que também deve ser responsivo.

Responsivenesscomo uma propriedade não é de responsabilidade única de nenhum componente. Todos os componentes devem ser responsáveis ​​por sua própria criação, a fim de contribuir para a aplicação geral. Uma excelente interface de usuário e controlador pode se tornar inútil por solicitações de dados aparentemente intermináveis.

No que diz respeito aos testes, o uso de uma abordagem em camadas ainda funciona a seu favor no que diz respeito ao esforço geral e à capacidade de resposta. Se você possui 5 dispositivos e escreveu camadas individuais para cada dispositivo, teria 15 componentes para testar. O uso do padrão MVC * permite remover 8 componentes dos testes, uma vez que você possui um Model and Controller comum. Se essas duas camadas executam sua parte do trabalho como responsivas, é necessário testá-las apenas uma vez. Você pode então concentrar seus esforços restantes nas 5 visualizações.

Eu não acho que isso viole a separação de preocupações, pois o CSS usa consultas de mídia para separar o estilo para um tamanho de tela específico. As consultas de mídia encapsulam o código para um tamanho de tela específico.

Penso que, em vez de pensar no design responsivo como trabalhando para um número X de dispositivos, o design responsivo deve ser considerado como funcionando para todos os tamanhos de tela. É a mesma página da web, apenas com o tamanho da tela.