What are the advantages of ValueObject and DTO?

Question

symfony

I looked at a bunch of materials about this pattern everywhere they explain the essence, but why I still don’t understand
it, let’s say let’s do it

class DateRange {

function __counstruct( $from, $to ) {
   . . .
}

function getValue($name) {
    if($name != "from" and $name != "to" ) {
         throw new \Exception("");
    }

    return $this->{$name};
}

Well, the parameter to the function will need to be passed not two but one. behavior, then there is no
second question about DTO
, I also read about it
and realized that my code

return $this->render($view, 
     array_map(function( $hit ) {
          return $hit->getVersionInfo()->getContenInfo();
     }, $searchResults);

in a sense, I also reduce a complex object and pass the DTO to the view, right?
I see the point of ValueObject and DTO only if an extensible application is being developed to ensure that the developer passes an object in which the necessary property is available to the desired function,
but inside in those parts whose logic is fixed and cannot change - the key-value array is quite suitable
some time ago I noticed that my controllers often return an array with 3 keys content, searchResults, facets, and even thought to define a class for such a data structure,
but then did not - because sometimes you need a 4th key or even a 5th one, and if one of these keys is not passed somewhere, this is immediately an Exception and rightly so - the system cannot work without them
and another 3rd question
how to implement in php a typed collection like in SI
so that each element of the array is one specific instance?
Thanks to all

Answer 1

The advantage of VO is that these are values ​​that have already been checked for bounds and type. In your example, validation occurs in the getter - this is, to put it mildly, pointless. Here is an example for you

class UUID
{
    /** @var string */
    private $value;

    /**
     * @param string $value
     */
    public function __construct(string $value)
    {
        if (!preg_match('/^[\da-f]{32}$/', $value)) {
            throw new \InvalidArgumentException(
                sprintf('Argument "$value" must be correct UUID, actual value: "%s"', $value)
            );
        }
        
        $this->value = $value;
    }

    /**
     * @return string
     */
    public function getValue(): string
    {
        return $this->value;
    }
}

Further in the code, you just need to do type hinting on the VO type and that's it, the value will be correct. From reflection, or runkit, you still can not defend yourself.
-- --
DTO is a thing for convenient data transport between different parts of the system. For example, you have a method that takes 20+ arguments as input (for example, registration), it will probably not be convenient to call such a code, but after collecting dto you can pass it with one argument and rely on the data being transferred with the correct types. The boundary values ​​will have to be checked, since the task of "transport" does not include checking the correctness of the data between the systems that use it.
Using KV in the context of DTO/VO is a wildly shitty practice, in very rare cases its use justifies itself. The fact is that an array is a collection of arbitrary data. To write reliable code, you will have to check the correctness of this array at each stage. What are these checks?
* all required keys exist
* all values ​​for these keys are of the correct types
* the array does not contain left data

class MyTypedCollection implements \Countable, \IteratorAggregate, \ArrayAccess
...

Answer 2

Well, the parameter to the function will need to be passed not two but one. there is no behavior

But the parameters themselves are clearly defined, their types, default values, there is validation.
Passing arrays is bad form.

a key-value array is fine

The method leads to many errors, is more verbose, more expensive to maintain.

how to implement a typed collection of type in php as in SI

So implement it - use type hinting in getters and setters. And validation for more complex situations.