Interessante, mas acho que o estilo imperativo é verboso mas muito mais simples de ler e entender. Em uma passada no código você consegue absorver praticamente tudo o que o criador do código quiz fazer. O estilo declarativo é interessante para casos isolados e de baixa complexidade, quando aumenta a complexidade e níveis de condicionais, fica extremamente difícil de ler e compreender. O caso da API de Streams é um exemplo, quando é necessário muita complexidade e lógica condicional, vira um monstrengo que pode te tomar muito tempo até conseguir absorver a intenção do criador. Já peguei alguns códigos com Stream que eram de chorar, se fossem feitos "à moda clássica" teriam ficado mais simples de entender e manter.
Obrigado demais pelo comentário! Eu também tenho esse viés, pois também venho do modo clássico, e sabemos que, tudo depende do contexto que estamos tentando resolver! Sempre temos que validar também a carga cognitiva que é necessária para quem for dar manutenção ao código em si. Respeito muito seu ponto de vista, mas minha opinião é que talvez, dividindo o problemas em pequenos problemas, não colocando muita regra de negócio nas expressões lambdas, o que é uma má prática pois lambdas devem ser glue code (blog.agiledeveloper.com/2015/06/la...), utilizando method reference de maneira consciente, seja possível ter talvez ter um código mais elegante, conciso.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interessante, mas acho que o estilo imperativo é verboso mas muito mais simples de ler e entender. Em uma passada no código você consegue absorver praticamente tudo o que o criador do código quiz fazer. O estilo declarativo é interessante para casos isolados e de baixa complexidade, quando aumenta a complexidade e níveis de condicionais, fica extremamente difícil de ler e compreender. O caso da API de Streams é um exemplo, quando é necessário muita complexidade e lógica condicional, vira um monstrengo que pode te tomar muito tempo até conseguir absorver a intenção do criador. Já peguei alguns códigos com Stream que eram de chorar, se fossem feitos "à moda clássica" teriam ficado mais simples de entender e manter.
Obrigado demais pelo comentário! Eu também tenho esse viés, pois também venho do modo clássico, e sabemos que, tudo depende do contexto que estamos tentando resolver! Sempre temos que validar também a carga cognitiva que é necessária para quem for dar manutenção ao código em si. Respeito muito seu ponto de vista, mas minha opinião é que talvez, dividindo o problemas em pequenos problemas, não colocando muita regra de negócio nas expressões lambdas, o que é uma má prática pois lambdas devem ser glue code (blog.agiledeveloper.com/2015/06/la...), utilizando method reference de maneira consciente, seja possível ter talvez ter um código mais elegante, conciso.