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

Question

У меня есть класс, который содержит произвольное состояние, и он определен так:

class AbstractFoo
{
};

template <class StatePolicy>
class Foo : public StatePolicy, public AbstractFoo
{
};

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

EDIT:
Вот еще немного информации о моей проблеме:
Foo - это класс, который представляет состояние и поведение определенного оборудования, которое можно изменить либо физически, либо через пользовательский интерфейс (и существует несколько пользовательских интерфейсов). У меня есть еще четыре вопроса:
1) Подойдет ли механизм сигнала / слота?
2) Можно ли привязать каждый излучаемый сигнал из слота в Foo, чтобы иметь указатель на Foo, как если бы он был членом класса? 3) Должен ли я вместо этого использовать посетителя и рассматривать Foo как посещаемый класс?
4) Почему StatePolicy плохой дизайн?

Вот обновленный API:

class AbstractFoo
{
public:
  virtual void /*or boost::signal*/ notify() = 0; // Updates the UI.
  virtual void /*or boost::signal*/ updateState() = 0 // Updates the state
};

Answer 1

Я не совсем понимаю вашу ситуацию, но вот мой выстрел: что если вы сделаете AbstractStatePolicy вместо этого? Пример:

class AbstractStatePolicy
{
};

class Foo
{
    AbstractStatePolicy *state_policy;

public:
    Foo(AbstractStatePolicy *state_policy)
        : state_policy(state_policy)
    {
    }
};

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

Если вам не нравится идея указывать state_policy каждый раз, когда вы создаете Foo, подумайте об использовании значения по умолчанию или создании фабрики для создания экземпляров Foo s.

Answer 2

Я не думаю, что у вас есть очень разумный подход. У вас должен быть чистый виртуальный базовый класс, который описывает, что на самом деле могут делать ваши реализации, а затем вы можете создавать конкретные классы, которые наследуют от базового класса, используя любое нужное вам состояние. После этого вы сможете взаимодействовать с состоянием через любой интерфейс, который вы определили для этого базового класса. Теперь, если у вас есть произвольные, динамические атрибуты, которые могут изменяться во время выполнения, то хороший способ сделать это с помощью типа карты или словаря; вы можете либо сопоставить строки (имена атрибутов) со строками (представляющими значения атрибутов), либо, если вы хотите немного большей безопасности типов, вы отображаете строки (имена атрибутов) в экземпляры boost :: любой .