Answers.Body: <p>There are two somewhat separate concepts of a decorator. I'm guessing that you mean the one related to using &quot;first class&quot; functions in Python or in a more traditional functional language. The other concept is from OO programming and involves the method structure of an object. They are related, of course, since a function in Python is an object.</p>
  <p>The first concept is discussed <a href="https://realpython.com/primer-on-python-decorators" rel="nofollow noreferrer">here</a>. The other is in the standard OO design pattern literature in many places. For example, <a href="https://www.tutorialspoint.com/design_pattern/decorator_pattern.htm" rel="nofollow noreferrer">here</a></p>
  <p>But this is an idea for a project that could be implemented in either paradigm.</p>
  <p>Imagine a robot that has certain &quot;reversible&quot; action, moving, turning, etc. Suppose that you want to send the robot off on some sort of quest. The quest may be modified along the way as the robot encounters various obstacles or such. Suppose further that, at the end of the quest you want to have the robot return to its original position - a partial &quot;undo&quot; of its actions.</p>
  <p>The idea is to have a Strategy for the robot that it &quot;carries&quot; either as an object or as a function (The Strategy Pattern). For each action that you want to undo, have the robot &quot;decorate&quot; its strategy with an additional action that undoes the current action. For example, to undo a &quot;left turn&quot; you execute a &quot;right turn&quot; assuming that the robot will then be facing the opposite direction.</p>
  <p>In effect, you build up a stack of decorators that define all of the actions required to return to the base position from wherever it is at the moment.</p>
  <p>Each decorator will first execute the immediate undo action and then invoke the decorated item, unwinding the stack. But note that to &quot;undo&quot; all that is required is a single message, not a loop. The structure itself implements the repetition.</p>
  <hr />
  <p>Implementation notes:</p>
  <p>If you are doing this with novices I have one bit of advice. The strategy and the decorator need <em>exactly</em> the same interface. For the functional idea, that means the same parameter structure, and for the OO version the classes should have the same public method interface. If you break this rule (as pros might need to do on occasion) you will likely confuse the students as to what is essential in the idea.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-04-28T18:05:51.560Z
Answers.LastActivityDate: 2021-04-28T20:47:51.817Z
Answers.LastEditDate: 2021-04-28T20:47:51.817Z
Answers.UserDisplayName: Buffy
Answers.Body: <p>Although it should probably be only one strategy among many, you might teach it through practical examples.  In this short program that uses flask_user (and
  which students can install in just a few minutes) the decorator ensures that only authenticated users can use the route:</p>
  <p><a href="https://flask-user.readthedocs.io/en/latest/quickstart_app.html" rel="nofollow noreferrer">https://flask-user.readthedocs.io/en/latest/quickstart_app.html</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-05-01T18:37:31.633Z
Answers.LastActivityDate: 2021-05-01T18:37:31.633Z
Answers.UserDisplayName: Luke
Body: <p>How to teach decorators to Undergrad students? I mean how make the concept crystal clear?
  Sometimes it becomes complex as :</p>
  <p>&quot;functions passing another functions in argument, adding new functionality to existing functions or classes without modifying the existing structure&quot; and using &quot;@&quot; symbol confuses students.</p>
  <p>I know decorators are very powerful tools. Any suggestions for teaching them effectively?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-04-28T12:40:33.420Z
Comments.Text: "Python" isn't really essential here. The same examples work in other OO languages. I'll give some ideas later today, I think.
Comments.UserDisplayName: Buffy
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-04-28T13:01:10.727Z
Comments.Text: In the short term think about teaching Strategy immediately before Decorator. Strategies are a natural thing to decorate.
Comments.UserDisplayName: Buffy
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-04-28T14:28:04.587Z
Comments.Text: I am asking about the concept of decorators.. it is specific to python in my case
Comments.UserDisplayName: Free Palestine
Tags: <undergraduate><object-oriented-paradigm><python>
Title: Decorators in Python
ThreadText: # Decorators in Python
  
  (Asked by: username_0 on 2021-04-28)
  
  How to teach decorators to Undergrad students? I mean how make the concept crystal clear?
  Sometimes it becomes complex as :
  
  "functions passing another functions in argument, adding new functionality to existing functions or classes without modifying the existing structure" and using "@" symbol confuses students.
  
  I know decorators are very powerful tools. Any suggestions for teaching them effectively?
  
  **Tags:** undergraduate, object-oriented-paradigm, python
  
  > **Comments:**
  > **username_1**: "Python" isn't really essential here. The same examples work in other OO languages. I'll give some ideas later today, I think.  
  > **username_1**: In the short term think about teaching Strategy immediately before Decorator. Strategies are a natural thing to decorate.  
  > **username_0**: I am asking about the concept of decorators.. it is specific to python in my case  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2021-05-01. Score: 3
  
  Although it should probably be only one strategy among many, you might teach it through practical examples. In this short program that uses flask\_user (and
  which students can install in just a few minutes) the decorator ensures that only authenticated users can use the route:
  
  <https://flask-user.readthedocs.io/en/latest/quickstart_app.html>
  
  
  ---
  
  ### Answer by username_1 on 2021-04-28. Score: 1
  
  There are two somewhat separate concepts of a decorator. I'm guessing that you mean the one related to using "first class" functions in Python or in a more traditional functional language. The other concept is from OO programming and involves the method structure of an object. They are related, of course, since a function in Python is an object.
  
  The first concept is discussed [here](https://realpython.com/primer-on-python-decorators). The other is in the standard OO design pattern literature in many places. For example, [here](https://www.tutorialspoint.com/design_pattern/decorator_pattern.htm)
  
  But this is an idea for a project that could be implemented in either paradigm.
  
  Imagine a robot that has certain "reversible" action, moving, turning, etc. Suppose that you want to send the robot off on some sort of quest. The quest may be modified along the way as the robot encounters various obstacles or such. Suppose further that, at the end of the quest you want to have the robot return to its original position - a partial "undo" of its actions.
  
  The idea is to have a Strategy for the robot that it "carries" either as an object or as a function (The Strategy Pattern). For each action that you want to undo, have the robot "decorate" its strategy with an additional action that undoes the current action. For example, to undo a "left turn" you execute a "right turn" assuming that the robot will then be facing the opposite direction.
  
  In effect, you build up a stack of decorators that define all of the actions required to return to the base position from wherever it is at the moment.
  
  Each decorator will first execute the immediate undo action and then invoke the decorated item, unwinding the stack. But note that to "undo" all that is required is a single message, not a loop. The structure itself implements the repetition.
  
  ---
  
  Implementation notes:
  
  If you are doing this with novices I have one bit of advice. The strategy and the decorator need *exactly* the same interface. For the functional idea, that means the same parameter structure, and for the OO version the classes should have the same public method interface. If you break this rule (as pros might need to do on occasion) you will likely confuse the students as to what is essential in the idea.
  
  
  ---
  
  