Value Objects

[Simon Vocella]

I want to understand better what is a Value Object. I mean I understand that a Value Object is immutable and two value objects they are equal if their value are equals. Beyond this point:

Do you think we can decide if an object could be a value object or is it something intrisic?

I try a better explanation: many times when I see examples of value objects, I usually see String or Date, that they are obviously a value object, but if we think something more complex I start to doubt if they are really value objects or not.

One example is the Response of a Web Application: some frameworks or libraries they return it as a new object and in this case it seems a value object, in other case they inject him and it seems a normal object.

Do you put validation or behaviours in value object?

How do you test it? With mock or with state-based test?

I followed the TDD course of JB and He usually say: "never mock values". Do you agree with that?

Thanks,

Simon

[Raoul Duke]

You can also view non-value objects as merely a time ordered
collection of value objects. :-)

[George Dinwiddie]

Simon,

On 9/25/15 11:44 AM, Simon Vocella wrote:
> I want to understand better what is a Value Object. I mean I understand
> that a Value Object is immutable and two value objects they are equal if
> their value are equals. Beyond this point:
>
> Do you think we can decide if an object could be a value object or is it
> something intrisic?
> I try a better explanation: many times when I see examples of value
> objects, I usually see String or Date, that they are obviously a value
> object, but if we think something more complex I start to doubt if they
> are really value objects or not.
> One example is the Response of a Web Application: some frameworks or
> libraries they return it as a new object and in this case it seems a
> value object, in other case they inject him and it seems a normal object.

Is a web response really a value object? Do you ever compare them by
value? Even for the same URL, don't they have differences, such as the
IP address of the requestor?

I think of a value object as something where the value IS it's identity.

In my experience, a web response is more of a bag of data than a value

object.

>
> Do you put validation or behaviours in value object?

Perhaps some convenience methods, especially for creation.
MyNumber number = MyNumber.fromString("5");

>
> How do you test it? With mock or with state-based test?
> I followed the TDD course of JB and He usually say: "never mock values".
> Do you agree with that?

How would you test a 5? Why not just use one?

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Nat Pryce]

On 25 September 2015 at 16:44, Simon Vocella <vox...@gmail.com> wrote:

One example is the Response of a Web Application: some frameworks or libraries they return it as a new object and in this case it seems a value object, in other case they inject him and it seems a normal object.

An HTTP Response streams the response back to the client over TCP, and so maintains state and/or acts as a proxy to state maintained in the operating system to implement the TCP connection.  This means it's not a value eobject

Do you put validation or behaviours in value object?

Yes.  A value object represents some value in the domain, and I'll add methods to it that perform domain calculations.

I'd probably not put validation in the value object, but try to make it impossible to create a value object for an invalid value. I'd put input validation at the edge of the system, in code that parses untrusted input into value objects.  Then the rest of the system can rely on the type system to guarantee that the values are not invalid.

 

How do you test it? With mock or with state-based test?

Usually plain ol' assertions.  But sometimes I've written immutable value objects that can affect stateful objects by calling back to interfaces passed to their methods.  In that case, I'd consider mocking the interface to test the behaviour.

I followed the TDD course of JB and He usually say: "never mock values". Do you agree with that?

Yes.  Value objects are immutable, so stateful objects cannot send commands to value objects to effect change in their environment.  Therefore, there's no point in mocking the value.

 

Thanks,

Simon

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

http://www.natpryce.com

[Grzegorz Gałęzowski]

I want to understand better what is a Value Object. I mean I understand that a Value Object is immutable and two value objects they are equal if their value are equals. Beyond this point:

I did some write up on values recently, where I tried to answer at least some of the questions, you may want to take a look: part 1, part 2, draft part 3. 

 

Do you think we can decide if an object could be a value object or is it something intrisic? 

I try a better explanation: many times when I see examples of value objects, I usually see String or Date, that they are obviously a value object, but if we think something more complex I start to doubt if they are really value objects or not.

GOOS describes some good strategies for discovering value objects. I would add that the same domain concept may be a value or not depending on what you do with it inside the application. For example a filesystem "path" may be treated as an object when you think of paths in terms of places where you e.g. create files. On the other hand, I saw applications that treat paths as values - because all they did was passing the paths received as its inputs to 3rd party APIs after doing some calculations and some comparisons on them.

 

As for testing, I agree with Nat - most of the time, the only visible behavior of values should be creating (calculating) other values. You can assert it by creating an expected value in your test and comparing the calculation result to the expected value you created. There are times, however, when making a value pass some data into another object rather than returning it might be more convenient.

 

grzesiek

[Josue Barbosa dos Santos]

On Sat, Sep 26, 2015 at 1:38 PM, Nat Pryce <nat....@gmail.com> wrote:

I'd probably not put validation in the value object, but try to make it impossible to create a value object for an invalid value. I'd put input validation at the edge of the system, in code that parses untrusted input into value objects.  Then the rest of the system can rely on the type system to guarantee that the values are not invalid.

 

So you don´t do this?

class MaxValue100(Integer value){

    //just an example.

    if (value > 100) throw Exception()

    this.value = value

}

Why? 

Isn´t good a VO validating himself in construction?

--

Abraços,
Josué
http://twitter.com/josuesantos

[Steve Freeman]

Usually the factory methods are closely related to the value types, think in terms of modules rather than just classes.

My preference is to keep constructors as simple as possible, essentially just initialising the state of the object. Once a value object is created, it doesn't need to carry the validation with it any more. If you like, think of it as separation of concerns: there's the value behaviour, and the creation of the value behaviour. They're related but not the same thing.

S

[Nat Pryce]

On 5 October 2015 at 15:23, Josue Barbosa dos Santos <josue...@gmail.com> wrote:

On Sat, Sep 26, 2015 at 1:38 PM, Nat Pryce <nat....@gmail.com> wrote:

I'd probably not put validation in the value object, but try to make it impossible to create a value object for an invalid value. 

So you don´t do this?

class MaxValue100(Integer value){

    //just an example.

    if (value > 100) throw Exception()

    this.value = value

}

 

No.

 

Why? 

Isn´t good a VO validating himself in construction?

Because I prefer the validation to be enforced by the type system (assuming untyped exceptions).

Taking your example, I'd give the type a simple, private constructor and write factory functions that takes a number that may be out of range and returns a Maybe<MaxValue100>.  Something like the following pseudocode:

class MaxValue100 {

    private MaxValue100(int value) {

        this.value = value;

    }

    public static Maybe<MaxValue100> fromInt(int value) {

        return value <= 100 ? Some(MaxValue100(value)) : None;

    }

}

--

http://www.natpryce.com