I've been enjoying going through the OOP literature from the 90's (and earlier) and have especially enjoyed Trygve Reenskaug's view on things. I came across the OORam methodology in Trygve's book, "Working with Objects" [0] which I found after reading about Ivar Jacobson's "Use case driven design."<p>I found the idea of reifying use-cases into explicit code constructs interesting.<p><a href="https://heim.ifi.uio.no/~trygver/1996/book/WorkingWithObjects.pdf" rel="nofollow">https://heim.ifi.uio.no/~trygver/1996/book/WorkingWithObject...</a>
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.<p>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."<p>That's an abstraction more easily and succinctly solved by higher-order functions.<p>And to boot OOram uses inheritance for re-using those role-models, which we would avoid nowadays.<p>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.
For those that want to understand what modern class-based OOP really is, there's a great analysis at <a href="https://wiki.haskell.org/OOP_vs_type_classes#There_is_only_one_dictionary_per_function_call" rel="nofollow">https://wiki.haskell.org/OOP_vs_type_classes#There_is_only_o...</a>
Reenskaug did further work on this under the heading DCI.<p><a href="https://en.wikipedia.org/wiki/Data,_context_and_interaction" rel="nofollow">https://en.wikipedia.org/wiki/Data,_context_and_interaction</a>
OOP is not a helpful paradigm for modeling systems. If it was, we would design digital circuits with classes. But, of course that's not possible. Because classes are absolutely a horrible metaphor for representing shared state at runtime. And, that's most of what modern systems are doing. Have you ever stopped to consider that a class API is effectively the pin-out to a chip that's missing it's observable state vs input specification? Nobody would use that chip because it's actually not adequately documented. And, so why people think OOP is still a reasonable basis for building re-usable code and expressing ideas about system architecture after decades of disappointment is one of software enduring mysteries. My speculation is that the half-life of talented engineers before they become managers is approximately equal to the number of years you need to seriously struggle with OOP before you have enough perspective to start having ideas of your own. And, then you switch to management, and buy a book on design patterns, and kick the can to the next generation.
Note that the idea here is sound; identify and specify the roles of various actors in detail specifying explicitly that they are not actual _classes_. Effectively, this is high-level block diagram and there's every reason in the world to have that clearly defined before actually building a system.<p>But, then when you go to actually implement and testing something designed this way that's non-trivial. That's the point where I am arguing that OOP should not be manner in which the implementation is expressed because the paradigm is optimized for organizing functions that operate on common data context. But, not for organizing actors that must share data and carefully coordinate the which and in what order functions are applied to modify that data.