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

Por Paulo Silveira em 14/09/06

Muitas pessoas me perguntam “como aprender OO?”. Há várias maneiras de aprender OO, creio que não tenha uma melhor, mas sem dúvida alguma existem maneiras de não aprender.

Uma das piores práticas 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; } 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.

Em uma próxima oportunidade falarei de outro vício muito citado pela literatura básica: herança.

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. E em breve teremos uma versão 2.0 desse material.

Postado em design patterns, hibernate, java, oo |

33 Comments »

Essa história dos setters não serem necessários vai ainda mais longe!

Em muitos casos é ótimo (chega a ser uma boa prática) que o seu objeto não possa ser modificado (nem por métodos set, nem por nenhum outro). Isso o caracteriza como um objeto imutável, que NUNCA irá sofrer de nenhum problema de concorrência!

Já que o objeto é imutável, pode ser acessado concorrentemente por quantas Threads seja necessário, já que nenhuma delas poderá alterá-lo!

Fica a dica: seu sistema é multi-threaded? => Use objetos imutáveis sempre que possível! E você nem vai esquentar a cabeça com synchronized …

Comment by Fabio Kung — September 15, 2006 @ 1:53 pm
Muito bom o artigo é muito comum o exagero no uso de setters.
O que vem a ser a utilização de ids para relacionar os objetos? No banco de dados se usa IDs mas com relação aos objetos não entendi. Se pudessem me dar um exemplo disso ficaria agradecido. Obrigado.

Comment by Valerio Ferreira — September 19, 2006 @ 8:40 am
[...] 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”. [...]

Pingback by Fragmental » Mais (ou melhor: menos!) Getters e Setters — September 19, 2006 @ 10:28 am
Olá Paulo,

Permita que eu faça alguns comentários sobre o seu artigo. Em primeiro lugar achei bem interessante a sua discussão, trazendo bons questionamentos à minha mente.

Entretanto, acho um certo equívoco da sua parte massacrar os coitados dos getters e setters, por motivos de regras de negócio.

Concordo plenamente que a visão de negócio deva imperar sobre a construção do software, e que questionar a existência de cada getter e setter pode ser realmente bom, mas:

(1) Se você está construindo uma API que será liberada para um conjunto de desenvedores, é bom que você forneça meios de extender essa API para que não fique tentando acomodar todas as regras do mundo ao mesmo tempo. Assim, alguns dos desenvolvedores usuários vão precisar acessar a sua API de uma forma não-tradicional e você vai ter que fornecer getter e setters adicionais (e outros recursos também, claro).

(2) Se você estiver depurarando seu código e quiser saber quando uma determinada propriedade sua - digamos saldo - está sendo setada, você terá que espalhar muitos breakpoints se não tiver um setter disponível. É claro que se a sua classe for pequena, isso não vai dar muito trabalho, mas pense em classes grande, com variados níveis de herança (não que eu aprove isso, mas isso existe por aí). Será que um setter vai sempre contra os princípios de programação?

(3) Você mencionou como sendo “praticas piores” a utilização de ids para relacionar os objetos. Cuidado porque isso é um padrão comprovado para sistemas baseados em componentes (minha especialidade) [Veja o livro "Business Component Factory", Herzum e Sims, para mais detalhes]. Concordo que, para sistemas orientados a objetos, isso realmente não é o ideal.

(4) Substituir setters por “bons construtores” também é perigoso. Eu trabalho num sistema que tem JavaBeans com até 61 propriedades, todas válidas no contexto de negócio. Você teria coragem de construir um construtor para esse caso?

Espero apenas ter contribuído para as suas idéias.
Gostei do artigo e vou adicionar seu site aos meus feeds.
Como instalei o feeds no meu site há pouco tempo, convido a todos também a fazer o subscribe.

Grande abraço,
Hugo.

Comment by Hugo Vidal Teixeira — September 19, 2006 @ 12:07 pm
Olá Hugo.

Sobre os seus pontos:

(1) e (2) - não quis dizer para você nunca colocar um setter. o que quis mostrar é que as pessoas colocam um getter e setter sem motivo algum! se você tem um bom motivo para colocar um getter/setter, e pensou nisso antes, ótimo! Aí não há problema algum!

(3) - Não sei exatamente qual é o seu caso, mas se realmente não há outra maneira de relacionar os componentes, ok. Mas hoje em dia com injeção de dependências você normalmente não precisa de id nenhum, basta seu construtor/setter/annotation declarar que precisa de determinado componente, para ele ser injetado de algum contexto. Não conheço a referência bibliográfica, então não posso comentar sobre esse seu caso mesmo…

(4) - Não colocaria 61 parâmetros num construtor, mas eu certamente nunca teria um javabean com 61 atributos!! Certamente eu quebraria esse bean em mais uns outros 4 ou 5. É o mesmo caso de ter uma tabela com 61 campos… criaria outras tabelas e amarraria em relações one-to-one. Uma classe com 61 atributos certamente está virando um monstro fora de controle, ou você tem um caso muito peculiar. E sobre substituir com o construtor ainda tem a vantagem que o Fábio Kung comentou: você pode ter a vantagem da imutabilidade (bom para hash, thread safety, etc).

agradeço muito o comentário!

Comment by Paulo Silveira — September 19, 2006 @ 12:19 pm
Esse artigo mostra exatamente o porquê do Eclipse não possuir um atalho para gerar todos os Getters e Setters de uma classe =)

Comment by Fernando Boaglio — September 19, 2006 @ 12:39 pm
Depurar código na verdade é perder um pouco o controle do seu código. É o momento onde você não sabe mais dizer o que acontece com ele.

No XStream por exemplo, não existe api de logging nem usamos debugging pois a stacktrace é suficiente para identificar que tipo de problema ocorreu.

Sobre o item (3) também vale lembrar que no mundo orientado a objetos, os ids são maléficos. No mundo OO. Não no mundo relacional onde são justamente a maneira de fazer as coisas funcionarem.

É a mesma discussão de ponteiros x ids em C/C++.

Comment by Guilherme Silveira — September 20, 2006 @ 9:22 am
Oi Hugo,

Expor os seus atributos indiscriminadamente através de getters e setters de modo a prover uma extensibilidade aos seus componentes é de certa forma ilusório.

Quando você faz isso, você quebra o encapsulamento expondo coisas sobre os seus objetos que outros objetos não deveriam conhecer. Além do mais, se o que você quer é ampliar as responsabilidades de uma classe, por que não adicionar mais métodos na própria classe?

Quando você adiciona funcionalidade/comportamento/responsabilidade nova a uma classe fora dela você faz código procedural. Seus objetos acabam se tornando meros fantoches cheios de getters e setters e sem responsabilidade nenhuma. Como se fossem meras estruturas de dados!

Já a outra classe com o comportamento só se preocupa em manipular o seu fantoche. Como se fosse apenas uma função.

Separar os dados do comportamento vai contra tudo que a OO prega!

Comment by Fabio Kung — September 20, 2006 @ 9:30 am
Em alguns casos o uso de getters/setters é indicado, como por exemplo quando se está utilizando o Hibernate como framework de acesso à base de dados, ele utiliza-os para resgatar os dados da base.

Comment by Leonardo Cabral — September 21, 2006 @ 10:34 am
Olá leonardo, o hibernate não precisa de getters e setters (a não ser que você marque que quer acesso via métodos), pois ele manipula o bytecode para criar as proxies e manipular seus atributos (pra falar a verdade, pra manipular os atributos private você nem precisa de um manipulador como a cglib)

Comment by Paulo Silveira — September 21, 2006 @ 10:42 am
Oi Leonardo,

Se você não quer expor os seus atributos, nem quando você usa Hibernate você precisa colocar os getters e setters indiscriminadamente.

As ferramentas atuais são mais expertas e se não tiver um getter/setter, elas modificam o atributo diretamente com reflection.

Comment by Fabio Kung — September 21, 2006 @ 10:43 am
[...] Já falei sobre os problemas que os getters e setters podem trazer, caso usados de maneira indiscriminada. A bola da vez é a herança. [...]

Pingback by blog.caelum.com.br » Como não aprender orientação a objetos: Herança — October 14, 2006 @ 10:42 pm
Interessante pensar assim, muitos de nós achamos que sabemos, orientação a objetos, quando estamos mesmo é usando o paradigma procedural.
Veja não diferença nenhuma.

public class Aluno()
{
private String nome;
public void setNome(String nome)
{this.nome = nome;}
}

para uma struct do Czão bom.

struct Aluno
{
*char nome;
}

….Diferença ? “Eu vejo pouca”

Mas note, que quando sabemos mesmo a criar soluções orientadas a objetos, tudo muda, usamos sim a herança o encapsulamento as mensagens entre as classes, tudo num perfeito mecanismo vivo.

Objetos conversando….

Hoje posso dizer que estou começando a entrar no mundo do OO de verdade, venho do .NET para o Java. E meu aprendizado foi mais intenso e profundo.

Comment by Leandro — November 22, 2006 @ 10:36 am
*\
Esse artigo mostra exatamente o porquê do Eclipse não possuir um atalho para gerar todos os Getters e Setters de uma classe =)

Comentário de Fernando Boaglio — Setembro 19, 2006 #
\*

O Eclipse possui esse recurso sim
-
Eu acredito que a utilização de getter / setter são válidas quando se tem a necessidade de validar ou fazer algum tratamento com a ‘informação’ que a variável irá receber, principalmente quando se trabalha com construções de serviços que seram utilizados por vários desenvolvedores.
Parabéns pelo artigo Paulo! Realmente se você pegar um livro que ensina o básico de OO e também em qualquer curso de OO que você for fazer, é sempre a mesma história: “Distribua get/set em seu código e seja feliz!”. O que não é uma realidade…

Comment by Thiago Ferraz — November 24, 2006 @ 3:56 am
De modo geral, concordo que os seus pontos neste artigo, Paulo. Em inglés, as vezes chamamos estes “beans getseterados” de “Glorified Hashtables”, pois afinal não são quase nada mais do que “sacos de atributos”, ou mesmo structs, como destacou o Leandro acima.

O pior caso, é quando você vê a estrutura normal de um projecto “multi-camada” J2EE moderno, que contém níveis intermináveis de código para copiar valores de atributos dinámicos (ex. um HTTP parámetro) para um atributo compilado (ex. um bean property), que depois está copiado para um VO, para um Map, para um EJB atributo, através de milhas de código usando Reflection.

Apenas com a ajuda de ferramentas bem-pensadas com Spring, Cglib, Hibernate, ou o OFBiz Entity Engine, que fica aguentável.

Contudo, gostaria de discutir alguns pontos contigo.

1. Com todo respeito para alguns dos posters aqui, não creio que fazendo uma distinção como “as vezes achamos que tamos a fazer O-O enquanto de facto tamos a fazer procedural” ajudam muito em escolher bons desenhos. O que ajuda são artigos bem-explicados e focados, sobre casos específicos como este de getters e setters. Pessoalmente, embora “cresci” num ambiente O-O, nunca vi um sistema “puramente O-O”, e duvido que uma vez vou. Tem enormes quantididades de pensamento valioso que foi feito pelos programadores desde os anos 60, usando abordagens procedurais, data-driven, etc, que as vezes pessoas da nossa geração simplesmente desconhecem, para o meu espanto, porque estão tão fanáticos para o “puro OO”. Para integração de sistemas, ou protocolos de rede, por exemplo, nunca vi um projecto bem-sucedido que não aproveitou muito de certas tácticas bem mais antigas do que O-O.

Não me parece que aqui temos esses fanáticos (hehe), mas é exatamente por isso que saiu uma lagriminha quando vi algumas dessas dicas aqui.

2. Para mim, o motivo mais comum para pessoas criarem objectos tipo “struct”, apoiados por legiões de métodos estáticos, é que eles baseam seu desenho numa visão fundalmente torta do “business domain”. Business é feito por people (hehe minha lingua nativa entrando ai), e na minha experiência, tenho muito mais sucesso em sistemas de gestão de informação/empresarial, quando tento modelar /o fluxo de negócio/ e seus atores, procedimentos e tarefas, em vez de as /entidades estáticas/ daquele domínio.

Ai, 99% dos livros de O-O não ajudam. “Tamos a criar um sistema para um banco, então vamos modelar ‘Conta’, ‘Cliente’ etc.”. Enquanto de facto as entidades realmente interessantes, desenvolvidos nos procedimentos de bancos após séculos, sao as Taxas, ATMs, Balcões, os varios papeis dos oficiais do banco etc. Conta existe, mas realmente é um “saco de atributos e relacionentos” so. Quando saco dinheiro, saco da ATM e não da conta.

Acho que não to a me explicar muito bem, mas talvez o melhor exemplo disto é o Spring Framework. Um sistema baseado em Spring é como uma organização humana composto de /n/ pequenos trabalhadores, cada um fazendo seu pápel e colaborando com os outros. Mas quase todos estes papéis representam abstrações de “procedimento/mecanismo” e não de “dados”.

A exceção a isto é quando você tem um domínio que, por causa de algum padrão ou lei natural, realmente segue uma hierarquia natural bem clara. Por exemplo química (veja jscience.org) ou SQL Error Codes (veja a hierarquia em baixo de DataAccessException no Spring).

Um livro que se calhar ajuda a explicar esta maneira de ver coisas é “Images of Organization” pelo Gareth Morgan.

3. Gostaria de notar que outras línguas “novas”, tal como C# e Ruby, oferecem suporte melhor ao nível do sintaxe, para declarar atributos e especificar sem perder tempo, se eles são readable, writable, os dois, etc. Também para botar “guards” (proteções) nesses métodos de modo que eles passem de ser apenas simples “operators”. Não tenho estado a seguir o progresso de Java 6, mas se calhar alguém nesta conversa poderia dizer se este tipo de apoio seja contemplado ou não?

Comment by Cameron Smith — December 4, 2006 @ 10:12 am
[...] 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. [...]

Pingback by blog.caelum.com.br » Relacionamento bidirecional entre classes — March 28, 2007 @ 7:41 pm
[...] 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. [...]

Pingback by » JustJava 2007, Arquitetura e Caelum » blog.caelum.com.br — October 8, 2007 @ 1:52 am
[...] 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 [...]

Pingback by O momento em que Java quase virou .Net e C++ ao mesmo tempo « Objectzilla — October 24, 2007 @ 7:37 pm
[...] 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 [...]

Pingback by O uso indiscriminado de getters e setters! « TJRN Developers — February 9, 2008 @ 12:00 am
Parabéns pelo artigo Paulo!
Estou ingressando no universo Java e tenho lido diversos livros relacionados …
Sempre me questionava o porque de tantos getters e setters…
O artigo somado aos comentários me ajudou muito a entender melhor este conceito!

Comment by Álvaro — March 20, 2008 @ 3:52 pm
Achei um exagero. Quando uma pessoa esta aprendendo OO, a melhor prática são exemplos simples. Acho que a regra de negócio não faz a menor diferença na hora do aprendizado e sim entender a lógica dos conceitos com exemplos simples.

Comment by Frederico Pires — July 7, 2008 @ 5:24 pm
Olá!

Realmente eu aprendei OO na base dos getters e setter e achava que estava fazendo o certo. Então tenho algumas dúvidas agora.

Quando eu quero utilizar uma classe que tenha certos comportamentos, mas que essencialmente funcione como um registro?
Eu deixo os campos que eu quero acessar públicos?

Tipo:

clas Agenda{
public String nome;
public String telefone;
public String email;
//etc..
}

Mas se eu precisasse validar os campos, tipo não seria bom ter um setter?

clas Agenda{
private String nome;
private String telefone;
private String email;

public void setEmail( String email ){
…String regex = “[A-Za-z0-9\\._-]+@[A-Za-z]+\\.[A-Za-z]+”;
…if(!email.matches(regex))
……trow new InvalidAttributeException(”Email inválido.”);
…this.email = email;
}

// etc.
}

E se nem todos os campos precisassem ser validados? Então alguns campos seriam acessados por getters/setters, e outros pela variável de instância pública?

Eu agradeceria se vc me tirasse essas dúvidas e me dissesse onde estou pensando errado.

E o que vc acha da API Java usar getters/setters o tempo todo? (Por exemplo, a maioria das classes swing.)

Abraços, Danilo.

Comment by Danilo — July 17, 2008 @ 1:06 pm
Ola Danilo!

Variavel de instancia publica nem deve ser considerado uma opcao: é uma quebra de encapsulamento grande demais. Mesmo não havendo validacao, é sempre bom encapsular, pois nunca sabemos o futuro.

Sera que voce precisa mesmo de um setter na classe Agenda para o email? Porque nao receber o email no construtor, e deixa-lo imutavel (final). Sobre a validacao, voce poderia criar uma class Email{}, e ela faz a validacao da String que a contem.

Danilo, estou esbocando ideias: nao é errado usar o getter e setter quando encessario, é errado usa-los quando existem maneiras mais interessantes de dar vida ao objeto, e nao trata-lo apenas como um registro/record/estrutura. A sua frase “funcione essencialmente como registro” é onde mora o perigo: em OO, deveriamos evitar esse “objetos fantoches”, como o Phillip Calcado os chama (puppets).

Sobre as classes swing: foram criadas com a ideia de javabean. Muita gente do proprio swing hoje em dia ve diferentes solucoes que poderiam remediar esse abuso de “registros.”

obrigado pelo comentario!

Comment by Paulo Silveira — July 17, 2008 @ 1:18 pm
Entendo…

Obrigado pela resposta.

Ah, vc recomenda algum livro que ensine POO direito?

Comment by Danilo — July 17, 2008 @ 6:04 pm
Eu recomendo o Effective Java e o Design Patterns, em especial os dois primeiros capitulos do GOF que fala de boas praticas de OO!!

Comment by Paulo Silveira — July 17, 2008 @ 6:14 pm
Obrigado de novo!

Comment by Danilo — July 17, 2008 @ 6:18 pm
Parabens pelo posting de alto nivel.
estava 1/2 constrang em postar mas o conteudo e perfeito para mim que estou estudando Conta da apostila fj11 e sou novato em oo e obviamente queria testar a ultima versao de Conta
instanciei Conta em uma classe de teste e nao consegui compilar por conta do construtor.
Para conseguir compilar e usar os metodos de Conta tive que substituir o construtor pelo metodo setLimite da classe GetSet (chamei assim a antiga Conta).
agradeço por um complemento ao posting com uma classe de acesso aos metodos de Conta preservando o construtor.

obrigado

Comment by sobrinho — July 24, 2008 @ 2:45 am
ops!!
nao precisa nem liberar o posting.
continuei na apostila e cheguei em contrutores e so bastou instanciar Conta passando o parametro de limite e compilou.
obrigado

Comment by sobrinho — July 24, 2008 @ 4:39 am
interesante. muito interesante.
pensado DDD….
do ponto de vista do cliente/usuario de um caixa eletronico itau ok. so temos acesso ao ’saldo’ (saldo + limite), porem, do internet bank do mesmo banco temos acesso detalhado aos limites de credito.
ate por uma questao pratica se vc ficar com nhenhem na fila do caixa eletronico vai começar o bunizaço dos outros clientes
partindo desta premissa seria interessante, pratico e real, embutir em Conta,com a elegancia do posting, um metodo para acessar o limite, pois na vida real isto acontece depois de um tetiAteti com a gerente, tb chamada por alguns de Conta

abs

Comment by trainspotting — July 25, 2008 @ 12:42 am
Ótimo texto. Me fez pensar bastante. Só fiquei com uma dúvida por causa de uns projetos que estou desenvolvendo: O Spring precisa de getters/setters pra injetar dependências ou da pra fazer sem? e os JSPs? da pra acessar os atributos sem getters/setters?

Comment by Murilo Ferraz — August 20, 2008 @ 6:40 am
muito bom mesmo fala de um jeito bem mais facil de entender rapido e direto sem complição
parabéns

Comment by cesar — September 7, 2008 @ 6:23 am
Os getters e setters no Hibernate serve como modelo de negócio para persistir os dados de uma tabela em um banco de dados qualquer. Eu uso getters e setters só para isso e mais nada. Agora se tratando de classes onde preciso encapsular dados sigilosos, onde o usuário final não pode ter acesso ai sim… os getters e setter são abolidos da minha concepção.

Comment by Willian Silva — October 3, 2008 @ 3:36 pm
Olá Paulo, como seria minha interação do objeto de dominio com a camada web com a eliminação do getter/setter? Como faria para recupepar dados do objeto afim de apresentar para o cliente?

Comment by Otávio — October 31, 2008 @ 12:05 am