Encapsulamento

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4639 Offline

Oi pessoal, bom dia.

Depois que o cv me instigou a ler mais sobre o assunto, encontrei o seguinte artigo, que deveria ter lido tempos atrás:
http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html

Nele, entre outras coisas, o autor afirma o seguinte:

Encapsulation rule 1: Place data and the operations that perform on that data in the same class

Sendo assim, DAO não seria uma anti-pattern? Operações CRUD deveriam então ser realizadas dentro das próprias classes? Ou não?

E analisando a evolução do código do autor, percebi o uso de getters e setters pode ser arriscado, então deve-se pensar algumas vezes e escrever o código com cuidado.

Porém, ao usar frameworks como Hibernate, que provê muitas facilidades, o desenvolvedor é obrigado a definir getters/setters para todos os atributos a serem persistidos. E então? Usar ou não usar essas facilidades?

Obrigado pessoal.

Colocar getters e setters pra satisfazer o framework nao te impede (bom, nao totalmente) de continuar com o encapsulamento bom - voce pode colocar as operacoes que lidam com aqueles dados na mesma classe mesmo assim.

Sobre o DAO, de certa forma eh um anti-pattern do jeito que normalmente se ve feito por ai. Uma alternativa seria o ActiveRecord, do tio Fowler: http://patternshare.org/default.aspx/Home.MF.ActiveRecord

PS: avatar comedia

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4639 Offline

Beleza, entendi o lance dos getters/setters.

Mas cv, sobre o link que você me passou, bem ... como implementar isso de forma coerente?

Isso?

E como colocaria várias operações dentro de uma transação fazendo desta maneira? E se o meu domínio tem centenas de objetos, não fica meio complicado para manter essas classes que implementam ActiveRecord?

Obrigado cv

ps.: fala pro sr Flower aumentar o tamanho do texto do site dele

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4639 Offline

E mais uma dúvida: métodos que filtram os dados e retornam coleções do objeto em questão deveriam estar contidos na mesma classe? Se não, onde??

Lipe, que cada vez mais sabe que não sabe nada

Voltando ao assunto do encapsulamento, outros artigos que causaram alguma polêmica foram estes do Allen Holub:

Why getter and setter methods are evil

Building user interfaces for object-oriented systems

Nesse último ele argumenta que MVC não é OO. Eu acho que ele se apega demais ao encapsulamento. É uma diretriz, não uma lei. De qq forma é uma boa leitura.

Eh preciso saber absorver o conteudo de muitos desses artigos. Alguem pode ler e tomar atitudes "drasticas" se confiar cegamente no que o autor diz, aumentando a "complexidade da aplicacao" (ou qualquer outra coisa, nao vem mto ao caso) por querer seguir a risca todas as "boas praticas" que leu pela net.
Fico imaginando a cena de alguem que acabou de ler o artigo onde eh argumentado que "mvc nao eh OO" e, por tal razao, declara a todos da equipe de desenvolvimento que "..nao vamos mais usar mvc pq ele nao eh oo".

Rafael

De fato, Rafael, é arriscado se fiar na opinião de qualquer um que escreve um artigo. Todo mundo precisa saber pensar sobre o que lê.

O que eu achei interessante é o "absurdo" a que se chega quando se toma uma diretriz como se fosse um axioma absoluto. O projeto de um sistema envolve uma série de de escolhas de engenharia - se privilegia um aspecto em detrimento de outro. Isso talvez seja menos visível em software do que em outras áreas, porque as limitações físicas são muito menos importantes do que, por exemplo, ao se construir uma ponte.

O Holub acha que encapsulamento é uma regra inviolável. Mas, como os milhões de programas escritos usando MVC desde o smalltalk-80 mostram, é possível obter sistemas elegantes e funcionais relaxando um pouco o encapsulamento.

Um dos pontos que o artigo da javaworld nao fala sobre os getters eh o "problema da imutabilidade" das classes. O que alguns alegam eh que, tendo getters como temos a maior parte do tempo, as classes podem ter o status alterado facilmente. Imagine um codigo como

digamos que o a intencao era nao permitir que a data interna fosse alterada, e portando nao foi adicionado um setXxx(). O problema eh que, por estar o getData() retornando a referencia para a instancia da classe Date, qualquer metodo podera ser chamado, mudando as prpriedades internas:

A solucao para isso retornar uma copia ao inves da referencia. Porem, fazer isso somente "por fazer" - ou seja, sem a necessidade real de imutabilidade - somente teria resultados mais "desfavoraveis" que a favor.

O problema, porem, eh fazer 90% dos desenvolvedores entender isso.

Rafael

This message was edited 1 time. Last update was at 28/02/2005 21:59:05

Rafael Steil wrote:
A solucao para isso retornar uma copia ao inves da referencia. Porem, fazer isso somente "por fazer" - ou seja, sem a necessidade real de imutabilidade - somente teria resultados mais "desfavoraveis" que a favor.

O problema, porem, eh fazer 90% dos desenvolvedores entender isso.

Sei lá. Eu acho que imutabilidade na verdade deveria ser mais usada. Simplifica bastante o contrato da classe e vc não precisa se preocupar muito com mudança de hash-code. Além de poder dar alguma vantagem minuscula de performance (isso é secundário).

edição: Ficar copiando na hora de entregar para o cliente geralmente quer dizer q a classe do objeto retornado deveria ter sido imutavel. Acho q foi mancada da sun fazer o Date mutável.

DAO pode ser visto como um antipattern, mas também é solução pro caso de classes "Canivete Suiço".

Eu acho que encapsulamento não pode ser tudo ou nada, tem que existir uma maior liberdade para outros objetos colaboradores olharem por traz da cortina.

Eu prefiro muito mais ter vários objetos colaborando entre sí que poucos objetos muito independentes. Essa é a velha discução de Coesão x Acoplamento e Spaghetti x Raviolli.

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4639 Offline

Adorei ler o artigo, ótimo ver uma opinião bastante diferente do que se ve hoje em dia.

Contudo, mandar meu objeto Candidato se gravar no reposítório de dados me cheira muito mal

Voce pode mandar seu objeto Candidato se gravar no banco de dados usando um CandidatoStore tal

O problema de getters/setters é que eles foram criados para um modelo de componentes gambiarral (ou vocês realmente acham que JavaBeans não são uma gambiarra? Convenção de nomes só apra reflection?Habla sério...) que foge das boas práticas e tende para o aparecimento de objetos sem comportamento, só atributos.

O uso de boas práticas ou não realmente é uma decisão muito séria, mas acho que deve-se conehcer o máximo possível para se saber quando usar e quando não usar.

Não me lembro de nenhum padrão J2EE que não tenha sentido apenas para suprir uma deficiência da plataforma, mas o DAO, IMHO, é mais que isso, age na impedância (cadê o link apra aquele outro tópico?). É ideal? Claro que não, mas funciona (Como DTOs, que até hoje eu busco algo que possa eliminar).

Um DAO deve ler o estado de um objeto e persistí-lo, ou as outras letrinhas do CRUD. Extrair o estado de um objeto apenas com consultas quebra o encapsulamento (a menos que houvessem "friends" em Java), mas uma solução para quem procura se manter nas boas práticas é aplicar o pattern Memento e persistir o Memento. Isso é meio trabalhoso e agrega uma complexidade que, na prática, só vai ser útil para se persistir o objeto.

pcalcado wrote:...age na impedância (cadê o link apra aquele outro tópico?).

Este? http://www.guj.com.br/posts/list/20496.java

]['s

Forum Spammer Membro desde: 12/03/2003 11:25:57 Mensagens: 4639 Offline

cv, e nos casos de outras consultas que retornam coleções de objetos Candidato? Em que lugar enfio estes métodos sem doer?

Estou lendo o segundo artigo que o AllMighty postou, estou até achando perigoso de tanto que estou adorando o que o cara está escrevendo. Faz um monte de sentido pra mim