rtm Опубликовано 9 сентября, 2017 Поделиться Опубликовано 9 сентября, 2017 Не могу определиться с архитектурой чита. Функции - радар, перемещение персонажа в заданную точку. MVC паттерн. Как определить классы? Надумал два варианта. 1. Класс Монитор(Model): входные данные - pid, View`шки, характеристики мониторинга. выходные - контейнер с структурами персонажей. внутри зашиты все нужные оффсеты. включает в себя класс по работе (композиция) Класс Телепортер(View): входные данные - некоторые начальные характеристики телепортирования, контейнер с структурами персонажей от Model. выходные - увидомление о телепортировании персонажа. перемещает персонажа на x, y, z. внитри зашиты все нужные оффсеты(теже, что и Model, что плохо). включает в себя класс по работе(теже, что и Model, что плохо). Класс Отображение(View): входные данные - некоторые начальные характеристики движения, контейнер с структурами персонажей от Model. выходные - отображение данных. Класс Монитор только добывал данные из игрового процесса и передавал View`шкам. Класс Телепортер, получав информацию от Model, выполнял перемещение. Но мне не понравилось, что оффсеты и класс по работе с памятью дублируются и хранятся в двух разных местах. Решил как то переделать. 2. Класс Игра: входные данные - pid. выходные - контейнер с структурами персонажей внитри зашиты все нужные оффсеты. включает в себя класс по работе (композиция) Класс Монитор(Model): входные данные - Класс Игра, View`шки, характеристики мониторинга. берет контейнер с персонажами у класса Игра и передает всем View`шкам. Класс Телепортер(View): входные данные - Класс Игра, характеристики движения, контейнер с структурами персонажей от Model. выходные - увидомление о телепортировании персонажа. посылает классу Игра "сигнал" о том, что надо переместить персонажа на x, y, z. Класс Отображение(View): входные данные - некоторые начальные характеристики движения, контейнер с структурами персонажей от Model. выходные - отображение данных. То бишь у меня получился какой то God Object в виде класса Игра, который читал память игры, перемещал персонажа, хранил оффсеты и т.д. К тому же, так как надо было обеспечить потокобезопасность и ассинхронность операций, он получился громоздким, что тоже не особо нравится. Классы Монитор и Телепортер просто управляют классом Игра. И что то мне это тоже не особо нравится. Как бы вы выделили классы? Ссылка на комментарий Поделиться на другие сайты Поделиться
rtm Опубликовано 11 сентября, 2017 Автор Поделиться Опубликовано 11 сентября, 2017 Блин, наверное трудно осилить ахинею, которую я тут написал) Ссылка на комментарий Поделиться на другие сайты Поделиться
MasterGH Опубликовано 11 сентября, 2017 Поделиться Опубликовано 11 сентября, 2017 Я плохо разбираюсь в паттернах, но как я представляю. View - отделить UI от кода. Визуальные компоненты. Controller - связь кода и представления, интерфейс ввода/вывода. Связь между кодом и UI. Model - логика. Что делает код. Как я представляю, по этой абстрактной модели MVC можно делать много скинов независимо от логики. Можно менять и логику, она не будет зависеть от остального. Ну, а Controller похоже нет смысла менять. Это как интерфейс между представлением и логикой. В 09.09.2017 в 12:07, rtm сказал: Как бы вы выделили классы? Я не стал выделять классы, поскольку не могу помочь в этом Ссылка на комментарий Поделиться на другие сайты Поделиться
Рекомендуемые сообщения