Здравствуйте, Аноним, Вы писали:

А>Что касается разделения классов, то здесь я просто предлагал использовать разделение на GUI и BL. Сейчас диалоги работают напрямую с объектами, т.е. передаем диалогу ссылку на некий объект FilterEntity и диалог сам его изменяет, заполняет. Наверное, само по себе это уже не очень хорошо.

Само по себе это ни хорошо, ни плохо.

А>Плюс, вышеназванная проблема именования — просто так теперь класс этого объекта не переименовать, т.к. все предыдущие проекты завязаны на старом названии.

Значит, старые проекты тоже должны обновиться. Или "заморозиться".

А>Я бы сделал так: создал бы класс FilterEntityGui, который выставляет наружу только самые необходимые свойства для конкретного диалога FilterDialog. И работает данный конкретный диалог с этим классом. А все остальные пользователи этого диалога используют выходные данные по своему усмотрению.

Пока что маловато обоснований для прослойки. Зачем она? Если только для того, чтобы ограничить интерфейс Filter — то неправильно ставишь задачу. Прослойку имеет смысл делать только ради того, чтобы проще было решать какие-то задачи. Какие?

А>Просто интересно, сталкивался ли кто с таким? Может, зря я паникую

Да нет, вроде не зря. В именах, ИМХО, путаница получается.

Попробуйте для начала перепроектировать структуру классов, только выкиньте эти дурацкие приписки Entity — любой объект и так Entity. Получится, как минимум, Filter и Condition. Сразу вылезает интересное наблюдение: Filter включает в себя Condition и какое-то поведение по отношению к "фильтруемому" объекту. По крайней мере, с точки зрения семантики человеческого языка.