Хорошо, я подозреваю, что вы выполняете процесс от А до Я, начиная примерно с G.
Прежде всего, каковы ваши варианты использования? Что ты пытаешься сделать? Какую «систему обмена сообщениями» вы создаете? ЭЛ. АДРЕС? Я? Telepathic
Во-вторых, какой домен вы получаете из этих вариантов использования?
Теперь, подумав об этом, да, вы часто находите удобным сделать азбуку для базовых классов. Вместо этого подумайте о создании интерфейса (хотя различие между интерфейсами и ABC в C ++ менее четко определено, чем в других языках.) За последние 20 лет ОО на основе наследования, как оказалось, создавало много проблем, поэтому интерфейсы и агрегация сейчас любимый. Не всегда лучше, но вы должны подумать о них в первую очередь.
Теперь, скажите мне, что такое физическая вещь, соответствующая "протоколу"? Вы хотите смоделировать что-то вроде потока сообщений? Это средство коммуникации?
Формат, в частности, звучит подозрительно, если не сразу неправильно: форматы сообщений, как правило, тесно связаны с протоколом.
В общем, сделайте резервную копию и расскажите нам больше о том, что вы пытаетесь сделать , сначала.
Обновление
Aha. Хорошо, видите, мы получаем большую помощь от этого. Во-первых, вы имеете в виду «протокол» в смысле доступных операций - вполне разумное использование, но его путают, когда вы путаете его с TCP против UDP, такого рода вещи, как я.
Теперь, как говорится, у вас действительно есть по крайней мере несколько вариантов. Далее я использую термин «игрок» для любой сущности в sim, которая может отправлять или получать сообщения.
Ключевым понятием здесь является проектирование локусов для изменений и нефункциональных требований. Очевидные локусы изменений
у вас может быть несколько «протоколов» в вашем смысле, и если у вас их целых три, вы должны просто планировать, что всегда может быть больше. Если вы ожидаете более двух, запланируйте, что вы можете иметь произвольно много.
Вы можете использовать несколько различных способов форматирования сообщений, например, JSON, XML или YAML. Вновь, если вы ожидаете более двух, планируйте, что вы можете иметь произвольно много.
Вы можете иметь несколько транспортных механизмов. Судя по всему, вы можете по крайней мере использовать сокеты UNIX-доменов & times; совместно используемую память & times; именованные каналы, но моя интуиция говорит, что у вас также есть опция local и remote, что означает, что у вас также есть опция UDP или TCP. Определенно больше, чем два, планируем расширяемость.
Опция 1:
Используйте шаблон Proxy, где каждый протокол определяет интерфейс, который должен быть реализован одним из нескольких способов, в зависимости от используемого ниже формата обмена сообщениями. Игроки рекламируют, какие сообщения они хотят получить; в то время, когда они готовы получить сообщение, они конструируют что-то, что вызывает их код для любого конкретного сообщения операции, которое они получают. Для отправки они создают объект, реализующий соответствующий интерфейс для своего принимающего партнера Player.
Под прикрытием эти объекты могут иметь несколько реализаций, каждая для своего формата обмена сообщениями и транспортного механизма.
Примеры такой системы включают SOM / DSOM a / k / a CORBA и Java RMI с использованием интерфейса Remote.
Вариант 2:
Вы можете построить что-то вокруг шаблона Command. Каждый протокол имеет конкретную реализацию «отправить мне», и ваш получатель просто знает, как восстановить отправленный объект. Командные объекты имеют смешанный вход (многократно наследуемый или переданный как объект во время выполнения), который знает, как маршалировать и сериализовать объект Command; у вас может быть второй, который понимает транспортный механизм.
Вы отправляете сообщение по определенному протоколу, сериализуя объект и используя свой транспортный механизм для перемещения сериализованной формы в получатель. Получатель «повторно обрабатывает» объект и вызывает соответствующие методы на основе фактического отправленного типа.
Примером этого является Java RMI с интерфейсом Serializable вместо использования Remote.