Такой подход имеет право на жизнь, чем то похоже на Test-driven development. В университете заставляли делать курсовую по Архитекутре ЭВМ таким же образом, сначала пишем идеальные программы с блок-схемами, потом для этого идеального кода проектируем архитектуру. Из опыта написания этого же курсача вынес, что идеальный код потом может привести к очень неэффективной реализации самого движка или сделать эту реализацию вообще нереальной. Как думаете избегать этих проблем? Будем в конце концов подгонять «идеальный» код игр под реалити движка?
На удивление получается неплохо, сам фреймворк работает как роутер для адресов страниц и серверной логики (работа с бд, уровни доступа и т.п.), шаблонный движок jade используется для отрисовки, dart — для динамики фронтэнда. Главная проблема — все очень сыро и недоработанно, фреймворк еще на стадии беты.
Когда переходил с C++ на D, я был шокирован отсутствием качественных IDE. Однако, вскоре я попал в лагерь «знатоков языка» и мне стало хватать самодельных скриптов для редактора и подсветки синтаксиса. IDE сильно привязывает к себе и не дает распробовать вкусности новых языков.
Сразу после запуска появляется ошибка с «В системе нет установленного драйвера», за ним бесконечно с периодом, примерно, в полсекунды появляются ошибки с «No MCI device open». Если зажать enter и перебороть поток окон, форма появляется, ничего кроме кнопок не видно, поток ошибок меняется на поток «Access violation at adress 004359B8 in module Deathcraft.exe/ Read of address 00000008.», которые уже подвешивают систему основательно. Самый экзотический способ упасть для приложения, который я встречал.
Скриншоты вызвали ностальгическую слезу. Попытался запустить в режиме совместимости (стоит Win7 64), начало выдавать бесконечный поток окошек «No MCI device open», а так хотелось посмотреть…
В предыдущем проекте на С++ я решал эту проблему по первому варианту. У каждого сообщения была своя реализация чтения из потока байтов, а в менеджере была map<int, AbstractMessage*>. Хотя я как можно упростил создание реализаций методов чтения, такой вариант меня не радовал. И простым для использования нельзя назвать и эффективным тоже.
Тут на самом деле большая проблема с сериализатором. У меня так и не получилось создать удобный сериализатор (я про C++), который не требовал бы вмешательства в классы (макросы или регистрации полей). Если допустить, что имеется общий алгоритм для чтения классов из байтов, то копать нужно в сторону шаблонов для автоматического построения иерархий классов, на каждом уровне проверять id на совпадение с заданным на этапе компиляции, и при совпадении вызывать сериализатор с нужным типом.
Тут будет много подводных камней. Можно обнаружить коллизию на этапе компиляции и добавить к имени, например, последний символ и опять взять кеш. Главное продумать ситуацию, когда есть два разных клиента с немного разными наборами сообщений, а сервер имеет самый полный набор. Тогда обойти коллизии нереально…
Ну можно использовать строки как id, главное следить за своими именами, чтобы не раздувать head сообщения. Сейчас меня посетила мысль, что можно просто брать хеш от имени и это будет уникальный id, который не зависит от порядка перечисления сообщений.
Но тут возникает подводный камень, так как индексы для сообщения вычисляются сами. Очень возможна ситуация, когда программист случайно перепутает местами сообщения в списке, и все… все ломается. Поэтому я решил специально заставлять явно указывать индексы, чтобы можно было проверить одинаковы ли протоколы на клиенте и сервере.
Я не понял как именно вы хотите заменить id на строки в самом пакете сообщения. В начале сообщения всегда идет константное количество байтов для записи id, которое однозначно определяет то, что пойдет дальше. Можно заменить на строку постоянной длины, но она опять таки должна быть как можно меньше по размерам, чтобы не было большого overhead'а по памяти, так почему просто не использовать uint для этого?
В большинстве случаев сериализатору (это все сериализаторы, которые я видел) нужно знать о типе класса сообщения еще на этапе компиляции. Допустим у нас есть таблица, которая переводит название сообщения в его id, который пойдет в поток на отправку, и наоборот. Как с помощью этой таблицы вызвать сериализатор с нужным типом? Я вижу тут 2 пути: написание опять таки switch и использование перегрузок функций с шаблоном Int2Type (Подсмотрел в книге Александреску «Современное программирование на С++»). Switch будет работать быстрее, а с помощью автоматической генерации мы получаем и скорость и удобство.
Тут на самом деле большая проблема с сериализатором. У меня так и не получилось создать удобный сериализатор (я про C++), который не требовал бы вмешательства в классы (макросы или регистрации полей). Если допустить, что имеется общий алгоритм для чтения классов из байтов, то копать нужно в сторону шаблонов для автоматического построения иерархий классов, на каждом уровне проверять id на совпадение с заданным на этапе компиляции, и при совпадении вызывать сериализатор с нужным типом.
Но тут возникает подводный камень, так как индексы для сообщения вычисляются сами. Очень возможна ситуация, когда программист случайно перепутает местами сообщения в списке, и все… все ломается. Поэтому я решил специально заставлять явно указывать индексы, чтобы можно было проверить одинаковы ли протоколы на клиенте и сервере.
В большинстве случаев сериализатору (это все сериализаторы, которые я видел) нужно знать о типе класса сообщения еще на этапе компиляции. Допустим у нас есть таблица, которая переводит название сообщения в его id, который пойдет в поток на отправку, и наоборот. Как с помощью этой таблицы вызвать сериализатор с нужным типом? Я вижу тут 2 пути: написание опять таки switch и использование перегрузок функций с шаблоном Int2Type (Подсмотрел в книге Александреску «Современное программирование на С++»). Switch будет работать быстрее, а с помощью автоматической генерации мы получаем и скорость и удобство.