Рассмотрим гипотетическую ситуацию, когда старая, унаследованная библиотека презентаций поддерживалась на протяжении многих лет, и постепенно в нее закодировалось все больше и больше бизнес-логики в результате процесса поспешных исправлений и отсутствия надлежащего архитектурного контроля. В качестве альтернативы рассмотрите бизнес-класс или пространство имен, которые не отделены от представления границами сборки и, таким образом, могут ссылаться на что-то вроде System.Windows.Forms без необходимости добавления ссылки (гораздо более отрезвляющее действие, чем простое предложение using) .
В подобных ситуациях не исключено, что бизнес-код, используемый этим кодом пользовательского интерфейса, в конечном итоге будет вызван для повторного использования. Как хорошо провести рефакторинг двух уровней, чтобы учесть это?
Я плохо знаком с шаблонами проектирования - по крайней мере, в принципе. Однако у меня нет большого практического опыта, поэтому я несколько не уверен в своей интуиции. Я начал использовать для этого паттерн Стратегия. Идея состоит в том, чтобы определить места, где бизнес-логика вызывает компоненты пользовательского интерфейса, чтобы задать пользователю вопрос и собрать данные, а затем инкапсулировать их в набор интерфейсов. Каждый метод в этом интерфейсе будет содержать код, ориентированный на пользовательский интерфейс, из исходного рабочего процесса, а затем класс пользовательского интерфейса будет реализовывать этот интерфейс.
Новый код, который хочет повторно использовать рассматриваемую бизнес-логику, также реализует этот интерфейс, но заменяет либо новые окна, либо, возможно, готовые или параметризованные ответы на вопросы, на которые изначально ответили компоненты пользовательского интерфейса. Таким образом, бизнес-логику можно рассматривать как настоящую библиотеку, хотя и с несколько неудобным параметром интерфейса, переданным в некоторые из ее методов.
Это достойный подход? Как лучше мне это сделать? Я полагаюсь на вашу коллективную интернет-мудрость.
Спасибо!
