Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fifty Shades of OOP

lesleylai.info

Post reply on HN
Print view View original

71–80 of 119 posts

Re: Fifty Shades of OOP

#71

Post by cess11 »

cjfd wrote: post #67
Rochus wrote: post #12

> The industry and the academy have used the term “object-oriented” to mean so many different things. I think we can safely stick to how IEEE defines OOP: the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation (from https://ethw.org/Milestones:Object-Oriented_Programming,_196... ). The article assumes that C++, Java, and Smalltalk impleme…

(1) and (2) sound reasonable enough. What do they mean by "dynamic object generation"?

Runtime instantiation.

From the link above:

"Instead of seeing a program as a monolithic structure, the code of a SIMULA program was organized in a number of classes and blocks. Classes could be dynamically instantiated at run-time, and such an instance was called an "object". An object was an autonomous entity, with its own data and computational capabilities organized in procedures (methods), and objects could cooperate by asking another object to perform a procedure (i.e., by a remote call to a procedure of another object)."

Re: Fifty Shades of OOP

#72

Post by taberiand »

vips7L wrote: post #26
Rochus wrote: post #12

> The industry and the academy have used the term “object-oriented” to mean so many different things. I think we can safely stick to how IEEE defines OOP: the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation (from https://ethw.org/Milestones:Object-Oriented_Programming,_196... ). The article assumes that C++, Java, and Smalltalk impleme…

Object orientism is just encapsulation. It’s the only thing that is required. You can have objects without inheritance and virtual dispatch.

I would say specifically encapsulation of mutable data

Re: Fifty Shades of OOP

#73

Post by 21asdffdsa12 »

ejflick wrote: post #8
jolt42 wrote: post #5

My OO projects were usually in Java with a DB. They all ran afoul of what Martin Fowler calls the Anemic Domain Model. Basically your objects are data-only, so there's no benefit. In addition Spring injection became ubiquitous, and further killed objects with behavior. The only project using a DB and had objects with behavior was an old one that happened to use TopLink as an OR mapping.

> Basically your objects are data-only, so there's no benefit. This makes me wonder why most of us use Java at all. In your typical web app project, classes just feel like either: 1) Data structures. This I suspect is a result of ORM's not really being ORM's but actually "Structural Relational Mappers". - or - 2) Namespaces to dump functions. These are your run-of-the-mill "utils" classes or "service" classes, etc. T…

You are so ready : https://fsharpforfunandprofit.com/rop/

The separation of functions and records..

Re: Fifty Shades of OOP

#74

Post by mrkeen »

> Another criticism comes from functional programmers, who argue that you don’t need to maintain invariants and thus don’t need much information hiding if data is immutable.

Yep

> Information hiding also encourages people to create small, self-contained objects that “know how to handle themselves,” which leads directly into the topic of encapsulation.

This is where it all goes wrong. No module is an island. There's always relationships between different objects/modules/actors in your system.

Who delivers a letter: Postman or Letter? Who changes a light globe, Handyman or LightGlobe?

Things rarely handle themselves - and if they do, it's probably just a pure function call - so why use Objects?

If you start bending over backwards to implement Letter.deliver(Postman p) (and then make it "general" by changing it to IPostman) you'll never stand up straight again. What if I have a List, where does the deliver() code go now?"

If you instead write Deliver(Postman p, Letter l), the opportunities to rewrite/refactor/batch just present themselves.

Re: Fifty Shades of OOP

#75

Post by throwup238 »

jillesvangurp wrote: post #62
Rochus wrote: post #12

> The industry and the academy have used the term “object-oriented” to mean so many different things. I think we can safely stick to how IEEE defines OOP: the combination of three main features: 1) encapsulation of data and code 2) inheritance and late binding 3) dynamic object generation (from https://ethw.org/Milestones:Object-Oriented_Programming,_196... ). The article assumes that C++, Java, and Smalltalk impleme…

The problem with that definition is that modern languages like Rust, Go, and Javascript fall between the cracks here with de-emphasizing things like classes and inheritance while still providing things like generics, interfaces, encapsulation, etc. For example, Javascript was influenced by a few languages, one of which was a language called Self which is a Smalltalk like language where instead of instantiating classe…

> Rust has traits and other constructs. So it definitely has a notion of encapsulation, polymorphism, etc., which are things associated with OOP.

Why do you associate polymorphism with OOP? It’s a pretty universal PL concept. Haskell’s polymorphism is one of the defining features of its type system.

Re: Fifty Shades of OOP

#77

Post by austin-cheney »

> OOP-bashing seems fashionable nowadays.

Yes, and for just cause. OOP was invented in Simula76 (1976) and popularized in C++ (1982). OOP solved a very real problem of allowing applications to logically scale in memory constrained systems by allowing logic to grow independently and yet retain access to memory already claimed by a parent structure. Amazing.

Now fast forward and you get languages like Java, Go, and JavaScript. These languages are garbage collected. Developers have absolutely no control over memory management in those languages. None at all. It really doesn't matter because the underlying runtime engines that power these languages are going to do whatever is in the best interest of execution speed completely irrespective of application or memory size. We just don't live in a world where the benefits offered by OOP exist. Technology has moved on.

The only reason for OOP today is code culture. Its a form of organizational vanity that continues to be taught because its what people from prior generations were taught. Most new languages from the last 15 years have moved away from OOP because it contains a lot of overhead as decoration with no further utility.

Re: Fifty Shades of OOP

#78

Post by stOneskull »

morshu9001 wrote: post #18

OOP basically means Java or things like Java. Not how it started ofc, but that's what it's been for decades. Minus the lambdas and stuff they added relatively later to compromise on OOP.

i think of it as a focus (oriented) on instances of something.. class, type, struct..

Re: Fifty Shades of OOP

#79

Post by infogulch »

rawgabbit wrote: post #13

Muratori traced the history of OOP to the original documents. Skip to the 1:18 mark if you want to skip to his findings. https://youtu.be/wo84LFzx5nI

The craziest thing in that video is realizing that the Entity Component architecture was actually invented for Sketchpad in 1963, but the whole idea was slept on until Looking Glass reinvented it in 1998 for Thief: The Dark Project.
Post reply on HN