Как написать фильтр для групп пугинов?
Как написать фильтр для групп пугинов?
Снова хочется неправильного...
Задачка выглядит так: есть куча плугинов, которые будут добавлятся и/или удалятся из системы.
Понятное дело это не должно сказываться на работоспособности системы и не должно требовать переработки кода.
Эта часть не сложная - делалось несколько раз. Ну разве что мультитон для инстансов надо будет добавить.
Теперь нужно группировать плугины.
Группы, по задаче, должны определятся ДО разработки плугинов.
Групп - несколько, критерии фильтрации в группу будут определены позднее.
Проблема - Я очень не хочу ТРЕХ вещей:
1. закладывать в плугины информацию об группировках - т.е. ни атрибуторно, ни интерфейсно;
2. закладывать в группы информацию об плугинах - никаких списков возможных включений на момент разработкi;
3. делать 1. или 2. как либо опосредованно.
Вопрос: Как написать фильтр для групп пугинов в таких условиях?
У меня куча плугинов описывающих оборудование.
Очень хочу иметь их независимыми от остального софта.
А с группами - приходят консультанты и говорят - вот отсюда надо посчитать ЭТО, а вот оттуда - ТО... и показать вот так.
При этом максимальный возможный в их понимании выхлоп - зполненый в ручную ехцеловский файл... показывали мне недавно один - записи об проблемах - два человека на окладах держат чтобы его заполнять...
Так вот хочется написать Группа чтобы считать ТО и ЭТО и не заморачиваться ни с плугинами, ни с кодингом группы... ![]()
Пока ничего глупее как прописать в плугинах их имена и формировать из них группы в файлах конфигурации - не придумал... ![]()
Все равно непонятно зачем группы нужны. Но что бы ты не делал тебе нужен будет какой ид как то привязанный к плагину и также привязка данного ид к группе.
Я бы лучше наделил плагины атрибутами типа: выдает вес, выдает размер, может резать. Ну или что там тебе нужно. А уж по атрибутам соединял с группами.
непонятно зачем группы нужны
-----
В тех 2-х Гб кода, за возьню с которыми мне уже пятилетку платят немаленькую зарплату, разманы различные рассчеты связанные со станочным парком.
Каждая смена или модификация станка ведет к судорожному перебору... всех 2 Гб кода.
Ну а возможностей это делать у меня все меньше и меньше - головка бо-бо и есть другие интересы.
Вот и хочу (и делаю, по возможности) вынести расчеты в специализированные дллки.
Ну а раз есть дллки, то почему бы не доработать и не сделать их плугинами.
Я бы лучше наделил плагины атрибутами типа: выдает вес, выдает размер, может резать.
-----
Пока был один атрибут на классе и имплементация пары интерфейсов.
Ну или что там тебе нужно.
------
Хи-хи...
Что мне нужно мне скажут после того как этот код будет написан. В этом проблема.
А сделать нужно сейчас и чтобы работало потом при любых глупостях и изменениях.
Классифицируй плагины namespace'ами.
-----
Поясни идею, плс.
В том плане, что по условию:
1. плугины не знают об группировке
2. группировка не знает об плугинах.
3. изменения группировок происходит без изменения кода плугинов и кода группировки.
П.С. С атрибутами работать проще.
Требования меняются на лету :)
Я имел в виду, что namespace - это вроде пути к папке с плагином. Ну типа "ИзмерительныеПриборы.Дистанция.Лазерный"
Если надо реализовать такое:
В том плане, что по условию:
1. плугины не знают об группировке
2. группировка не знает об плугинах.
3. изменения группировок происходит без изменения кода плугинов и кода группировки.
То надо просто создать дерево папок на файловой системе:
..\MyApp
\Plugins
\MeasuringInstruments
\Distance
\Laser
Plugin_1.dll
Plugin_2.dll
\Manual
Plugin_3.dll
\Thickness
Plugin_4.dll
Таким образом планигы ничего не будут знать о группах
Группа ничего не будет знать о плагинах
И менять группы можно будет как угодно
При этом плагин всегда сможет узнать свою группу и группа гарантированно имеет уникальное имя. Профит.
Думаешь описание хоть немного продвинуло в направлении зачем нужны группы?
Кстати, я не имел в виду "класс атрибуты" - просто некие сущности.
Что мне нужно мне скажут после того как этот код будет написан
Что то ты путаешь еще больше. Как можно писать код ничего не зная или скажут что то существенное уже после того как.
Требования меняются на лету :)
-----
Неа... их просто сообщают после того как написан правильно работающий код... :)
НУ а как написать - это работа программиста...
Ну типа "ИзмерительныеПриборы.Дистанция.Лазерный"
------
Т.е. группы должны быть известны ДО.
У меня же группы будут вида "Проект345676.Приборы".
При этом то что проект будет называться "Проект345676" и в нем будет группа "Приборы" мне скажут... потом. :)
реализовать такое
-----
Т.е. информацию об составе групп представить в виде структуры в файловой системе.
Увы, на практике такое нежизнеспособно.
Посмотреть есть ли какой-то файл в папке Плугины - еще можно. Ползать по структуре в файловой системе - мучительно... Там, мягко говоря, все не связанные с непосредственной задачей вещи просто исключены. Ехплорер, например, просто не присутствует в системе...
Профит.
-----
Нет - решение, но решение - плохое.
Скорее всего придется писать файлик (тот же конфиг) с необходимым профилем групп - так будет хоть понятно что и где искать...
Код загрузки плагина в плагине?
-----
Можно и там...
Как там было у мелкомягких - воткни и двигай - вот примерно так...
Но лучше все же отдельно...
без конкретной задачи нефиг что и начинать.
-----
Написать код под задачу - не проблема - проблема - написать нужный код не имея полной задачи. ![]()
проблема - написать нужный код не имея полной задачи
тут ты меня в полный тупик ставишь, как можно что то написать не имея полной задачи? Ну или хотя бы какого то аналога.
Какая то информация должна быть. Могут отсутствовать какие то неважные детали - как то понятно еще
Этого, по моему мнению, достаточно
зная тебя, ты недоговариваешь еще тонну информации. ![]()
Этой информации даже недостаточно что чтобы понять необходимость применения групп, не то что бы что то писать.
Да и не уверен я что один станок будет в одной и только одной группе. Вот даже и этой информации нет. ![]()
Да и не уверен я что один станок будет в одной и только одной группе.
-----
Так и Я не уверен. Про мультитон в имплементации вроде упоминал - грузим один раз и добавляем куда надо...
понять необходимость применения групп
-----
Эээ... так это как бы и не требуется... для задачи - не требуется... если только для понимания задачи... но задача понять задачу вроде как не ставилась - ставилась задача предложить решение... ![]()
но задача понять задачу вроде как не ставилась
ну жди тогда когда придет баба Ванга.
ну должны группы и плагины как то быть связаны: логически (по ид) или физически (по месту расположения/каталоги).
Должен быть критерий определения того принадлежит ли плагин данной группе.
Если и плагин и группа имеют какие-либо ид то связать их при помощи третьего объекта не должно быть проблемой

