Шаблон дизайна и настройки конфигурации - PullRequest
1 голос
/ 22 января 2010

Я занимаюсь разработкой приложения, которое преобразует XML-документы с использованием xslt.

В приложении есть диалог настроек для установки значений, таких как

* input
* output (directory)
* stylesheet
* and so on...

Пользователь также может выбрать преобразование в pdf, xhtml и т. Д., И приведенные выше настройки немного отличаются для каждого формата. Теперь мне было интересно, есть ли у кого-нибудь хорошие идеи о том, как обращаться с этими настройками с точки зрения дизайна. Я как бы использую шаблон MVP (модель-представление-презентатор) для приложения в целом, и я создал класс модели для этих настроек. Поскольку они хранят настройки в разных местах и ​​по-разному (в файлах сборки для преобразований), я подклассифицировал класс модели для каждого типа формата (PdfModel и т. Д.). Но помимо наличия разных способов хранения (что мотивирует создание подклассов), они также имеют различные свойства в некоторой степени, как я уже упоминал. Например, для формата xhtml требуется свойство css, а для формата pdf - свойство fo для форматирования и т. Д.

Я попытался решить эту проблему, и у меня получилось, что она работает нормально несколькими различными способами, так что это не проблема. Мне просто интересно узнать, может ли кто-нибудь с хорошим опытом проектирования пролить свет на это, если это действительно хороший способ сделать это. Мне кажется, что многое становится слишком сложным для относительно простой вещи. И все же трудно найти действительно элегантное решение. Например, если я делаю это, как описано выше, я могу использовать интерфейс для кодирования, и таким образом у меня может быть несколько разных представлений (с докладчиками), показывающих настройки, без необходимости знать, какая модель будет представлена ​​(напр. сетка свойств, показывающая текущие настройки в представлении, кроме представления, в котором пользователь устанавливает настройки). НО проблема в том, что мне нужно иметь интерфейс, содержащий несколько свойств, которые не используются для каждой модели формата. Поэтому для модели pdf мне придется установить свойство Css не применимым или что-то в этом роде. И это могло бы ухудшиться, если бы я добавил более конкретные свойства.

Я также попробовал другой вариант, где у меня есть только общие свойства в интерфейсе, и затем я кодирую интерфейс, но понижаю объект в получающем классе, чтобы получить свойства подкласса. Я не уверен, хорошо это или нет, но это работает. Может быть, это нормально, но мне бы очень хотелось, чтобы какой-то вклад выяснил, не усложняю ли я вещи, или я мог бы сделать это более элегантно ...

Надеюсь, что понять проблему можно из моего описания. Любые предложения будут с благодарностью!

С уважением,

Андерс

1 Ответ

0 голосов
/ 22 января 2010

Возможно, вам следует больше задумываться о своем поведении, а не о свойствах или методах по имени. Было бы хорошо, если бы у вас был метод, обеспечивающий все свойства и связанные ограничения и проверки. Этот метод будет доступен через интерфейс. Другой возможностью могут быть, например, некоторые функции отражения, которые могут определять свойства автоматически.

...