8 June, 2012 0 Comments AUTHOR: elemarjr CATEGORIES: Sem categoria

Afinal, quando usar métodos privados?!

Tempo de leitura: 1 minute

Olá pessoal. Tudo certo?!

Esse post é uma provocação. No lugar de apresentar algo, quero aprender com vocês! Venho tendo dificuldades para justificar métodos privados e gostaria que me ajudassem a “reencontrar o caminho”.

Pense:

  • Se um método é uma “analogia” para um “comportamento” de um objeto, então, um método privado seria um comportamento que esse objeto tem vergonha de assumir?!
  • Métodos privados tornam as classes mais difíceis de testar. Isso é um fato!
  • Métodos privados deveriam ser testados indiretamente, através de chamadas explícitas a métodos públicos. Entretanto, isso nem sempre é claro (nem fácil).
  • Outro dia, fui criticado por sugerir uma alternativa para testar diretamente métodos privados. Entretanto, como “não sei” mais programar sem usar “test-first”,  ao “pegar” um código legado (aka, sem testes), prefiro assumir uma dívida técnica usando  este recurso do que “adiar” a escrita de testes.
  • Muitas vezes, vejo métodos privados sendo utilizados como facilitadores, executando, por exemplo, algum tipo de validação. Entretanto, acho essa abordagem questionável (veja Melhorando a semântica com ValueTypes).
  • Há também situações onde métodos privados são utilizados para executar alguma operação de nível mais baixo. Novamente, para mim, um caso claro de violação para SRP.

Afinal, quando usar métodos privados?!

UPDATE: 

Minha intenção, com este post, era externalizar minhas dúvidas e aprender com a comunidade.

Realmente não me considero dono da verdade. Ainda mais no que se refere a design de software. Por isso, prefiro falar o que me preocupa e ouvir o que os outros acham. Quando tenho alguma contestação (afinal, já estou pensando no assunto há algum tempo), apresento e vejo como o argumentador responde.

Não tenho vergonha alguma de mudar de ideia. Desde que seja para outra que considere superior.

Até aqui, obrigado a todos que participaram dessa “thread” improvisada. Vocês realmente me ajudaram a caçar um de meus fantasmas recentes.

