Hacker News Reader

Comment by shasta | Hacker News Reader

No, please. OOP does not have a monopoly on abstraction, encapsulation, modularity, etc. If you are focused on "state transformations and encapsulated abstractions", you're not necessarily writing OOP.

View on HN

From the article: "You can completely implement data abstraction, encapsulation, messaging, modularity, polymorphism and (to a limited extent) inheritance without using an object structure."

So the author agrees with you. So please, no "No, please."

Yes but he wrote that to support his view that abstraction+polymorphism+encapsulation=OOP even when you are not using object structures: "The first sentence says that you must use object data structures to write OOP. That's blatantly wrong. You can completely implement data abstraction, encapsulation, messaging, modularity, polymorphism and (to a limited extent) inheritance without using an object structure." I don't much enjoy arguments about semantics but I personally feel his definition of OOP is way too broad to be useful. I am tempted to believe it was called tempted to believe it was called Object Oriented Programming for a reason.

Someone downvoted you, so I think we should elaborate that further. I think you mean the right thing, but cited the sentence which only strangely says that OOP can be without objects (which alone doesn't mean that the focus on on "state transformations and encapsulated abstractions" is an OOP-thing). He wrote later on:

>But if you're focusing on state transformations and encapsulated abstractions, you're writing OOP.

So he is indeed saying that you can write OOP without objects, but also that the focus on "state transformations and encapsulated abstractions" is OOP.

I think that this is a really strange way to think about OOP.

edit: that was prior to an edit of the comment i respond to.

Thanks. I edited my comment to try making it more clear. Another very important point that was mentioned here is that programming paradigms are not mutually exclusive. The author of this post seems to create a false dichotomy between procedural and OO programming.

That wasn't my intention at all. I'm sorry if that's how it came across. It's just that I got tired of seeing people refer to code as procedural because it uses functions, and refer to code as OOP because it uses classes. I was just trying to point out that the approach is different from the tools that you use to implement the approach...

I think it's true that you can encode OOP objects in any number of languages, but OOP really is about the objects. If your encoding isn't little bundles of methods, it's not OOP, even if it uses the other general techniques you've listed: abstraction, modularity, etc.

I agree, but I would state that it's easier to do encapsulation and modularity in OOP than procedural style.

I prefer the functional method, though. In my opinion it's much easier to understand and much more flexible, but many programmers dislike that flexibility.

"Procedural style" is a strawman though, corroborated by years of people thinking C and FORTRAN are the only procedural languages out there.

Most OOP languages are still procedural and many "traditional" procedural languages provide support for data abstraction.

The syntactical sugar provided by languages that support objects is the only real improvement over something like ADTs, but I think it's a noteworthy improvement.

> No, please. OOP does not have a monopoly on abstraction, encapsulation, modularity, etc.

Exactly. One of the best resources on those things that I've read/watched is MIT's SICP (both books and video lectures). And it is about everything else than OOP.

Abstraction, encapsulation and modularity are bigger than any programming paradigm. They are orthogonal to OOP, et al., you think about them separately. Moreover, they transcend the programming itself, and serve as one of the most basic mental tools humans can use for everything in their lives.

As I recall in my reading of SICP, one of the first big chapters actually hints towards OOP but has you designing it from the ground up. They never call it OOP, but it is heavily leaning towards it; they just happened to set it up using closures (see relevant humorous quotes below). I am referring to the stuff about setting up a virtual function table that switches to the appropriate method based on the type of the data so that multiple developers can write their own way while honoring agreed interfaces/protocols.

"Objects are a poor man's closures." -- Norman Adams (?)

"Closures are a poor man's objects." -- Christian Queinnec (?)

SICP walks through a number of paradigms, including OOP. OOP is a pattern than allows abstraction, encapsulation and modularity in specific ways. Other patterns or paradigms may provide these features in different ways. You would create different abstractions in an OO pragram than in FP, even if you were solving the same problem. So abstraction is definitely not orthogonal to programming paradigm.

Reply on news.ycombinator.com