The Strategy
In development, we discovered a need to decouple the behaviour of the objects from the way they are represented. To this end, we used a Factory Method on data objects that would produce a visual representation of the object. However, we also found that we needed a way to attach additional behaviour to Graphic objects (e.g. being clickable or drawing a frame around a sprite). For this reason, we used a Decorator to attach these additional responsibilities on-the-fly, with an option to "un-decorate" a graphic where appropriate.
With this structure, each object in the application that can be drawn to the screen will have a corresponding Graphic that will be returned from createGraphic(). It's worth noting here that - to appropriately display the object - a wide interface is required between the object and its graphic.
Warning
If the classes are left as-is, this would require multiple inheritance. Would this be a good idea, granted we limit it to behaviour-only inheritance (i.e. interfaces)?
Furthermore, we need a way to parameterize requests for different actions that need to be performed on different objects in the game, using the Command pattern we can easily encapsulate a request as an object and use it throughout the game loop with the invoker object invoking all the needed commands.
Creating Orders with different specifications
Create food items that can be decorated easily
The kitchen is the concreteSubject and Waiter is a concreteObserver.
The idea behind this is that when food is ready to be delivered, the waiters are notified to collect.
This will follow the push strategy; any waiter will take whatever food as been marked as ready and deliver it to a table.
Activity Diagram