# Combine abstract factory with decorator pattern [closed]

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:

## closed as off-topic by D.W.♦, David Richerby, Nicholas Mancuso, Luke Mathieson, JuhoFeb 16 '15 at 6:42

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "This question does not appear to be about computer science, within the scope defined in the help center." – David Richerby, Nicholas Mancuso, Luke Mathieson, Juho
If this question can be reworded to fit the rules in the help center, please edit the question.

• If you're asking for advice, this question might be better suited to Programmers.SE. Don't cross-post there, but if you want it migrated, you can click "flag" to flag your post for moderator attention and ask them to migrate it. If you wanted to ask for an answer with evidence to support it, that would be reasonable for this site, but subjective questions (e.g., about "best practice" or "accepted wisdom") are probably not a good fit for this site. As your question appears to be of the latter sort, I'm not sure whether it is a good fit for this site. Perhaps others will have a different view. – D.W. Feb 13 '15 at 21:45
• Is this a project for a course? Normally, a pattern is a kind of tool to solve a particular problem. It seems odd to create a problem that requires a two types of tools combined, e.g. a combined use of a drill and a hammer in woodworking. – Fuhrmanator Feb 14 '15 at 13:05
• @Fuhrmanator yes, a project for a course.. i should show some design/programming technique like something of Effective Java, or a (usefully) combination of two pattern (like observer+strategy or like my example). – Duccio Bertieri Feb 15 '15 at 12:27

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.