Архитектура чита

[rtm]

Не могу определиться с архитектурой чита. Функции - радар, перемещение персонажа в заданную точку. 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]

Блин, наверное трудно осилить ахинею, которую я тут написал)

[MasterGH]

Я плохо разбираюсь в паттернах, но как я представляю.

 

View - отделить UI от кода. Визуальные компоненты.

Controller - связь кода и представления, интерфейс ввода/вывода. Связь между кодом и UI.

Model - логика. Что делает код.

 

Как я представляю, по этой абстрактной модели MVC можно делать много скинов независимо от логики. Можно менять и логику, она не будет зависеть от остального.

Ну, а Controller похоже нет смысла менять. Это как интерфейс между представлением и логикой.

 

В 09.09.2017 в 12:07, rtm сказал:

Как бы вы выделили классы?

Я не стал выделять классы, поскольку не могу помочь в этом