From: Woody Peterson Date: 2010-09-24T10:42:56+09:00 Subject: Re: composition vs 'leaf-class mixins' (vs class inheritance) Robert, if I understand you correctly, you're saying my 'composition' example is too coupled to the skill implementation, specifically that you might want to change both the way skills are invoked and the skill itself? What I saw about your example is that skill invocation and iteration are separated, it doesn't expose it's internals, and you could inherit from Person to fight differently or invoke a skill differently (in addition to swapping out skills). I think this is what you were advocating, in which case I definitely agree, my example was pretty naive. Brian, thanks, that's perfect. I agree. I looked at rails 3 again briefly, and they mitigate introspection concerns with some extra methods for reading what's been included in a class. Not sure what they do about the other points, ex. testing, but I'm still keeping it in mind... perhaps for layering on behavior where access to state could be considered desirable (ex. pulling something out of the request headers) and where ordering isn't a primary concern. It's not just that schools focus on inheritance as the key part of OO, it's also that OO language designers tend to build in inheritance as a very dominant concept (in opposition to ex. Alan Kay's statements that message passing should be the dominant concept of OO). Solving problems in terms of the languages' built-in dispatching sure seems like it shouldn't be of such limited use. That said, I find a lot of value in separating concerns and clean tests, so for now my real-world problems will most likely avoid using this 'leaf-class mixin' technique as an end goal. -- Posted via http://www.ruby-forum.com/.