Como não aprender Java e Orientação a Objetos: getters e setters

Conheça o novo curso online da Caelum no Alura Aprimorando a Orientação a Objetos com Java!

Muitas pessoas perguntam “como aprender OO?“. Há várias maneiras de aprender OO, creio que não tenha uma melhor, mas existem maneiras de não aprender.

Uma das práticas mais controversas que aprendemos no início é a geração indiscriminada de getters e setters. Os exemplos básicos de centenas de tutoriais java estão recheados com getters e setters da pior espécie: aqueles que não fazem sentido algum. Considere:

class Conta {
  double limite;
  double saldo;
}

Rapidamente os tutoriais explicam o private para o encapsulamento. Mas aí como acessar? Getters e setters nela!

class Conta {
  private double limite;
  private double saldo;
  
  public double getSaldo() {
    return saldo;
  }
  
  public void setSaldo(double saldo) {
    this.saldo = saldo;
  }
  
  public double getLimite() {
    return limite;
  }
  
  public void setLimite(double limite) {
    this.limite = limite;
  }
}

Qual é o sentido desse código? Para que esse setSaldo? e esse setLimite? e o getLimite? Você vai usar esse métodos? Nunca crie um getter ou setter sem sentir uma real necessidade por ele. Isso é uma regra para qualquer método, mas particularmente os getters e setters são campeões: muitos deles nunca serão invocados, e grande parte do restante poderia ser substituído por métodos de negócios. Códigos do tipo conta.setSaldo(conta.getSaldo() + 100) se espalharão por todo seu código. Segue então a nossa classe Conta reformulada de acordo com essa necessidade:

class Conta {
  private double saldo;
  private double limite;

  public Conta(double limite) {
    this.limite = limite;
  }

  public void deposita (double x) {
    this.saldo += x;
  }

  public void saca(double x) {
    if(this.saldo + this.limite >= x) {
      this.saldo -= x;
    }
    else throw new IllegalArgumentException("estourou limite!");
  }

  public double getSaldo() {
    return this.saldo;
  }
}

E nem estamos falando de test driven development! Testando a classe Conta rapidamente você perceberia que alguns dos getters e setters anteriores não têm uso algum, e logo sentiria falta de alguns métodos mais voltados a lógica de negócio da sua aplicação, como o saca e o deposita acima. Esse exemplo é muito trivial, mas você pode encontrar por aí muitas classes que não tem a cara de um java bean que expõem atributos como Connection, Thread, etc, sem necessidade alguma.

Existem sem dúvida práticas piores: utilização de ids para relacionar os objetos, arrays não encapsuladas como estruturas, código fortemente baseado em comparação de Strings hardcoded (que o Guilherme Silveira sarcasticamente carinhosamente batizou de POS, ou programação orientada a strings), milhares de métodos estáticos, entre outros. Todas essas práticas são muito comuns quando estamos começando a quebrar o paradigma procedural e confesso já ter sido um grande praticante de muitas delas. Você só vai utilizar bem o paradigma da orientação a objetos depois de errar muito.

O Phillip Calçado aborda esse tema, chamando essas classes de classes fantoches (puppets). Uma classe fantoche é a que não possui responsabilidade alguma, a não ser carregar um punhado de atributos! Onde está a orientação a objetos? Uma grande quantidade de classes fantoches são geradas quando fazemos Value Objects, entidades do hibernate, entre outros.

Mas o que colocar nas minhas entidades do hibernate e nos meus VOs além de getters e setters?“. Antes de tudo, verifique se você realmente precisa desses getters e setters. Para que um setID na sua chave primária se o seu framework vai utilizar reflection ou manipulação de bytecode para pegar o atributo privado, ou se você pode passá-la pelo construtor? Sobre value objects, você realmente precisa dos seus setters? Em muitos casos VOs são criados apenas para expor os dados, e não há necessidade alguma para os setters… bastando um bom construtor! Dessa forma evitamos um modelo de domínio anêmico.

No hibernate costumo colocar alguns métodos de negócio, algo parecido como na classe Conta. Minhas entidades possuem uma certa responsabilidade, em especial as que dizem respeito aos atributos pertencentes a elas.

Para quem ainda está aprendendo, a apostila da caelum de java e orientação a objetos tem algumas dessas discussões e procura ensinar OO comentando sempre dessas más práticas, como por exemplo o uso de herança sem necessidade.

