A pergunta é: qual dos dois devemos receber? Essa é uma pergunta profunda, que envolve até uma discussão sobre acoplamento. Discutimos anteriorment...

A pergunta é: qual dos dois devemos receber? Essa é uma pergunta profunda, que envolve até uma discussão sobre acoplamento. Discutimos anteriormente que devemos sempre nos acoplar com dependências mais leves e menos frágeis. Nesse exemplo em particular, NotaFiscal parece ser uma classe pouco estável e bastante complicada; já uma lista de itens parece ser mais simples. Receber essa lista como parâmetro pode deixar o método calcula() mais simples e menos propenso a sofrer modificações. Se, para o cálculo do imposto, o algoritmo precisasse apenas do valor total, por que não receber um double total apenas? Quanto mais simples, menos problemas. Mas talvez uma lista de itens ou um double não deixe bem claro o que o método calcula() precisa receber. Um double pode ser qualquer número, uma lista de itens pode ser qualquer lista de itens, mas não é isso que ele quer: ele quer um valor de uma nota fiscal, ou uma lista de itens de uma nota fiscal. Garantias essas que tínhamos quando passávamos uma NotaFiscal como parâmetro. Para resolver isso de maneira elegante, por que não criar uma abstração? Poderíamos ter uma interface chamada Tributavel, que seria implementada pela classe NotaFiscal. O método calcula(), por sua vez, receberia essa interface. Assim como no exemplo anterior, acabamos emergindo uma interface leve. Nesse exemplo em particular, a criação da interface Tributavel nos traz vantagens: Diminuímos o risco do acoplamento, pois a interface Tributavel é muito mais estável que a classe NotaFiscal. O método calcula() recebe agora apenas o que realmente precisa. Tributavel é uma interface magra. Temos semântica no parâmetro do método. Não recebemos uma lista ou um double qualquer, e sim algo passível de tributação.