SP
не использовать наследование/расширение типов там где оно не работает)
Size: a a a
2021 October 01
V
Спасибо. В дто структура базовая но дело не типизации свойств а в дополнительных свойствах
SP
базовые структуры в DTO это тоже обычно источник проблем. поменял базовую структуру и потом хер знает кто на это был завязан. провацирует тот самый "каскад изменений" с которым OCP из этих ваших солидов призван бороться.
V
А какой вариант с дто? Кроме поставить mixed?🙂
SP
пересматривать структуру и дата флоу
SP
я вот смотрю на этот твой ProductProviderInterface и не оч понимаю зачем он нужен
SP
и почему у тебя FirstProductProvider это DTO, это ж не DTO
SP
class BuyProductDto
{
public int $count;
public string $item;
}
class BuyFirstProductDto extends BuyProductDto
{
public float $price;
}
SP
я бы просто не юзал наследование и скопировал поля поскольку эти dto юзаются явно для разных операций
V
Provider все от интерфейсов
SP
ну или разбираться почему в одном случае стоимость нужна а в другом нет. откуда идут различия и искать более корректное разделение данных и абстракции
V
Один провайдер просто продаёт. Другой продаёт по твоей цене
SP
да, дублируй код
SP
это будет оптимально
SP
и почитай чего на тему DRY (что это не про "дублирование кода" в этом виде а про дублирование "знаний", больше коррелируется с SRP из Solid) и rule of three (не надо париться о дублировании пока ты не убедишься что это проблема)
V
Хорошо спасибо. В данном варианте все решение дто делать полными )
V
Да это щас про мой пример. Поставщики редко меняют структуру данных на апм и не все разом 🙂