Доброго времени суток.
Пишу приложение для обработки изображений.
Есть фильтры которые пользователь может применять к изображению. Наборы таких фильтров являются профилями. Пользователь может добавлять, удалять, редактировать профили, сохранять их под заданными именами.
Каждый фильтр реализует интерфейс из одного метода.

public interface Filter
{
  BufferedImage filter(BufferedImage src, BufferedImage dest);
}

Соответственно в профилях хранятся коллекции из элементов Filter. У конкретных классов фильтров настройки могут быть абсолютно разные. На этапе добавления нового фильтра все идет гладко, пользователь выбирает из списка нужный ему фильтр, выполняет все настройки (конкретного класса, реализующего интерфейс Filter) и фильтр добавляется в профиль, а его интерфейс срезается до Filter. А вот как быть с обратным процессом? Редактируем профиль и входящие в него фильтры, но у нас то они хранятся как интерфейсы, т.е. какие должны быть настройки мы не знаем.
Пока в голову приходят только разные вариации подобного кода.

if (filter instanceof SomeFilter)
{
  showConfigDialogForSomeFilter();
}
else if (filter instanceof SomeOtherFilter)
{
  showConfigDialogForSomeOtherFilter();
}

Но такое решение не кажется мне хорошим. Как бы Вы решили данную проблему?
P.S. Язык Java.

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

> Доброго времени суток.
> Пишу приложение для обработки изображений.
> Есть фильтры которые пользователь может применять к изображению. Наборы таких фильтров являются профилями. Пользователь может добавлять, удалять, редактировать профили, сохранять их под заданными именами.
> Каждый фильтр реализует интерфейс из одного метода.
>

> public interface Filter
> {
>   BufferedImage filter(BufferedImage src, BufferedImage dest);
> }
>

А почему бы не расширить интерфейс:
взять настройки, сохранить настройки, взять диалог настроек?

Здравствуйте, AlexNek, Вы писали:
AN>А почему бы не расширить интерфейс:
AN>взять настройки, сохранить настройки, взять диалог настроек?
Сохраняться и загружатся настройки будут внешним кодом (сериализация), а вот на GUI (Диалог настроек) в интерфейсе фильтра завязываться абсолютно не хочется, ведь GUI это абсолютно не его зона ответсвенности (MVC используется).

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

> AN>А почему бы не расширить интерфейс:
> AN>взять настройки, сохранить настройки, взять диалог настроек?

> Сохраняться и загружатся настройки будут внешним кодом (сериализация), а вот на GUI (Диалог настроек) в интерфейсе фильтра завязываться абсолютно не хочется, ведь GUI это абсолютно не его зона ответсвенности (MVC используется).
Ну так пусть результат сериализации и отдается фильтру, а он сам решает куда все складывать.
Ну фильтр я вижу плагином, потому все что "мне надо вожу с собой" иначе нужно делать две части. Кстати, никто не запрещает сделать универсальный диалог настроек, а плагин просто дает "описание полей".

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

А>Пока в голову приходят только разные вариации подобного кода.
А>

А>if (filter instanceof SomeFilter)
А>{
А>  showConfigDialogForSomeFilter();
А>}
А>else if (filter instanceof SomeOtherFilter)
А>{
А>  showConfigDialogForSomeOtherFilter();
А>}
А>

А>Но такое решение не кажется мне хорошим. Как бы Вы решили данную проблему?
А>P.S. Язык Java.

Я бы взял аналог .NET-овского PropertyGrid. Что-нибудь типа PropertySheet
или NetBeans bean property editor.
С таким компонентом всё просто — отдаёте ему JavaBean класса конфигурации,
компонент находит в нем все свойства и отрисовывает подходящие редакторы.
То есть, кроме как выставить get/set для конфигурации через интерфейс Filter,
ничего делать особо и не придётся.