[Guerra de Programador] Declaração de parametros da classe

11 respostas
dtxk

Imaginem a situação, tenho uma classe chamada Contract e uma classe chamada Payment nela tenho uma chamada para Contract ou seja:

@Entity
@Table(name = "payments")
public class Payment implements java.io.Serializable {
    private Contract contract;
    gets sets...

}

@Table(name = "contract")
@Entity
public class Contract implements java.io.Serializable, DiffComparable<Contract> {
  
   gets sets...
}

A situação é a seguinte, na Payments eu tive necessidade de criar uma chamada para Contract. Só que na Contract não tive a necessidade de chamar Payments.

O meu “chefe” falou que é um erro de programação não declarar na Contract um parametro para Payment como segue:

@Table(name = "contract")
@Entity
public class Contract implements java.io.Serializable, DiffComparable<Contract> {
   private List<Payment> payments = new ArrayList<Payment>(0);  
   gets sets...
}

Isso está certo? Mesmo que não tive a visão de criar isso e tambem náo senti a necessidade de se criar isso?
Quem está certo nessa questão?

fico no aguardo obrigado.

11 Respostas

henriqueluz

Como diria um professor meu: Depende!

Você tem necessidade de mostrar os “Payments” de um “Contract”?
Ou apenas o “Contract” de cada “Payment”?

dtxk

henriqueluz:
Como diria um professor meu: Depende!

Você tem necessidade de mostrar os “Payments” de um “Contract”?
Ou apenas o “Contract” de cada “Payment”?

Então foi oq aconteceu surgiu a necessidade de criar Payments de Contract… e ele(“chefe”) diz que eu já deveria ter previsto isso…

E eu estava desenvolvendo em Payments onde eu criei o Contract.

Foi isso q aconteceu :shock:

asandrob

Quem é a entidade forte? Ou seja, pode existir Payment sem Contract? Se sim, então Contract não precisa de Payment!!!
E dá para pegar os Payment de um Contract, mesmo que Contract não tenha Payment:

Toca o barco, não é erro não!!!

dtxk

asandrob:
Quem é a entidade forte? Ou seja, pode existir Payment sem Contract? Se sim, então Contract não precisa de Payment!!!
E dá para pegar os Payment de um Contract, mesmo que Contract não tenha Payment:

Toca o barco, não é erro não!!!

Não, um Payment tem q ter ao menos um Contract.

Agora criar uma lista de Payment no Contract mesmo sem a necessidade, eu não entendo onde esta a “obrigatoriedade”.

asandrob

Não há obrigatoriedade, por isso que tu não estás entendendo!!!

luxu

Tem q ver as regras de negócio, ou seja, o q ser quer com cada classe, vai ver q vc e ele não estão em sincronia de pensamentos, um pensa uma coisa e o outro outra coisa, saka?

dtxk

Então luxu, é isso q esta acontecendo, ele vê de um jeito e eu de outro… oq acontece q eu nao senti necessidade de declarar o Payment no Contract.
E ele falou q é um erro gravissimo!

Eu não vi isso…

luxu

kra se vc conseguir convencê-lo disso td bem, mas acho melhor vc se adequar a ele, opinião!

dtxk

ou seja… Puxar o saco! rsss…

fantomas

Isso está certo? Mesmo que não tive a visão de criar isso e tambem náo senti a necessidade de se criar isso? Quem está certo nessa questão?

Minha opinião:

Em uma “Visão àgil” vc estaria certo, lembrando que deveria se fazer uma leitura nas regras de negócio para verificar se a necessidade do relacionamento realmente existe (como já foi dito). Na visão àgil é sempre bom não perder tempo e nem recursos com excessos ou coisas que não foram solicitadas.

Em uma visão mais tradicional ele (o chefito) estaria certo, na maneira mais tradicional é normal se precaver de imediado, o pensamento é: “Vai que um dia precise deste relacionamento…” ou “Já que estamos fazendo isto vamos fazer aquilo tambem, ja adiantamos um pouco mais…”

Enfim, é o de sempre, o velho bom senso. Tem que ficar atento ao que o “chefe” diz, independente de estar certo ou errado, muitas vezes eles conhecem as “manhas” da empresa; a regra pode não estar no papel e nem ter sido dita porem pode estar na cabeça de algum usuário que não foi envolvido ainda.

Outro ponto é, se a regra foi escrita e assinada e vc não leu por esquecimento ou sei lá ele ( o chefito ) fica com a razão; se está na regra vc deveria ter implementado. Caso contrario vc fica com a “razão” porem saiba que “chefe é o chefe” e não precisa puxar o saco, verifique se não havera perda de performance ou recursos diz que esqueceu do detalhe e implemente.

P.S Acho que vc irá gostar do livro “Como trabalhar para um idiota” rsrsrs.

flws

maior_abandonado

ou seja… Puxar o saco! rsss…

não, se adequar não é puxar o saco, puxar o saco seria ficar dizendo “o quanto a ideia dele é maravilhosa ou como ele é inteligente por saber disso”, o que imagino que não seja o caso, seguir está mais para obedecer, é uma questão de hierarquia… ao menos essa é a minha opinião.

Criado 22 de agosto de 2011
Ultima resposta 23 de ago. de 2011
Respostas 11
Participantes 6