THE ETERNAL PROBLEM OF OBJECT ORIENTED PROGRAMMING

1. I need to encapsulate state in this object.
2. Good. Now the state is only accessible inside the object.
3. *Doing something else* Wait how do I get to the state that was in that object
The thing I've been thinking for 15 years but never found a good way to act on is that most of OO is about "paths", ie, starting from an object you need to request "the speed of the player obj of the levelmode obj of the level obj of me"

But languages don't know about the paths
So you set up "paths" in an always ad hoc way, and only at the moment you need it. So maybe there winds up being an accessor for the player obj in the levelmode obj, but you read the speed directly out of the player struct, and the levelmode itself is assumed a global singleton
And because you use a hodgepodge of methods to follow the "paths" that link the object, level, level mode, player, and player speed all together, when the relationships change (say maybe now levelmodes are one-to-many), you have to wade through and change the whole hodgepodge.
Skipping a bunch of steps here, this train of thought usually leads me to the conclusion "languages should make extension by composition as transparent as they currently make extension by inheritance". If you want me to explain the steps up to that conclusion invite me to OOPSLA
You can follow @mcclure111.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled:

By continuing to use the site, you are consenting to the use of cookies as explained in our Cookie Policy to improve your experience.