Object Oriented Role Analysis and Modeling | Hacker News Reader

Object Oriented Role Analysis and Modeling

en.wikipedia.org

38 pointsdmux19 comments

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."

I found the idea of reifying use-cases into explicit code constructs interesting.

https://heim.ifi.uio.no/~trygver/1996/book/WorkingWithObject...

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.

"solved by higher-order functions" Then C is enough for everything. What a waste !!!

> And to boot OOram uses inheritance for re-using those role-models, which we would avoid nowadays.

Why do you believe that nowadays we should avoid implementing a common interface?

For those that want to understand what modern class-based OOP really is, there's a great analysis at https://wiki.haskell.org/OOP_vs_type_classes#There_is_only_o...

Reenskaug did further work on this under the heading DCI.

https://en.wikipedia.org/wiki/Data,_context_and_interaction

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.

Decades of disappointment? Most large software projects are still done with OOP and it doesn't seem like any functional programming prodigy paradigm is going to replace it any time soon.

OOP languages also happen to be some of the most popular languages around - C#, Java, C++, Javascript. Coincidence? (in before nitpicking about how C++ and Javascript aren't OOP).

There are a few sure things in life. One of them is that speaking of OOP in a positive light will get an immediate comment on the orange site saying that it's garbage. Its almost comedy at this point.

Budweiser is pretty popular but it's not a great beer.

https://unity.com/dots

Take full advantage of today’s multicore processors with Unity’s new high-performance, multithreaded Data-Oriented Technology Stack (DOTS).

DOTS makes great games run faster on multicore processors without the heavy programming headache.

DOTS provides programmers with a convenient sandbox to write safe multithreaded code for massive performance gains, while also optimizing thermal control and battery life on players’ mobile devices. By moving from object-oriented to data-oriented design, it will also be easier for you to reuse your code and for others to understand and work on it.

The new Conversion Workflow converts your GameObjects to entities with one click. At runtime, check the new Entity Preview Inspector to see how DOTS turns your GameObjects into entities

Popular things can improve

OOP as realized by the languages in common use is a bit of a disaster.

What was originally conceived as message passing[1] is actually implemented by OO languages as passing around pointers to objects that have mutable state, so in effect, every object is potentially part of global shared state.

Inheritance is a confused mess of "is-a" semantics, type system behavior, and code/state sharing in a set of subclasses.

I'm often somewhat amazed that we can build working large-scale systems at all in these languages given their weaknesses and the knowledge/skill level of the average programmer.

One source for what OOP was meant to be is https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented. That article links to others, and you can follow quite a rabbit trail of "what OOP is" threads.

It isn't the languages themselves it is the structures and software architecture that people think will scale while not realizing how tangled their program is.

Inheritance by its nature introduces dependencies but accomplishes little to nothing that couldn't be accomplished better with a different technique.

Likewise putting any sort of transformation from one type to another inside a class introduces a dependency on that type, which may be doing the same thing, thus depending on other types, etc.

On the other hand message passing in the form of pointers, interprocess communication, copying within a program, etc. Can be done in C++. Unfortunately most people go where the language leads them because few people really have a great idea of how to structure complex software.

please, current software - not event thinking about Electron-like things, just the software that comes with operating systems, be it Finder, explorer.exe, even fucking photo viewers and music players or terminals - are already slow and frustrating enough as is, it's not like message passing is going to make shit happen faster.

I saw a Pharo (smalltalk) demo recently, the damn thing was so slow to react I thought it was a bad joke. Can't even begin to imagine what actual message passing would look like - oh wait, I do actually know due to spending 6 hours last weekend finding why a software had uncomfortable mouse interaction, actually caused by fucking objc_msgSend making everything async and slow on that wretched Apple OS.

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.

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.

>...and in what order functions are applied to modify that data.

Is this solved in a better way using other paradigms?

> 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.

you mean... the actor model?!

Reply on news.ycombinator.com