Пожалуйста, НЕ комментируйте плохие методы, используемые здесь. Я просто пытаюсь справиться с абстракцией этого сценария с помощью простых для описания примеров.
Я пытаюсь смоделировать систему, которая позволяет пользователю вводить объект с именем TASK с определенными параметрами конфигурации, а затем TASK выполняет действия, специфичные для этой задачи.
Некоторые примеры определений задач могут быть:
* Создайте файл {имя_файла} в каталоге {path}.
* Скопируйте файл {имя_файла} из {исходного каталога} в {целевой каталог}.
* Откройте приложение «Блокнот», введите текст {образец текста} и сохраните файл как {имя файла}.
* Откройте {sample.docx}, введите текст {sample text} в конце второго абзаца.
Каждое задание имеет описательное имя и до 5 параметров. В приведенных выше примерах параметры заключены в фигурные скобки {}. Пользователи будут проинструктированы о выполнении вышеуказанных задач, и наше приложение проверит, были ли они выполнены Каждая задача должна иметь следующую функцию:
В статическом мире я бы создал следующие классы:
public abstract class TaskBase
{ public abstract void Perform(param1, ... param5); }<br>
public class TaskFileCopy: TaskBase
{ public override void Perform(param1, ... param5) {} }
Проблема в том, что задачи могут быть практически любыми, и после компиляции и развертывания программы необходимо добавить больше задач. Первое и худшее, что приходит на ум, - это продолжать наследовать из TaskBase, реализовывать Perform, перекомпилировать и повторно развертывать, сохраняя при этом результаты предыдущих задач в такте.
Здесь две проблемы: к тому времени, когда мы выполним 2000 задач, у нас будет не более 2000 производных классов, и, во-вторых, базовый OODB будет увязнуть.
В какой-то момент я думал о System.AddIn, но убежден, что этот сценарий имеет лучшее решение в рамках ООП-дизайна.