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

Muitas pessoas perguntam:

como aprender orientação a objetos?

Há várias maneiras de aprender O.O., creio que não tenha uma melhor, mas existem maneiras de não aprender. Esse post, criado em 2006 e atualizado em 2017, mostra como o design de classes continua seguindo algumas regras de boas práticas importantes.

Uma das práticas mais controversas que aprendemos no início do aprendizado de muitas linguagens orientadas a objeto é 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 esses 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 e deveria 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, o que pode ser muito nocivo: como você vai logar aumentos de saldo, se a forma de alterar saldo de uma conta está espalhada por todo seu sistema?

Tirar dinheiro gera uma situação ainda mais delicada: se precisar verificar se há saldo na conta antes de subtrair um valor do saldo, onde ficará esse if? Espalhado por todo o sistema em diversos pontos? O que acontecerá quando precisar alterar essa regra de negócio?

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 sentiria falta de alguns métodos mais voltados a lógica de negócio da sua aplicação, como o saca e o deposita.

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 batizou de POS, ou programação orientada a strings), milhares de métodos estáticos, entre outros.

Todas essas práticas são comuns quando estamos começando a quebrar o paradigma procedural e confesso já ter sido um grande praticante de algumas. 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 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. E, claro, pode ser que o seu caso justifique a criação desses métodos.

Vemos bastante esse tópicos nos cursos de Java e de .NET na Caelum.

