O documento apresenta um conjunto de dicas de 'object calisthenics' para melhorar o design de código, incluindo regras que visam aumentar a manutenção, legibilidade, testabilidade e compreensão do código. As diretrizes incluem manter um nível de indentação por método, não usar 'else', encapsular tipos primitivos, e manter funções/entidades pequenas. Referências a práticas como SOLID e design patterns são fornecidas para suporte adicional.

1. Object Calisthenics
Conjunto de dicas para melhorar o seu design de código

2. O porquê
Seu primeiro dia em um projeto novo, uma calculadora de salários !
Objetivo:
- integrar com um sistema legado, dando manutenção nele se
necessário
- garantir que tudo está ok e bem testado

3. O porquê

4. O porquê

5. O porquê

6. O porquê
● Difícil de entender

7. O porquê
● Difícil de entender
● Testar

8. O porquê
● Difícil de entender
● Testar
● Dar manutenção

9. O porquê
● Difícil de entender
● Testar
● Dar manutenção

10. O porquê
● Difícil de entender
● Testar
● Dar manutenção

11. "Programe como se a pessoa que for dar
manutenção do seu código fosse um psicopata
violento que sabe onde você vive."
Anônimo

12. Object Calisthenics
Um conjunto de exercícios de programação
descritos por Jeff Bay, formalizado em 9 regras
Visam melhorar o código em 4 pontos:
● Manutenção
● Leitura
● Testabilidade
● Compreensão

13. Ou expandindo...
1. Coesão
2. Baixo acoplamento
3. Sem redundância
4. Encapsulamento
5. Testabilidade
6. Legibilidade
7. Foco

14. Quais são as regras?
1. Um nível de indentação por
método
2. Não usar else
3. Encapsular tipos primitivos
4. Encapsular coleções em classes
5. Um ponto por linha
6. Evitar abreviações
7. Manter as entidades pequenas
8. Não ter mais de duas variáveis de
instância por classe
9. Não usar getters / setters

15. Mas antes...

16. Um nível de indentação por método
Camadas de indentação
X
Leitura

17. Um nível de indentação por método
Camadas de indentação
X
Leitura

18. Um nível de indentação por método
Camadas de indentação
X
Leitura

19. Um nível de indentação por método
#callback hell
Código extraído de http://callbackhell.com/

20. Um nível de indentação por método
#callback hell
Código extraído de http://callbackhell.com/

21. Um nível de indentação por método
#callback hell
Código extraído de http://callbackhell.com/

22. Não usar else
Repete o mesmo problema de legibilidade da última regra
Aumenta o fator de ramificação do código (aumentando a
complexidade dos testes)

23. Não usar else

24. Não usar else

25. Não usar else

26. Não usar else

27. Não usar else

28. Encapsular tipos primitivos
● Alguns tipos podem ter comportamentos que valem a pena ser
capturados
● Value Objects X Entidades
● Evita o code smell "Primitive Obsession"

29. Encapsular tipos primitivos
X

30. Encapsular coleções em classes

31. Encapsular coleções em classes

32. Um ponto por linha
Não é válido para Fluent Interfaces ou Method Chaining (exemplo: chai)
Em outros casos:
● Múltiplos encadeamentos podem indicar múltiplas responsabilidades
● "Fale com seus amigos próximos, não fale com estranhos"
● "Cannot read property of undefined / null"

33. Um ponto por linha
Dilema: Open/Closed
Uma classe deve ser aberta a extensão, mas fechadas a mudanças

34. Um ponto por linha

35. Evitar abreviações
Por que abreviar?
Abreviações "ocultam" palavras e podem ocultar problemas
E os termos de domínio?

36. Evitar abreviações

37. Evitar abreviações
?

38. Evitar abreviações
!

39. Evitar abreviações

40. Manter as entidades pequenas
Tentar manter as funções / arquivos em um número
pequeno de linhas (50 ~ 100 linhas)
Manter uma responsabilidade por arquivo

41. Manter as entidades pequenas
SFA (Single File Application)

42. Manter as entidades pequenas
SFA (Single File Application)

43. 1
2

45. 2

46. 1

47. Não ter + de 2 vars de instância p/ classe
Controlar a variação de estados de um objeto / componente
Evitar um grande número de dependências dentro de uma classe / entidade

48. Não usar getters / setters
#Polêmica

49. Não usar getters / setters
#Polêmica

50. Não usar getters / setters
#Polêmica
vs "Tell don't ask"

51. Não usar getters / setters

52. Não usar getters / setters

53. Termina aqui?
● SOLID
● Design Patterns
● Domain Driven Design
● Clean Code
● etc...

54. Referências
● https://pragprog.com/titles/twa/thoughtworks-anthology
● https://williamdurand.fr/2013/06/03/object-calisthenics/
● https://blog.neoassist.com/object-calisthenics-9-regras-para-aperfeicoar-seus-codigos/
● https://github.com/bennadel/Object-Calisthenics
● https://www.slideshare.net/rdohms/your-code-sucks-lets-fix-it-15471808
● https://www.slideshare.net/guilhermeblanco/object-calisthenics-applied-to-php
● https://sourcemaking.com/refactoring

55. Obrigado!
danielbpdias@gmail.com
http://github.com/danielbdias