Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Философия программирования > Наследование... Множественное наследование?

Автор: Logo 6.3.2015, 23:32

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

Код


Controller::AnyProto  # общие методы
  Controller::Web     # для web версии
  Controller::Game    # для внутриигровой версии

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

Код


Controller::AnyGame   # общие методы
  Controller::Game1   # методы для одной игры
  Controller::Game2   # методы для другой игры

Но вместе эти варианты уже не использовать просто так. Остается вариант с множественным наследованием по алгоритму C3.

Код


          Controller::AnyProto::AnyGame
              /             \
Controller::Web::AnyGame  Controller::AnyProto::Game1
              \             /
           Controller::Web::Game1

Но многие не советуют использовать множественное наследование. Другой вариант, наверно, более сложный, сделать свою систему разрешения коллбеков, на метапрограммировании.
Как тут поступить?

Автор: makarov_dv 7.3.2015, 08:58

Доброго времени суток.

В с# например множественного программирования вообще нет, то есть разработчикам языка настолько не понравилась эта идея, что они решили вообще запретить это делать.

Да и вообще самой идеей наследования не стоит увлекаться.

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

При такой архитектуре достигается более слабая связанность кода - легче тестировать, легче модифицировать.