Шаблон проектирования для хранения вызовов классов / функций

Question

Прежде всего, извините, не могу найти хорошее название :(

Проблема Допустим, у нас есть объект, и мы можем применять различные действия для управления этим объектом, и я хочу сохранить его в базе данных.

В качестве примера мы можем определить следующие классы.

interface IAction{ object transform(object input); }

class Stretch : IAction {  }

class Shrink : IAction {}

И объект может иметь список IAction.Также у каждого действия может быть тип, который мы определили.

enum ActionType { Stretch, Shrink }

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

Если я просто изменю порядок элементов в перечислении, то ничто не скажет мне, что моя база данных также должна измениться, и это может привести к серьезным изменениям.

Я пытаюсьнайти шаблон дизайна, который позволит избежать этой ситуации.Есть ли?

Answer 1

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

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

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

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

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

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