Vale relembrar que o exemplo é apenas didático. Trabalhar com dinheiro exige inúmeros cuidados, como não usar double. O foco desse post é para você parar para pensar antes de criar o getter e o setter. Pode ser que o seu caso justifique a criação desses métodos.

141 Comentários

  1. Paulo Silveira 11/03/2013 at 20:14 #

    Sancario, vai tudo depender do quao importante é o deposito no seu negócio e de como ele está relacionado com suas classes. Varia de domínio pra dominio. Pode ser que deposito seja até mesmo uma classe! Às vezes, é dificil de dizer mesmo conhecendo o dominio

  2. SancarLo 12/03/2013 at 06:29 #

    Concordo com você plenamente Paulo, tudo depende do contexto de domínio. A questão é que, dependendo da modelagem do domínio  o método depositar ou sacar pode não ser uma responsabilidade da entidade Conta. Em minha experiência com esse tipo de domínio posso te dizer que não é. Por fim, voltando ao problema dos geters e setters, ainda teria-se, para esse cenário, a necessidade de métodos encapsuladores(protetores) de mais baixo nível para garantir a integridade da entidade Conta. Ex. “Não  permitir atribuição de valores ao objeto conta se a mesma estiver bloqueada”. Entende? Diante desta questão, não vejo problema em ter métodos(getters e setters) que protejam seus atributos. A meu ver, criar métodos encapsuladores por padrão, é o menor dos problemas. O verdadeiro dilema é conseguir uma boa modelagem OO. Em OO, muitos falam, alguns entendem, poucos fazem. Novamente parabéns pelo post e obrigado pela resposta.

  3. Paulo Dantas 22/04/2013 at 15:12 #

    bom, o que parece é que na verdade so trocaram o nome dos get e set por nomes de negocio. continuam fazendo a mesma coisa. E se eu quisesse apenas saber o limite da minha conta? Na teoria funciona na pratica só está trocando os nomes dos metodos e especificando uma operação.

  4. Paulo Silveira 22/04/2013 at 15:17 #

    ola Paulo

    Acho que sua leitura foi rapida. Voce pode usar o nome que quiser, podem ser até getter e setter, se fizer sentido naquele caso em específico. O que o post alerta é o uso indiscriminatório dos getters e setters, e sua criação automatica. O getSaldo esta la. O getLimite nao está pois, nesse caso em particular, ele não é necessario. Se voce quisesse sim, pode colocar o metodo.

    O erro seria cria-los todos automaticamente. Ja imaginou se na LinkedList houvesse um método getHead que devolvesse um objeto Node, que é o atributo interno da LinkedList? Ou se a MySQLConnection, implementacao do Connection de JDBC tivesse um getSocket? Seria uma quebra total de encapsulamento. O post diz para ser criterioso ao criar um getter ou um setter, nao que não deva utiliza-lo.

    Esse post, apesar de antigo, ja nao era novidade. Voce pode ler mais aqui: http://www.martinfowler.com/bliki/AnemicDomainModel.html

  5. Andrey F. Alves 06/05/2013 at 17:37 #

    Ótima publicação, parabéns!

    Porém, acho que todo atributo deve sim, possuir seus getters e setters. Suponhamos que um dia, algo precise utilizar o setSaldo. Prever possíveis necessidades é algo que deve fazer parte de quem está criando o objeto.

  6. Paulo Silveira 06/05/2013 at 21:07 #

    Andrey, você deve evitar ficar prevendo usos da sua classe que ainda não sao utilizados. Se for assim, vai acabar criando milhares de metodos desnecessarios que talvez nunca serao usados. Melhor cria-los quando voce precisar deles.

  7. Custodio Leitão 27/06/2013 at 12:19 #

    Prezados
    Estou a começar agora no mundo java, gostaria de dicas como baixar o Eclipse e JDK incluido a instalação no Windows ou Ubuntu.
    obrigado

  8. Everton Sales 11/08/2013 at 23:03 #

    Eu adoto o seguinte, se o usuário vai editar o atributo diretamente crio os sets e gets, se não, não crio, apenas os métodos acessarão diretamente….

  9. Paulo Silveira 12/08/2013 at 12:33 #

    oi Everton. Nao tem pra que o usuario editar o atributo diretamente muitas vezes, é justo esse o argumento do post. Nao tem pra que por setSaldo.

  10. Gamarra 04/10/2013 at 01:27 #

    Ai ai ai! Verbosidade na veia. Infelizmente até utilizar o Lombok tá osso, ainda mais codar mais limpo. O mercado exige padrões fora das boas práticas, os frameworks viajam na batatinha e os desenvolvedores sofrem com códigos extremamente verborrágicos. A teoria é tão linda!

  11. Rodja 04/12/2013 at 02:13 #

    Java realmente deveria ter um jeito mais simples para get/set.

    Eu li o post achando que você simplesmente estava contra a idéia de getter/setter, o que seria meio contra produtivo.
    Seria a mesma coisa que ignorar a encapsulação, aumentar o coupling e deixar a sua equipe maluca quando um dia precisarem mudar algo aí.

    Mas quando li a sua reformulação eu percebi que a idéia não é apenas contra o uso indiscriminado de get-set. Mas também sobre a como devemos manter nosso código dentro da metáfora que a nossa classe deve cumprir (o que eu acho muito mais importante).

    Quando você pergunta “Qual é o sentido do setSaldo()?” eu acho que você também está se perguntando se esse método faz sentido nesta classe. E não, não faz.
    Como a gente pode saber se no futuro alguém vai precisar desse método? Bom, se precisarem desse método é melhor criar uma outra metáfora e outra classe, porque nesta não vai ter lugar para isto.

    Por exemplo. Se a sua classe se chama conta, você deve ter exatamente um método para sacar e outro para retirar.
    Se formos pensar na metáfora da conta, nós não conseguimos (e nem queremos) que os usuários simplesmente enfiem um valor na sua conta, como seria o que o setSaldo(double v) faria.

    Então uma outra coisa que acho importante deixar comentado aqui é a necessidade de avaliar se a sua classe está sendo o que ela deveria ser.
    Use bem as suas metáforas, pois são uns dos grandes poderes da OOP! 🙂

  12. Darcy Brás da Silva 12/01/2014 at 04:33 #

    O autor que ‘congratula-se’ dos seus 10 anos de experiência, na pagina sobre o autor, tem um post de 2006 completamente errado, actualiza em 2012 uma referencia a mais material didatico sem o corrigir o mesmo.

    De facto usar getters e setters incorrectamente é algo a evitar, contudo, o exemplo escolhido não podia ser pior, pois é um dos cenarios onde eles fazem mais sentido, sem contar com outros erros no proprio exemplo.

    NOTA: vou usar o euro como exemplo pois não tenho experiencia com a moeda ‘real’, contudo, as regras são iguais, e obrigatorio na maioria dos paises onde existe software que trata de finanças.

    1º Grande e grave Erro.

    class Conta {
    double limite;
    double saldo;
    }

    “double” é o erro. Não existe meia moeda nem meia nota.
    0.50€ é uma simplificação escrita e não uma caracteristica da moeda.

    Portanto 0.50€ continua a ser uma unidade inteira. esta em outra categoria de dinheiro. Os centimos.

    Uma vez visto que o dinheiro não é um tipo de dado simples/primitivo, e sim complexo, uma “class” é recomendavel, para abstrair os mecanismos internos do objecto/tipo de dado.

    A pratica chama -se: ADT “Abstract Data Type” permitindo-nos a usar o tipo de dado sem necessitar entender as suas componentes internas.

    Caracteristicas do dinheiro ?
    1º Não existe dinheiro negativo. Voce pode ter uma divida, mas o dinheiro nunca é negativo.
    2º Não é divisivel. Isto é, repartir dinheiro significa converter o numerario base para o decimal/centimos.

    Exemplo 1€ pode tornar-se 2x50centimos, mas não duas metades de 1€.

    Tentarei simplificar o maximo possivel, no entanto dinheiro tem standards e leis aplicaveis quando usado em software, logo a sua complicação tende a ser acrescida.

    Como saber o tipo de dado para Dinheiro então ?

    Uma vez que java não tem o tipo de dado unsigned, algumas pessoas usam BigDecimal, no entanto o ideal sera realizar as operações bitwise de modo a ignorar o bit do sinal, pois só assim podemos realmente evitar problemas da arbitrariedade dos numeros de virgula flutuante.

    class Dinheiro {
    Private long montante_base;
    Private long montante_decimal;

    public void setMontante(String montante) {
    }

    public String getMontante() {
    }

    }

    class Conta {
    Private Dinheiro saldo;

    public boolean Depositar(String valor) {
    //valiar de acordo com as regras de deposito da conta
    this.saldo.setMontante( valor );
    }

    public String getSaldo() {
    //validar com as regras
    return this.saldo.getMontante();
    }
    }

    Agora porque não usar directamente saldo ?

    Os computadores não tem apenas um processador, nem fazem apenas uma unica tarefa, logo é necessario entender como o codigo é mandado executar pelo sistema operativo.

    como funciona o sistema operativo ?
    Tem uma tarefa, executa, por um tempo, para pega noutra, executa por um tempo para e pega noutra, ate terminar todas e voltar a executar a 1ª.
    No meio destas operações pode ainda existir interrupções.
    Exemplo, quando a impressora acaba de imprimir.
    Nessa altura, o processador para o que esta a fazer, grava, onde esta, vai ver o que a impressora quer, trata disso, e depois retoma a sua tarefa. entretanto o tempo ‘disponibilizado para o processo 1, pode ter acabado, não podendo continuar e partindo para os proximos, ate retornar ao 1º.

    Agora vamos dizer que o processo 1
    é o joão a levantar dinheiro

    no seguinte codigo

    class Conta {
    Private double montante;

    public boolean getDinheiro(double valor) {
    if( montante >= valor ) {
    montante -= valor;
    }
    return true;
    }

    }

    o return true devera dizer a maquina que pode deixar o dinheiro sair.

    agora imagine que o processador ja verificou que montante >= valor é verdade, mas foi interrompido para fazer outra coisa.

    A maria podia agora vir e ter o seu computador mais livre/disponivel e levantar o dinheiro todo.

    e quando o computador do joao volta-se a executar
    apenas faria montante -= valor;

    o que obviamente resultaria em saida de mais dinheiro do que aquele que existe na conta, e os bancos não gostariam.

    Por esta e outras razões usamos um ‘setter e um getter’ para casos destes, pois assim podemos fazer um lock/bloqueio de cpu e obrigar a que a função seja sempre executada por inteiro inves de permitir a sua paragem a meio.
    caso não existisse um setter e um getter, todo o codigo não só seria obrigado a saber como o dinheiro funciona, assim como teria de saber como uma conta funciona, poluindo todo o codigo.

    Existem de facto zonas onde não faz sentido usar setters e getters. mas esta definitivamente não é uma delas.

  13. Paulo Silveira 13/01/2014 at 01:41 #

    @Darcy varios comentários seus são pertinentes ao seu contexto. Pro seu sistema grande e importante, não existe meio dinheiro. Faz todo sentido. Pro meu exemplo ridículo de duas linhas, pouco importa. Pra mim uma data é dia mês e ano, pra você pode ser importante o tempo em milissegundos desde o unix time. Contexto. Aqui o contexto é falar sobre não sair escrevendo getter e setter de qualquer forma, como voce mesmo falou que é importante evitar. Não é sobre a melhor forma de evitar problemas com as casas flutuantes de currency (que você parece conhecer bem e pouco importa para esse post), nem sobre como evitar interleaving e race conditions (nao está claro que o post é sobre escrever getter e setter as cegas??).

    Dos seus pontos:

    1. Certamente nao é pra ninguem usar dinheiro em double. Aqui tem um pouco sobre o uso do BigDecimal, Strings e alguns cuidados basicos:
    http://blog.caelum.com.br/arredondamento-no-java-do-double-ao-bigdecimal/

    Como voce nao é o primeiro nesses 8 anos de post a fazer essa mesmissima observação, acabei atualizando o post e deixando uma nota.

    Se você não quer que o valor fique negativo e quer controlar a flutuação da vírgula, pode fazer isso tanto mantendo o modelo em String quanto em BigDecimal. Como? Olha só que curioso: evitando o getter e setter! Ou colocando ifs estranhos no seu setter. O getter nao tem tanto problema nesse caso pois ambas sao imutaveis. Mas se voce deixar o setSaldo puro, aquele que estou criticando nesse post, seja BigDecimal, seja String, qualquer um pode invoca-lo e passar um numero com virgula onde voce nao quer ou com valor negativo!

    2. Voce realmente está discutindo de thread safety e race conditions num post sobre orientacao a objetos basica? Por mais válido que seja, é um ponto que nao vem ao caso. Nem disse que ela seria acessando por mais de uma thread! Todos sabem que qualquer classe com estado mutável pode sofrer race conditions! Ou eu devo escrever isso em TODO post que tiver uma classe mutável no blog? No fim do post já havia o link para a nossa apostila de java básico, que começa a falar desse assunto aqui. Cada problema deve ser ensinado e debatido em seu momento. Repito que esse não é um post sobre a melhor forma de modelar o domínio de currency, como você mesmo já disse que é complicado e exigem diversas atenções.

    Mas vamos ao seu ponto:

    Voce está dizendo entao que precisa dos getters e setters para fazer o synchronized de fora? “Por esta e outras razões usamos um ‘setter e um getter’ para casos destes, pois assim podemos fazer um lock/bloqueio de cpu e obrigar a que a função seja sempre executada por inteiro inves de permitir a sua paragem a meio.” Por que nao remover o setter e declarar os métodos mutantes como synchronized, como por exemplo public syncrhonized void addMontante(). E tem uma vantagem: ninguem nunca vai esquecer de trabalhar com locks com ela. Alias, se uma classe deseja ser thread safe ela mesma deve cuidar de seu acesso, e não uma outra! Caso contrário o usuário dessa classe pode esquecer de usar blocos syncrhonized ou qualquer classe do juc. Não sou eu quem fala isso. Item 66 do Effective Java: nunca deixe getters/setters nao devidamente sincronizados de tudo que for shared state/data. Se não gosta, mande um tweet reclamando pro Joshua Bloch.

    Claro, voce pode me dar um exemplo em que o caso importante é gerenciado por uma classe principal e que precisa utilizar mutex do juc diretamente, e que voce quer evitar a sincronizacao excessiva. Otimo. Mas é um caso particular. Esse post NADA tem a ver com thread safety. Não é um post sobre “como implementar dinheiro”. Pra isso há a jsr 354 e tantas outras bibliotecas.

    É obvio que cada solucao vai depender do contexto! Preciso mesmo escrever isso? Preciso falar que ele deve implementar Serializable e escrever o serialVersionID se for trafegar o objeto via RMI?

    Concentre-se no assunto de OO: é ou não é ruim escrever uma classe e gerar os getters e setters dela sem nem pensar? Se no seu caso particular faz sentido ter getters e setters e voce sabe justificar, ótimo, crie-os. Em nenhum momento falo para nunca criar. Está bem claro no post é que em muitos casos pode fazer mais sentido haver apenas métodos de negócios e para ter cuidado para não acabar justificando seu Anemic Domain Model cheio de velhas ADTs do C ou dos Value Objects e Business Objects.

  14. Darcy Brás da Silva 13/01/2014 at 13:52 #

    @Paulo_Silveira Isto tudo poderia ter sido evitado se voce tivesse utilizado dbs -> “Defensive Blogging Strategies” e a nota estivesse presente desde o dia 1 e não 8anos depois, pois embora não precise explicar isso em TODO post que voce escreve, é necessario, ter uma noção de quem sãos seus leitores. Após ter tido varias pessoas, cujo a compreensão sobre a tematica abordada estava incorrecta a referenciar o seu artigo, tive que ver por mim mesmo, hora não sendo um leitor assiduo dos vosso materiais, não posso falar de outras referencias para alem da presente em questão.

    Note que em nenhum momento apontei como ‘erro’ o seu ponto de vista em relação aos getters e setters, mas sim ao exemplo escolhido para o explicar. Existem claramente exemplos em que não seria necessario estar constantemente a dizer “ignorar esta secção, a titulo de simplificação”, e no caso de existir o material a abordar o tema de forma mais aprofundada, o ideal seria no minimo deixar referencias ao mesmo.

    Espero que numa proxima tenha mais atenção, e assim todos poderemos beneficiar de uma industria mais polida (infelizmente, a verdadeira formação, continua a acontecer durante os projectos e não na faze academica).

  15. Paulo Silveira 13/01/2014 at 14:05 #

    Não há como fazer defensive blogging contra atacking trolls. Mesmo com o um excelente disclaimer, alguém poderia falar: “ah! mas repare que estou usando uma JVM embedded que não tem JIT e preciso de performance nos hotspots, logo não tem inlining de métodos. Por isso eu uso todos meus atributos públicos”. A pessoa tem razão. Acha mesmo que eu deveria escrever o post pensando nesses casos isolados? Estou escrevendo um post de um assunto específico, não um livro extensivo de um assunto generalizado.

  16. Caio Veloso Cutrim 24/01/2014 at 13:36 #

    Quero ser que nem esse cara quando eu crescer 🙂 Obrigado pelas dicas!

  17. Glauber 16/04/2014 at 09:36 #

    Paulo, você afirma que costuma colocar alguns métodos de negócio no hibernate.
    Neste caso não estaria contrariando aquela máxima “Uma classe não deve fazer nada mais ou nada a menos que foi projetada para fazer” ? Pelo que entendi, vale abrir mão de alguns paradigmas ou padrões em nome da boa programação. Seguindo esta linha de raciocínio, não seria útil, criar algumas as propriedades da classe como public ? Neste caso abrimos mão do encapsulamento, mas teríamos construtores bem mais “enxuto”, correto ?

  18. Paulo Silveira 16/04/2014 at 09:45 #

    Glauber, nesse caso ainda nao estou quebrando nada: a ideia é jogar metodos que justo pertençam a aquela classe. Se voce tem a classe Conta como @Entity, por que tiraria o saca e deposita de la? Sao metodos de negocio que fazem sentido na classe Conta, e nao na classe DepositadorDeConta. Claro, há exceções.

    E eu nunca criaria propriedade como publica. Sera um preco carissimo a pagar.

  19. Fábio 28/05/2014 at 12:50 #

    E quando criar uma instância que já tem saldo? Faço um depósito?
    Uma classe modelo foi feita pra “mapear” os dados, se quer sacar ou depositar faz um controle.

  20. Paulo Silveira 28/05/2014 at 13:34 #

    e justo isso que combato nesse post Fabio. Uma classe modelo *nao* foi feita apenas para mapear dados. Foi feita para ter dados e comportamentos. Há sim casos onde pode ser interessante deixar alguma responsabilidade para o controller, mas normalmente ele vai é orquestrar a invocação dos métodos das classes modelo. Pode ler mais sobre modelo anemico aqui:

    http://blog.caelum.com.br/o-que-e-modelo-anemico-e-por-que-fugir-dele/

  21. R.S. 08/07/2014 at 21:04 #

    Parabens Paulo, excelente post.

  22. Luís Gabriel Nascimento Simas 20/07/2014 at 11:03 #

    Paulo. Excelente Post… discordo de alguns pontos… mas, no total, o Post é ótimo. Parabens.

  23. Rodrigo Cardoso 28/07/2014 at 20:14 #

    Parabéns Paulo.

  24. Jorge Pedro 12/11/2014 at 01:18 #

    Paulo Silveira gostei muito de seu artigo. Mas tenho uma dúvida.
    Se tiver a seguinte situação: Tenho uma sistema que esta sendo evoluido gradualmente e novos recursos estão sendo implimentados constantemente. Não seria melhor criar get(s) e set(s) para mantermos o código menos acoplado. Com classes sendo herdadas se tivermos que criar um controle de acesso para esses atributos a refatoração de código será imensa.
    Qual a sua opinião?

  25. Paulo Silveira 15/11/2014 at 11:29 #

    ola Jorge Pedro. Não recomendo criar o getter/setter antes de enxergar um uso realmente necessário pra ele. Se voce criar um getter e setter agora, estará acoplando o seu código futuro com o estado interno do objeto. O melhor é esperar a necessidade aparecer, e aí ver como resolver, preferencialmente com métodos que representem lógica de negócios. E refatoração é sempre inevitável. Com getters e setters expostos 100% do tempo, a refatoração, na minha experiência, é ainda maior, dado o acomplamento.

  26. João Paulo 18/11/2014 at 19:39 #

    Explicação muito boa, pois explica muitos aspectos que eu não sabia.

  27. Pedro Lira 21/01/2015 at 13:48 #

    Olá Paulo, no meu caso que utilizo o Lombok para esta atividade de criar getter e setter. Então esta seria uma má pratica? O que me indica?

    Parabéns pelo post… Muito bom mesmo.

    Att. Pedro Lira

  28. Victor Hugo 11/04/2015 at 16:14 #

    Pedro Lira, nesse caso não use o Lombok. Pois ele é só uma ferramenta para automatizar a função de acoplar o código com getters and setters.

  29. Penha Valero 10/06/2015 at 09:12 #

    Muito bom

  30. Penha Valero 10/06/2015 at 09:13 #

    Sensacional sem duvidas!!! Continue realizando esse ótimo trabalho

  31. tiago 18/06/2015 at 14:32 #

    Boa tarde Paulo!
    No caso de uma imagem que é desenhada na tela de um game. A classe Imagem tem atributos X e Y que denotam a posição da tela a ser desenhada. Como esses atributos sempre são alterados em tempo real, a fim de gerar uma animação, eles deveriam ser PUBLIC? Porque senão teriam que ser criados os GETs e SETs e isso resultaria no mesmo que PUBLIC. Ok?

  32. Paulo Silveira 18/06/2015 at 16:48 #

    oi Tiago. Nunca é a mesma coisa. Mesmo ter gets e sets é melhor que u atributo publico. Pode ser que no futuro voce queira limitar que vlores X e Y possam ter. Se for atributo público, não tem como fazer isso sem quebrar o contrato da classe. Poderia dar o argumento de velocidade, mas isso também não acontece há bastante tempo, dado que as VMs modernas vão fazer inline de tudo isso e dar um jeito, salvo raras exceções.

  33. Denis 23/06/2015 at 09:14 #

    Paulo, a visão está correta, concordo. Porém, fiquei com uma dúvida. Como podemos popular a classe (a propriedade saldo, por exemplo) com dados vindos do banco de dados sem utilizar um ORM como o Hibernate? Se fosse fazer usando jdbc direto mesmo.

  34. Paulo Silveira 23/06/2015 at 18:25 #

    pode popular via construtor, que é justo a forma elegante de se popular dados de objetos na inicializacao

  35. Denis 25/06/2015 at 08:35 #

    Faz sentido. Obrigado!

  36. Igor Cavalcante 19/08/2015 at 18:34 #

    No caso de eu ter um objeto que é preenchido com dados de um formulário?
    Como eu faria para evitar todos os setters?

  37. Paulo Silveira 24/08/2015 at 20:41 #

    pode receber via construtor. mas se for uma obrigacao do seu framework, tudo bem, voce tem um motivo. mas seria melhor não ter esse tipo de restrição

  38. Leandro 20/10/2015 at 16:42 #

    Olá,

    Recentemente houve um debate aqui na empresa sobre uma implementação que fiz dentro dos gets de uma classe viewModel(estou usando spring).

    public classe MinhaClasseViewModel {

    List tiposA;
    List tiposB;
    …..

    public List getTiposA(){

    if(this.tiposA == null){

    tiposA = new arrayList();

    }
    return this.tiposA;

    }

    A idéia que tive é garantir que essas listas nunca seriam nulas, isso diminuiria o risco de nullPointerException e reduziria o numero de IFs para checar se a lista é nula antes de iterar por exemplo.
    No entanto, me disseram que no se deve usar new dentro de gets, pois há convenções que nao recomendam isso. Honestamente eu desconheço essa informação. Alguem sabe algo a respeito? há algum problema com minha abordagem ?

  39. Alan 29/08/2016 at 15:34 #

    Olá Paulo, li seu artigo e antes de parar aqui estava assistindo alguns vídeos na internet e lendo sobre o assunto.
    Sei que não tem relação direta com o que foi escrito, mas fiquei na dúvida em relação algumas menções nestas mídias em que dizem que há uma segurança maior em utilizar esses métodos acessores, o problema é que nesses materiais não explicam nada sobre isso.
    Há alguma relação nessa abordagem voltada a segurança? Se sim qual ?

  40. Paulo Silveira 30/08/2016 at 15:00 #

    nao é seguranca da maneira que voce pensa, e sim para programar com mais tranquilidade sem quebrar codigo. claro, é melhor do que usar atributo publico, mas encher seu codigo com acessores e modificadores tem o efeito quase nulo na ideia de encapsular.

Deixe uma resposta