Styjun

I have read and seen many examples describing why decorator is a structural pattern. And how it's composing objects to add new functionalities.
While Visitor pattern helps with adding new functions to an object. And strategy pattern is to swap algorithm at run time.

I still can't wrap my head around the concept of why decorator pattern is a structural and not a behavioral pattern.

Can someone exemplify these patterns with few real world programming examples? The pizza and flying duck examples makes me think that I understand, but in a while I end up with - what did I just read.

Would be really helpful to take a real system design, spilt into smaller problems and apply all these design patterns.

EDIT: Took the following use case to apply and understand different design patterns. Please share your thoughts on this example.

An voice interactive system for Museum where kids can ask anything and get information about it and book tickets for any shows.
Eg: kid asks what is solar system, and then drills down with questions about planets. Then book tickets for a planetarium show.

Here are the technical use cases where design patterns can be applied. Please help choose the right design patterns for each case:
1) Listen to kid's questions and parse data from it.
2) Identify if kid is asking information or requesting direction or want to book a ticket and so on...
3) Based on the kid intent, respond with an answer or collect more info to book ticket or schedule a group tour.
4) Manage conversations and context data.
5) Call API to get an answer or book a tour.

Would like to apply design patterns so that the system can follow SOLID principles.
Design requirement for each of the above use case:
1) With out modifying existing code the system should accept new input methods (touch, voice, keyboard, mouse) by following OCP. Also accept new sensor inputs like facial reaction while kids ask question.
2) The system should be extensible to support new user intents.
3) Some questions have straight forward answers and some cases need follow-up questions to get more details from kids (book tour). Here every conversation does similar things (listens to the kid, system does something, respond to the kid with follow up or an answer). Can decorator design pattern be used here to compose objects like parent object (to get what the kid want to do) and child objects (to get follow-up details to book tour)
4) Should be able to reuse the same design to manage any flow of back and forth questions and manage the context data.
5) loosely couple the APIs, swapping APIs as needed, support API from different providers to book tour, answer questions etc. (Strategy pattern ?). If it involves multiple API competing for book the tour and the system chooses one API, what would be a good pattern to use.

The system should be extensible to support new use cases like 'ask for help from a museum employee' or 'buy a coffee from food court' or 'sign up for volunteering'.

Not sure if this forum supports this kind of discussion. But I couldn't find a better forum to take this discussion.

Behavioral design patterns are concerned with the interaction and responsibility of objects. In these design patterns, the interaction between the objects should enable them to easily talk to each other and still be loosely coupled. Visitor in your case lets you define a new operation over the object structure without changing the classes of the elements on which it operates.

Structural design patterns on the other hand are concerned with how classes and objects can be composed to form larger structures. It is the structure that is flexible.

interface Executable 

 void execute();



class DeleteUser implements Executable 

 @Override
 public void execute() 
 // delete
 



class LoggingExecutable implements Executable 

 private final Executable executable;

 @Override
 public void execute() 
 // log before
 executable.execute();
 // log after
 



class TransactionalExecutable implements Executable 

 private final Executable executable;

 @Override
 public void execute() 
 // open transaction
 try 
 executable.execute();
 catch (FooException e) 
 // rollback
 finally 
 // close transaction
 
 

Here is a hypothetical composite structure with use of decorators. As you can see it is the structure that is flexible. I can construct Executable that is both logging and transactional, but I am free to have it just logging for example or decorated with something completely different.

new LoggingExecutable(
 new TransactionalExecutable(
 new DeleteUser()));

new LoggingExecutable(
 new DeleteUser());