S.O.L.I.D – Coisas que todo programador deveria saber

Esse post é mais um da série “Coisas que todo programador deveria saber” (talvez o primeiro do BytesDontBite [BdB] com esse título na verdade :P).

Hoje vou falar um pouco sobre o S.O.L.I.D, que é na verdade um acrônimo onde cada letra representa um “princípio” de design de orientação a objetos.  A importância desses princípios é imensa. Então vamos lá:

  • S (Single Resposability Principle) – Toda classe deve ter uma única responsabilidade, e essa responsabilidade deve ser completamente encapsulada por essa classe. Parece uma coisa simples, mas a grande maioria dos problemas que vejo por aí, acontecem pelo simples motivo de termos classes (e métodos) gigantes que fazem tudo o que você pode imaginar. Talvez esse seja, ao meu ver, o mais importante (e o mais simples) desses princípios. Obviamente ele é muito relacionado aos conceitos de (alta) coesão e (baixo) acoplamento, e também é bem descrito e detalhado pelos princípios do GRASP (tópico para o próximo post dessa série)

    Arquitetando…
  • O (Open/Closed Principle) – Todas as entidades do software (classes. módulos, métodos, …) deveriam ser abertas  (open) para extensão e fechadas (closed) para modificação. Isso significa que essas entidades do software tem que permitir uma mudança de comportamento sem a alteração do seu próprio código fonte. Em uma conclusão bem óbvia e simplista, estamos falando de usar mais interfaces e classes/métodos abstratos, que podem facilitar a mudança não dolorosa de comportamento de algumas entidades.
  • L (Liskov Substitution Principle) – Qualquer objeto do tipo X (que é subtipo Y) deveria poder substituir um objeto de tipo Y sem alterar as propriedades básicas do sistema (corretude, etc).
  • I (Interface Segregation Principle) – Prega que as interfaces tenham somente os métodos que serão usados por quem vai implementar essa interface. Ou seja, separar (segregar) interfaces que contenham muitos métodos, em interfaces menores, de forma que, quem implemente a interface, não seja forçado a implementar métodos que não são usados naquele contexto.
  • D (Dependency Inversion Principle) – Esse princípio prega uma forma de desacoplamento, aonde os módulos tem que depender de abstrações (leia-se interfaces) ao invés de depender de classes concretas. Isso se aplica principalmente quando falamos das dependências entre as camadas arquiteturais de um determinado sistema. Uma forma de inversão de dependência é a Injeção de dependência.

Como você pode notar, todos esses princípios meio que se completam de forma a atingir o objetivo que é um design flexível e de fácil manutenção. Espero que tenha sido útil, e até o próximo post dessa série, onde falaremos sobre o GRASP 😉

Anúncios

Copa do Mundo de Testes de Software

A copa do mundo está chegando! E em 2014 não há dúvidas que esse será um dos principais tópicos discutidos em todos os lugares e mídias. Mas não é esse o tema desse post, afinal esse não é um blog sobre futebol.

Fiquei sabendo nesse final de semana a respeito da Copa do Mundo de Testes de Software. Isso mesmo que você acabou de ler, em 2014 teremos uma competição para descobrir os melhores testadores do mundo.

Ainda não temos as informações completas sobre como o evento vai funcionar, abaixo destaco alguns dos pontos já divulgados na página oficial.

Quem pode participar?

Testadores de qualquer localidade, formando equipes de 2 a 5 pessoas.

Como irá funcionar?

A competição será realizada em 2 etapas:

  • Fase de Classificação: Conduzida online e por continente, onde apenas o time vencedor de cada continente estará classificado para a etapa final.
  • Etapa Final: Realizada durante o evento Agile Testing Days 2014.

O que será analisado? 

Os critérios de pontuação durante todas as etapas levarão diferentes aspectos em consideração, como: melhor bug report, melhor report de testes, bug mais valioso, etc.

O foco principal será o aspecto funcional de determinadas aplicações indicadas pelos avaliadores no início de cada etapa, podendo existir um tempo adicional alocado para aspectos não-funcionais.

Inscrições:

Na página do evento há um formulário com nome e e-mail para os interessados no evento.

##UPDATE##

Prêmios:

Premiação da competição já foi divulgada, e a equipe vencedora levará 3.000,00 EUR.

 

Com certeza parece uma boa oportunidade para praticar suas habilidades como analista de testes e conhecer outros profissionais da área. Já solicitei mais detalhes para a inscrição de minha equipe na página do evento, e você?