146 Comentários

  1. Pedro 27/05/2010 at 21:58 #

    Cara vocês são demais!

    Estou expandindo meu conhecimento em OO e as discussões presentes neste post e o mesmo me fizeram compreender muito melhor o paradigma de OO.

    Obrigado pela oportunidade!

    Keep Walking!

  2. Rômulo Augusto 29/07/2010 at 01:12 #

    Uma observação: VO não é DTO, segundo Fowler e Evans.

  3. Paulo Silveira 29/07/2010 at 13:10 #

    @Romulo, certamente. Por isso deixei entre parentes. estava falando de DTO, mas a nomenclatura antiga da Sun chamava os DTOs de VOs, hoje em dia eles ja se alinharam: DTO para transferencia entre tiers, VOs para objetos “sem identidade”.

  4. Daniel Alencar 18/08/2010 at 10:34 #

    Paulo,
    Na verdade, na orientação objetos, a utilização de construtores é uma péssima prática, uma vez que utiliza-los nos remete a um dos acoplamentos horríveis de se tratar, a saber: “Acoplamento de tempo” ou dependência temporal. E outra, sim, se minha classe tem 61 atributos exclusivos eu poderia utilizar o padrão “invenção pura” do Craig Larman para diminuir o acoplamento, mais isso aumentaria a minha coesão? É dificil afirmar que se uma classe tem 61 atributos ela deve ser quebrada, sem conhecer o domínio do requisito, que é primordial quando vamos atribuir responsabilidades as classes. Um outro ponto, é o seguinte: VOs, para objetos “sem identidade”. Ora, para ser objeto ele tem de ter três características básicas, a saber: comportamento, estado e identidade. Sem ele não tem identidade, logo ele não é um objeto.

  5. Paulo Silveira 18/08/2010 at 10:53 #

    @Daniel: Descorto totalmente em relacao a pratica do construtor. Qualquer referencia de OO, como o Fowler, Uncle Bob e todo mundo de IoC. Alias, o uso de construtor para dependencias é o principio basico do “good citizen principle”. É a unica maneira de garantir a consistencia do seu objeto desde o momento de sua criacao. Obviamente voce nao vai utilizar o construtor para fazer o setup de uma dependencia cara e temporal, é claro que vao haver casos para se usar setters e initters.

    Sobre a quantidade excessiva de atributos, voce tem razao: nao existe metrica magica para dizer que voce deve quebrar sua classe, seu metodo, depende do contexto. Mas 61 atributos liga um sinal amarelo, sem duvida (alias, ferramentas como o checkstyle vao ligar a luz vermelha para uma classe com 61 atributos, mas existem casos que pode fazer sentido).

    Sobre os VOs, creio que voce tenha interpretado “identidade” de outra maneira. Existem centenas de exemplos faceis de objetos sem identidade: Dinheiro, Data, etc. O que diferencia dois objetos que representam 50 dolares? Nada. Voce pode trocar um pelo outro, mesmo tendo estado. Creio que voce esteja confundindo identidade e estado

  6. Jefferson Santana 28/01/2011 at 03:33 #

    Realmente, quando comecei a aprender Java estava na faculdade de Ciência da Computação, disciplina LP3, porem um semestre é pouco pra tanto assunto… no fim ficava me perguntando pra q declarar os atributos como private, se temos os sets…?
    Bom artigo, uma questão básica que muitos iniciantes passam sem nem perceber!

  7. Lisasf 27/03/2011 at 15:51 #

    Olá, estou iniciando em JAVA e vi o endereço desse artigo na apostila FJ11 que baixei do site da Caelum.
    Estou espantada como os comentários aqui postados me estao ajudando… Não tenho uma contribuição, mas me senti na obrigação de elogiar o posti. Parabéns ao autor e a todos que contribuiram. Abraço.

  8. Araceli 27/04/2011 at 11:28 #

    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…

  9. Maicon Araujo de Oliveira 21/06/2011 at 07:43 #

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

  10. Rael Max 06/07/2011 at 14:42 #

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

  11. Flávio Correia Lima 19/07/2011 at 17:18 #

    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

  12. Pedro 30/08/2011 at 17:48 #

    Ó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

  13. Rodrigo 02/09/2011 at 10:05 #

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

  14. Paulo Silveira 02/09/2011 at 13:15 #

    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.

  15. Rodrigo 05/09/2011 at 10:42 #

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

  16. Infax 23/09/2011 at 22:38 #

    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.

  17. Adams Zago 19/10/2011 at 11:12 #

    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?

  18. Jesse James 04/01/2012 at 11:12 #

    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.

  19. Paulo Silveira 04/01/2012 at 12:20 #

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

  20. Marcelo Nalon 18/01/2012 at 20:24 #

    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.

  21. Paulo Silveira 18/01/2012 at 20:33 #

    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

  22. Marcelo Nalon 18/01/2012 at 20:52 #

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

  23. Paulo Silveira 19/01/2012 at 09:31 #

    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.

  24. JOSÉ RONALDO LELES JÚNIOR 18/05/2012 at 10:59 #

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

  25. Faculdades = SCUM 19/05/2012 at 06:07 #

    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.

  26. Sena 29/05/2012 at 16:17 #

    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.

  27. Ronaldo Morais 14/06/2012 at 20:58 #

    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

  28. Ademir Giraldelli 26/06/2012 at 22:11 #

    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!”);

  29. Paulo Silveira 26/06/2012 at 22:25 #

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

  30. agente x 12/07/2012 at 23:08 #

    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 ?

  31. Paulo Silveira 13/07/2012 at 08:55 #

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

  32. agente x 17/07/2012 at 22:54 #

    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.

  33. Ricardo 16/08/2012 at 22:45 #

    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?

  34. Andre Girão 10/10/2012 at 11:39 #

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

  35. JAVA10 09/11/2012 at 21:41 #

    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.

  36. Paulo Silveira 12/11/2012 at 13:32 #

    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.

  37. daniel waite 20/11/2012 at 15:20 #

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

  38. Marcus 24/11/2012 at 15:02 #

    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

  39. Iago Frota 22/01/2013 at 23:51 #

    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!

  40. Vanderson Assis 19/02/2013 at 11:27 #

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

  41. Bruno 19/02/2013 at 14:44 #

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

  42. Wederson 25/02/2013 at 20:13 #

    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!

  43. Sancarlo 09/03/2013 at 06:07 #

    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.

Deixe uma resposta