Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- That's the Smalltalk school of OOP. There is also the Simula school. It is kind of unfortunate that they use the same name.by ahartmetz
- > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
This sounds a lot like microservice architecture.
by _pdp_ - Foundational source nowadays. Cited by wikipedia on the topic of OOP
I have personally taken to calling OOP either Kay OOP or Java OOP to differentiate between the original more philosophical meaning, and the later language imposed features.
by TZubiri - I think the actor model comes closest to Kay's objects.
An object holds it's own state and might change that state based on messages it receives.
Today you can find this in, for example, Elixir and Microsoft Orleans.
by paolfs - IMO, the most important philosophy in all of software engineering is "Separation of responsibilities." The best way to achieve it is through the principle of "High cohesion, loose coupling."
OOP is just another layer of philosophy which builds on top of that. It's more specific, imposes additional guardrails. It requires objects with state encapsulation (locality) and message-passing as the mechanism for components to interact with each other; each component is responsible for changing a subset of the state of the system. Each component is responsible for handling messages (calls to action) by performing local state changes and potentially also sending messages to other components which have more specific sub-responsibilities.
OOP without "High cohesion, loose coupling" is almost worthless IMO. It must build on top.
I think were most people fail with OOP is that they think coming up with good separation of concerns, good abstractions is easy. They just start implementing the first idea which comes out of their heads and then figure out the scope of responsibilities as they go.
The test for good separation of concerns is that you should be able to explain your architecture to someone with the intellect of a 9 year old child who happens to understand the business domain. I'm not exaggerating. It has to be that obvious or else you will not be able to maintain clean separation... You will not be able to maintain alignment in your team.
If the responsibilities of a specific object are somewhat vague, what will happen is that the scope of responsibilities between objects will soon blur and the messages between objects will start to look increasingly elaborate; your system will look like a bunch of horrible incompetent managers trying to micromanage junior employees using long, convoluted instructions and occasionally throwing chairs at them...
If your system is passing around object references all over the place; that's usually a sign of poor separation of concerns; passing around complex objects by reference is tight coupling, by definition. Each object, each person should be able to fulfill their responsibilities and finish the job using communication only.
- People are going to come out of the woodwork to argue about OO specifically, and I'd probably join in, but the higher-level view that I've come to over the years is that one programming paradigm is not the best in all situations. It really helps to work on a lot of different systems that are not all in the same class and look at a lot of code written by people of all skill levels. It's not possible to really talk about all programs, but I will say that the OO way of thinking can very easily be overdone and end up a giant mess. Similarly, the FP way of thinking can also be very easily be overdone and end up a giant mess. The old-style procedural programming (C with a pile of global variables) can easily be overdone and end up a giant mess. Yet all three of those can actually work out great at the right scale on the right problem!
I think the problem is that we can't really architect a program well until after it works and fulfills all of its design requirements. Those are usually in flux and then we have to engineer dimensions of extensibility to prevent committing to the wrong architecture in the beginning. Those extra dimensions of extensibility come at some cost too, as they often mean indirection and cognitive overhead.
We often don't write the same program twice, or even three times, unless it's a really important program or a we just like doing it. Contrast to other fields, e.g. building houses, where we have lots and lots of examples of how to do it and they started to form archetypes. We try to call those design patterns in programming, but they're actually pretty vague and low-level. Can you imagine going to build a house and thinking "yeah, I think I need to use the wood-and-nails design pattern here, and I think I'll do rafters-and-shingles there, with some brick-and-mortar there." Yeah, real specific ideas on how to do it.
by titzer - I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages
It was originablly conceived as a simulation of a distributed system.
Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?
The amazing part to me is that so many were trained and convinced to accept that adopting this simulation could make all programming easier or somehow "better". As if adding complexity would magically lead to simplification.
by jqpabc123 - I studied the history of OOP a while back because I was curious, and I organized what I learned into my personal wiki[1]. From what I remember, there were quite a few different perspectives on it. One view traces OOP's practical ancestry back to Ole-Johan Dahl's Simula. From Alan Kay's perspective, on the other hand, an object was something like a small computer of its own.
The two main lineages of OOP are Simula and Smalltalk. But from what I recall, modern languages actually inherited more from the Simula side in practical terms, while the terminology and philosophy were influenced more by Smalltalk. [1]https://www.makonea.com/en-US/wiki/object-oriented-programmi...
by jdw64