GRASP – Coisas que todo programador deveria saber

the-thinkerEsse é o segundo post do BdB (Bytes don’t Bite) da série “Coisas que todo programador deveria saber”. Caso você tenha perdido o primeiro post, nele eu falei sobre os princípios de design de software chamado SOLID e você pode acessar esse post aqui (Não se preocupe pois a leitura do primeiro não é pre-requisito para esse post).

O foco do segundo post é sobre o GRASP, que é algo desconhecido para muita gente, mas é também muito importante. GRASP não é uma ferramenta, não é uma metodologia, não é um software, não é um plugin nem nada do tipo. De forma similar aos princípios do SOLID, o GRASP é um conjunto de conceitos que ajudam na hora de pensar no design do software, em como suas classes estarão estruturadas e relacionadas, onde cada operação vai ser implementada, etc.

Craig Larman escreveu no seu livro (mesmo livro onde ele descreve o GRASP), uma frase interessante:

“the critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology.”

Quando eu vi essa frase eu já me identifiquei, pois reflete o que eu penso também. UML não vale de nada se você não souber como estruturar (design/architecture) o seu sistema. Se você não sabe como fazer um design bem feito, UML vai se resumir a uma ferramenta de desenho, como o paintbrush. Isso só faz reforçar a importância de princípios e padrões como o SOLID e o GRASP.

Como disse antes o GRASP é um conjunto de princípios e padrões para design de software, e nesse post eu vou cobrir alguns desses princípios/padrões que acho relevantes. Então vamos lá:

  1. High Cohesion (Alta Coesão) e Low Coupling (Baixo Acoplamento): Esses 2 pontos merecem ser tratados juntos, pois estão sempre de mãos dadas. A idéia central aqui, é diminuir as dependências entre as classes, de forma que uma mudança em uma classe não afete muitas outras. E a melhor forma de fazer isso é separando as responsabilidades de cada classe, dessa forma aumentando a coesão. Quanto mais coisas não relecionadas uma classe faz, menos coesa essa classe é. O resultado de uma alta coesão e um baixo acoplamento é que suas classes e componentes vão ser mais reusáveis.
    (Esse ponto também está relacionado com um dos princípios do SOLID)
  2. Creator: Quem deve ser o responsável por criar uma instância de uma classe X? Essa pergunta as vezes pode parecer fácil, mas se você der uma resposta errada, você começa a ferir outros pontos importantes como o acoplamento e coesão discutidos no ponto anterior. Esse padrão lista algumas dicas para responder essa pergunta. Geralmente a classe Y responsável por instanciar objetos da classe X deve ser sob as seguintes condições (quanto mais melhor) : (i) Classe Y contém ou é composta por X (ii) Classe Y usa extensivamente classe X (iii) Classe Y possui todas as informações necessárias pra instanciar X (e aqui está um ótimo link para falarmos sobre o próximo ponto, que talvez seja um dos mais importantes na minha opinião).
  3. Information Expert: Como saber quais responsabilidades atribuir a quais classes? A resposta é simples, mas é preciso ter essa resposta sempre em mente se quiser definir o design de seu sistema de forma satisfatória e elegante. A resposta é: A responsabilidade de uma determinada operação, deve ser da classe que tem todas as informações necessárias para completar aquela operação. Se você tiver isso sempre em mente, fica fácil saber em qual classe você vai implementar determinado método, qual classe vai conter um determinado atributo, e qual classe vai ser responsável por instanciar uma outra classe (aqui está o link de volta para o ponto 2 “Creator”)
  4. Indirection: Esse princípio prega que, de forma a diminuir (ou evitar) o acoplamento entre duas entidades quaisquer, a melhor forma é atribuir essa responsabilidade a uma entidade intermediária. Alguns design patterns se baseiam nesse princípio, como por exemplo: Adapter, Bridge, Façade, Observer, etc.
  5. Controller: Uma aplicação clara do princípio de Indirection, é o Controller. De quem é a responsabilidade de diminuir (ou evitar) o acoplamento entre os dados (model) e sua representação (view)?? Resposta clara, Controller 🙂 Não quero explicar o que é um Controller, mas queria chegar nesse ponto só para ficar claro a relação dos padrões e como um ponto impacta e afeta os outros. No final estão todos conectados!

Esse foi o segundo capítulo da série “Coisas que todo programador deveria saber”. Se você gostou, e gostaria que essa série continuasse, deixe um comentário aqui ou compartilhe esse post com seus amigos que você sabe que acharia útil essa informação.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s