Se alguma vez houvesse um cheiro ruim para objetos projetados preguiçosamente, ele viria de métodos privados. Cada método privado introduzido deve ser um sinalizador vermelho, disparando uma segunda olhada em como as responsabilidades estão sendo divididas entre os objetos.
Bons objetos fornecem uma interface confiável e bem balanceada para uma implementação simples de alguma metáfora útil. A programação orientada a objetos são todas as atividades que empregamos para fazer bons objetos. Infelizmente, muitas pessoas erroneamente aplicam essas atividades a apenas um aspecto restrito dos programas, o que é chamado de modelo de domínio, deixando apodrecer os outros domínios que convergem no programa.
Freqüentemente, o erro está em presumir que o domínio do negócio é o único que precisa ser modelado. Em vez disso, deve-se entender que muitos domínios se unem para tornar um programa possível. Software podre, como tudo o mais que apodrece, é encontrado escondido nos cantos privados negligenciados e intencionalmente negligenciados das coisas (neste caso, objetos). Cada pedaço particular de comportamento é uma oportunidade para um novo domínio de objetos bons assumir. Liberando seus objetos para fazer apenas as coisas relevantes para seus domínios específicos.
Se você está fazendo métodos privados, pergunte-se por que e veja se há uma ferramenta de design melhor disponível. Se você acha que não existe, consulte alguém que possa fornecer uma perspectiva diferente. De qualquer maneira, procure uma maneira de resolver o seu problema que não envolva esconder o comportamento. Cito de forma preocupante a NSA: “Se você não tem nada a esconder, não tem nada a temer.” Se você tem algo a temer, provavelmente tem um design ruim.