[HN Gopher] Fifty Shades of OOP
___________________________________________________________________
Fifty Shades of OOP
Author : todsacerdoti
Score : 25 points
Date : 2025-11-24 09:40 UTC (13 hours ago)
(HTM) web link (lesleylai.info)
(TXT) w3m dump (lesleylai.info)
| MarkusQ wrote:
| I expected this to be a play on the old joke about Java being
| designed to appeal to people who were into SM/B&D.
| dmux wrote:
| Regarding Message Passing and Late-binding, I think it's
| important to take into account that Alan Kay was working on
| Smalltalk -- a system that was image based; a system where you
| could change things as it was running. I think that message
| passing and late-binding are often championed but then sort of
| fall flat given standard deployment techniques: build & deploy
| (often to a ephemeral runtime / container).
| tracker1 wrote:
| Commenting while reading...
|
| On classes, I get it... tbf though I'm fine with prototype
| inheritance as well, there's positives and negatives to both
| approaches... not to mention, there are benefits to not really
| having either and just having objects you can interrogate or even
| that are statically assigned at creation (structs).
|
| What's funny on the Method Syntax for me, is that I actually
| don't like mixing classes that hold data and classes that do
| things more often than not. I mean, I get the concepts, but I
| just don't generally like the approach. The only exception might
| be a controller with a handle to a model(state) and the view...
| but even then, the data itself (model) is kind of separated as a
| reference, and don't tend to attach too many variants of state to
| anything... I'm generally a fan of the single state tree approach
| (often used for games, and famously via Redux).
|
| On information hiding... I'm generally not too much of a fan of
| hiding members of an object used to hold data... I mean, I can
| see filters when you're passing something to the edge of a
| system, like a hashed password on a user object exposed via an
| api. But internally, I'd almost rather see immutability as a
| first class over locking bits and pieces down, then exposing
| member methods to mutate the object internally. Just my own take.
|
| On Encapsulation, like above... I'm more on the side of the Data
| oriented design approach. To me this is where you have API
| surfaces and like above I tend to separate modules/classes that
| do things, from templates/models/classes that hold data.
|
| I'm mixed on Interfaces.. they're definitely useful for plugin
| systems or when you have multiple distinct implementations of a
| thing... but after a couple decades of C#, they're definitely
| overrated and overused.
|
| No strong opinions on Late Binding pr Dynamic Dispatch... other
| than I do appreciate it at times in dynamic language environments
| (JS).
|
| Inheritance and SubTyping imo are, similar to Interfaces,
| somewhat overrated... I just try to avoid them more than use
| them. There are exceptions, I'm actively using this in a project
| right now, but more often than not, it just adds undue
| complexity. With prototype based inheritance, it's also possible
| to really slow down certain processes unintentionally.
|
| Strong proponent of Message Passing approaches... it often
| simplifies a solution in terms of the surface you need to be
| aware of at a given point. Allows you to construct decision trees
| and pipelines of simpler functions.
|
| Interesting overall... but still not a fan of some of the
| excesses in OOP usage in practice that I've had to deal with. I
| just prefer to break problems up slightly differently...
| sometimes blurring clear lines of separation to have a simpler
| whole, sometimes just drawing the lines differently because they
| make more sense to me to break up for a given use case.
___________________________________________________________________
(page generated 2025-11-24 23:00 UTC)