It sounds a little bit like a solution for a problem you wouldn't have if you didn't use classes and inheritance in the first place.
A role as understood by OOram design principles paper is "An activity is a task carried out by a set of associated objects in cooperation."
That's an abstraction more easily and succinctly solved by higher-order functions.
And to boot OOram uses inheritance for re-using those role-models, which we would avoid nowadays.
An interesting idea for sure, but more like an observation on the limitations of (older) object-oriented language with regard to abstractions we now take for granted.
>That's an abstraction more easily and succinctly solved by higher-order functions.
Definitely a legitimate approach. In my mind, it seems to be describing Dependency Injection or some type of Strategy Pattern. The activity is defined using "roles" (interfaces) in some use-case class and then implementations of those interfaces are injected.
A role as understood by OOram design principles paper is "An activity is a task carried out by a set of associated objects in cooperation."
That's an abstraction more easily and succinctly solved by higher-order functions.
And to boot OOram uses inheritance for re-using those role-models, which we would avoid nowadays.
An interesting idea for sure, but more like an observation on the limitations of (older) object-oriented language with regard to abstractions we now take for granted.