Когда читал, думал что будет развита идея, об осознанном применении инструментов разработки включая версии языка...
Собственно новые версии языка создаются не просто так они решают определённые задачи которые необходимы для разработчиков. Да не всегда используется весь инструментарий, но это зависит от различных факторов, а уж от хостера меньше всех (хотя, если бюджеты копеешные и за каждый доллар в месяц нужно воевать, то наверно есть определённая зависимость)
К тому же обновление до последних версий очень желательно. Это связано в первую очередь с поддержкой языка и обновлениями связаннвюыми с безопасностью (но это уже другая тема)
К сожалению PHP не имеет нормального инструмента для реализации перечислений и приходилось выкручиваться, а использовать в таком виде
public function someFunc(TheEnum $enum): void {}
куда безопасней, наглядней и понятней, чем в таком
public function someFunc(string $enum): void {}
Мы пришли к тому что бы использовать одиночку (при строгом и не строгом сравнивании был один результат) при этом реализация одиночки была положена в абстрактный класс Enum, а вот наследники должны были реализовать определенный метод, в котором весь пул доступных значений.
К сожалению приходилось перечислять все статические методы, но без этого ни куда.
Правда мы не учитывали кейсы где мы используем serialize или unserialize т.к. мы используем JMS сериалайзер и сериализуем в JSON, с кастомными handler-ами.
Действительно, хотелось бы детальней подобную тему раскрыть. Желательно без бонального "закладывает я при разработке", т.к спустя время технические компоненты устаревают, и с течением времени копится техдолг, если его не решать.
Ну так бейте большие куски на маленькие, тестируемые unit-ы, а уж потом собирайте из них большие куски, для которых тоже сначала пишите тесты. Single Responsibility Principle очень удобная штука.
Полностью согласен. Хотел бы добавить, что не малый фактор влияет на возможность тестирования декомпозиция на модули, особенно для unit тестирования. Для больших кусков с огромным числом исходов и вариаций поведения весьма сложно написать unit-тест, а уж тем более поддерживать его. Это приводит к увеличению цены unit-тестов.
Для решения подобной проблемы стоит активно использовать паттерны и принципы.
А вот то что творится в отрасли, гораздо сложнее понять и разобраться.
Когда читал, думал что будет развита идея, об осознанном применении инструментов разработки включая версии языка...
Собственно новые версии языка создаются не просто так они решают определённые задачи которые необходимы для разработчиков. Да не всегда используется весь инструментарий, но это зависит от различных факторов, а уж от хостера меньше всех (хотя, если бюджеты копеешные и за каждый доллар в месяц нужно воевать, то наверно есть определённая зависимость)
К тому же обновление до последних версий очень желательно. Это связано в первую очередь с поддержкой языка и обновлениями связаннвюыми с безопасностью (но это уже другая тема)
куда безопасней, наглядней и понятней, чем в таком
Мы пришли к тому что бы использовать одиночку (при строгом и не строгом сравнивании был один результат) при этом реализация одиночки была положена в абстрактный класс Enum, а вот наследники должны были реализовать определенный метод, в котором весь пул доступных значений.
К сожалению приходилось перечислять все статические методы, но без этого ни куда.
Правда мы не учитывали кейсы где мы используем serialize или unserialize т.к. мы используем JMS сериалайзер и сериализуем в JSON, с кастомными handler-ами.
Действительно, хотелось бы детальней подобную тему раскрыть. Желательно без бонального "закладывает я при разработке", т.к спустя время технические компоненты устаревают, и с течением времени копится техдолг, если его не решать.
Как раз про это и сказал в последнем предложении.
Для решения подобной проблемы стоит активно использовать паттерны и принципы.