Elemar DEV

Negócios, tecnologia e desenvolvimento

Afinal, quando usar métodos privados?!

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.

63 comentários em “Afinal, quando usar métodos privados?!

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

  2. Mauricio Aniche
    08/06/2012

    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… :)

    • elemarjr
      08/06/2012

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

    • elemarjr
      08/06/2012

      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).

  3. Pedro Reys
    08/06/2012

    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?

    • elemarjr
      08/06/2012

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

  4. Rodrigo Laranjo
    08/06/2012

    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…

    • elemarjr
      08/06/2012

      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?!

  5. ericlemes
    08/06/2012

    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?

    • Rodrigo Laranjo
      08/06/2012

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

    • elemarjr
      08/06/2012

      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?!

  6. 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.

    • elemarjr
      08/06/2012

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

      • 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 …

        • elemarjr
          08/06/2012

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

          • 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
    08/06/2012

    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?!

    • Daniel Presser
      08/06/2012

      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.

      • elemarjr
        08/06/2012

        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”

  8. alexsandrealmeida
    08/06/2012

    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.

  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.

    • elemarjr
      08/06/2012

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

      BTW, como você testa essa condition?!

  10. Mauricio Aniche
    08/06/2012

    “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.)

    • elemarjr
      08/06/2012

      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?!

      • Yan Justino
        08/06/2012

        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.

    • elemarjr
      08/06/2012

      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.
      ;)

  11. Robson Castilho
    08/06/2012

    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

    • elemarjr
      08/06/2012

      Deixa eu ver se entendi:

      Template Method (segundo eu mesmo :D ): 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 :D

      • Robson Castilho
        08/06/2012

        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

        • elemarjr
          08/06/2012

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

          Tá aí algo para eu pensar.

  12. Denis Ferrari
    08/06/2012

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

  13. Willian Oizumi
    08/06/2012

    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.

    • elemarjr
      08/06/2012

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

      • sergio_ykz
        08/06/2012

        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.

  14. Sergio Garcia
    08/06/2012

    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.

    • elemarjr
      08/06/2012

      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.

      • sergio_ykz
        08/06/2012

        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.

        • elemarjr
          08/06/2012

          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?!

          • sergio_ykz
            08/06/2012

            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
              08/06/2012

              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. 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.

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

    • elemarjr
      08/06/2012

      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)

      • 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+…

        • elemarjr
          08/06/2012

          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. :D Concordo com você, nada justifica código feio.

          • 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
    09/06/2012

    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…

    • elemarjr
      09/06/2012

      :D

      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.

  17. Cleyton Ferrari
    09/06/2012

    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)

    • elemarjr
      09/06/2012

      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.

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

  19. Francisco Hisashi Berrocal
    12/06/2012

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

  20. ricardonpcha
    17/06/2012

    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.

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

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

  23. Flavio Micheletti
    14/03/2014

    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.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Informação

Publicado em 08/06/2012 por em Post.

Estatísticas

  • 702,739 hits
%d blogueiros gostam disto: