Evitar Getters/Setters?!

[sergiotaborda]

[quote=André Fonseca][quote=sergiotaborda]
Se vc se enganou ao criar um método com double que deveria ter a exatidão de BigDecimal e ainda vai a tempo de alterar faça um simples refractoring da classe. Se a classe já está em produção marque o método como deprecated, explique que ele não têm a exatidão necessária e que o método getSomeBigger deve ser usado em vez. Explique que o método getSome será retirado da API na versão x.y.z. O método getSomeBigger é um método novo. O método getSome permanece inalterado.
[/quote]

Me corrigam se eu estiver errado, mas para resolver isso você poderia usar um pattern do GOF chamado Adapter [/quote]

Sim e não. Na verdade não.

O Adapter, como o nome indica, serve para adaptar. Serve para transformar a interface de objeto em outra.
No caso isso é o que não queremos fazer. Queremos mudar o interior da classe sem mudar o seu exterior ( a sua interface).
O Adapter não nos ajuda já que não teria acesso ao interior da classe.

No caso inverso de ter que criar um método que retorne BigDecimal, sem alterar mais nada, ai poderíamos considerar um Adapter.
Contudo, essa técnica só é usada se não tivermos controle sobre a classe que queremos mudar. Caso em que, simplesmente alteramos a interface , documentamos, e pronto.

Ou seja, neste caso, Adapter não seria a solução.

[peerless]

resumindo, o adapter desvirtua um cidadão, para libertar outros… hehehehe

[Andre_Fonseca]

Entendi, valeu pela explicação Sérgio… isso é para eu aprender a ler melhor o problema antes de achar uma possível solução… rs

[sergiotaborda]

Eu estava procurando por outra coisa quando me deparei com os Java Coding Conventions (1989). Já nessa época era claro o problema do get/set

Providing Access to Instance and Class Variables
Don’t make any instance or class variable public without good reason. Often, instance variables don’t need to be explicitly set or gotten-often that happens as a side effect of method calls.
One example of appropriate public instance variables is the case where the class is essentially a data structure, with no behavior. In other words, if you would have used a struct instead of a class (if Java supported struct), then it’s appropriate to make the class’s instance variables public.

A chamada para o structs vc class é interessante. Em java temos que usar classes como se fossem estruturas e é ai que mora o perigo ( quando usamos classes que são clases, mas lhe damos poderes de estruturas)

[Andre_Fonseca]

Pessoal,

Surgiu uma dúvida agora, aqui no projeto nós temos algumas classes de negócio que realizam processos que muitas vezes possuem coisas em comum…

Essas classes possuem o que poderia ser considerado um struct conforme o pessoal falou acima, mas esse struct pode possuir alguns atributos que são diferentes em algumas das classes de negócio.

A minha dúvida é, para essas classes como passar os parâmetros para os processos de negócio??
Utilizando um construtor com os atributos? Utilizando sets e gets na própria classe? E como facilitar para o caso de algumas classes de negócio possuírem atributos em comum??

Por exemplo, eu teria algo assim:

[code]ClasseNegocio cn1 = new ClasseNegocio(attr1, attr2, attr3, attr4,…)
cn1.executaProcesso();

OutraClasseNegocio cn2 = OutraClasseNegocio(attr2,attr3,attr5, …)
cn2.executaProcesso();
cn2.executaOutroProcesso();
[/code]

Ou eu poderia fazer assim?

ClasseNegocio cn1 = new ClasseNegocio() cn1.setAttrr1('foo'); cn1.setAttrr2('bar'); cn1.executaProcesso();

Neste caso eu acho que a forma mais fácil seria assim:

[code]ObjetoVOClasse1 obj1 = new ObjetoVOClasse1();
obj1.setAttr1(‘foo’);
obj1.setAttr2('bar);

ClasseNegocio cn1 = new ClasseNegocio(obj1);
cn1.executaProcesso();
[/code]

Porque eu acho que a alternativa 3 é a mais facil para o meu problema??

1. Este objeto contendo os atributos pode ser usados em mais de uma classe de negócio em um ou mais sub-processos dessas classes
2. Fica mais fácil você olhando para o objeto saber o tipo dos atributos e também a ordem em que eles são passados, caso fossemos passar por contrutores tem alguns que teriam que ter até uns 13, 15 atributos
3. É bem provável que esses atributos mudem durante o desenvolvimento, e mesmo depois do sistema em produção

Bom, eu tb não sei direito como resolver, se tiverem sugestões desde já agradeço…
O que eu estou pensando nem é em usar o padrão xpto que é logico melhoraria, estou pensando mesmo em facilidade de manutenção e reuso…

[]´s

[sergiotaborda]

[quote=André Fonseca]Pessoal,

Surgiu uma dúvida agora, aqui no projeto nós temos algumas classes de negócio que realizam processos que muitas vezes possuem coisas em comum…

Essas classes possuem o que poderia ser considerado um struct conforme o pessoal falou acima, mas esse struct pode possuir alguns atributos que são diferentes em algumas das classes de negócio.

A minha dúvida é, para essas classes como passar os parâmetros para os processos de negócio??
Utilizando um construtor com os atributos? Utilizando sets e gets na própria classe? E como facilitar para o caso de algumas classes de negócio possuírem atributos em comum??
[/quote]

A primeira coisa é : sem saber que atributos são não ha como ajudar , i.e. conhecer o dominio é essencial a fazer uma boa modelagem. Não existem receitas , existem conceitos.

Segundo, se existem muitos atributos (15 !?!?) alguma coisa está errada. Tlv esses atributos têm que ser agrupados eles mesmos.
(sem saber o que são, não tem como falar)

A opção viável é criar um Builder. Ou seja, uma classe que constrói outra. Vc vai lançandos os valores e o builder vai armazenando
no fim ele cria o objeto de comando para ser executado depois.

Outra opção é não usar o construtor mas um método de construção. Isso é mais flexivel já que internamente o acesso perviligiado do método tornas a coisas mais simples

class ClasseNegocio {

    public static ClasseNegocio  fromABC ( a, b, c ){
           ClasseNegocio   cn = new ClasseNegocio  (); // consturtor padrão
            cn.a = a;
            cn.b= b;
            cn.c=c;
           return cn;
    }


  private ClasseNegocio  (){} // privado
}

Portanto

1. Analisar a granularidade : pode agrupar os atributos ? faz sentido ?
2. Usar builder
3. Usar método de construção em vez de construtor.

Attributos iguais não significam nada ( aka não use herança para os agrupar). Mas podem ser candidados a constituir um novo objeto que os agregue.

[Andre_Fonseca]

Essas classes possuem o que poderia ser considerado um struct conforme o pessoal falou acima, mas esse struct pode possuir alguns atributos que são diferentes em algumas das classes de negócio.

A primeira coisa é : sem saber que atributos são não ha como ajudar , i.e. conhecer o dominio é essencial a fazer uma boa modelagem. Não existem receitas , existem conceitos.

Porque vc precisa saber quais atributos são?? Disse que são muitos, podem mudar a qualquer momento e grande parte deles pode ser reutilizada em outros processos de negócio… por isso a minha idéia de agrupar eles em um struct ou VO para facilitar a manutenção …

Segundo, se existem muitos atributos (15 !?!?) alguma coisa está errada. Tlv esses atributos têm que ser agrupados eles mesmos.
(sem saber o que são, não tem como falar)

Sim, alguma coisa está errada, estamos lidando com vários sistemas legados que não possuem bases normalizadas e construídas para serem utilizadas por uma arquitetura OO de forma eficiente … de novo, o que o fato de saber quais atributos são pode ajudar aqui??

A opção viável é criar um Builder. Ou seja, uma classe que constrói outra. Vc vai lançandos os valores e o builder vai armazenando
no fim ele cria o objeto de comando para ser executado depois.

Vou dar uma pesquisada nesse caso…

Outra opção é não usar o construtor mas um método de construção. Isso é mais flexivel já que internamente o acesso perviligiado do método tornas a coisas mais simples

class ClasseNegocio {

    public static ClasseNegocio  fromABC ( a, b, c ){
           ClasseNegocio   cn = new ClasseNegocio  (); // consturtor padrão
            cn.a = a;
            cn.b= b;
            cn.c=c;
           return cn;
    }


  private ClasseNegocio  (){} // privado
}

[]´s
Portanto

1. Analisar a granularidade : pode agrupar os atributos ? faz sentido ?
2. Usar builder
3. Usar método de construção em vez de construtor.

Não vi o que isso poderia ajudar, já que o problema principal: facilitar a manutenção de um struct de dados continua, já que o método fromABC(a,b,c) poderia ter que ser alterado por from(x,p,a,b,c)… posso não ter entendido direito, você poderia colocar mais um exemplo por favor??

[quote=sergiotaborda]
Attributos iguais não significam nada ( aka não use herança para os agrupar). Mas podem ser candidados a constituir um novo objeto que os agregue.[/quote]

O que isso tem de diferente em criar um VO?? ou seja, uma classe com atributos privatos e métodos get e set publicos?? A minha dúvida aqui é quando é uma boa prática criar um VO, apenas quando eu vou trafegar objetos entre camadas de sistemas distribuídos?? ou existem outras situações? eu acho que neste caso que eu coloquei poderia ser uma situação… outra coisa, não são atributos iguais, é um conjunto de atributos que pode ser utilizado em mais de um processo de negócio com alguns atributos diferentes…

[DaviPiala]

Não vi o que isso poderia ajudar, já que o problema principal: facilitar a manutenção de um struct de dados continua, já que o método fromABC(a,b,c) poderia ter que ser alterado por from(x,p,a,b,c)… posso não ter entendido direito, você poderia colocar mais um exemplo por favor??

A idéia não é facilitar a “manutenção” no objeto de dados e sim evitar que o controle sobre seu estado esteja totalmente em outro objeto que o manipule.

[sergiotaborda]

A primeira coisa é : sem saber que atributos são não ha como ajudar , i.e. conhecer o dominio é essencial a fazer uma boa modelagem. Não existem receitas , existem conceitos.

Porque vc precisa saber quais atributos são??

Eu falei pq: “conhecer o dominio é essencial para fazer um boa modelagem”

Disse que são muitos, podem mudar a qualquer momento e grande parte deles pode ser reutilizada em outros processos de negócio…

sim, mas para efeitos de modelagem isso significa: “são muitos, não sei quais são, está uma zona” :lol:

por isso a minha idéia de agrupar eles em um struct ou VO para facilitar a manutenção …

Se vc pode criar objetos que agrupem esses outros isso corresponde com a solução que lhe passei.

Segundo, se existem muitos atributos (15 !?!?) alguma coisa está errada. Tlv esses atributos têm que ser agrupados eles mesmos.
(sem saber o que são, não tem como falar)

Sim, alguma coisa está errada, estamos lidando com vários sistemas legados que não possuem bases normalizadas e construídas para serem utilizadas por uma arquitetura OO de forma eficiente … de novo, o que o fato de saber quais atributos são pode ajudar aqui??

Porque se “se alguns podem ser usados em outros processos de negocio” significa que alguns não podem. Separar quais podem e quais não podem implica em criar não 1 mas vários objetos para agrupar os atributos. Possivelmente até alguns com atributos repetidos. Apenas conhecendo o dominio é possivel saber quem vai com quem já que essa agrupamento depende do processo de negocio que o utiliza e portanto depende do negocio, do dominio.

Outra opção é não usar o construtor mas um método de construção. Isso é mais flexivel já que internamente o acesso perviligiado do método tornas a coisas mais simples

Não vi o que isso poderia ajudar, já que o problema principal: facilitar a manutenção de um struct de dados continua, já que o método fromABC(a,b,c) poderia ter que ser alterado por from(x,p,a,b,c)… posso não ter entendido direito, você poderia colocar mais um exemplo por favor??

como já foi disto esconder o construtor é uma forma de inverter o controle. É o objeto que sabe como se criar e não quem o usa.
Vc pode criar vários métodos de construção sem criar vários construtores ( isso é bom); por exemplo, um que aceite os atrbutos “a vulso” e outro que aceite os VO que quer criar.

Ou seja, criar os objetos de agrupamento é um passo, mas não é o único que vc pode tomar. Como falei antes primeiro tem que analisar a granularidade. Isso significa criar objetos para agrupar os atributos (objetos, plural). quantos e quais depende do dominio. Depende de onde e como vão ser usados. não precisam ser um monte de atributos privados com get/set. Se quer um struct crie um struct, ou seja, use atributos publico mesmo. A menos que exista uma boa razão para os encapsular ( a qual advem do dominio)

[quote]

Attributos iguais não significam nada ( aka não use herança para os agrupar). Mas podem ser candidados a constituir um novo objeto que os agregue.[/quote]

O que isso tem de diferente em criar um VO??

É diferente na quantidade. Eu estou dizendo que precisa criar vários e não um só. E estou dizendo tb que não use herança entre eles.

A minha dúvida aqui é quando é uma boa prática criar um VO

Sempre que tiver problemas de granularidade.Sempre que seus métodos ou contrutores recebam mais de 4 parametros pode começar a desconfiar. Faça uma re-analise.

Isto é exatamente o que vc está fazendo. A sua ideia de usar um objeto para agrupar os atributos é certa.
Apenas lhe passei outras opções, porque, como eu disse, sem conhecer o domínio não tem muito o que dizer.

O fato dos atributos mudarem indica instabilidade do seu modelo. Talvez precisa de algo mais dinâmico. Uma estrutura semelhante a um Map tlv seja o que precisa.

–
Nota: Vc está utilizando VO como sinónimo de “objeto que agrupa outros objetos”. VO é correntemente uma sigla inexata.
“Objecto que agrupa outros objetos” é um TO. VO é um objeto que encapsula valores (value object)

[Andre_Brito]

Não li o tópico todo, mas li os primeiros posts.

Eu estava com essa mesma dúvida… bati uma semana na mesma moeda, até que criei vergonha na cara e humildade e fui perguntar para o Emerson Macedo. Tirei a liberdade de colocar aqui o que ele me explicou (que por sinal, foi excelente).

Olá André, tudo bem?

Rapaz, eu vou tentar explicar de maneira bem simples.

Quando você cria um objeto (de verdade), você não deve criar uma coisa que tem um monte de campos, como se fosse uma tabela do banco de dados. Você deve pensar em conceitos. Imagine que você precise modelar uma classe de Conta Corrente.

class ContaCorrente {
  private double saldo; //Melhor seria usar alguma classe de Moeda
  public void setSaldo(double saldo) {
    this.saldo = saldo;
  }
  public double getSaldo() {
    return this.saldo;
  }
}

A primeira vista, parece que o saldo está bem encapsulado. Acontece que quando estamos falando de encapsulamento, temos que esconder os detalhes de implementação. Neste caso, até mesmo por convenção, quem usa seu objeto consegue saber o que o método faz internamente. Tentaremos mudar um pouco.

class ContaCorrente {
  private double saldo; //Melhor seria usar alguma classe de Moeda
  public ContaCorrente(double saldoInicial) {
    this.saldo = saldoInicial;
  }
  public boolean saca(double quantia) {
    // Possivelmente verifica se tem saldo para sacar,
    // observa limites do cheque especial, empréstimos, etc.
  }
  public boolean deposita(double quantia, boolean poupanca) {
    // Deposita o dinheiro em conta corrente ou poupança
    // Pode ter outras lógicas
  }
  public double saldoConsolidado() {
    // Faz toda consolidação com saldo de conta-poupança, 
    // investimentos, limite do especial
  }
}

Como pode notar, isso é bem diferente. Eu não tenho como alterar valores de forma arbitrária, como se faz num método setXXX. Todo estado é alterado de acordo com um corportamento bem definido. Outra coisa importante é que os detalhes internos de cada método (i.e. Implementação), estão bem escondidos de quem usa o objeto. O fato dos dados estarem escondidos é uma consequência.

É claro que existem frameworks Web que precisam de métodos getXXX e até mesmo setXXX, mas ai você estará fazendo por limitação tecnológica e não por escolha sua de design.

Espero ter te ajudado.

Grande abraço.
Emerson Macedo Leite

[Andre_Fonseca]

Bom, respondendo ao Sérgio entendi o que você quis dizer, e obrigado pelas sugestões…

Respondendo ao meu xará, acho que o meu problema é um pouco diferente do seu, porque no meu caso eu tenho alguns processos com vários sub-processos de negócio, e neste caso eu tenho um conjunto de atributos comuns que são utilizados por alguns processos e sub-processos, ou seja, não é bem uma entidade do domínio que possui atributos apenas…