Просмотр полной версии : [Вопрос] Совет по архитектуре системы
Пишу одну из ключевых систем и она выходит на тысячу строк. В ней описаны действия на некоторых машин (5) и каждой из них по несколько функций. Как мне поступить? Продолжать все делать в одном файле или разбить на файлы под каждый транспорт и файл с перехваченными колбеками, и поместить в папку с названием системы?
Я бы поступил по второму варианту, ибо так и делаю, и мне на много удобнее так писать и разбираться. Все моды в пабликах еще где всё одним файлом обычно отличаются своим говнокодом, не знаю почему, это просто по моей статистике)) Может это и есть признак более адекватного и структурированного написания) Каждому своё как говориться)
Я бы сделал отдельный инклуд с перехватами и необходимыми функциями, а все остальное оставил в моде.
Если не планируете публиковать мод, делайте так, как Вам будет удобно его поддерживать.
Ответ очень простой - делайте так, как вам нужно. Не нужно спрашивать остальных, так как каждый делает по-своему. Можно и в одном файле написать все так, чтобы можно было быстро найти и прочесть, чем, например, использовать файл, так и наоборот.
Все дело в том - мод для паблика
Все дело в том - мод для паблика
В чем проблема то? Структура не так важна, как важен код и то, как он написан.
Daniel_Cortez
01.02.2019, 17:46
Структура не так важна, как важен код и то, как он написан.
Сравнение тараканов с тапками. Структура - это не что-то отличное от кода, это один из критериев его качества, поэтому да, она в любом случае имеет значение.
m1n1vv, в качестве примера советую взглянуть на Open-GTO (https://github.com/Open-GTO/Open-GTO), сейчас это один из немногих грамотно структурированных модов (разве что копировать куски кода прямиком оттуда - не самая лучшая идея, ибо лицензия разрешает только некоммерческое использование).
Сравнение тараканов с тапками. Структура - это не что-то отличное от кода, это один из критериев его качества, поэтому да, она в любом случае имеет значение.
m1n1vv, в качестве примера советую взглянуть на Open-GTO (https://github.com/Open-GTO/Open-GTO), сейчас это один из немногих грамотно структурированных модов (разве что копировать куски кода прямиком оттуда - не самая лучшая идея, ибо лицензия разрешает только некоммерческое использование).
А почему pwn не в gamemode?
Open-GTO не так идеален, как хотелось бы, на самом деле.
Правда, уже и не вспомню что именно было, но когда работать с ним приходилось, была парочка не очень логично разбитых на файлы систем. И идея разбивать одну и ту же систему на pwn и inc - тоже такое себе, как по мне. Приходится много лишних телодвижений делать, чтоб проследить те или иные зависимости.
Ну а если по теме, то способов разбить код на файлы - уйма. И нельзя сказать, что какой-то из них прямо лучше других (особенно в SA-MP, где разбивка мода на файлы не распространена от слова "совсем" и нет каких-то устоявшихся реализаций). Всё очень зависит от структуры кода системы и того, как остальной код структурирован.
Лучше почитай статьи на эту тему, почерпни для себя парочку разных точек зрения и попробуй определиться с тем, что подойдёт в твоей ситуации.
Open-GTO не так идеален, как хотелось бы, на самом деле.
Правда, уже и не вспомню что именно было, но когда работать с ним приходилось, была парочка не очень логично разбитых на файлы систем. И идея разбивать одну и ту же систему на pwn и inc - тоже такое себе, как по мне. Приходится много лишних телодвижений делать, чтоб проследить те или иные зависимости.
Ну а если по теме, то способов разбить код на файлы - уйма. И нельзя сказать, что какой-то из них прямо лучше других (особенно в SA-MP, где разбивка мода на файлы не распространена от слова "совсем" и нет каких-то устоявшихся реализаций). Всё очень зависит от структуры кода системы и того, как остальной код структурирован.
Лучше почитай статьи на эту тему, почерпни для себя парочку разных точек зрения и попробуй определиться с тем, что подойдёт в твоей ситуации.
Вот как я воспринимаю архитектуру (http://tscars.narod.ru/sfcr2/inc.png). Не идеал, но разобраться не сложно что к чему. Каждая по мелочи зависит друг от друга. Склеивается PVar'ами.
Так почему файл мода не в папке gamemode?
Насчёт мода не в gamemode - хз (Ziggi, вроде, отвечал на это, и, кажется, даже в такой же теме с вопросом об архитектуре, но уже не помню чем он это обосновывал).
Насчёт разбивки скрипта на файлы: имхо, но разбивать на файлы и использовать, при этом, перехваты - не очень хорошая. В написании это, конечно, проще, но вот редактировать такой код довольно сложно, так как будет трудно изменить порядок вызова какой-то одной из перехваченных функций (особенно если ты не автор кода). Уж лучше просто обрамлять код в функции, а функции уже вызывать в pwn, тем самым позволяя легко увидеть то, какие инклуды вызываются в том или ином коллбэке и легко поменять порядок вызова.
Я в своём моде придерживаюсь простых правил:
1) Одна система = один инклуд (и инклуды раскиданы по папкам, по типу "admin", "player", "core" и т.п.)
2) Одна функция выполняет только одну конкретную задачу
3) Все "перехваты" коллбэков реализуются через вызов функций внутри pwn
- - - Добавлено - - -
Вот как я воспринимаю архитектуру (http://tscars.narod.ru/sfcr2/inc.png)
Для паблик-мода, имхо, не лучшая структура. Античиты и фиксы стоит вынести как отдельные корневые папки, а не распихивать по другим папкам. У паблик-мода должно быть минимум вложенных папок, как мне кажется, ибо это усложнит запоминание структуры проекта при работе с ним.
И вспомнил один из спорных моментов в Open-GTO. Команды админов там реализованы как "1 команда = 1 файл", а команды игроков все в одном файле находятся. Это сбивает с толку при первом знакомстве с модом.
Так же там есть некоторые довольно спорные разделения на файлы. Например, такая простая система, как личные сообщения, разбита на 2 файла (отдельно команда и отдельно не очень большая функция где-то строк на 30). Это лишь усложняет поиск нужного файла, как по мне (ну чем больше файлов, тем длиннее список и дольше нужно по нему глазами пробегать, чтоб найти нужный файл). Не очень оправдано с учётом того, что там в файле всего 1 функция.
Ну и разбивать команды на отдельные файлы - в целом, сомнительная идея, ибо вместо того, чтоб открыть один файл и просто воспользоваться поиском, тебе приходится либо вручную выискивать нужный файл, либо пользоваться поиском по файлам, что не так быстро, как просто поиск по файлу (в том плане, что поиск по файлу - нажатие "Ctrl+F", в отличии от поиска по папке, где нужно папку выбирать и т.п.)
Не хватает плагина, который мог бы взять на себя работу над модулями.
На скрине архитектура мода не для паблика. В паблик-моде будет: players, vehicles, admins. Сейчас ломаю голову, как удобней поставить мускул. Или делать в файле мода, или сделать папку database и там разложить файлам регистрацию, загрузку и сохранение.
Open-GTO не так идеален, как хотелось бы, на самом деле.
Правда, уже и не вспомню что именно было, но когда работать с ним приходилось, была парочка не очень логично разбитых на файлы систем. И идея разбивать одну и ту же систему на pwn и inc - тоже такое себе, как по мне. Приходится много лишних телодвижений делать, чтоб проследить те или иные зависимости.
История Open-GTO идёт с 2006 года, с мода GTO, это один из самых старейших модов. Большую часть кода в Open-GTO я переписал, но много чего осталось из того времени.
.pwn и .inc - это аналог .c и .h из C, такое разделение необходимо, когда два файла зависят друг от друга. Заголовочные файлы мы подключаем выше, файлы с реализацией ниже.
Так почему файл мода не в папке gamemode?
В проектах, как правило, все исходники хранятся в папке src/ (или sources/ и т.п.). И, с логической точки зрения, будет довольно странно отделять исходники друг от друга.
Насчёт разбивки скрипта на файлы: имхо, но разбивать на файлы и использовать, при этом, перехваты - не очень хорошая. В написании это, конечно, проще, но вот редактировать такой код довольно сложно, так как будет трудно изменить порядок вызова какой-то одной из перехваченных функций (особенно если ты не автор кода). Уж лучше просто обрамлять код в функции, а функции уже вызывать в pwn, тем самым позволяя легко увидеть то, какие инклуды вызываются в том или ином коллбэке и легко поменять порядок вызова.
Согласен, перехваты нужно использовать только в библиотеках.
И вспомнил один из спорных моментов в Open-GTO. Команды админов там реализованы как "1 команда = 1 файл", а команды игроков все в одном файле находятся. Это сбивает с толку при первом знакомстве с модом.
Проблема в том, что команд админов сильно больше. Вызов wc -l *.pwn показывает, что всего строк в админских командах - 3306, тогда как в командах игроков всего 181.
Так же там есть некоторые довольно спорные разделения на файлы. Например, такая простая система, как личные сообщения, разбита на 2 файла (отдельно команда и отдельно не очень большая функция где-то строк на 30). Это лишь усложняет поиск нужного файла, как по мне (ну чем больше файлов, тем длиннее список и дольше нужно по нему глазами пробегать, чтоб найти нужный файл). Не очень оправдано с учётом того, что там в файле всего 1 функция.
Согласен, я подозреваю, что принял такое решение о разделении во времена моего вдохновения схемой MVC. Это когда логика отделяется от представления. Сейчас бы я много чего реализовал иначе, более гибко.
Последние системы, архитектурой которых я доволен сейчас:
- Система соревнований (дм, гонки и т.п.), сама система реализована, но соревнования - нет: https://github.com/Open-GTO/Open-GTO/tree/master/sources/competition
- Античит, архитекрута и базовые защиты есть, но для реального использования не годится: https://github.com/Open-GTO/protection
Ну и разбивать команды на отдельные файлы - в целом, сомнительная идея, ибо вместо того, чтоб открыть один файл и просто воспользоваться поиском, тебе приходится либо вручную выискивать нужный файл, либо пользоваться поиском по файлам, что не так быстро, как просто поиск по файлу (в том плане, что поиск по файлу - нажатие "Ctrl+F", в отличии от поиска по папке, где нужно папку выбирать и т.п.)
В большинстве популярных редакторов есть поиск по всем файлам проекта, как правило - это Ctrl+Shift+F, работает очень быстро.
---
Сидеть и думать как реализовать то или то, спрашивать об этом - смысла не имеет. Бери и делай, делай и переделывай, со временем ты сам поймёшь как следует всё распределять, и на своей шкуре ощутишь минусы и плюсы той или иной реализации.
.pwn и .inc - это аналог .c и .h из C, такое разделение необходимо, когда два файла зависят друг от друга. Заголовочные файлы мы подключаем выше, файлы с реализацией ниже.
Я догадывался, что корни всего этого идут из С, но это всё равно считаю не самым удобным решением для паблик-проекта. Лично мне не очень удобно постоянно переключаться между двумя файлами, чтоб найти нужную информацию или что-то изменить. Сильно внимание расфокусируется при переключении. Но это чисто субъективщина.
Проблема в том, что команд админов сильно больше. Вызов wc -l *.pwn показывает, что всего строк в админских командах - 3306, тогда как в командах игроков всего 181.
Команды игроков в любом случае, обычно, проще искать через поиск по файлу, а не вручную. Поэтому не думаю, что большой объём админских команд был бы проблемой.
При этом, если ты, например, захочешь изменить уровень доступа к ряду админких команд или просто удостовериться, что команды распределены по уровням правильно, тебе придётся либо с поиском по файлам возиться, либо вообще открывать каждый файл отдельно и переключаться между ними.
Несомненно, если мод пишется для себя и подобную систему структурирования ты реализовал самостоятельно, то она может быть удобной. Но вот для паблик-мода она всё же имеет больше минусов, чем плюсов, как мне кажется.
В большинстве популярных редакторов есть поиск по всем файлам проекта, как правило - это Ctrl+Shift+F, работает очень быстро.
Речь о том, что всё равно придётся тратить время на то, чтоб указать путь до нужной папки. Ну или выискивать нужный файл среди результатов, когда поиск выдаст несколько совпадений. Поиск по файлу в этом плане лучше, как мне кажется.
- - - Добавлено - - -
На скрине архитектура мода не для паблика. В паблик-моде будет: players, vehicles, admins. Сейчас ломаю голову, как удобней поставить мускул. Или делать в файле мода, или сделать папку database и там разложить файлам регистрацию, загрузку и сохранение.
Регистрация, загрузка и сохранение должны лежать в папке игроков же. Сам инклуд поместить в папку "lib", в которой будут лежать все сторонние инклуды.
Некоторые вещи можешь почерпнуть для себя из статьи Ziggi (https://ziggi.org/arhitektura-pawn-proekta-dlya-sa-mp/). Ну и на хабре можно много полезных статей найти с правильными мыслями.
Daniel_Cortez
16.02.2019, 18:29
Я догадывался, что корни всего этого идут из С, но это всё равно считаю не самым удобным решением для паблик-проекта. Лично мне не очень удобно постоянно переключаться между двумя файлами, чтоб найти нужную информацию или что-то изменить.
ИМХО, не такая уж это и проблема. Когда модуль реализован, становится достаточно только его заголовочного файла для быстрой справки по функциям и константам модуля. Переключаться же между заголовком и реализацией обычно приходится, когда проектируешь или дорабатываешь сам модуль. Вполне возможно, что это неудобство с переключением (в контексте именно языка Pawn) скоро научатся устранять (а может и уже научились?) через редакторы кода - к примеру, так как это сделано в Visual Studio для C/C++: можно в файле *.h/*.hpp написать заголовок функции, а затем, не переключаясь, через меню "Быстрые действия и рефакторинг -> Создать объявление или определение" написать реализацию функции, которая сохранится в файл *.c/*.cpp.
Мало того, разбиение на файлы заголовков и реализаций может быть незаменимо при наличии взаимных зависимостей между модулями (т.е. когда модуль A зависит от констант и/или функций из модуля B и наоборот).
ИМХО, не такая уж это и проблема. Когда модуль реализован, становится достаточно только его заголовочного файла для быстрой справки по функциям и константам модуля. Переключаться же между заголовком и реализацией обычно приходится, когда проектируешь или дорабатываешь сам модуль. Вполне возможно, что это неудобство с переключением (в контексте именно языка Pawn) скоро научатся устранять (а может и уже научились?) через редакторы кода - к примеру, так как это сделано в Visual Studio для C/C++: можно в файле *.h/*.hpp написать заголовок функции, а затем, не переключаясь, через меню "Быстрые действия и рефакторинг -> Создать объявление или определение" написать реализацию функции, которая сохранится в файл *.c/*.cpp.
Мало того, разбиение на файлы заголовков и реализаций может быть незаменимо при наличии взаимных зависимостей между модулями (т.е. когда модуль A зависит от констант и/или функций из модуля B и наоборот).
Так о том и речь, что сложности появлялись именно тогда, когда модуль нужно было изменить на свой лад. Паблик-моды обычно и качают для того, чтоб взять за основу и переписать на свой лад, постаравшись выдать получившийся мод за уникальный или же просто исправить то, что не нравится. Так что в данном случае, имхо, это больше неудобств создаст конечному пользователю, хоть и будет удобно автору при написании.
UPD: А вот с полезностью при зависимости между модулями всё же соглашусь.
А если сделать библиотеку функций? Каждая в отдельном файле.
А если сделать библиотеку функций? Каждая в отдельном файле.
Если я правильно понял вопрос, всё зависит от конкретной ситуации. Если это какие-то общие функции, которые никак конкретно не относятся ни к одной системе (например, просто вычисление каких-то входящих значений), то да, имеет смысл их поместить в отдельный файл. А если это функции, которые используются в конкретной системе, то и хранить их стоит в одном файле с системой (и изменять проще будет код, и если отключить нужно будет модуль, не нужно будет выискивать побочные файлы).
Вообще как Ziggi уже заметил ранее, лучше просто экспериментируй и всё. Тебе никто не сможет сказать как сделать удачную архитектуру для твоего проекта. Максимум - ты можешь просто погуглить статьи на эту тему и почитать мысли других людей, к которым они пришли путём экспериментов, а после уже перенять что-то для себя.
Powered by vBulletin® Version 4.2.0 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot