O documento discute anti-padrões no desenvolvimento de software, como a classe biblioteca que encapsula funções desnecessariamente e o uso de valores mágicos em vez de enums claros. Ele enfatiza a importância de identificar e catalogar anti-padrões para melhorar a qualidade do código.
2. Padrões de projeto
• Exemplificam boas idéias
• Dão nomes a estas idéias - facilitando a
comunicação
• “objeto que, quando muda, chama um callback
que outros objetos registraram para serem
notificados quando algo muda” x “um
observable”
• Servem de inspiração (evitando o que vem a seguir)
3.
4. Os anti-padrões
• Idéias ruins
• Implementações ruins
• Às vezes decorrem do “poder inexpressivo” da
linguagem
• Uma vez instalados
5.
6. A classe biblioteca
• Às vezes, tudo o que você quer são funções
simples
• Algumas linguagens não deixa(va)m você ter
funções simples
• Tende a se tornar infinitamente grande,
recebendo múltiplas implementações de
funções quase idênticas
7.
8. O verniz
• Encapsula outra coisa, sem acrescentar ou
modificar nenhum comportamento
• É um vício comum quando se programa em
torno de objetos persistentes
• Invariavelmente associado ao
9.
10. Controlador de uma coisa só
• É a classe que implementa os métodos que
deveriam estar na classe verniz
• Nunca poderia ser usada com uma outra classe
verniz porque os métodos (pelo menos alguns
deles) implementam comportamento específico
daquele tipo de entidade
• A classe verniz não pode (nem deve, porque
todas as regras estão no controlador) ser usada
sozinha
11.
12. Valores mágicos
• Um misto de referência externa e enum
• Às vezes é uma referência externa, em outras,
um enum