New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-traditional meaning of "value object" used #17

Closed
matthiasnoback opened this Issue Oct 25, 2018 · 16 comments

Comments

Projects
None yet
6 participants
@matthiasnoback

matthiasnoback commented Oct 25, 2018

Hey everyone, I noticed this library being announced on Twitter. To be very honest, I think it's weird that this library and its documentation use the term "value object". How this term is used in the software development world and in the DDD community in particular corresponds in almost no way to how this library uses it. Could you maybe cast some light on this from your perspective?

@brendt

This comment has been minimized.

Member

brendt commented Oct 25, 2018

Naming is hard... It's "an object concerned with passing data", in other words: values.

That's where the name came from, but I understand the confusion. We briefly considered calling it plain "struct" but that seemed too low level (I personally compared it to structs in Rust).

I also considered the name "data transfer object", but I was afraid people would say that it didn't adhere to the DDD definition. I was trying to avoid the exact problem you're (rightfully) addressing now 😅

You're maybe aware that we're not following strict DDD rules in our projects. Sure we use some principles from the DDD community, but definitely not all. This explains why I didn't immediately saw any issue with the name "value object".

Anyways, I don't mind changing the name, but I cannot think of any good alternative that's not reserved yet... Any ideas?

@nyamsprod

This comment has been minimized.

nyamsprod commented Oct 29, 2018

Maybe you should call this package a Data Wrapper Object since what your are doing is basically encapsulating the original data contained in the array using an object oriented API ? Better Yet a ArrayWrapper object.

@skyrpex

This comment has been minimized.

skyrpex commented Oct 29, 2018

I actually find ValueObjecta good name for the class and the repository. It's an object that contains valid values.

@nyamsprod

This comment has been minimized.

nyamsprod commented Oct 29, 2018

Well that's not the definition of a Value Object.

In computer science, a value object is a small object that represents a simple entity whose equality is not based on identity: i.e. two value objects are equal when they have the same value, not necessarily being the same object. Wikipedia

For instance a DateTime is a value object and a DateTimeImmutable is an immutable value object.

This package, on the other hand, marshaled, optionally validated and finally converts data contains in a array in a convenient object structure. As you can see the usage is radically different and the naming is misleading.

@skyrpex

This comment has been minimized.

skyrpex commented Oct 29, 2018

Thanks for the Wikipedia reference, @nyamsprod. It may only occur to me, but I see that the description in the Wiki correctly applies to what this library offers:

  • Two value objects are equal when they have the same value (PHP also requires that they are the same class).

For example, why can't this be considered a value object?

class IndexUsersOptions extends ValueObject
{
    /** @var int */
    public $page;
    /** @var int */
    public $perPage;
    /** @var int|null; */
    public $age;
}
@yitz-phoneburner

This comment has been minimized.

yitz-phoneburner commented Oct 29, 2018

DataObject? Avoids collision with both DataTransferObject and ValueObject.

@nyamsprod

This comment has been minimized.

nyamsprod commented Oct 29, 2018

@skyrpex

PHP also requires that they are the same class

There is no such requirement in PHP

@skyrpex

This comment has been minimized.

skyrpex commented Oct 29, 2018

@skyrpex

PHP also requires that they are the same class

There is no such requirement in PHP

In order to the equality return true, yes. See http://sandbox.onlinephpfunctions.com/code/5c09aeb96292e677cc8f51f45b896e80e3b48238.

<?php

class ValueObject
{
}

class ExampleA extends ValueObject
{
    public $int;
    
    public $string;
}

class ExampleB extends ValueObject
{
    public $int;
    
    public $string;
}

// ExampleA and ExampleA are equal
$a = new ExampleA;
$a->int = 123;
$a->string = "abc";

$b = new ExampleA;
$b->int = 123;
$b->string = "abc";

var_dump($a == $b); // prints true

// ExampleA and ExampleB are different
$a = new ExampleA;
$a->int = 123;
$a->string = "abc";

$b = new ExampleB;
$b->int = 123;
$b->string = "abc";

var_dump($a == $b); // prints false
@matthiasnoback

This comment has been minimized.

matthiasnoback commented Oct 30, 2018

Actually, "DataTransferObject" wouldn't be a crazy idea after all. In fact, I created some package myself some time ago to implement the immutability aspect for DTOs that you're after with this library too (https://github.com/matthiasnoback/convenient-immutability). But you're also implementing typed properties, which is cool. What's important to me is that a DTO is an object you can decide to "populate" in part (whereas a Value Object can never exist in an incomplete or inconsistent state). Comparing Value Objects is indeed about equality (I didn't know about PHP's ability to ignore the class and only look at the values by the way!). But it's more about the correct representation of a domain concept. I don't think you could ever write a library that would help with that. All Value Objects are custom-made. For DTOs though, a library like this can be useful. It's just for passing around data (from JSON string or POST request data to application service, or to a template).

"DataObject" could be an option too, but you'd be introducing a technical term that isn't available yet (afaik). Plus it's way too generic in my opinion. You could also describe what this library offers, e.g. "ImmutableTypeSafeDTOs". In my opinion there's no correct DDD definition of a "DTO", but there is one for a "Value object", which leads me to conclude that it's better to let go of "Value object", and use "DTO" instead.

A little background: I'm offering training on topics like DDD and it's already had to for people to grasp the idea behind a value object and implement it right. So I don't think it should be any more confusing by mixing up terminology.

@brendt

This comment has been minimized.

Member

brendt commented Oct 30, 2018

So I don't think it should be any more confusing by mixing up terminology.

I agree Matthias. We discussed the name of this package at length last Friday, and decided we're going to change the name.

We settled on DataObject, because I was afraid of "claiming" the name DataTransferObject. However, if you think of it as a valid option to use DTO, I think we should go with it.

I'll leave this issue open for a few more hours, to see if there's any more input. Without any good arguments against DataTransferObject, it'll be the new name of this package later today or tomorrow.

@matthiasnoback

This comment has been minimized.

matthiasnoback commented Oct 30, 2018

Cool! Yes, I consider "DTO" a valid option here. Keep up the good work!

@matthiasnoback

This comment has been minimized.

matthiasnoback commented Oct 30, 2018

Also, thanks for a fruitful discussion and thanks everyone for their input.

@nyamsprod

This comment has been minimized.

nyamsprod commented Oct 30, 2018

@skyrpex value object equality is different from PHP object equality.
@matthiasnoback @brendt I agree that Data Transfer Object looks better to me too 👍

@driesvints

This comment has been minimized.

driesvints commented Oct 30, 2018

DataTransferObject is a good name. I now actually realize that I've been doing the same thing in a previous project at one point and we always called those object DTO's.

@brendt brendt self-assigned this Oct 30, 2018

@brendt

This comment has been minimized.

Member

brendt commented Nov 5, 2018

Took a bit longer than expected, but the package is now called data-transfer-object.

@brendt brendt closed this Nov 5, 2018

@matthiasnoback

This comment has been minimized.

matthiasnoback commented Nov 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment