I'm working on a simple project of software engineering that should combine two patterns. I choose Abstract Factory and Decorator patterns to modify (dynamically) objects created with the concrete Factory classes. My question is: is delegating object decorations to those Factory classes a design error?
Here's the UML scheme:
I don't see that as a problem.
Factory are used to implement the Dependency Injection (DI) pattern, where one wish to dispense a section of code from having to know how to construct objects of a certain class, which could involve other secondary classes and render the aforementioned section of code more coupled to the rest of the codebase. The less coupling, the easier it is to update the code — the client part (that section of code), or the service part (the object being created — Cake in your case).
When it comes to decorators, you are essentially describing an algebra on the object: you start from some class instance (Cake object), and by applying an operator (the decorator), you obtain another object from the same class (to be precise, it's a subclass, so it's more akin to a refinement operation, but for our purpose, ignoring that part is OK).
The client code needs to know about that algebra, as a part of how it may manipulate the object, so you have to disclose this information. Now it could be in the form of a set of methods on the Cake class, a set of functions acting as operators, or methods on a class implementing that algebra.
The 2nd option might be more complicated to implement, if decorators need to share some information on the Cake class only available at runtime; you'd have to implement the DI pattern on them, and you would end up with either the first or the 3rd solution.
The remaining options are equivalent from the client code point of view, not adding more dependency either way.
