Olá brazlucca,
A ideia do Nico está relacionada com as seguintes boas práticas de design de código:
- separação de responsabilidades
- modelo de domínio rico
- tell, don't ask / lei de demeter
Separação de Responsabilidades
É uma boa prática de OO a separação das responsabilidades para facilitar a manutenção e evolução do código.
Robert Martin documenta isso no Single Responsibility Principle (Princípio da Responsabilidade Única):
uma classe deve ter apenas um motivo para ser modificada.
O Managed Bean do JSF deveria ser responsável por fazer a ponte entre as entidades de domínio (Livro, Autor, etc) e as telas (.xhtml).
Modelo de domínio rico
As responsabilidades de negócio (cálculos, validações, restrições), devem ser colocadas mais perto das entidades de negócio (Autor, Livro, etc), que fazem parte do modelo de domínio.
Não devemos colocar as regras de negócios no código relacionado a telas ou banco de dados.
Martin Fowler documenta o perigo de um modulo de domínio sem regras de negócio no que ele chama de Modelo Anêmico:
https://www.martinfowler.com/bliki/AnemicDomainModel.html
Tell Don't Ask / Lei de Demeter
No artigo The Art of Enbugging (HUNT; THOMAS, 2003), Andy Hunt e Dave Thomas indicam que um lema de OO deveria ser Tell, don't Ask.
Em português, algo como "Diga, não pergunte":
Envie comandos para objetos dizendo o que você quer fazer. Explicitamente, não queremos consultar
um objeto sobre seu estado, tomar uma decisão e, então, dizer ao objeto o que fazer.
Ian Holland na Northeastern University que, por volta de 1987, cunhou a Lei de Deméter.
Essa "lei" afirma que todo método de um objeto deve chamar apenas métodos pertencentes a:
- si mesmo
- quaisquer parâmetros que foram passados para o método
- quaisquer objetos criados
- qualquer composição
É uma maneira mais detalhada de declarar que um bom objeto apenas interage com seus "vizinhos"
imediatos.
