Первый вопрос:)
В основном я хотел бы получить множественное наследование форм в проекте .NET WinForms .
Мы работаем с Framework, который имеет 2 базовых класса: UIForm и UIWizard. Мы (к сожалению :) вынуждены использовать эти формы для запуска наших собственных реализаций.
Помимо них мы построили следующую структуру:
UIForm является суперклассом OurForm. UIWizard является суперклассом OurWizard. OurForm и OurWizard - близнецы.
OurForm сама по себе является также суперклассом для других форм: OurCrudBase, OurListBase, OurSearchBase, ...
Возможность
OurForm и OurWizard содержат свойства и методы, связанные с досье, в то время как этот контекст досье не имеет отношения ко многим формам. Что еще хуже, мы недавно начали добавлять формы, которые имеют совершенно новый контекст: существующее досье, а также клиент, статистика и т. Д.
Итак, вот оно
Нам нужна форма, которая является одновременно CrudBase и DossierBase. Или форма ListBase, ClientBase и т. Д. Чтобы достичь этого с помощью одного наследования, количество базовых форм может увеличиться (например, DossierBase + CrudBase + ListBase и т. Д. И т. Д.). Поэтому мы не хотим этого делать.
Решение
Мы стремимся удалить UIForm, говоря, что UIForm на самом деле является UIWizard, но всего за один шаг. Количество базовых классов уже уменьшилось бы вдвое.
Базовые классы можно разделить на две категории
- Функциональные: досье, клиент, статистика, ...
- Технический: Crud, List, Search, ...
UIForm станет суперклассом технической или функциональной форм. Другой тип будет реализован как Стратегия.
Функциональные производные классы:
+ Форма может быть только одним из функциональных классов. Форма не может быть сделана как для "стики", так и для "клиента". Таким образом, наследование имеет здесь смысл.
+ Реализация технической функциональности как стратегии, вероятно, возможна. Я думал об интерфейсе, у которого в основном был метод для всего, что может происходить в форме: загрузка, сохранение, закрытие, закрытие, ...
- Взаимодействие между различными стратегиями, вероятно, будет грязным. (т.е. убедитесь, что когда вы помещаете и List, и Crud в форму, чтобы реализации не прикручивали друг друга)
Технические производные классы:
+ Каким-то образом я чувствую себя лучше с этим подходом. (Хотя я могу перечислить только отрицательные моменты)
- Еще раз вам нужно дублировать классы, когда вы хотите объединить, например, List + Crud. Однако количество копий минимально.
- Для Клиента, Досье, Статистики нет единого основания. Так что превратить их в стратегию довольно сложно.
Думаю, я уже почти ответил на свой вопрос. Но ты согласен? Или вы думаете, что я обдумываю это и должен ли я просто поместить как можно больше в суперклассы и сделать как можно меньше наследования?
Или, может быть, совершенно другой подход к решению проблемы?
Любая помощь будет наиболее ценится!
Приветствия
Wouter