хорошо или плохо это не инженерные понятия. В этом разница между "упражнением что бы заставить тебя думать по другому/в нужном направлении" от реальности где ты врядли будешь эти ограничения соблюдать.

не надо применять эти правила "на проекте" - берешь себе маленькую задачку - например координация лифтов в здании - и ваяешь себе это все дело применяя эти правила как задачка на день два

особый интерес и польза будут от тех вещей где "да блин нереально соблюдая эти правила это сделать"

Безусловно, но как я понял, разговор про ограничения чуть шире чем про статью. Для начинающих эти “ограничения” для того что бы поддать что-то сомнению, подумать лишний раз и т.д. Но мне непонятно почему думать нужно всегда в ограничениях и что это хорошо

там вот придется придумать способ (он обычно есть и не один) и это именно то что подразумевает процесс обучения

сю-ха-ри

?

в нашей индустрии все плохо с образованием потому что "сначала нас учат иерархии наследования черех студентов и людей делать" а потом ты уже пишешь свой фреймворк

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

ну а потом уже "нету времени твою эту теорию изучать. я практик! Ремесленник!"

Теперь понял о чём вы

потому что в нашей индустрии мало опыта обучения и спрос очень высокий, можно быть и малознающим разработчиком, при этом кое как делать дела и получать хорошую зп

можно и много знающим быть и не уметь настраивать процессы)

это уже про менеджмент

народ, кто как дизайнит сущность, у которой в зависимости от состояния меняется функционал? Например в состоянии A доступны method1 и  method2; в состоянии B — method2 и method3; и в таком духе. Данные во всех методах используются одни и те же, разные фазы работы с этими данными
Вижу несколько решений:
1) В лоб, просто в каждом методе делать assert на нужное состояние
2) Для каждого состояния создать отдельный класс
3) Использовать паттерн состояние

вот гист с рандомным примером на PHP https://gist.github.com/WalentinG/0e764ced84c75f2bbe9bb1fcc4d9629a

2-3 варианты предпочтительные кмк, между ними разница буквально в наличие фасада со всеми методами. Еще важным может быть, насколько код, который будет использовать сущность “знает” про состояние

второй вариант

третий тоже самое что и первый с точки зрения контроля за состоянием, хотя он все же лучше первого

Как по мне, то паттерн Состояние для описания сущности Tournament не подходит. Во-первых, сущность большая, а состояние - лишь малая чсть логики этого большого куска. Во-вторых, непрозрачная обязанность. Tournament может всё - добавлять команды, начинаться, заканчиваться, восстанавливаться, менять количество команд. Даже резделив эту гору обязанностей по разным Tournament-ам в разных стостояних - эта проблема не решается. Предложил бы посмотреть в сторону Mediator или хотя бы разобрать логику на более мелкие части