Прежде всего, я думаю, что ваш дизайн довольно умный и хорошо подходит для поведения, которое вы пытаетесь смоделировать.
В любом случае, я понимаю, что вы пытаетесь создать некий «предметно-ориентированный язык», в котором вы можете связать «глаголы» (различные методы фильтрации), представляющие действия или соединяющие «сущности» (где изменчивость представлены различными форматами именования, которые могут существовать, хотя вы ничего не говорите об этом).
В этом отношении очень интересное обсуждение можно найти в книге Мартина Флоулера " Специфичные для домена языки ". Просто чтобы дать вам представление о том, что это такое, здесь , вы можете найти интересную дискуссию о паттерне "связывание методов", определенном как:
«Методы make-модификаторов возвращают хост-объект, чтобы в одном выражении можно было вызывать несколько модификаторов».
Как видите, этот шаблон описывает тот самый механизм цепочки, который вы используете в своем дизайне.
Здесь у вас есть список всех шаблонов, которые были найдены интересными при определении таких DSL. Опять же, вы легко найдете там несколько специализированных шаблонов, которые вы также подразумеваете в своем дизайне или описываете как более общие шаблоны (например, декоратор). Вот некоторые из них: лексер таблиц регулярных выражений, цепочка методов, построитель выражений и т. Д., И многое другое, что может помочь вам более точно определить свой дизайн.
В целом, я мог бы добавить свое зерно соли, сказав, что я вижу место для шаблона "командный процессор" в вашей спецификации, но я довольно уверен, что, развернув мощные абстракции, которые предлагает Фаулер, вы сможете придумать гораздо более конкретный и точный дизайн, охватывающий аспект проблемы, который сейчас просто скрывается «общностью» набора паттернов GoF.
Это правда, что это может быть "излишним" для такой проблемы, как та, которую вы описываете, но как упражнение в дизайне, ориентированном на шаблоны, оно может быть очень проницательным.