Комментарии 9
По-моему, это не компоновщик. Мне кажется, здесь можно применить паттерн цепочка обязанностей. А еще используйте IOC, ибо вот это:
$composite = new \CompositeAndStrategy\CompositeStrategy(
new \CompositeAndStrategy\CompositeStrategyAnd(
new \CompositeAndStrategy\CompositeStrategyOr(
рак.
$composite = new \CompositeAndStrategy\CompositeStrategy(
new \CompositeAndStrategy\CompositeStrategyAnd(
new \CompositeAndStrategy\CompositeStrategyOr(
рак.
Из-за чего Вы считаете, что это не компоновщик?
Цепочка обязанностей немного не то, на мой взгляд, т.к. тут главная задача определить единственное развитие событий из множества возможных, а это уже стратегия.
Цепочка обязанностей немного не то, на мой взгляд, т.к. тут главная задача определить единственное развитие событий из множества возможных, а это уже стратегия.
Компоновщик — это структурирующий паттерн, у вас же здесь определяется поведение. И скорее всего у вас это и есть цепочка обязанностей с чуть более сложной логикой из-за древовидной структуры. Так как вы передаете запрос фактически набору обработчиков (стратегий) и при этом не знаете какой их них должен его обработать. Запрос идет по дереву, и, как только достигается условия выполнения, возвращается ответ.
Собственно по этому мне и кажется, что это не компоновщик. А в паттерне цепочка обязанностей принцип интерфейс обработчика такой же, как и у стратегии.
Собственно по этому мне и кажется, что это не компоновщик. А в паттерне цепочка обязанностей принцип интерфейс обработчика такой же, как и у стратегии.
У вас просто получился объектный Expression Language. Если бы вы немного выше абстрагировались бы, то у вас бы логика процессинга перенеслась бы из perform() в некоторый Interpreter или в коллекцию Visitor'ов, которые бы проходили вашу иерархию как AST.
Composite + Strategy — немного уводят от основного смысла, хотя нельзя сказать, что ваши
сущности ими не являются.
Composite + Strategy — немного уводят от основного смысла, хотя нельзя сказать, что ваши
сущности ими не являются.
И ещё не совсем понятно, зачем вы здесь ввели в целом ICompositeStrategy не унаследовав IStrategy при этом.
То есть, Composite ведь должен неявно реализовывать логику множественного. Либо, вы могли бы в целом отказаться от ICompositeStrategy и ввести стратегию композиции — StrategyList(...).
Я бы на вашем месте ещё и в стороны шаблона Builder посмотрел.
То есть, Composite ведь должен неявно реализовывать логику множественного. Либо, вы могли бы в целом отказаться от ICompositeStrategy и ввести стратегию композиции — StrategyList(...).
Я бы на вашем месте ещё и в стороны шаблона Builder посмотрел.
return false; …
return $this;
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Компоновщик стратегий или объединение Composite+Strategy