Entidade ou Value Object?
16/05/2017
0
Olá, pessoal. Tudo bem?
Com frequência a gente chama algumas classes das aplicações de Entidades, mas recentemente ouvi também o termo Value Object e fiquei na dúvida. Tanto faz usar um termo ou outro? Como vocês usam Entidades e VOs nos seus projetos?
Abraços.
Com frequência a gente chama algumas classes das aplicações de Entidades, mas recentemente ouvi também o termo Value Object e fiquei na dúvida. Tanto faz usar um termo ou outro? Como vocês usam Entidades e VOs nos seus projetos?
Abraços.
Rachel Andrade
Curtir tópico
+ 0
Responder
Post mais votado
17/05/2017
Olá, Rachel. Tudo bem?
A diferença entre Entidade e VO é bem discutida e explicada no contexto do Domain-Driven Design, mas esses conceitos podem tranquilamente ser aplicados fora dessa metodologia. Sendo assim, tentarei resumir:
Entidades possuem uma IDENTIDADE dentro do seu sistema e a mantém durante o ciclo de vida da aplicação. Por exemplo, um cliente normalmente é identificado pelo Id, CPF ou Código que se mantém enquanto aquele cliente existir. Por mais que alteremos o nome do cliente, email, telefone, endereço, etc, ele continua sendo aquele mesmo cliente, mas com características alteradas.
Já um VO tem como principal característica ser IMUTÁVEL, além disso ele é identificado pelo conjunto de seus atributos. Sendo assim, se mudarmos um atributo de um VO, ele passa a ser outro objeto. Por exemplo, imagine um endereço, que é composto por rua, bairro, cidade, estado, CEP e número. Um endereço é realmente o conjunto dessas informações, que o localizam no espaço em um determinado país, estado, cidade, rua e posição nessa rua. Se alterarmos qualquer um desses valores, já passamos a ter outro endereço diferente, concorda?
"Avenida Ayrton Senna, 3000. Barra da Tijuca. Rio de Janeiro - RJ."
é diferente de
"Avenida Ayrton Senna, 3001. Barra da Tijuca. Rio de Janeiro - RJ." (perceba a mudança no número).
Deu pra sacar a ideia?
Qualquer coisa é só falar.
A diferença entre Entidade e VO é bem discutida e explicada no contexto do Domain-Driven Design, mas esses conceitos podem tranquilamente ser aplicados fora dessa metodologia. Sendo assim, tentarei resumir:
Entidades possuem uma IDENTIDADE dentro do seu sistema e a mantém durante o ciclo de vida da aplicação. Por exemplo, um cliente normalmente é identificado pelo Id, CPF ou Código que se mantém enquanto aquele cliente existir. Por mais que alteremos o nome do cliente, email, telefone, endereço, etc, ele continua sendo aquele mesmo cliente, mas com características alteradas.
Já um VO tem como principal característica ser IMUTÁVEL, além disso ele é identificado pelo conjunto de seus atributos. Sendo assim, se mudarmos um atributo de um VO, ele passa a ser outro objeto. Por exemplo, imagine um endereço, que é composto por rua, bairro, cidade, estado, CEP e número. Um endereço é realmente o conjunto dessas informações, que o localizam no espaço em um determinado país, estado, cidade, rua e posição nessa rua. Se alterarmos qualquer um desses valores, já passamos a ter outro endereço diferente, concorda?
"Avenida Ayrton Senna, 3000. Barra da Tijuca. Rio de Janeiro - RJ."
é diferente de
"Avenida Ayrton Senna, 3001. Barra da Tijuca. Rio de Janeiro - RJ." (perceba a mudança no número).
Deu pra sacar a ideia?
Qualquer coisa é só falar.
Joel Rodrigues
Responder
Mais Posts
22/05/2017
Rachel Andrade
Muito obrigada, Joel. Me ajudou bastante a esclarecer. =)
Nesse caso, se eu tivesse um objeto Color, por exemplo que contém os valores de Red, Green e Blue, ele também seria um VO, certo? Afinal, se eu mudar qualquer propriedade ele se torna uma cor diferente.
Nesse caso, se eu tivesse um objeto Color, por exemplo que contém os valores de Red, Green e Blue, ele também seria um VO, certo? Afinal, se eu mudar qualquer propriedade ele se torna uma cor diferente.
Responder
23/05/2017
Joel Rodrigues
Perfeito, Rachel. Esse é um bom exemplo de VO.
Aqui fica uma sugestão: algumas pessoas optam por implementar os VOs como classes sem setters. Já que as propriedades não podem ser alteradas, senão o objeto muda, então bastaria permitir a passagem dos valores no construtor e não permitir que as propriedades fossem alteradas.
Abraçoo.
Aqui fica uma sugestão: algumas pessoas optam por implementar os VOs como classes sem setters. Já que as propriedades não podem ser alteradas, senão o objeto muda, então bastaria permitir a passagem dos valores no construtor e não permitir que as propriedades fossem alteradas.
Abraçoo.
Responder
Clique aqui para fazer login e interagir na Comunidade :)
