You will have to excuse my brevity and any typos in advance, as I am writing this on my cell phone.
If I understand correctly, you want to define how a particular object (the subject, using your vocabulary) can notify another (observer) of an event, have the observer take some action, and then return some thing as a result. I understand that decoupling the subject from the observer could appealing, so that you can call any function provided by observer when an event occurs. (And possibly provide logic inside the request to route the event to one of many possible functions inside the observer) However, I think this particular implementation would cause more issues than it solves. For instance, in the case that a third object wires a subjects event to the wrong method the observer, and some exception thrown the observers method. In this case, my stack trace will show that the subject called the observer, and that an exception was shown. A developer would then spend time tracking down where these calls happened, only to not find anything wrong. They would have to know that object 3 wired the event, and only upon looking at the code in object 3 would they find the bug. This makes the code a maintenance nightmare. Especially if the maintainer didn't write the code. And I'm all for making maintainers lives easier. Secondly, this means that an object does not fully control what it's response is to an event. I am of the mind that an object should explicitly define its behaviour to events. Have you considered using event handlers? Observers must satisfy an interface that the subject can call directly, making maintenance easier. Also, the observer then is in full control over what happens in response to the event. Finally, a subject is then able to provide subscribe/unsubscribe functionality to allow dynamic routing of events to different observers. Turns out that wasn't so brief after all. On Thursday, April 17, 2014 9:07:10 AM UTC+12, Marcus Ottosson wrote: > Hey guys, > > > I'm looking for feedback on a programming pattern I've been tinkering with > lately; its a simplification of signalling an event and getting a result back > via another signal, such as when a GUI requests an event to be performed, but > the event it performed elsewhere - most likely a separate object - and gets > an event back from the separate object upon completion. > > > The Request Pattern > > > Let me know what you think. > > > Best, > Marcus -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/585f7e11-45ba-401a-a533-6811a3c0069d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
