Мне одному мозолят глаза public атрибуты в примерах? Инкапсуляция, наследование и полиморфизм до SOLID обычно продаются. Если уж давать примеры, то сразу по всем канонам, ничего бы не усложнилось сильно.
Вообще все зависит от случая. Есть много примеров, когда небольшой семейный бизнес по продаже шмотья приносить прибыль, которая позволяет не работать пару месяцев летом. Или наоборот работаешь пару месяцев в году, а потом ждешь следующего сезона. Надо за год оценку брать.
В придачу к legacy коду часто достаются legacy разработчики, которые в упор не видят своих проблем, не хотят ничего менять, а банку червячков поддерживать становится все сложнее и бессмысленнее.
> Лично меня подобное не смущает.
> Ну и если вы все еще считаете что «это не очевидно» и т.д. предлагаю вам не личные субъективные ощущения (или мои) использовать, а провести полноценное исследование данного вопроса.
Не конструктивно. На сколько я понимаю, вы не проводили исследование и точно не знаете, что у неизменяемого объекта лучше делать методы из названия которых предполгается, что объект будет изменен, но вдруг эти методы начинают возвращать клонированный новый объект якобы для подхода в стиле ФП.
> Ну и опять же вопрос в том что имутабельность это хорошо (потому что можно всегда вывести типы и отследить стэйт не запуская код) но получать новые значения все еще нужно. И проще клонировать объект при изменениях (можно частично если эти части не меняются).
Я не против клонирования неизмениямых объектов, я против клонирования этих объектов через методы этого объекта, предполгаюащие изменение самого объекта.
Можно ввести статический метод и клонировать через него. Только на входе у него будет source объект и значение, которое нужно получить в новом объекете.
final class Money
{
public static function add(Money $source, double $sum): Money
{
// ...
}
}
К тому же изменяемые объекты так же можно делать неизменяемыми, для этого можно создавать обертки:
class Mutable
{
protected $val;
public function __construct(int $val)
{
$this->val = $val;
}
public function getVal(): int
{
return $this->val;
}
public function add(int $val): void
{
$this->val += $val;
}
}
class Immutable extends Mutable
{
public static function addAndClone(Immutable $immutable, int $val): Immutable
{
return new Immutable($immutable->getVal() + $val);
}
public function add(int $val): void
{
throw new \RuntimeException('Immutable value.');
}
}
Слишком короткая цепочка получается. В случае, например, построения запросов, конфигурирования, фильтрации и т.д. это было бы оправданно. Но здесь, на мой личный взгляд, бессмысленное притягивание ФП за уши. У неизменяемого объекта лучше уж вообще не делать таких методов, чтобы не вводить в заблуждение. А изменять его статичными методами, чтобы было очевидно, что объект неизменяемый.
Я, конечно, понимаю, что некропостингом занимаюсь, но через поиск на статью попал, интересно стало, чем же все в итоге закончилось? Дело было или нет? Результат? Что с обменником? Еще продолжили заниматься обменниками может на серверах за рубежом или надоело? Сейчас домен ведет на http://файлообменник.рф, не ваш? В общем много вопросов, а развязку я вроде бы не увидел ни в коментариях ни в статье.
Статья отражает и мое впечатление об изменениях в сфере веб-разработки за последние 10 лет. Вряд ли описанные шаги являются пособием для новичков, но они хорошо показывают то, как изменились требования к соискателям. Времена, когда знания PHP было достаточно, ушли. Для развертывания приложений сейчас требуется выполнить столько всевозможных настроек и установок, что начинаешь ощущать себя админом, возможно, Docker и решает частично этот вопрос, но он же порождает новые конфиги. Сами приложения теперь включает в себя множество подязыков и языки на языках. Да можно сделать сборку и пользоваться ей, но она устаревает уже через полгода. С легкостью прыгнуть с проекта на проект не получается, нужно смотреть список задействованных технологий. И проблема здесь не в средствах разработки, не в том фреймворке, который вы выберете, а в требованиях к конечным продуктам. Планка выросла. Мне это напоминает игровую индустрию, раньше игру мог написать один человек, сейчас такая игра никому уже не будет интересна, есть исключения, но это будет не та игра, которые сейчас выпускаются корпорациями.
А как же доступ к атрибутам класса через методы этого класса.
А разве доктрина сама все не генерирует? И сущности и репозитории и базу? По крайней мере в Symfony это генерируется.
Что программируете? Почему не можете это сделать работой?
Есть особый вид бизнеса — ебизнес) Если бизнес приносит меньше чем 2.5*ЗП, тогда нет смысла, нервы, усталость и т.д.
В придачу к legacy коду часто достаются legacy разработчики, которые в упор не видят своих проблем, не хотят ничего менять, а банку червячков поддерживать становится все сложнее и бессмысленнее.
> Ну и если вы все еще считаете что «это не очевидно» и т.д. предлагаю вам не личные субъективные ощущения (или мои) использовать, а провести полноценное исследование данного вопроса.
Не конструктивно. На сколько я понимаю, вы не проводили исследование и точно не знаете, что у неизменяемого объекта лучше делать методы из названия которых предполгается, что объект будет изменен, но вдруг эти методы начинают возвращать клонированный новый объект якобы для подхода в стиле ФП.
> Ну и опять же вопрос в том что имутабельность это хорошо (потому что можно всегда вывести типы и отследить стэйт не запуская код) но получать новые значения все еще нужно. И проще клонировать объект при изменениях (можно частично если эти части не меняются).
Я не против клонирования неизмениямых объектов, я против клонирования этих объектов через методы этого объекта, предполгаюащие изменение самого объекта.
Можно ввести статический метод и клонировать через него. Только на входе у него будет source объект и значение, которое нужно получить в новом объекете.
К тому же изменяемые объекты так же можно делать неизменяемыми, для этого можно создавать обертки:
Если вызываешь add у объекта, то ждешь, что добавление будет именно к этому объекту. В чем проблема была через статик дублировать.