Стандарты кода #5. Архитектурный ад. Сколько нужно файлов и папок. Коннекторы для OsEngine #24

Проблема, о которой поговорим сегодня – генерация хитрых архитектур для коннектора. Сразу же скажу, что коннектор в рамках OsEngine, насколько бы он для вас сложным не был, — очень простая штука, если пользоваться моими советами и вести тесты. Настолько простая, как складной нож. Он очень прост и не нуждается ни в каких дополнениях.

Складной нож не нужно прикручивать к палке, чтобы им управлять.

Складной нож не требует постоянного отмачивания в машинном масле.

И конечно же, складной нож не нуждается в перевязывании изолентой с другими предметами — топорами или вилками. В этом нет смысла.

Совместные классы-парсеры для разных коннекторов.

Самое худшее, что можно сделать, – придумать класс, который будет использоваться разными коннекторами для парсинга данных. Сколько бы я этого не видел, это почти неизбежно приводит к неработоспособности коннектора.

Всё это заканчивалось переделыванием с нуля.

Поэтому:

Совместные классы-парсеры, вёбСокет-обёртки и рест-оболочки для коннекторов запрещены.

Кол-во папок.

Все классы и файлы, которые создаются в рамках работы над коннектором, должны находиться в папке Market/Servers, что в проекте:

Один брокер/биржа криптовалют – одна папка, в которой могут быть подпапки, разделяющие биржу по площадкам. Например, в случае с Binance / BitGet это разделение на фьючерсы и спот:

Сама площадка должна состоять из:

Класса реализации сервера.
Класса с разрешениями для этого сервера.
Подпапки Entity(JSON), в которых хранятся JSON объекты и возможные хелперы, если коннектор сложный.

Всё, что выходит за рамки этой схемы, вне закона.

Паттерны проектирования ЗАПРЕЩЕНЫ.

В данный момент ServerRealization – это набор функций, которые надо правильно реализовать. Он не требует применения никаких паттернов проектирования совсем.

Им здесь нет места.

Что почитать?