Плагин архитектуры, дизайн дилемма - PullRequest
Новая
       10

Плагин архитектуры, дизайн дилемма

1 голос
/ 25 июня 2011

Вот моя проблема,

У меня есть пара аудио-плагинов, все они наследуются от базового класса Filter . Теперь я с нетерпением жду создания для них пользовательского интерфейса, чтобы пользователи могли выбирать / настраивать их.

Я застрял в реализации свойств плагина.

Когда я делаю их как FilterParameter против (типа double или float), мне гораздо проще создать их UI через уникальный DataTemplate, чем создавать DataTemplate для каждого типа плагина.

Класс FilterParameter - это созданный мной тип, который содержит Description, Min, Max, Value членов; это позволяет сэкономить время, но при рефакторинге моего дизайна (с графиком зависимостей VS) я только что обнаружил, что он создает много зависимостей для типов плагинов. Хотя сейчас я удовлетворен иерархией наследования, эти отношения Plugin <-> FilterParameter снова портят мой график.

Что бы вы сделали в этом случае?

Пройдите трудный путь, сохраните простые типы для свойств и предоставьте выделенный шаблон данных для каждого типа?

Или продолжайте в общем настроении, учитывая преимущества / недостатки по сравнению с вышеописанным методом?

Спасибо !!! : -)

1 Ответ

0 голосов
/ 27 июня 2011

Это зависит.

Если бы универсальность выполнила свою работу, и были другие ограничения дизайна или драйверы, которые поддерживали этот подход, то я, вероятно, придерживался бы этого.

Но если сохранитьвещи общего характера, или в узкой / строго определенной полосе, начинают ограничивать то, что я могу сделать функционально, или начинают искажать другие аспекты системы, тогда определенно пора идти трудным путем.Маленькая боль сейчас, меньше (больше) боль позже.

...