gjohnson wrote: > I wanted to get some feedback on mixing in a dependency over just > storing off the dependency as a property. > [ ... ] I am more interested in hearing people's opinions > on which way you would do it and why; by this I mean what way you feel > is more "correct".
I'm afraid neither is more correct. Using a mixin generally implies that the mixed in properties have some inherent meaning as a group, and can work together in various different contexts, one of which is the object in question, but the mixin may not have all the capabilities to stand on its own. Using a separate property implies that that property object is itself intact and is simply being used by the containing object. > If you say "it depends"; well the use case at hand is some sort of RPC > pattern, where my framework only deals with the plumbings of parsing a > message and applying the method based on what's in the message. The > framework user needs to tell the framework for category "X" messages, > use object "Y" and the method name enclosed in the message will be in > there (Hopefully!). For a variety of reasons, you cannot include in > the message what object contains desired method, this is why you > either need to: a) mix in the target or b) store it off as a property. Although this is lucid and clear it's not really enough for me to make a recommendation. One clear-cut reason, though, to use mixins rather than composition, would be if the code had to call other functions in the parent object. Mixins obviously have some performance benefits. And that might be a reason to use them, but this is rarely the bottleneck of a system. -- Scott -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
