ООП дизайн и pcap

Добрый день. Задача - фильтровать пакеты из pcap файла по заданной пользователем строке. Все бы ничего, но в последующем предстоит расширять число протоколов для фильтрации и число свойств протоколов, по которым осуществляется фильтрация.
Так вот задумка такая - получить пакет из Pcap файла и применить фильтр составленный при помощи паттерна компоновщик ( древовидная структура фильтра в узлах которой содержатся описания протоколов, имеющих свойства для фильтрации). Фильтр принимает указатель на пакет, пробегается по всем своим узлам, сначала проверяет тот ли протокол, протокол пробегается по своим фильтрующим свойствам и говорит "Да фильтр подходит" или "Нет" . Но вот незадача( как генерировать такой фильтр динамически? ведь если использовать для создания Фабрику, то она должна будет знать обо всем - о протоколах, об их свойствах и т.д. Так вот вопрос - как генерить объект фильтра избегая большой связанности компонентов? Вариант делать фильтрацию путем создания и наложения LibPcap фильтра- не катит.
Если подскажите в виде паттернов - будет вообще круто

0

Сообщение от LARSnn но в последующем предстоит расширять число протоколов для фильтрации и число свойств протоколов, по которым осуществляется фильтрация.

таки стратегия налицо...

Сообщение от LARSnn ведь если использовать для создания Фабрику, то она должна будет знать обо всем - о протоколах, об их свойствах и т.д.

кажется вы собирались фильтры со строки командной задавать

Сообщение от LARSnn фильтровать пакеты из pcap файла по заданной пользователем строке.

Сообщение от LARSnn , то она должна будет знать обо всем - о протоколах, об их свойствах

а разве это не так? фабрика лишь дает метод на выходе которого объект, но созданием она сама занимается - следовательно знает о его свойствах

0

Может подойдет паттерн визитер ?

0

Сообщение от LARSnn Фильтр принимает указатель на пакет, пробегается по всем своим узлам, сначала проверяет тот ли протокол

а зачем проверять со всеми протоколами? если можно вызывать ф-цию для конкретного протокола сразу, т.е определили протокол, вызвали ф-цию обработки соответствующую данному протоколу

0

Сообщение от aLarman а зачем проверять со всеми протоколами? если можно вызывать ф-цию для конкретного протокола сразу, т.е определили протокол, вызвали ф-цию обработки соответствующую данному протоколу

Сообщение от aLarman а зачем проверять со всеми протоколами? если можно вызывать ф-цию для конкретного протокола сразу, т.е определили протокол, вызвали ф-цию обработки соответствующую данному протоколу

Сейчас многое переделал. В принципе есть пока только несколько протоколов разных уровней OSI. Есть фильтр, составленный через патерн Компоновщик, в котором в строгом порядке в списке храняться фильтры для протоколов. Композитный фильтр должен:
1) Получить сырой пакет, вызвать конкретный фильтр, проверить тот ли пакет, если да, то проверить есть ли фильтрующие условия для данного протокола, если нет -> вызвать фильтр для протокола следующего уровня

Добавлено через 8 минут
Конкретный фильтр протокола может
1) определить этот ли протокол
2) по возможности определить тип вышележащего протокола
3) проверить есть ли фильтрующее условие, если да, то наложить данный фильтр
Вопросов масса
1) Ну создал я композитный фильтр по умолчанию, как в него запихнуть фильтрующее условие для конкретного протокола? стратегия вроде подходит, но тогда эт ужос получается со свойствами протоколов
2) как лучше создавать фильтрующее условие? т.к. условие должно быть связанно со свойством протокола а протокол должен быть внутри простого фильтра (ну как должен быть, мне кажется что так)
Если что могу прислать UML того, что сейчас есть

Добавлено через 49 минут
Если кто знает Open Source аналоги - ссылки в студию. WireShark не предлагать ( там все проще для уже закапчереного пакета - для каждого пакета изначально выстраивается таблица содержащая свойства и значения, потом фильтр переводится в такую же таблицу -> таблицы сравниваются)

0

У Вас задача решить поставлненную проблему или поигратся с паттернами?

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

1

Главное решить проблему, но и с паттернами поиграться тоже хочется ( для большей практики в данной тематике).
Вчера как раз расчертил полностью схему (изначально понимал, что вряд ли получится хорошо). Да дизайн получился в некоторых моментах такой, что стыдно стало. НО Вы правы на все 100. Я четко увидел все конкретные проблемы на всех уровнях, что помогло легко найти простое решение.
В качестве резюме для себя:
1) Не заниматься преждевременной оптимизацией
2) Попытаться сначала решить проблему, а потом уже подумать над более элегантным вариантом
3) Практика, практика, практика... Только она поможет. Большие умные книжки об ООП/проектировании и менне объемные о паттерах не решат за тебя проблему и не дадут шаблонных путей решения. Все связано с конкретным контекстом задачи и предметной области. Вооот))
Ps. причем вчера решил, а сегодня пост увидел))

0