В прошлом эпизоде мы завершили работу с представлением. А сегодня займёмся усовершенствованной работой с состоянием. Вместо работы с состоянием в виде примитивной структуры мы сделаем полноценный объект-хранилище.
После этого автоматизируем вызов перерендера страницы, реализовав возможность подписывать свои слушатели на событие изменения состояния.
А в следующем эпизоде активно займёмся доработкой действий.
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Вопрос о вредности сеттеров. Если избавиться от сеттеров, то как в том же php инициализировать фикстуры в определенном состоянии? Например статус у фикстуры должен быть processing, а сеттер для статусов я убрал. Как при таком подходе инициализировать фикстуру?
Инициализировать через вызовы реальных методов, а не через сеттеры.
Как мы делаем свои фикстуры для регистрации.
Понятно. Просто в качестве бандла для фикстур используется nelmio/alice . Там декларативный стиль объявления фикстур. А статус меняется только через workflow.
В этом как раз и неудобство многих таких готовых декларативных решений вроде Alice, админок, API-бандлов и прочего. Что они умеют работать только с примитивными анемичными сущностями через геттеры и сеттеры.
Кстати хороший вопрос. Я у В.Вернона читал, что конструктор и мутирующие методы могут вызывать доменные события или другие "побочные эффекты" кроме изменения состояния. Однако есть ещё задача просто восстановить состояние из БД или создать фикстуру. В принципе может быть гидрация через рефлексию. А ещё видел трюк с наследованием сущности для добавления сеттеров полей: при восстановлении используется расширенная версия, а по остальному коду бегает базовая версия без сеттеров.
Да, Doctrine и подобные ORM как раз для записи и восстановления из БД используют прямой доступ к приватным полям через рефлексию или bind анонимной функции, не вызывая конструктор. Поэтому там никаких проблем с конструкторами и методами нет.
Как всегда - высший класс! Спасибо за четкое объяснение без воды.
Спасибо
Вопрос наверное больше по ООП: в чем преимущество в параметрах методов, таких как calculateTotalPrice(), передавать не сразу весь объект (product например), а только те числовые параметры, которые точно нужны для расчета: product.quantity, product.price И по итогу мы имеем:
calculateTotalPrice(product)
и
calculateTotalPrice(product.quantity, product.price)
В чем преимущество или недостатки первого и второго? Спсибо
1) Если мы пишем тесты, то для второго способа тест будет таким:
assertEqual(75, calculateTotalPrice(3, 25))
А для первого нам нужно будет создать весь объект со всеми даже не нужными нам полями:
product = new Product(1, 'Title')
product.setPrice(25)
product.inStock(3)
assertEqual(75, calculateTotalPrice(product))
2) Первый метод можно использовать только c объектом продукта. А второй метод можем использовать напрямую с числами из БД или кэша.
Значит часть логики Вы предлагаете вынести в некий "экшен" для:
Но какую часть логики стоит выносить? Оно интуитивно понятно, но хотелось бы определение :)
Насколько понял:
Верно. В View оставлять только пассивные вычисления и форматирования для отрисовки. А все активные операции, произвдящие изменения, помещать в экшены.
Спасибо.