#опрос #async #gamedev

Итак, друзья )

Тестируем наш первый опрос в новом формате (спасибо за идею механики Алексею 😊)

Есть код, эммулирующий загрузку данных из сети 👇

TimeSpan workDuration = TimeSpan.FromSeconds(10);
DateTime endDateTime = DateTime.Now.Add(workDuration);

while (DateTime.Now < endDateTime)
{
    // some fast network operation, receive data from socket, speed 200 Mbps    
    Task receiveDataTask = Task.Delay(1);
    //    
    await receiveDataTask;
}

 
❓Все ли в порядке с кодом? Или код требует улучшения❓

ГОЛОСОВАТЬ >>>

❗Внимание ❗Обсуждаем код и ведем дискуссию здесь, а в следующем посте Вы только голосуете и расписываете ответ в комментариях, если считаете, что код требует улучшений

#опрос

Приветствую 👋
Предлагаю порассуждать и поучаствовать в опросе!
Ниже описан подход к организации общения между классами через интерфейсы 👇

Есть 2 класса: логика и представление. Один класс использует методы другого.
Чтобы ослабить зацепление, в каждом классе выделяем интерфейс и реализуем использование классов через вызовы методов интерфейсной ссылки.

Задача оценить оптимальность описанного подхода и рассказать о своем, если он отличена от приведенного выше. Если ваш подход совпадает с описанным - раскрыть, почему с вашей точки зрения данная реализация оптимальна

ГОЛОСОВАТЬ >>>

❗Внимание ❗ Обсуждаем предложенный подход и ведем дискуссию здесь, голосуем по ссылке

#опрос

Приветствую, друзья 👋

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

Вопрос звучал:
Есть 2 класса: логика и представление. Один класс использует методы другого. Чтобы ослабить зацепление, в каждом классе выделяем интерфейс и реализуем использование классов через вызовы методов интерфейсной ссылки. Оптимален ли подход? Совпадает с вашим?

Результаты 👇
30% применяют описанный подход
47% используют альтернативные способы ослабления зацепления в коде
23% затруднились с ответом

Итак, приступим 🚀

Что касается приведенного в опросе подхода: на мой взгляд, он оптимален там, где редко меняются бизнес процессы.
Поэтому, как правильно отметил @GlassOfDream 👌в игровой индустрии - такой подход - скорее утопичен и зависит от многих факторов: сложность и стадия проекта, количество человек в команде и т.д.

Также вы перечислили другие варианты, отражающие разнообразие подходов и методов:
- Прямая связь, если в этом месте не нужен полиморфизм. С защитой от дурака в виде автотестов с рефлексией.
- Через публичный api-интерфейс в классах представления и логики и создание третьего класса ~адаптер/контроллер, который знает о логике и представлении и связывает их.
- Через ивенты. Логика отправляет ивент, подписчики слушают и обрабатывают.
- Перенос зависимостей в аргументы метода.
- Использовать ECS.

Как правильно было подмечено в комментариях, сейчас в разработке нет единой концепции и правил, которые подходили бы для всех задач.
Контекст проекта, требования, сроки и другие факторы влияют на выбор оптимального подхода взаимодействия между классами.


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


Было бы неплохо внедрить в современные учебные программы принципы разработки информационных систем, включая игры.
Это поможет будущим разработчикам получить фундаментальные знания и навыки, которые позволят принимать более обоснованные решения при проектировании и разработке программного обеспечения.

Спасибо за участие в опросе
Хорошего вечера 👍