У меня есть функциональный класс AdjacencyListGraph, который придерживается определенного интерфейса GraphStructure. Чтобы наложить на это ограничения слоя (например, ациклические, ненулевые, уникальные данные вершин и т. Д.), Я вижу два возможных маршрута, каждый из которых использует интерфейс GraphStructure:
Создайте отдельный класс («ControlledGraph»), который имеет набор битовых флагов, определяющих различные возможные ограничения. Обработка всех ограничений в этом классе. Обновите класс, если станут известны новые ограничения.
Используйте шаблон декоратора (по сути, DI), чтобы создать отдельную реализацию класса для каждого отдельного ограничения, которое клиентский класс может пожелать использовать. Преимущество заключается в том, что мы придерживаемся принципа единой ответственности.
Я бы склонялся к последнему, но Боже! Я ненавижу Шаблон декоратора. Это воплощение беспорядка, ИМО. По правде говоря, все зависит от того, сколько декораторов может быть применено в худшем случае - в моем случае это число равно семи (количество дискретных ограничений, которые я распознал на этом этапе). Другая проблема с декоратором состоит в том, что мне придется выполнять перенос метода интерфейса в каждом ... отдельном ... классе декоратора. Ба.
К чему бы вы пошли, если тоже? Или, если вы можете предложить более элегантное решение, это будет приветствоваться.
РЕДАКТИРОВАТЬ: мне приходит в голову, что использование предложенного класса ControlledGraph с шаблоном стратегии может помочь здесь ... своего рода настройка метода / функторов шаблона, с отдельными битами, применяющими отдельные элементы управления в различных методах граф-канонического интерфейса. Или я теряю сюжет?