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

Postado em 14. set, 2006 por Paulo Silveira em Arquitetura, Java

Atualização 2012: conheça o novo curso online da Caelum 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. Um professor sempre me disse que você só vai utilizar bem o paradigma da orientação a objetos depois de errar muito.

O Phillip Calçado tem um artigo simplesmente incrível que de certa forma aborda esse tema: 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!

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.

Paulo Silveira ()

Mais sobre o autor

Tags: , , , ,

106 Respostas para “Como não aprender Java e Orientação a Objetos: getters e setters”

  1. Araceli

    27. abr, 2011

    Excelente conteúdo, o pior de tudo é ter visto e participado de projetos desorientados. rs…
    Mas sempre vão existir erros deste tipo, que atire a primeira pedra quem ainda não cometeu este pecado. rs…

  2. Maicon Araujo de Oliveira

    21. jun, 2011

    Ótimo post. Realmente aprendemos a colocar getters e setters de qualquer maneira, seu post me abriu os olhos. Obrigado!!!

  3. Rael Max

    06. jul, 2011

    Quando estudei OO na faculdade essa foi a coisa me eu mais questionei nas aulas. Getters e Setters demais. :)

  4. Flávio Correia Lima

    19. jul, 2011

    Olá, não tenho muita experiência com Java. Começando a estudar mais a fundo agora. Fiquei com uma dúvida à respeito dos getters e setters. Além de prover acesso aos atributos esses métodos auxiliam no encapsulamento. Se eu quiser alterar a forma como acesso ou como altero o atributo a alteração ocorre apenas em um lugar (no getter ou setter). Quando você deixa de construir esses métodos você não está abrindo mão do encapsulamento? Se você precisar (em um momento futuro) alterar a forma de acesso você vai poder criar um getter ou setter, entretanto, terá que modificar em todos os lugares onde está acessando o atributo. Existe alguma saída pra isso (como o uso de properties em Python, por exemplo)?
    Abraços

  5. Pedro

    30. ago, 2011

    Ótimo post,
    Desde a época da facul nunca entendi o real motivo desses gets and sets, não programo em java ainda, porem é bem semelhante com o que acontece no C#, na vdd no C# faz menos sentido ainda…….kkkkk
    são coisas totalmente dispensaveis, tipo se vc observar alguns códigos……vc notará que as vezes para fazer uma simples tarefa que seria possivel realizar-la com 2 variaveis……a pessoa utiliza 2 ou 3 métodos com mais variaveis declaradas dentro dos métodos……….tipo não consigo entender pq as pessoas fazem isso……kkkkk
    Parabens pelo post + 1 vez….
    vlew

  6. Rodrigo

    02. set, 2011

    Interessante, mas o título está incorreto.

    No caso de programas escritos em Java, a maior motivação para getters and setters é a especificação Java Beans, a qual diversos frameworks se baseiam para acessar propriedades dos objetos.

    Com isso, algumas vezes precisamos SIM criar getters and setters, mesmo que apenas para referenciarmos “propriedades” na camada de apresentação ou para fazer o mapeamento objeto relacional (JPA, por exemplo, requer as entidades com construtor default, fazendo uso de setters para setar as propriedade dos objetos).

    A questão chave não é “como não aprender Java e OO”, e sim apresentar Java como sendo limitada em não suportar uma noção de propriedades mais elegante (como suportada por Scala ou C#).

  7. Paulo Silveira

    02. set, 2011

    Olá Rodrigo

    Na nossa opinião (e de alguns autores), o título não está incorreto.

    Na JPA, que você mencionou, não precisa de getters e setters para acessar propriedades dos objetos (seção 2.1, “The persistent state of an entity is represented by instance variables, which may correspond to JavaBeans properties” Seção 2.2 “The persistent state of an entity is accessed by the persistence provider runtime either via JavaBeans style property accessors (“property access”) or via instance variables (“field access”)“). Ela usa diretamente os atributos privados, como no Hibernate. Logo não há necessidade alguma de programar com esse monte de getter e setter. Bom é ter apenas os métodos necessários, os de lógica de negócio, pro seu objeto não acabar sendo apenas um punhado de dados, como uma estrutura qualquer.

    Mesmo se precisasse, aí é uma limitação do framework, e não da linguagem/OO. E OO em si não devemos ensinar baseado no que um framework obriga ou não você a fazer. Aliás, quanto mais obrigações um framework te impõe, mais acoplado ele é.

    Também não há relação com propriedades mais elegantes. Mesmo com propriedades, devemos tomar cuidado para não permitir reads/writes por default, e sim só se fizer muito sentido. Propriedades e getters/setters representam o mesmo problema se usados indiscriminadamente

    Como você disse, e como está escrito no próprio post, há casos em que os getters e setters são necessários sim. Mas não devem virar um hábito do programador.

  8. Rodrigo

    05. set, 2011

    Olá Paulo,

    > E OO em si não devemos ensinar baseado no que um
    > framework obriga ou não você a fazer.

    Concordo, mas o problema reside no modelo de propriedades seguido pela linguagem Java, e que desenvolvedores de frameworks ou de aplicações precisam se basear. Inclusive, essa noção de getters and setters está disseminada em Java (especificação Java Beans), não sendo seguido no ensino de outras linguagens OO (basta ler boas referências de Smalltalk, C++, …., Scala).

    Claro que Java é uma linguagem relevante (tenho mais experiência em Java, falar mal, é dar um tiro no meu próprio pé), mas seu processo de evolução está muito lento- e esse modelo de propriedades precisa ser repensado (conforme indicaram nas discussões iniciais sobre Java 7, apesar de terem evoluido pouco nesse sentido).

    Ao meu ver, sem “assumptions” como getters and setters (ou, de preferência, um modelo de componentes / propriedades de mais alto nível), fica difícil desenvolver frameworks com qualidade (pelo menos eu não considero o acesso direto a fields uma boa alternativa).

  9. Infax

    23. set, 2011

    Flávio, creio que você está assumindo que, sem getters e setters o programador tornaria os atributos públicos. Não é o que está sendo sugerido no artigo. O artigo sugere que alguns atributos são usados apenas para cálculos internos ou devem ser acessados com lógicas um pouco mais rebuscadas que um simples getter. O exemplo de método “saca” é um caso desses em que o valor do atributo saldo pode ser alterado sem usar o setter, mas usando um método que faz sentido dentro da lógica do negócio.

  10. Adams Zago

    19. out, 2011

    Sempre ouvimos dizer que, os métodos get e set devem possuir alguma razão de existir. Eu realmente concordo com isso. Logo fica uma dúvida. Numa aplicação JSF em que tenho uma lista de determinado objeto, a atualização desta lista deveria estar no get ou em outro método? Estando no get estaria ferindo algum padrão? Piorando a performance?

  11. Jesse James

    04. jan, 2012

    Parece que tem gente que não sabe ler. O artigo não é contra o uso de getters e setters, ele condena o uso indiscriminado. Os getters e setters são úteis mas devem ser usados de acordo com as regras do negócio, e respondendo a alguns que perguntaram: encapsulamento não é apenas ocultar atributos, mas tornar eles acessíveis apenas para satisfazer a aplicação, o exemplo citado emula o funcionamento de uma conta bancaria real onde não se atribui um valor a um saldo, mas esse valor é alterado via atividades inerentes à atividade bancaria como depositar e retirar dinheiro.

  12. Paulo Silveira

    04. jan, 2012

    Jesse, exatamente!!! É um alerta para a criação indiscriminada, que ocorre frequentemente.

  13. Marcelo Nalon

    18. jan, 2012

    Olá, também não tenho muita experiência com Java e estou apenas começando, mas concordo com o nosso amigo Flávio. No que eu aprendi até hoje, os métodos get e set servem para manter uma boa engenharia de software, uma vez que é mais fácil manter códigos que fazem uso deles. Pense numa classe bem grande que tenha vários métodos que utilizam um determinado atributo. Se por ventura for necessário por exemplo fazer uma modificação no nome do atributo, seria necessário alterar o nome em todos os métodos que utilizam esse atributo também. Usando get e set só seria necessário alterar o nome do atributo nesses dois métodos.

  14. Paulo Silveira

    18. jan, 2012

    Olá Marcelo

    Um simples refactoring de nome de atributo resolve esse problema com um clique. Nao é para nao ter de renomear um atributo que voce deve usar um getter/setter. Getter e setter só é bom se realmente faz sentido pro seu modelo, entao depende do domínio.

    Cria uma classe cheia de getter e setters, automaticamente, é um péssimo hábito em relação a engenharia de software. Aqui tem uma discussão mais aprofundada:
    http://www.arquiteturajava.com.br/livro/cuidado-com-o-modelo-anemico.pdf

  15. Marcelo Nalon

    18. jan, 2012

    Sim, é verdade… mas isso se você estiver usando uma IDE né.
    Interessante, no livro do Deitel, ele cita uso dos getters e setters como uma boa prática, por isso é sempre bom buscar mais de uma fonte de referência.
    Você tem esse livro disponível em pdf??

  16. Paulo Silveira

    19. jan, 2012

    oi Marcelo. o livro tem pra vender online:
    http://www.arquiteturajava.com.br

    o Deitel é enxuto em algumas partes de design. Receitas de bolo devem ser executadas com cautela.

  17. JOSÉ RONALDO LELES JÚNIOR

    18. mai, 2012

    Parabéns! Excelente post! A Equipe da Caelum como sempre passando as melhores informações. Me orgulho de já ter feito curso na Caelum!!!

  18. Faculdades = SCUM

    19. mai, 2012

    E essas faculdades lixo com esses professores igualmente imprestáveis vão contaminando a mente dos alunos com essas péssimas práticas. Até que algum sujeito venha realmente aprender as coisas da maneiras correta, já se perdeu muito tempo, dinheiro e oportunidades como desenvolvedor. Hoje recomendaria faculdade apenas pelo título e por lá praticar como escrever relatórios de acordo com a norma ABNT e nada mais. A Caelum é, sem sombra de dúvida, melhor do que qualquer faculdade de TI nesse país.

  19. Sena

    29. mai, 2012

    Questionei getters e setters meses atras para o meu professor de faculdade e ele disse que não tinha nenhum problema e que aconselhava criar todos getters e setters. O que nunca fez sentido na minha cabeça…

    Parabéns, bela explicação.

  20. Ronaldo Morais

    14. jun, 2012

    As faculdades abusam do uso de getters e setters como uma maneira de habituar o estudante a usar essa forma de encapsulamento. Não há nenhum mal em usá-los, desde que seja feito com bom senso (como mostra o artigo).

    Na verdade muitos programadores, principalmente quem vem de linguagens que usam programação estruturada, tem o habito de abusar de variáveis de instância para representar dados de entidades. Isso significa encapsulamento zero e enfraquece a estrutura de código. Então, é melhor exceder no uso de getters e setters do que cometer um erro maior.

    O que falta é trabalhar os iniciantes para aperfeiçoarem essa prática, utilizando outros meios de encapsulmento (getters e setters compõem apenas um meio).

    Abraço,

    Ronaldo Morais

  21. Ademir Giraldelli

    26. jun, 2012

    Olá!

    Somente uma observação com relação ao método saca da classe Conta.

    Ele vai lançar a exceção sempre”

    throw new IllegalArgumentException(“estourou limite!”);

  22. Paulo Silveira

    26. jun, 2012

    perfeito! faltava um return ou um else. coloquei um else

  23. agente x

    12. jul, 2012

    Bom, aqui acolhemos muitas informações a respeito dos getters e setters, ok deve ser usado com a conciência; o caso é que os mesmos se baeseam em capusular as informações de forma que os dados ficam protegidos para que uma chamada nao esperada posso acessalo. Até agora nao vi um exemplo satisfatório que possa paramentrizar a ações que seja importante sem o uso dos getters e setters.

    Alguem se habilita ?

  24. Paulo Silveira

    13. jul, 2012

    @agentex, nesses casos a solução é usar o contrutor. alias, ele existe justo para passar tudo o que o objeto precisa para funciona (configuracoes, recursos, dependencias, etc). Se ficar complicado, use um Builder.

  25. agente x

    17. jul, 2012

    Então Paulo Silveira, para usar construtor não teria que ser tudo na mesma classe ? E se o programa usar mais de uma classe como ficaria para stanciar, não teria problemas ?
    já que quando se trabalha com contrutor usa-se stanciar. stancia() {
    dessa forma nao usa a stancia sobrecarregada; diferente do getters e setters.

  26. Ricardo

    16. ago, 2012

    Olá,
    Quero aprender Java, mas antes quero aprender POO, pois acho mais logico que começar logo com Java.
    Alguém pode me indicar um bom livro de POO?

  27. Andre Girão

    10. out, 2012

    Ate um dia desses fiz uma prova na faculdade que precisávamos informar todos os atributos e getters e setters

  28. JAVA10

    09. nov, 2012

    Não concordo com o que foi esboçado neste texto. Se o desenvolvimento em questão é apenas para fim de estudos ou algum trabalhinho de faculdade concordo que terão getters e setters em excesso, mas se você estiver numa equipe de desenvolvimento criando um sistema profissional, robusto e cheio de funcionalidades é de extrema necessidade a criação deles, pois pode muito bem necessitar de um deles que nem se esperava pra fazer alguma funcionalidade por mais trivial que seja. Criar getters e setters não aumenta o custo computacional, não torna o código ilegível e não da trabalho pra fazer, então não vejo o problema de construir-los.

  29. Paulo Silveira

    12. nov, 2012

    oi “Java 10″. A sua justificariva ” Criar getters e setters não aumenta o custo computacional, não torna o código ilegível e não da trabalho pra fazer, ” poderia ser aplicada a diversas más práticas de computação. O getter e setter tem custo SIM. Ele aumenta seu acoplamento quando muitas vezes não há necessidade para tal. Seu objeto acaba virando uma simples estrutura de dados, como nas linguagens procedurais. Getter
    e sim útil. Gerrar getter e setter sem pensar é uma péssima prática.

  30. daniel waite

    20. nov, 2012

    Creio que Paul e Harvey Deitel não o fizeram de propósito, pois getters e setters fazem parte da Linguagem Java, e não conhecê-los seria um pouco estranho, mas a maneira de utilizá-los vai mais do amadurecimento do programador OO em saber quando utilizá-las ou nao !!! Eu que sou apenas um dev-jr me irritei varias vezes, e sozinho descobri que essee getters e setters só fazem vc perder tempo e neuronios preciosos; mas o importante é saber bem usar Interfaces, construtores, e metodos sobrescritos e sobrecarregados, para daí utilizar de forma elegante o polimorfismo !!!!
    Abraços galera !!!!

  31. Marcus

    24. nov, 2012

    O problema é que: para cada 2 classes nas quais você vai poder escolher minuciosamente quais membros terão getters e setters, quais terão só getters, quais serão acessíveis por regras de negócio (como “depositar” e “sacar”) e quais serão realmente privados; haverá 10 classes que realmente serão alguns atributos e um monte de getters e setters, porque algum framework exigiu (CDI, JSF, JPA, qualquer framework que exija um “bean”).

    E a refatoração é um saco: o tipo do dado fica repetido nuns 3 lugares e o nome fica repetido nuns 6 lugares (nomes de métodos, parâmetros, corpo do getter ou setter). A gente acaba apagando tudo e mandando gerar de novo (e o perigo de um getter ou setter daqueles não ser tão trivial quanto parecia e ser apagado sem querer?!).

    Estou cada vez mais tentado a usar o projeto Lombok (
    http://projectlombok.org/ ). O código fica umas 10 vezes menor, e aqueles surtos de vontade de mudar para Ruby ou C# vão embora na hora :-)

    O meu único receio é a interação com as ferramentas (Eclipse, refatoração automática, localizar e substituir, “ir para”, warnings antes mesmo de compilar, NetBeans, Maven, velocidade de compilação etc.). Dizem que o Lombok atualmente está ficando muito bom em integração com as ferramentas, e num projeto pessoal eu usaria, mas num projeto institucional não é tão simples… Bom, na verdade nem fiz o download ainda pra testar, talvez seja melhor do que eu penso :-)

    Será que no Java 9 ou 10 incluem os recursos do Lombok? Aposto que quando fizerm isso, vão anunciar como sendo a maior maravilha do mundo, como se não existisse já em várias outras linguagens :-p

  32. Iago Frota

    22. jan, 2013

    Muito bom. Bem no começo, quando estava aprendendo, 1º criava as variáveis private logo em seguida getters e setters. Quando ia testa os métodos, pouco ou nunca usava alguns getters e setters. Artigo muito bom. Parabéns!

  33. Vanderson Assis

    19. fev, 2013

    Grande Paulo!
    Ficou massa esse artigo em, abriu um pouco mais meus olhos quanto a OO. rs … abraço!

  34. Bruno

    19. fev, 2013

    De fato, a criação de getters e setters sem sentido é um anti-padrão já mencionado por Martin Fowler em 2003, conforme no site http://martinfowler.com/bliki/AnemicDomainModel.html . No entanto, existe frameworks Web que, infelizmente, fazem uso desses getters e setters onde o desenvolvedor “automaticamente” os cria e mantem esses métodos. O ideal é ter atenção ao desenvolver para não ser mais um “Java Monkey” no mercado…

    Como somente agora tive a oportunidade de ler esse artigo, fica os meus parabéns!!

  35. Wederson

    25. fev, 2013

    Excelente artigo!
    Conciso, foi direto ao ponto.
    Existem frameworks “viciados” em getters e setters, o que por sua vez influencia os recém chegados às linguagens OO.
    Muitas vezes vi pessoas alegando que precisam deles para evitar um construtor “longo”, com muitos parâmetros. Mas mesmo nesses casos existem alternativas.
    Programo em várias linguagens, e em algumas OO, dentre elas Java e C#, e esse problema afeta todas as linguagens que conheço.
    Parabéns!

  36. Sancarlo

    09. mar, 2013

    Paulo, muito interessante o tema. Parabéns. Paulo, analisando o seu exemplo e levando a abordagem OO ao extremo fiquei com a seguinte dúvida: Seria o método depositar realmente responsabilidade da entidade Conta? Veja bem. Se compararmos sua modelagem (Conta) com conceitos de negocio, ou seja coisas do mundo real, fica estranho ter uma conta que se auto-deposita, certo? Pois, no mundo real, a ação de depositar deveria ser de um depositante(o correntista, o banco, agencia…) e não da conta. Analogamente, seria como se na modelagem de sistema(game) de futebol atribuissemos a ação de chutar à bola e não ao jogador. Ou seja, um método conta.depositar(xxxx) é bem parecido com bola.chutar(xxx). Estranho, não? O qu você acha? Novamente parabéns pelo post.

  37. Paulo Silveira

    11. mar, 2013

    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

  38. SancarLo

    12. mar, 2013

    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.

  39. Paulo Dantas

    22. abr, 2013

    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.

  40. Paulo Silveira

    22. abr, 2013

    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

  41. Andrey F. Alves

    06. mai, 2013

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

  42. Paulo Silveira

    06. mai, 2013

    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.

« Comentários mais antigos

Trackbacks/Pingbacks

  1. Fragmental » Mais (ou melhor: menos!) Getters e Setters - setembro 19, 2006

    [...] O Paulo Silveira postou há uns dias no blog da Caelum um artigo sobre o uso indiscriminado de getters e setters, incluindo uma referência para o artigo daqui do Fragmental sobre “classes de dados”. [...]
  2. blog.caelum.com.br » Como não aprender orientação a objetos: Herança - outubro 14, 2006

    [...] Já falei sobre os problemas que os getters e setters podem trazer, caso usados de maneira indiscriminada. A bola da vez é a herança. [...]
  3. blog.caelum.com.br » Relacionamento bidirecional entre classes - março 28, 2007

    [...] Isso tudo pode ser muito mais complicado em relacionamentos 1:N e N:M. O conselho é tentar evitar o relacionamento bidirecional, e nunca cria-lo sem uma real necessidade, assim como já comentamos sobre evitar herança e evitar getters e setters. [...]
  4. » JustJava 2007, Arquitetura e Caelum » blog.caelum.com.br - outubro 8, 2007

    [...] Toda vez que uma classe de domínio é criada em um sistema como esses, suas irmãs também aparecem: BOs, VOs, LOs, XYZs. Utilizar TOs apenas para transportar objetos entre camadas (e não tiers) não faz sentido algum, polui o código e diminui flexibilidade e manutenção. Separar funcionalidade e dados entre BOs e VOs é outro grande problema: onde está a orientação a objetos? Entity beans apenas com getters e setters é um mau sinal. [...]
  5. O momento em que Java quase virou .Net e C++ ao mesmo tempo « Objectzilla - outubro 24, 2007

    [...] Estou convencido de que nunca na história desse país, o uso de gettes e setters foi tão criticado. E isso porque uma classe com apenas getters e setters não é muito diferente de uma struct no [...]
  6. O uso indiscriminado de getters e setters! « TJRN Developers - fevereiro 9, 2008

    [...] criar uma classe com seus atributos e colocar automaticamente todos os getters/setters possíveis. Este post da Caelum trata justante do uso indiscriminado de getters e [...]
  7. marcuscavalcanti » Blog Archive » Getters e Setters? - janeiro 14, 2009

    [...] código. Links InteressantesFowler e GettersGetter ErradictorWhy getter and setter methods are evilComo não aprender Java e orientação a objetosSHARETHIS.addEntry({ title: “Getters e Setters?”, url: [...]
  8. O que é encapsulamento? « S A B E R E S - maio 5, 2011

    [...] a leitura de um post no blog da caelum que explica sobre a criação de getters e setters, clique aqui para acessá-lo. É isso aí galera, espero que tenham gostado e não deixem de comentar. Até a [...]
  9. Scala: os cuidados com encapsulamento | blog.caelum.com.br - julho 26, 2011

    [...] A criação de getters e setters deve ser feita com cuidado: uma vez que a implementação é exposta através de um getter e setter, a remoção dele, para finalmente encapsulá-lo, implica na mudança de todas as chamadas a ele. Em Ruby, o mesmo cuidado pode ser tomado: [...]
  10. REFACTORING – Caso Real e boas maneiras Parte IV (Keep Walking…) « Yuri Adams - novembro 27, 2011

    [...] privilégio. Então é isso, mais um caso prático de como melhorar seu código. Excelente dica: Como não aprender OO com java. Excelente post da [...]
  11. POO – Material Complementar | Material de Acompanhamento – UFS - dezembro 3, 2011

    [...] Como não aprender Java e Orientação a Objetos: getters e setters Como não aprender orientação a objetos: o excesso de ifs Como não aprender orientação a objetos: Herança [...]
  12. Revisitando a Orientação a Objetos: encapsulamento no Java | blog.caelum.com.br - junho 14, 2012

    [...] Objetos junto com os instrutores da Caelum, há mais posts por aqui, como um específico sobre esse problema dos getters e setters, o excesso de ifs e o relacionamento bidirecional entre classes. Quer praticar tudo isso com video [...]
  13. O “objeto” bom cidadão (Good Citizenship) « Marcos Brizeno - novembro 26, 2012

    [...] 2008. [2] Paulo Silveira, Como não aprender Java e Orientação a Objetos: getters e setters. (http://blog.caelum.com.br/nao-aprender-oo-getters-e-setters/) [3] Marcos Brizeno, Mão na massa: Singleton [...]
  14. Java menos verboso com Lombok | blog.caelum.com.br - fevereiro 18, 2013

    [...] vimos como não aprender Java e Orientação a Objetos. Aprendemos que a geração indiscriminada de getters e setters pode quebrar o encapsulamento de [...]

Deixar uma Resposta