Roles are the Perl way to ensure a class adheres to a certain design. In Linux you can OPEN a socket or a file or a device driver or whatever else. They are treated the same because they conform to a certain interface. You might want plug in different sorting algorithms without knowing the details of how they work. A role is just one language's implementation of a concept with the goals of reusing code, minimizing dependency, and designing with flexibility in mind. Sub classes and abstract classes have greater dependency because changing a parent class changes every child class. Often times you'll want to change behavior of a child object, but.. oh wait all that code is in the parent.
HackaMol - OO Perl for molecular hacking
PDF explaining design
Add Dry-Run testing to classes
http://blogs.perl.org/users/ovid/2010/01/roles-without-moose.html
| [reply] [Watch: Dir/Any] |
I think the idea is that you can combine more than one Role, where combining multiple base classes by inheritance leads to multiple inheritance.
Never mind that Roles in Perl are usually implemented through (multiple) inheritance, but they seem to placate people who understand OO design better than I do.
| [reply] [Watch: Dir/Any] |
Moose roles have some limitations, such as inability to override a method in a class which "with"es the role.
It is not a limitation, it is a feature. ;-)
The whole idea with roles is to avoid the mess occurring quite commonly with multiple inheritance, unseen method resolution conflicts, and so on. Roles make it possible to add behaviors to a class or to objects, not to override existing methods. If you need to override a method, then you have to subclass it.
Update: fixed a typo.
| [reply] [Watch: Dir/Any] |
Role methods can be 'overridden' using an 'around' method modifier.
| [reply] [Watch: Dir/Any] |
| [reply] [Watch: Dir/Any] [d/l] |