Сообщение Psr7 Http, почему неизменное?

Я смотрю на интерфейсы PSR-7 и думаю, как реализовать их.

Я также читаю эту запись в блоге. Очевидно, что объекты, реализующие интерфейсы PSR-7, должны быть неизменяемыми.

Итак, если я реализую метод withProtocolVersion из MessageInterface, это будет выглядеть примерно так:

public function withProtocolVersion($version)
{
    if ( $this->protocol === $version )
    {
        return $this;
    }

    $new = clone $this;
    $new->protocol = $version;
    return $new;
}

Мой вопрос действительно в том, почему неизменный? Почему бы просто не сделать return $this;?

Не то чтобы меня беспокоил объем памяти, которую он выделяет, я просто не вижу никакой пользы в сохранении его неизменности.

Как говорится в сообщениях блога, когда вы делаете это:

$request = $request
    ->withMethod('POST')
    ->withUrl(new Url('http://example.org/')
    ->withHeader('Content-Type', 'text/plain');

Затем создаются четыре копии, но конечный результат в $request такой же, как если бы я просто использовал return $this, верно?

Почему принято решение оставить его неизменным. Так почему я должен делать clone $this? Какая от этого польза?

Я не совсем понимаю, почему это началось.


php psr-7
person Vivendi    schedule 11.07.2015    source источник
comment
В последнем абзаце этого раздела сообщения в блоге говорится: Это решение было принято в целях надежности. Очевидно, это устранит целый класс ошибок.   -  person Barmar    schedule 11.07.2015
comment
@Barmar Я действительно не понимаю, что он имеет в виду. Я действительно не понимаю, как это могло бы удалить целый класс ошибок. Так как же удалить класс ошибок? Вы по-прежнему можете установить все свойства. Единственное, что он делает, это возвращает новую копию объекта вместо самого объекта.   -  person Vivendi    schedule 11.07.2015

Ответы (1)


arrow_upward
9
arrow_downward

Я предлагаю вам прочитать этот документ, где указаны все варианты дизайна. подробно объяснил.

В частности, вы должны прочитать разделы Why value objects? и New instances vs returning $this.

Ключевые моменты следующие:

По сути, моделирование HTTP-сообщений как объектов-значений обеспечивает целостность состояния сообщения и предотвращает необходимость в двунаправленных зависимостях, которые часто могут рассинхронизироваться или приводить к отладке или проблемам с производительностью.

а также

Эти операции можно выполнять и с объектами-значениями, что дает ряд преимуществ:

  • Исходное состояние запроса может быть сохранено для извлечения любым потребителем.
  • Состояние ответа по умолчанию может быть создано с заголовками по умолчанию и/или телом сообщения.

Если вы хотите копнуть глубже, я бы порекомендовал заглянуть в историю списка рассылки fig (вы можете найти его здесь), где было много обсуждений неизменности объектов

person marcosh    schedule 11.07.2015
comment
Спасибо, в настоящее время работаю над списком рассылки. Но это уже заставило меня понять идеи, лежащие в основе неизменяемых объектов запроса. - person Vivendi; 12.07.2015
comment
Не вижу причин в приведенных ссылках. дело в том, что на этот прямой вопрос нет ответа напрямую, а с какими-то ссылками и такими же расплывчатыми мнениями. Мнения о возможных заблуждениях других разработчиков. Это доказывает мне, что это серьезное дизайнерское решение не совсем обосновано и, вероятно, основано только на том, как php используется и ведет себя в настоящее время/в прошлом. - person Summer-Sky; 27.09.2016