Я недоволен этой реализацией, если будет больше условий и изменения состояний не линейные, как у вас в примере, т.е. я могу вернуться обратно в предыдущее состояние или вообще перескочить, то у вас будет огромный вложенный 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)
Добрый вечер. Спасибо за урок. Есть вопрос. Такой подход ведь нарушает принцип единой ответственности. Когда один объект начинает уметь выполнять разные вещи. Или здесь "центральный объект" служит перекрестком для других объектов, которые как раз таки и удовлетворяют приницпу единой ответственности. То есть как бы не объект может делать много вещей, а он вмещает в себя функционал разных объектов. Я правильно понимаю?
Писать код, спать, читать и тренироваться. Да это же идеальный программист )))
совсем ку ку? идеально это вместо писанины кода играть во что то и вместо чтения смотреть аниму на роботе
Робот какой-то а не человек)
Я недоволен этой реализацией, если будет больше условий и изменения состояний не линейные, как у вас в примере, т.е. я могу вернуться обратно в предыдущее состояние или вообще перескочить, то у вас будет огромный вложенный if в одном месте. А паттерн должен этот 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)
А не лучше было бы прописать прямо в конкретных реализациях activity у каждого действия его следующее действие? И код получился бы кучи if else
Добрый вечер.
Спасибо за урок.
Есть вопрос.
Такой подход ведь нарушает принцип единой ответственности.
Когда один объект начинает уметь выполнять разные вещи.
Или здесь "центральный объект" служит перекрестком для других объектов, которые как раз таки и удовлетворяют приницпу единой ответственности.
То есть как бы не объект может делать много вещей, а он вмещает в себя функционал разных объектов.
Я правильно понимаю?
Спасибо)
Анжумания делат, пресс качат, бегит
Thank's a million
Thanks!
Это же FSM как понимаю?
Насколько я понимаю, этот шаблон также реализуется через enum. А в Java17 - через sealed классы