Здравствуйте, a.coder, Вы писали:

AC>Имхо, следующие задачи решать станет проще:
AC>* реализация логики, связанной с фильтрами, если фильтры реализовать так, как удобно для бизнес-логики, а не для диалога.
AC>* юнит-тестирование

Хорошо, допустим.

AC>Да, в первую очередь хотелось бы ограничить интерфейс Filter GUI. Как было в примере, в 3 разных проектах используется один и тот же диалог, но из-за того, что в нем используется класс сущности для извлечения данных, неудобно эту саму сущность изменять.

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

AC>Попробую описать свою проблему конкретным примером

AC>Структура проектов такая:
AC>1. PluginProject1 (enum FilterTypes1)
AC>2. PluginProject2 (enum FilterTypes2)
AC>3. PluginCoreProject3 (BaseFilter, KeywordsFilterDialog, ListFilterDialog)

AC>В PluginCoreProject3 есть классы фильтра BaseFilter и диалогов KeywordsFilterDialog, ListFilterDialog.
AC>У фильтра BaseFilter есть поле Type — типа int.

.Net-овского reflection мало оказалось?

AC>

AC>public class BaseFilter
AC>  ...

AC>  public KeywordsFilterDialog(BaseFilter filter)
AC>    ...

AC>

Странно. По идее KeywordsFilterDialog отлично знает о том, какой именно фильтр ему нужен (KeywordsFilter), но получает почему-то BaseFilter. Зачем такие сложности?

AC>Проекты PluginProject1 и PluginProject2 используют BaseFilter, но Type трактуются в каждом по-своему. Для этого заведены enum'ы FilterTypes1 и FilterTypes2. В коде же используются преобразования типа:

[skip преобразования]

AC>Такие конструкции неудобны, когда дальше в логике приходится интенсивно использовать Filter.

Ещё бы... Прости за ёрничество, а оперировать объектами нужных типов вместо базового религия не позволяет?

AC>Была идея сделать BaseFilter generic'ом, которому передавался бы свой enum в каждом проекте, но тут я уперся в диалоги.

Зачем??? Выкиньте вы этот хвост enum-ов. Не нужны они тут.

AC>Диалоги в своих конструкторах обязательно принимают BaseFilter как один из аргументов.

Ну вот и зачем? Зачем передавать в конструктор параметр базового типа, когда на самом деле нужен вполне определённый? Чтобы плодить код кастинга?

AC>Неудобно конструктору GuiControl'а передавать generic тип. Использовать дизайнер форм становится сложнее.

AC>Основной аргумент, против таких идей — не стоит вообще так заморачиваться для наших небольших проектов

Да нет, вопрос скорее в том, как обосновано решение о введении дополнительной прослойки. Если просто абстрактным "хорошо-плохо", то это одно, а если соображениями практического порядка — совсем другое. Но вам, ИМХО, имеет смысл поменять дизайн. Что-то больно много всего накручено, альтернативный способ идентификации типов через enum/int — вообще в топку (во всяком случае, из твоих примеров не следует, что это зачем-то нужно, кроме как для того, чтобы упражняться в преобразованиях BaseFilter).