0 Comments

  1. Juan Lopes (@juanplopes) 4 years ago says:

    Um dos usos possíveis pra mim é poder escrever código recursivo:

    https://gist.github.com/2897783

    Reply
    • elemarjr 4 years ago says:

      Aí está um bom uso. Um bom exemplo. Obrigado.

      Reply
  2. Mauricio Aniche 4 years ago says:

    Oi Elemar,

    Acho que está criando uma tempestade em copo d'água aqui. Vc elencou a lista de quando NÃO usar um método privado: quando ele faz coisas demais, quando ele torna a classe difícil de testar, etc. Acho que a resposta para tua pergunta é exatamente o complemento da lista que levantaste.

    "Se um método é uma “analogia” para um “comportamento” de um objeto, então, um método privado seria um comportamento que esse objeto tem vergonha de assumir?!".

    Hmm, não sei pq inferiu isso. Uso métodos privados apenas para deixar o método acima mais claro e fácil de ler. Simples assim. Se esse método cresce demais e começa fazer coisas complicadas, aí penso em extrair para algum outro lugar.

    Outra utilização é para reutilizar código dentro da própria classe. Vc tem uma classe que expõe métodos públicos ricos pro mundo de fora, e esses caras podem compartilhar código.

    Talvez eu que não tenha entendido a profundidade da sua pergunta, mas acho que a resposta é bem simples... 🙂

    Reply
    • elemarjr 4 years ago says:

      Métodos privados são apenas particionamento lógico de métodos públicos?!

      Reply
    • elemarjr 4 years ago says:

      BTW, talvez seja uma pergunta boba, mesmo.

      Mas, veja, considero improvável que um método, com uma só responsabilidade fique grande a ponto de ficar difícil de ler (mais que ~10 linhas).

      Reply
  3. Pedro Reys 4 years ago says:

    Porque metodos privados tornam sua classe dificil de ser testada? Que diferença faz se o programador extraiu um método privado ou colocou toda o código no corpo do método público para a testabilidade do seu objeto?

    Reply
    • elemarjr 4 years ago says:

      Não estaria o método privado "mascarando" a complexidade ciclomática do método público?!

      Reply
  4. Rodrigo Laranjo 4 years ago says:

    Algumas vezes uso um método privado apenas como "organizador de código". Ou seja, tenho um método público muito complexo que eu divido em alguns métodos privados. Como não quero que os mesmos sejam chamados separadamente, "escondo-os" como privados. Do ponto de vista de "reaproveitamento de código", tá errado, já que trata-se na verdade do método público.

    Mas as vezes isso não tem muito sentido mesmo. No desenvolvimento de um componente, por exemplo, as vezes uso classes "facade" (fachada) para controlar o que pode e o que não pode ser acessado. Sendo assim, se tudo fosse público, não haveria problema.

    Gostei da sua abordagem do "ValueType". To começando a achar que to desaprendendo também...

    Reply
    • elemarjr 4 years ago says:

      Obrigado, Laranjo.

      Mas a questão que fica é: Será que esse método "separado" não caberia melhor em outra classe/definição de entidade?!

      Reply
  5. ericlemes 4 years ago says:

    Eu utilizo quando tenho qualquer reuso de lógica dentro de um objeto, mas que não desejo expor essa lógica pra outros objetos. Já tive casos em que mais de um método público (com assinaturas amigáveis) reutilizavam um método privado (com assinatura não tão amigável).

    Eu só tomaria cuidado com essa questão dos testes. Se os testes estão gerando questionamentos e dificuldades a ponto de não querer mais usar métodos privados, eu já ligaria a luz amarela no painel. Ferramenta é pra ajudar.

    É meio paradoxal essa coisa dos testes. Vc quer testar a "unidade", mas testar a unidade pode te fazer quebrar o encapsulamento. Fico imaginando como seria isso numa indústria, sei lá, automobilística. Quantas máquinas teriam que fazer pra testar um carro peça a peça? Nego ia sair testando parafuso a parafuso? Será que não é isso que estamos fazendo?

    Reply
    • Rodrigo Laranjo 4 years ago says:

      Taí um uso nobre: Ser chamado por métodos públicos "amigáveis". Isso faz sentido.

      Reply
    • elemarjr 4 years ago says:

      Repare, penso que os testes são um "indicador" para a qualidade do design. Penso que: se está difícil testar, meu design está ruim.

      Será que esses métodos menos amigáveis não caberiam melhor em outra classe/enitidade?!

      Reply
  6. Marcelo Alves Pires (@map2701) 4 years ago says:

    Para tornar um método grande "mais de 15/20 linhas" mais fácil de ler e dar manutenção, ficando o metodo público como um "Facade", ou seja, esses métodos privados não devem ser utilizados fora da minha classe ou método.

    Reply
    • elemarjr 4 years ago says:

      Não estaria esse "método Façade" fazendo coisas demais?!

      Reply
      • Marcelo Alves Pires (@map2701) 4 years ago says:

        Algumas vezes sem dúvida esse método de trabalho acaba substituindo técnicas/princípios OO mais corretos, porém em muitos casos é apenas um organizador, dando uma visão macro do método sem scroll. Ex: Telas muito complexas com 30/40 campos para salvar e carregar ...

        Reply
        • elemarjr 4 years ago says:

          aí está: salvar e carregar não deveriam ser, cada um deles, uma classe?!

          Reply
          • Marcelo Alves Pires (@map2701) 4 years ago says:

            As vezes são classes e as vezes métodos, porém mesmo sendo uma classe só para o salvar, ele ainda pode precisar ser quebrado para não duplicar código, porém é algo que só "serve" para esse método. O Método principal publico orquestra a execução de métodos privados menores, isso me ajuda a deixar o código fácil de entender e explicar.

  7. elemarjr 4 years ago says:

    Pelo que estou vendo, métodos privados são, quase sempre, "sub-rotinas". Seria isso?!

    Não se classificam, dessa forma, como comportamento. Será que não estão ferindo princípios de OO?!

    Reply
    • Daniel Presser 4 years ago says:

      E o encapsulamento não é um dos princípios da OO? Digo, complexidade existe mesmo que você respeite SRP. Métodos privados são uma ferramenta pra lidar com ela preservando a interface do objeto.

      Reply
      • elemarjr 4 years ago says:

        certo. concordo com você.

        Entretanto, perceba que o princípio de encapsulamento está relacionado com o método não precisar expor como "resolve".

        Esses métodos privados não estariam melhor colocados em tipos onde poderiam "ser públicos"

        Reply
  8. alexsandrealmeida 4 years ago says:

    Mas se nesse caso as "sub-rotinas" forem também "sub-comportamentos".

    Explicando: Às vezes temos métodos públicos que expõem comportamentos que podem ser quebrados, eles são a junção de vários comportamentos que não fazem sentido serem públicos. É comum implementar métodos distintos que possuem algum comportamento em comum. Acho que os métodos privados atendem isso, opinião que parece ser de muitos, visto os comentários acima.

    Reply
    • elemarjr 4 years ago says:

      Não seria aqui uma violação de SRP?!

      Reply
  9. Um dos usos de métodos privados que eu uso já mencionaram aqui, quando a classe tem comportamentos públicos que compartilham processo.
    As vezes também utilizo para dar mais legibilidade para o código, como por exemplo em consultas linq: ex

    ...
    todasAsPessoas.Where(QueTemFilhosECarro);
    ...
    
    private bool QueTemFilhosECarro(Pessoa pessoa)
    {
        return pessoa.Filhos != null && Filhos.Any() && pessoa.Carro != null;
    }
    

    Apesar de ser uma condição simples, a leitura de QueTemFilhosECarro é processada mais rapidamente que a expressão, até para um leigo ficaria legível.

    Reply
    • elemarjr 4 years ago says:

      Bom exemplo! Mas, não caberia melhor em uma classe "Policy"?!

      BTW, como você testa essa condition?!

      Reply
  10. Mauricio Aniche 4 years ago says:

    "Métodos privados são apenas particionamento lógico de métodos públicos?!"

    Sim, IMHO, acho que é essa a ideia!

    "Não estaria o método privado “mascarando” a complexidade ciclomática do método público?!"

    Depende do que vc espera da métrica. Quando calculo CC, quero saber a complexidade ciclomática do método que estou lendo. Se eu diminuí a complexidade dele extraindo código para outras classes, módulos ou métodos, meio que não me importa. Ele, isoladamente, está mais simples de ser lido. O foco é naquele método.

    "Não seria aqui uma violação de SRP?!", "Não se classificam, dessa forma, como comportamento. Será que não estão ferindo princípios de OO?!"

    É uma troca difícil. Se tivermos métodos com apenas 1 linha (realmente faz só uma coisa), precisaríamos apelar muito mais para abstrações/polimorfismo pra juntar todo esse comportamento. A complexidade só mudaria de lugar, afinal código flexível também é complexo.

    Algumas responsabilidades exigem sim uma certa quantidade de código, e as vezes quebrar em mais de uma classe pode mais complicar do que ajudar. Nesse momento, métodos privados podem fazer sentido, ajudando a particionar o método maior.

    (Veja que aqui nem estou discutindo "contextos" específicos, que eu e vc sabemos que existe, e que não há regra fechada para isso.)

    Reply
    • elemarjr 4 years ago says:

      Muito obrigado pelas suas considerações. Me fizeram pensar um bocado.

      Honestamente, não sei se, no final, métodos privados não implicam em prejuízo semântico sério. Mesmo "naqueles cenários" em que você os defende. Começo a ter a tendência de olhar métodos privados como "dívidas técnicas"

      BTW, para classes você consideraria CC Média para entender a dificuldade de leitura dos métodos e CC total para a "carga" do tipo?!

      Reply
      • Yan Justino 4 years ago says:

        Tive esse probleminha filosófico esses dias! Eu tenho uma API cujas classes são do tipo internal. Estas classes tem um comportamento importante, mas não deve ser públicas. Daí tive um certo probleminha nos testes: acabei expondo o que não deveria ser exposto.

        Reply
        • elemarjr 4 years ago says:

          ExternalsVisibleTo não resolveu?!

          Reply
    • elemarjr 4 years ago says:

      BTW, sei desses cenários e uso métodos privados neles também. Só que hoje em dia eles me deixam mais inquieto que antes.

      😉

      Reply
  11. Robson Castilho 4 years ago says:

    Olá, Elemar
    Concordo bastante com a opinião do Aniche.
    Outro exemplo de reuso seria em um template method, onde é sabido que parte do algoritmo deve ser exatamente o mesmo para todas as classes filhas. Sendo assim, implemento essa "parte" como um método privado (e os demais métodos do template method pode ou devem ser sobrescritos pelas classes filhas).

    Boa discussão.
    []s

    Reply
    • elemarjr 4 years ago says:

      Deixa eu ver se entendi:

      Template Method (segundo eu mesmo 😀 ): você escreve um método público na classe abstrata (template) e métodos "protected" (primitives) que serão sobrescritos nas classes especializadas.

      Na prática, você "completa" a implementação nas classes filhas. Sendo que a classe base é abstrata .. It's ok, it's all right.

      Para mim, métodos protected, usados dessa forma, não são comparáveis aos privados. Logo, não entendi seu exemplo.

      BTW, Aniche é o cara 😀

      Reply
      • Robson Castilho 4 years ago says:

        Exatamente. Mas suponha que um desse métodos não precise ser sobrescrito nas classes filhas. Eu torno ele private na classe abstrata:

        public void TemplateMethod()
        {
        A(); // private (código comum a todas as classes filhas)
        B(); // protected abstract
        C(); // protected abstract
        }

        Isso entraria na "categoria reuso de código" mencionada por outros colegas. É um tipo de solução que já adotei algumas vezes.

        Você vê algum tipo de problema nela?

        []s

        Reply
        • elemarjr 4 years ago says:

          não, só não estou habituado a ver "A()" privado. Em minhas implementações, sempre foi public.

          Tá aí algo para eu pensar.

          Reply
  12. Denis Ferrari 4 years ago says:

    Métodos privados? Eles servem para mostrar que você precisa de métodos públicos em outra classe.

    Reply
  13. Willian Oizumi 4 years ago says:

    Muito interessante essa sua provocação. Eu nunca tinha parado pra pensar nisso, e realmente faz muito sentido se levarmos os princípios SOLID em consideração.
    Só para constar, na linguagem Smalltalk não existem métodos privados. Todos métodos (mensagens) são públicos e todos atributos são privados. Talvez isso tenha alguma relação.

    Reply
    • elemarjr 4 years ago says:

      Javascript também não tem métodos privados e foram o "estopim" dessa "dissonância cognitiva"

      Reply
      • sergio_ykz 4 years ago says:

        Porém veja que é há um bom consenso entre programadores JS sobre a exposição dos métodos, veja que a jQuery e jQueryUI usam o _ (underline) como prefixo de métodos privados, ou seja, eles deixam claro que estes métodos não devem ser usados por que consumir a biblioteca.

        Reply
  14. Sergio Garcia 4 years ago says:

    Então, eu tenho a seguinte opinião, um método deve ser privado exceto quando necessário em outra classe. Ou seja, para evitar aumentar a complexidade de um método, eu separo ele em métodos privados e sempre procurando deixa-lo genérico a ponto de poder ser reusado.

    Se preciso de uma funcionalidade, tento ver se não posso adaptar um método para também contemplar essa nova funcionalidade.

    Quando um método utilitário se torna necessário em mais de uma classe, ele deve ser migrado para um classe mais especifica, onde o mesmo faça sentido em ser publico.

    Todos os métodos públicos de uma classe devem fazer sentido ao estarem naquela classe, já os métodos privados (que são usados somente por está classe) não têm o mesmo requisito.

    Quanto aos testes, existem ferramentas que expõe os métodos privados de uma classe (criando accessors por exemplo), podendo assim testa-los. E se a ideia é usar test first, você pode simplesmente alterar a visibilidade dos métodos para private após implementado as funcionalidades e ter todos os testes passando.

    Reply
    • elemarjr 4 years ago says:

      Sérgio,

      Como indicado no próprio post, tenho recursos para testar métodos privados. Entretanto, acho que o caminho não é esse.

      Quanto ao requisito de fazer sentido, SRP, man.

      Reply
      • sergio_ykz 4 years ago says:

        Concordo quanto a responsabilidade única, porém é correto expor todos os métodos da sua classe? Acho esse justamente o ponto onde devemos colocar métodos privados.

        Pense que num futuro alguém irá utilizar seu projeto, ou apenas os binários. Essa pessoa terá acesso a todos os métodos da sua classe que são públicos, e como o próprio nome diz, se são públicos podem ser usados. Essa pessoa pode simplesmente estar ignorando testes, validações e até mesmo regras do negócio que não estão implícitas que devem ser feitas.

        Métodos públicos (principalmente em classes públicas) devem sempre válida a entrada e nunca assumir que ela virá no formato esperado.

        Tomemos com exemplo um método que cria um documento HTML a partir de um template, seguindo SRP temos os seguintes métodos:

        1) Recebe o template, os dados e o caminho do arquivo final.

        2) Valida o template

        3) Valida os dados

        4) Gera o arquivo com os dados

        5) Salva o arquivo

        Neste caso, o método 4 assume que os dados são válidos, logo tornar este método publico pode fazer com que este método seja chamado sem que os dados sejam corretamente validos.

        Se estes métodos estivessem em uma classe, faria sentido apenas o método 1 ser publica, o métodos 2 a 5 não são de utilidade fora da classe e podem sem deixados privados.

        Eu penso que o programador que for dar manutenção em um código, não precisa ler todos os módulos do sistema para entender como ele funciona, até porque em um sistema grande isto é impossível, os métodos e classes devem tornar explícitos o que fazem pelos seus nomes.

        Reply
        • elemarjr 4 years ago says:

          Entendi seu argumento. Mas, nesse caso, estamos falando de "classes métodos". Ou seja, criamos uma instância, executamos uma operação e destruímos a instância.

          Trata-se de um "caso especial". Não acha?!

          Reply
          • sergio_ykz 4 years ago says:

            Sim, mas pelo que eu entendi você estava sendo radical ao ponto de esquecermos os métodos privados e nunca usa-los. Acho que eles tem o seu lugar ao sol (ou melhor a sombra, já que eles não podem ficar expostos).

          • elemarjr 4 years ago says:

            Não. Não era esse o meu desejo. Me percebi questionando meus argumentos para defender métodos privados.

            Nos comentários, reforcei algumas posições e revisei muitas outras.

            🙂

            BTW, grato!

  15. Marcus Alexandre Silva 4 years ago says:

    Fico me imaginando quando eu não poderia deixar de usar os metodos privados para tentar responder sua provocação, acabei pensando em um:
    Se minha classe possui (ou consome) algum evento a responsabilidade e deveria ser dela em implementar a logica deste tratamento quase sempre este metodo sera privado dentro da classe.

    Alem disto, SRP é um principio complicado, ele podo depender. Qual a granularidade ideal de uma responsabilidade? Uma responsabilidade maior não pode ser quebrada em responsabilidades menores que só diz respeito a ela mesmo? Sou obrigado a sempre "expor" estas responsabilidades menores como classes?

    Tenho mesmo que cobrir todos meus metodos privados com testes?
    Este é um ponto interessante. Eu sou adepto ao TestFirst mas tenho minhas duvidas quanto ao TDD da maneira que ele é colocado: muitos testes, pouco resultado (acho). Principalmente quando expor estes testes implicam em quebra de design.
    Exemplo:
    Meu Requisito: FerverAgua
    Entradas: Agua/Chaleira/Fogao
    Saida: ObterAguaQuente()
    Neste caso meus testes não deveriam cobrir apenas o resultado se a agua esta quente ou não baseado nas `n`entradas da classe? Se eu tivesse um metodo privado dentro desta classe ColocarAguaNaChaleira(), porque eu deveria testar se a agua foi colocada ou não, ja que nos testes da maior responsabilidade daria erro em ObterAguaQuente()? Sem este teste meu requisito estaria coberto do mesmo jeito... Porque criar mais uma classe no sistema com algumas poucas linhas para ObterAguaQuente ja que esta classe nao faria mais sentido em nenhuma outra parte do sistema para reaproveitamento?

    Não sou bom com palavras, espero que me entendam....

    Abraço.

    Reply
    • Marcus Alexandre Silva 4 years ago says:

      Outro local bom para metodos privados: Execuções que são chamadas em construtores, quando a classe tem mais de um construtor.

      Reply
      • sergio_ykz 4 years ago says:

        Dependendo do caso você não precisa usar métodos privados, apenas chamar um construtor a partir do outro, a maioria das linguagens suporta isso de alguma forma.

        Reply
    • elemarjr 4 years ago says:

      Entendi, man

      Mas você está testando o fino. Métodos privados de forma indireta.

      BTW, assinatura de eventos, para mim, é um bom exemplo de utilidade para métodos privados (ou expressões lambda)

      Reply
      • Marcus Alexandre Silva 4 years ago says:

        Esta é a questão Elemar: Se eu já testo indiretamente (e isto é suficiente) os metodos privados servem apenas para organização do código, legibilidade e nada mais. Nao estou infringindo o SRP mesmo que exista composição de *pequenas responsabilidades* para atingir a responsabilidade maior: SRP = Uma classe, uma responsabilidade, e não (nem sempre) Uma responsabilidade e 'N' classes. SE o cenário permite que eles (metodos privados) existam sem a necessidade da extracao de classe, use-os. SE o cenário mudou, refatore-os e crie os testes que asseguram seu funcionamento.
        Não é só a arquitetura da solução que emerge, o design do seu código também deveriam emergir. E estou pra te falar: Não existe sigla no mundo que justifique código feio e, na minha visão, fragmentação desnecessária é feia d+...

        Reply
        • elemarjr 4 years ago says:

          Concordo absolutamente com você.

          Minha questão não está em fragmentar ou não. Minha dúvida é em que cenários tenho um método tão complexo que precise ser "quebrado" em métodos privados. Se eles existem, não seria por ter uma responsabilidade demasiado ampla para um método?

          Estamos defendendo métodos como organização de código, para melhorar a legibilidade. Entendo esse argumento e aceito. Entretanto, parece-me que PODE (veja, não é uma afirmação absoluta) ser um indicativo de falha de design.

          Por outro lado, se o método é aproveitado em mais de um cenário de uso (chamado por mais de um método), então, parece-me conveniente verificar sua função e revisar sua posição/relevância para o domínio.

          BTW, não acredito em design que não seja evolucionário.

          Outro aspecto, não defendo siglas, defendo conceitos. 😀 Concordo com você, nada justifica código feio.

          Reply
          • Marcus Alexandre Silva 4 years ago says:

            O que agente percebe nestes anos todos de luta, errando e acertando tudo é que ninguém vai conseguir uma verdade absoluta para todos os cenários 🙂
            Tudo é uma questão de design do seu dominio, seja o código orientado a ele ou não.

            Gostei demais deste teu post, e ja levanto uma bola para os próximos: Quando o teste atrapalha (sem necessidade) o design, ja que partimos do conceito que: se o código esta difícil de ser testado provavelmente voce tem um erro de design?

  16. cirellolaranjo 4 years ago says:

    O Elemar anda tanto "Test Driven" que deve estar medindo a voltagem da tomada antes de ligar o computador...

    Relaxa. E se não existir um jeito correto? Não testar não quer dizer que não deve ser usado.

    De qualquer maneira, é legal "por na roda" essas tretas. Afinal, vamos duvidar. Certeza é para os idiotas...

    Reply
    • elemarjr 4 years ago says:

      😀

      Perfeito man. Minha intenção é só externalizar minha dúvida e aprender com a comunidade.

      Realmente não me considero dono da verdade. Ainda mais no que se refere a design de software. Por isso, prefiro falar o que me preocupa e ouvir o que os outros acham. Quando tenho alguma contestação (afinal, já estou pensando no assunto há algum tempo), apresento e vejo como o argumentador responde.

      Não tenho vergonha alguma de mudar de ideia. Desde que seja para outra que considere superior.

      Até aqui, obrigado a todos que participaram dessa "thread" improvisada.

      Reply
  17. Cleyton Ferrari 4 years ago says:

    Caracas, está parecendo blog de gringo ou indiano! centos milhões de comentários! Legal isso! Aprendi muito mais com os comentários do que com o post propriamente dito (não menosprezando o post, mas enaltecendo os comentários)

    Reply
    • elemarjr 4 years ago says:

      Cleyton,

      Esse era, exatamente, meu objetivo. Vou começar a fazer alguns posts assim onde, no lugar de "mostrar o caminho", vou "mostrar a dúvida".

      Ninguém é perfeito, mas o grupo, frequentemente, pode ser.

      Reply
  18. Antonio Castro Jr (@agcjunior) 4 years ago says:

    Elemar, assim você tira a noite de sono de muita gente. De qualquer maneira esse tipo de discussão é muito benéfica.

    Reply
  19. Francisco Hisashi Berrocal 4 years ago says:

    Singleton é uma boa aplicação de método(no caso construtor) privado.

    Reply
  20. ricardonpcha 4 years ago says:

    Elemar para mim métodos privados, me corrija se eu estiver errado (existe grande possibilidade disso!, rsrsrs), devem ser métodos que desempenham funções significativas somente para o objeto e que não pertençam o um outro sub-sistema, exemplo:
    Digamos que tenhamos um classe objeto que possui um "luminária" que indica se está ligado/desligado, não faz sentido expor os métodos ligar/desligar luminária um vez que a manutenção do estado e de responsabilidade do próprio objeto. Note que os métodos privados fornecem encapsulamento a nível de classe, pode ser que seja somente alterar um flag boleano, ou pode ser que tenha todo um circuito por trás deste ligar/desligar luminária.

    Espero não ter viajado demais.

    Reply
  21. Daniel Yokoyama (@dmyoko) 4 years ago says:

    Meus métodos privados são, normalmente (pra não dizer sempre), resultado de refactorings depois que os testes passaram.

    Reply
  22. Flavio Micheletti 2 years ago says:

    Elemar, nota 10 esse post! Eu volto de tempo em tempo só para ver se alguém colocou mais um comentário.

    Deixa eu colaborar tb (ou talvez, descolaborar... rsss)

    private foo;
    function setFoo(value){
    this.foo = value;
    }
    function getFoo(){
    return this.foo;
    }

    Obs: Esse trecho de código agente encontra em tudo que é tutorial, triste isso.
    Se os métodos geters e seters agregam algum processamento extra, ainda vá lá!
    Mas se APENAS expôem o private dessa forma, então eu prefiro:

    public foo;

    ...

    E os tutos, blogs, livros (incluindo alguns renomados) apenas argumentam que o método privado ajuda no encapsulamento. E este, por sua vez, ajuda ao código cliente ser mais acertivo quanto a utilização da classe.
    Putz, que argumento mais pobre!

    Esse seu post é um clarão no meio da escuridão. Mais uma vez parabéns.
    E espere ver mais assuntos "quentes" como este.

    Reply

Trackbacks for this post

  1. PAREANDO: Como você escreveria esse código? « Elemar DEV