Open NicholasNeto opened 6 years ago
Acho que as funcionalidades necessárias para resolver esse kata não seriam facilmente/intuitivamente divididas em classes.
Um dos motivos de usar classes é quando você quer abstrair, esconder ou separar os detalhes de alguma implementação do resto do código. Podemos até pensar em termos de objetos físicos. Quando o código lida com pessoas, notícias, trens, estradas, hotéis, itens de um supermercado, etc... fica bem fácil ver o que a gente pode encapsular em objetos/classes.
No caso da calculadora, não vejo uma separação que faça sentido.
Talvez se você tivesse MUITOS tipos de limitações junto com as de números negativos e maiores que 1000... aí talvez daria para fazer uma classe de filtros para abstrair o detalhe dos filtros do resto do código, mas só dois... não sei se faz muito sentido.
Tem outras coisas que você pode fazer para deixar o código mais legível e conciso.
Puxa, muito obrigado ..
Eu entendo agora:
Quando o código lida com pessoas, notícias, trens, estradas, hotéis, itens de um supermercado, etc... fica bem fácil ver o que a gente pode encapsular em objetos/classes.
Agora esta bem claro pra mim !!!
Só para esclarecer uma coisa:
Essas situações com objetos/coisas são as mais fáceis de separar em classes, mas também é possível ter classes bem abstratas que não representem coisas físicas. Podemos usar classes para definir comportamentos ou ações (de usuários ou do próprio código).
O publisher, por exemplo, é uma classe que separa os códigos da ação de publicar. O scheduler, separa o código relacionado à agendamento. Outros códigos usam o publisher e o scheduler sem saber os detalhes, só chamando as funções que foram expostas com module.export
.
Com o tempo você vai vendo essas outras situações....
Thiago ,
voce acha que este cdg cabe classes , sei que tudo da pra se fazer com classes , mas pensando em arquitetura de cdg e coisas bem legiveis , voce acredita que seria uma boa fase pra ele?
Se sim , pq sim se nao, pq não