Я недоволен этой реализацией, если будет больше условий и изменения состояний не линейные, как у вас в примере, т.е. я могу вернуться обратно в предыдущее состояние или вообще перескочить, то у вас будет огромный вложенный if в одном месте. А паттерн должен этот if разбивать на классы. В общем, условия должны перетечь в классы реализации активити и в них же должно меняться состояние активити. Чтобы было яснее, нарисуйте детерминированный конечный автомат чуть сложнее вашего и примера и станет ясно, где ошибка
Вы говорите что шаблон применяется когда много условных операторов. При таком подходе, который вы описали, получается что к условным операторам прибавилось столько же классов. Во первых, условные операторы остались в методе changeActivity() класса Developer, во вторых, если нужно добавить новое состояние, нам нужно не просто сделать новую проверку, а еще и добавить новый класс для нужного состояния.
Вы немного не том сделали акцент - главное - это то, что выбор ветви зависит от состояния объекта. Если добавить сюде стремление следовать SOLID - то данный шаблон крайне полезен (при уместном его использовании).
Спасибо за материалы. Сжато и быстро! Idea Preferences / Editor / File and Code Templates / Includes / File Header (adjusting the header of the class) or Idea Preferences / Editor / File and Code Templates / Class (removing the whole header of the class)
Добрый вечер. Спасибо за урок. Есть вопрос. Такой подход ведь нарушает принцип единой ответственности. Когда один объект начинает уметь выполнять разные вещи. Или здесь "центральный объект" служит перекрестком для других объектов, которые как раз таки и удовлетворяют приницпу единой ответственности. То есть как бы не объект может делать много вещей, а он вмещает в себя функционал разных объектов. Я правильно понимаю?
