Blog do Eduardo

Tecnologia, Inovação, Negócios e muito mais...

Separation of concerns - SoC

Princípios de Design de Software

  • 7 de Novembro de 2017 às 23:59
Capa Post
SoC

Introdução

Em Engenharia de Software, é indispensável entendermos o conceito de Separation of Concerns (SoC) ou em tradução livre mesmo, Separação de Conceitos. Podemos defini-lo como o ato de segmentar elementos e objetos dentro de um sistema de computacional. A ideia desse princípio é o de “dividir para conquistar”. Amplamente usado em inúmeras aplicações a fora, traz vários benefícios. Parece algo trivial, mas a grande complicação é como usar suas diferentes formas para a atingir os objetivos específicos como irei explicar mais adiante existem vantagens e desvantagens, ganhos e perdas no seu uso

O objetivo desse artigo é discutir a final o que é Separação de Conceitos, buscando elucidar seus princípios fundamentais. O porquê e como usá-lo, existem inúmeras vantagens e algumas “desvantagens”, porém mais relacionadas a sua própria estrutura, as desvantagens estão entre aspas nesse caso, pois dependem muito da finalidade da sua aplicação podendo atrapalhar ou não, mais adiante irei detalhar esses aspectos. Por fim, vamos esmiuçar suas diferentes formas explicando cada aspecto e finalizando com um exemplo para elucidar a ideia.  

O que é, e o que não é, o princípio Separação de Conceitos

Esse é um daqueles casos que se olharmos superficialmente parece um tema simples, fácil de definir. Porém quando olhamos novamente percebemos que só estamos vendo a "ponta do iceberg". Podemos definir com o “Ato de segmentar as rotinas de programação em contextos e funções definidos”. Esqueça aquela maravilhosa função faz-tudo ao mesmo tempo. Eu entenderia e inclusive acharia completamente normal, se você pensasse agora, “espere ai, mas as coisas não foram sempre assim? ”. Tenho que lhe informar que NÃO, as coisas não são triviais assim. Os primeiros a adotarem esse princípio, foi a linguagem ALGOL na sua versão 68-R, nos primeiros anos da década de 1970, consolidando assim o termo “Programação Modular”. Okay você deve estar pensando: "Mas é óbvio, isso também é da época do Pele...", então tavez eu mexa na ferida de alguns aqui, mas é por uma boa causa. Vamos falar mal da linguagem PHP (Sorry). Houve uma gigantesca evolução, mas tempos atrás PHP ainda não tinha suporte para Programação Orientada a Objetos (OOP) e até hoje é possível pegar alguns códigos bizarros.

Na própria filosofia do Unix é possível notar esse princípio difundido por Peter H. Salus no seu artigo, ”A Quarter-Century of Unix”:

“Escreva programas que façam apenas uma coisa e bem-feito”

Nas décadas seguintes esse conceito se ampliou mais ainda, encabeçado principalmente pelo surgimento do paradigma de programação Orientado a Objetos, amplamente adotado pelas populares linguagens C++ e Java.

Benefícios visíveis

                Um dos maiores benefícios do princípio podemos elucidar com a metáfora usado pelo Navy Seals dos EUA para trabalhar psicologicamente seus agentes de como lidar problemas muito grandes. A metéfora é “Como se come um Elefante? ”. Para você caro leitor: “Se tivesse que comer um elefante, como o faria?”. Se você pensou com garfo e facas ou assado, provavelmente você não pegou aqui o ponto que eu estou me referindo. A questão aqui não é forma, mas o sim modo. A resposta para essa questão é simples, mas não trivial: "Uma mordida de cada vez". Vamos fazer um outro exercício mental, por exemplo só o Kernel do Linux na sua versão 3.3 passa de 15 milhões de linhas de código, como você iria programar um sistema desse como mesmo propósito? Eu tenho a resposta: uma parte de cada vez. É realmente inimaginável ter que fazer um isso em programação estruturada e sem módulos. Não verdade creio que seja impossível.

Efeito Dominó

Já ouviu falar no termo “efeito domino”? Pois ele explica o porquê devemos separar as rotinas em contextos bem definidos. Com certeza caro leitor você já teve que lidar com um código que você mexia de um lado e estourava do outro. Não é raro isso acontecer. Isso acontece, pois os contextos não foram bem definidos. Não estou me referindo a dependências aqui e sim a aquele código macarrônico que não tem começo nem fim. O simples ato de definir bem os contextos e agrupa-los de forma correta já evitaria esse efeito indesejado.

Arquitetura em camadas

Existem uma forma de separação do conceito que provavelmente você já tenha visto, mas nem percebeu como a arquitetura foi pensada. Por exemplo o framework web Django utiliza middlewares para fazer a autenticação, validar a sessão e verificar CSRFToken e entre outras. Neste paradigma, cada camada depende a anterior, ou seja, e bem importante definir claramente onde começa e termina a função de cada rotina no sistema. A vantagem é de que em processos totalmente interdependentes é possível definir os limites e encapsular a complexidade. Desvantagem é que a aplicação fica presa a uma linha um fluxo de processos que dificultam a flexibilidade da aplicação.

 Exemplo de separação em camadas

Separação Vertical

Pode ser mais conhecida aos olhos do mercado como modularização, com certeza o conceito mais utilizado em um sistema. Neste paradigma contextos ficam bem definidos e não existe uma forte interdependência entre ambos, trazendo assim uma maior flexibilidade a aplicação.

 Exemplo de módulos

Embora a separação vertical separe um conjunto de preocupações com base na sua relevância para a realização total de um recurso específico dentro de uma aplicação, isso não impede o uso de outras estratégias de separação de contextos sejam combinados. Por exemplo, cada módulo pode ser projetado usando camadas para delinear o papel dos componentes dentro do módulo. Podemos ainda combinar o conceito de módulos e camada.

 Exemplo de combinação de módulos e camada

Conclusão

Neste artigo foram elucidados apenas dois tipos conceitos, porém em minha experiência são os mais importantes e usados mercado a fora. Problemas grandes podem ser melhor trabalhados com a simples uso desde paradigmas, por isso vale a pena antes de começar a “colocar a mão” em qualquer código, elaborar um mapa de segmentação de contextos da aplicação, evitando assim retrabalho e dor de cabeça no futuro.

Referências:

The Art of Separation of Concerns - 03/01/2008, por Derek Greer

 

 

Algoritmo Design de Software Programação
  • COMENTÁRIOS: 0 Seja o primeiro a comentar!

Você tem o permissão de:

Compartilhar: copiar e redistribuir o material em qualquer suporte ou formato.

Adaptar: remixar, transformar, e criar a partir do material para qualquer fim, mesmo que comercial.

Esta licença é aceitável para Trabalhos Culturais Livres. O licenciante não pode revogar estes direitos desde que você respeite os termos da licença.


Blog do Eduardo - Todos os direitos reservados © 2020 Licença Creative Commons