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

Sugestão de Livro: Head First Design Patterns

Você não está sozinho! Em algum lugar do mundo, alguém reparou a dificuldade das pessoas em entender design patterns e decidiu facilitar a nossa vida. Essa(s) pessoa(s) resolveram escrever um livro sobre design patterns, e é dele que vou falar.

Estava eu em um avião, e iria encarar umas horas de viagem a alguns meses atrás. Felizmente ao meu lado estava @Tiago__Farias, e na sua mochila estava um livro chamado Head First Design Patterns. Conversamos um pouco e falamos sobre alguns livros, e foi quando ele me emprestou o livro para que desse uma lida no vôo. Como tinha interesse em conhecer design patterns, comecei a ler right away o livro naquele momento.

O primeiro capítulo desse livro é o mais genial de todos (ainda mais se você não conhecer a série Head First, pois será uma surpresa, como foi para mim). Você começa a ler o livro e ele vai falando de forma muito didática (ensinando para os burros, do jeitinho que eu gosto :P) a mágica de orientação a objeto desde o início, falando sobre princípios de design, utilização de interfaces, etc e BANG! Quando você se dá por conta ele já ensinou um design pattern e você nem sentiu! Isso anima a você continuar a ler e aprender o restante dos design patterns. Obviamente o livro pode servir como um livro de referência, mas os capítulos iniciais são leitura obrigatória ao meu ver.

Não precisa nem falar que depois dessa viagem que eu conheci o livro (que foi emprestado) eu comprei na hora o meu exemplar na amazon!

Para quem não conhece e se interessou aqui tem o capítulo 3 para download que descreve e explica brilhantemente o padrão Decorator.  Boa degustação!