8. Parâmetros de função

• A quantidade ideal de parâmetros para uma função é zero (nulo).
• Depois vem um (mônade).
• Depois viria dois (díade).
• Sempre que possível deve-se evitar três parâmetros (trí­ade). Para mais de três deve-se ter um motivo muito especial (políade) — mesmo assim não devem ser usados.

Parâmetros são complicados. Eles re­querem bastante conceito. É por isso que quase nos utilizei nos exemplos.

Con­sidere, por exemplo, o StringBuffer. Po­deriamos tê-lo passado como parâmetro em vez de instanciá-lo como uma variável, mas então nossos leitores teriam de interpretá-lo sempre que o vissem.

Ao ler o caso conta­da pelo módulo, fica mais fácil entender includeSetupPage ( ) do que includeSetupPageInto (newPageContent).

O parâmetro não está no nível de abstração que o nome função, forçando-lhe reconhecer de um detalhe (ou seja, o StringBuffer), que não é importante particularmente nesse momento.

A partir do ponto de vista de testes, os parâmetros são mais difíceis ainda. Ima­gine a dificuldade de escrever todos os casos de teste para se certificar de que todas as várias combinações de parâmetros funcionariam adequadamente. Se não houvessem parâme­tros, essa tarefa seria simples.

Se houver um, não é tão difícil assim. Com dois, a situação fica um pouco mais desafiadora. Com mais de dois, pode ser desencorajador testar cada combinação de valores apropriados.

Os parâmetros de saída são ainda mais difíceis de entender do que os de entrada. Quando lemos uma função, estamos acostumados à ideia de informações entrando na função através de parâmetros e saindo através do valor retornado. Geralmente não es­peramos dados saindo através de parâmetros. Portanto, parâmetros de saída costumam nos deixar surpresos e fazer com que tenhamos a necessidade de lermos novamente para que possamos compreendê-lo.

Um parâmetro de entrada é a melhor coisa depois de zero parâmetro. É fácil entender SetupTeardownlncluder.render (pageData). Fica claro que renderizemos os dados no objeto pageData.