2

So I've been going over some design patterns and I came across this discussion https://stackoverflow.com/questions/43565475/using-lists-instead-of-decorator-pattern

I've been thinking that in all honesty I can always replace a decorator design pattern with an ArrayList of methods that I can activate in the order of insertion. Maybe a plus side is that I can dynamically remove intermediate functionalities that were added this way while in a normal decorator pattern that would be difficult to do.

So what kind of real advantage does a Decorator pattern have over a list of methods? Can anyone think of examples or reasons why a list of methods called in succession would be inherently worse?

Thanks

3
  • 2
    Have you read all the linked question' answers? Because there's a lot of information, insights and pros and cons there. Runtime flexibility (lists) vs readability and expressiveness (decorator)
    – Laiv
    Jan 10, 2023 at 11:14
  • 1
    If you're not in control of the interface where you need to plug in the decorated object, then you have to use a decorator (cause the interface doesn't accept a list). Also, doing both pre-effects and post-effects with a list is a bit awkward. That said, structurally, a stack of decorators is essentially a linked list. And, you might want to simultaneously decorate more than one method. Jan 10, 2023 at 16:49
  • @FilipMilovanović I actually really like the example with decorating multiple methods at once. In general it is still possible with multiple lists (one list per decorated method) but maintaining a 2D array instead of using the decorator pattern sounds like a nightmare to maintain
    – crommy
    Jan 10, 2023 at 21:02

2 Answers 2

1

The advantage of the decorator pattern with inheritance is you can use it with any class without access to the internals and pass that decorator object into others transparently.

So I'm using some library with an Auth class with Auth.IsAllowed() and I want to fiddle with the logic a bit I can decorate and pass the decorated object into the rest of the library functions no problem.

If you know you will need multiple 'decorators' then there is probably a better solution than either version of the decorator pattern.

The coffee example is insane no one would program that. OOP examples always have Cats and Dogs of type Animal etc but in real life you are overriding EndStream() or Crypography.KeySize() where the inheritance ideas like 'A is a B' don't hold the same meaning.

0

Both are implementations of decorator pattern. The chained decorators implementation or onion style implementation offers loose coupling.

Consider the following aggregated decorators:

  • BDecorator, which decorates ADecorator which decorates SomethingToDecorate
  • CDecorator, which decorates BDecorator which decorates ADecorator which decorates SomethingToDecorate

In the scenario where CDecorator decorates a list containing BDecorator and ADecorator, CDecorator has to communicate to BDecorator to exclude what uses from ADecorator.

In the scenario where CDecorator decorates a list containing only BDecorator the list is redundant. CDecorator could get the instance of BDecorator without being wrapped in a list.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.