From: Robert Klemme Date: 2011-06-28T17:57:30+09:00 Subject: Re: Single Responsibility Question On Mon, Jun 27, 2011 at 3:27 PM, Mike Bethany wrote: > Thanks Robert, you always have excellent feedback. Thank you! > On Mon, Jun 27, 2011 at 3:20 AM, Robert Klemme > wrote: > >> On Sun, Jun 26, 2011 at 2:22 AM, Mike Bethany wrote: >> > I'm trying to figure out who's responsible for a resource. >> >> standard library has an implementation of this already (see ri >> Observable). >> http://www.ruby-doc.org/stdlib/libdoc/observer/rdoc/index.html >> >> > I wrote Eventable (https://github.com/mikbe/eventable) specifically because > Observable didn't do everything I wanted, e.g. fine-grain event control and > better handling of abandoned listeners. Also Observable doesn't use any > mechanism to prevent blocking callbacks and that was a must. If requirements are different then a different solution is needed. That's why "observer" is a pattern - implementations can differ. :-) >> Btw, there is no responsibility needed after creation of the thread: >> it will terminate eventually and that's it.  The story is a tad >> different if you create the thread on object construction and use a >> queue for concurrent notification execution. > > Excellent. I had come to that conclusion but it's good to hear I'm right. =) :-) >> Typically *many* listeners (or observers) can register with a single >> observable.  If the observable must make sure it doesn't get blocked >> by listeners then it should create the thread.  If on the other hand >> you want to keep the implementation lightweight, keep # of threads low >> or need to make sure that observers can prevent an operation in the >> observable (e.g. by raising an exception) the thread must not be >> created in the observable (because you need to wait for observers to >> finish anyway).  There may also be other reasons which prevent usage >> of a separate thread (i.e. if observers must be able to see the state >> of the observable /before the modifying method terminates/). >> >> As you can see there are various aspects and different situations may >> require different handling of this. > Thanks again Robert. My vision is to keep Eventable as lightweight as > possible while still making it as robust as possible. Incidentally keeping things as simple as possible often helps with the robustness as well: the lesser nuts and bolts there are less things can break and usually the lower the likeliness of things to break. :-) > I don't think it > should be Eventable's job to monitor threads but I do have the need to > monitor for run away threads in the application I originally wrote Eventable > for. > > To solve this issue I've decided to create a thread monitor mixin for that > responsibility. This will allow the the user of Eventable to specify thread > monitoring behavior without adding another responsibility to Eventable. It's always good to keep different aspects separate - that's all modularity is all about. :-) And modularity not only enables reuse but foremost it makes understanding code easier. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/