Entendendo a Separação de Conceitos (Separation of Concerns – SoC)

Quando eu cursava a pós-graduação, estudei uma disciplina que citava uma breve referência a um termo chamado Separation of Concerns (SoC), ou Separação de Conceitos. Como não era o foco do estudo, anotei o termo para que eu pudesse pesquisá-lo mais tarde com mais detalhes e adicionei-o na pauta de artigos. Agora é hora de esclarecer esse termo!

No desenvolvimento de software, podemos afirmar que Separação de Conceitos se refere a um princípio de projeto que permite a separação de um sistema em diferentes áreas, seções ou módulos. Estes conceitos, quando combinados, atingem um objetivo principal que, na maioria das vezes, é um software, uma página da Web ou um hardware. A Separação de Conceitos normalmente ocorre em softwares de grande porte ou em projetos que são desenvolvidos em mais de uma linguagem de programação.

É isso, pessoal! Até a próxima! 🙂

Acabou?

Claro que não! Partiremos, agora, para a apresentação de exemplos reais.

Programadores Web praticam a Separação de Conceitos indiretamente. Para construir uma página, diferentes linguagens são utilizadas, cada uma com um propósito em particular. Geralmente, para esses projetos, são utilizadas 4 linguagens: HTML, CSS, PHP e JavaScript, nas quais poderemos intitulá-las como agentes de “conceitos”. A primeira delas, HTML, é utilizada para estruturar e formatar o conteúdo de uma página, como a inserção de tabelas e marcação de seções (título, cabeçalho e corpo). A linguagem CSS, por sua vez, edita a apresentação do conteúdo gerado pela linguagem HTML, fornecendo estilos baseados em identificadores (id) e classes (class) dos componentes da página. O back-end (“retaguarda”) de uma página, responsável por manipular informações do banco de dados e executar operações de tratamento e envio de informações são feitas pela linguagem PHP. E, por fim, o JavaScript é empregado para executar scripts do lado do cliente, comportando-se de forma assíncrona para alterar a exibição do conteúdo sem comunicação com o servidor. O jQuery, por exemplo, fornece funções Ajax, que permitem a alteração de um componente da página sem a necessidade de recarregá-la.

E o desenvolvimento Desktop?

Softwares desktop também podem ser separados em conceitos ou módulos. Na verdade, essa separação é fortemente recomendável quando o software envolve uma complexidade muito alta e atende diferentes departamentos em uma única solução. Por exemplo, se um determinado software ERP possui os módulos contábil, financeiro, RH, custos, vendas e estoque de modo desacoplado, definimos o software como modularizado, já que é constituído de diferentes partes. Cada módulo pode ser alocado para uma equipe diferente de desenvolvimento, capacitada nas respectivas regras de negócio. Dessa forma, além de facilitar a manutenção, cada módulo poderá ser atualizado independentemente dos outros módulos. O Delphi, por exemplo, propicia a modularização do software através de arquivos BPL para simplificar a atualização.

Quando trabalhei no Data Center de um supermercado, acompanhei a atualização de um módulo do software piloto da empresa devido à uma exceção na tela de Contas a Pagar. Ao invés de atualizar todo o executável, apenas o arquivo BPL referente ao módulo financeiro foi substituído, dispensando até mesmo a reinicialização do sistema. Interessante, não é?

Caso queira saber mais sobre modularização no Delphi, procure por “delphi dynamic packages” no Google ou acesse este link da EDN. Quem sabe eu até adicione esse tema na pauta de artigos! 🙂

Na Programação Orientada a Objetos, a Separação de Conceitos é relacionada com a implementação de classes, herança e abstração. Em poucas palavras, podemos considerar que uma classe com todas as suas heranças (subclasses) representa um único conceito. Por exemplo, “TCliente”, “TVendedor” e “TFuncionario” herdam as mesmas características de “TPessoa”, já que compartilham da mesma abstração, ou, teoricamente, do mesmo conceito.

Agora acabou?

Não, tem mais! A Separação de Conceitos também é encontrada em padrões de arquitetura! O padrão MVC, por exemplo, separa a arquitetura do código em três camadas, cada uma com uma responsabilidade específica. Enquanto a View apresenta os dados para o usuário, a camada Model trata o processamento de dados (regras de negócio) e a camada Controller faz o intermédio entre ambas. Isso é uma Separação de Conceitos!

Observe que todos esses exemplos de separação acima visam a simplicidade, manutenção, e organização de diferentes seções para descomplicar as atividades de programação. Esse é principal objetivo desse princípio. Faça bom proveito dessa separação sempre que possível, amigos!

Agora, sim, o artigo acabou!

Grande abraço!

Publicado originalmente em Blog André Celestino

André Celestino

Mais artigos deste autor »

Desenvolvedor de software há 7 anos e autor do blog AndreCelestino.com. Graduado em Sistemas de Informação e pós-graduado em Engenharia e Arquitetura de Software com ênfase em Desenvolvimento Ágil. Atualmente trabalha como Engenheiro de Software.


4 Comentários

André Luis Celestino
2

Olá, Henrique, tudo certo?
A palavra “concern”, em inglês, se desdobra em várias traduções, como responsabilidade, preocupação, interesse, referência, entre outros. No âmbito do desenvolvimento de software, para evitar o emprego da tradução ao “pé da letra” (que causaria uma má interpretação ou, talvez, uma ambiguidade do termo), foi definida a tradução como “Separação de Conceitos”. Mesmo assim, não vejo problemas em se referir a este princípio como “Separação de Responsabilidades” também! 🙂
Abraço!

Bruno Felipe Leal Delfino
3

Olá André.
Ótimo texto, porém achei que encontraria algo novo. Tal termo pelo que pesquiso é mais difundido como Separação de Responsabilidades mesmo, como foi mencionado pelo Henrique quanto a tradução. Existe até um princípio da OO voltado para isso que é o “Single Responsibility Principle”.
Acredito também que seria interessante um artigo sobre os princípios SOLID da OO.

André Luis Celestino
4

Olá, Bruno!
Também tive a mesma percepção. Quando me deparei com o termo pela primeira vez, pensei que seria algo exclusivo, porém, é bem semelhante com outras definições que já conhecemos.
O SRP do SOLID preza pela responsabilidade única e, para alcançar esse princípio, é necessário realizar umas separações. Então, podemos afirmar que a Separação de Conceitos (divisão de classes, módulos, componentes, etc) propicia à Separação de Responsabilidades! Acredito que tudo isso caminha de mãos dadas.
Obrigado pelo comentário, Bruno!

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!