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

91–100 of 119 posts

Re: Fifty Shades of OOP

#91

Post by ChrisMarshallNY »

mrkeen wrote: post #69
vjvjvjvjghv wrote: post #10

Earlier quoted context omitted.

I think the biggest mistake was to teach inheritance as a main feature of OOP. I have done some stuff with inheritance but it was very specialized and it would have been fine without inheritance.

But OOP needs something to distinguish it from the rest, otherwise it's just P. Do people honestly think other languages don't do whatever definition OOP has today? Encapsulation & polymorphism? Message-passing & late-binding? Inheritance is the one thing that the other languages took a look at and said 'nope' to. (Also, the OOP texts say to prefer composition anyway)

If they use protocols with defaults (traits, interfaces, etc.), then they have inheritance.

What they don’t get with protocols, though, is polymorphism. I think a lot of folks confuse them.

I wrote about an odd bug that I encountered, from protocol defaults: https://littlegreenviper.com/the-curious-case-of-the-protoco...

Re: Fifty Shades of OOP

#92

Post by Jtsummers »

NoSalt wrote: post #83

> "OOP-bashing seems fashionable nowadays." Really, is this happening??? From the job listings I have seen, this is not so.

Job listings (written by potential employers) and programming culture are distinct things.

Bashing OO has been popular since I was in college 25 years ago, but it's also been part of nearly every job I've had except a few embedded systems (Fortran, C).

Re: Fifty Shades of OOP

#93

Post by austin-cheney »

franktankbank wrote: post #81
austin-cheney wrote: post #77

> 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 Jav…

I don't follow. Java is mega object oriented. Can you even write a standalone function? I get the impression you are focusing on a single aspect of OOP that has gone out of fashion without realizing by and large every application developer is doing OO development 99% of the time.

Nonsense. JavaScript developers will also tell you everything is framework. What these things really mean is that the person making the statement has only 1 perspective and so everything they see matches the only single lens through which they view the world.

All definitions of OOP in common use include some form of inheritance. That said I do OOP 0% of the time in my programming. Most developers I have worked with never do OOP unless the given language or employer forces it.

Re: Fifty Shades of OOP

#94

Post by vips7L »

taberiand wrote: post #72
vips7L wrote: post #26

Earlier quoted context omitted.

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

Lots of modern OO uses immutable data.

Re: Fifty Shades of OOP

#95

Post by vips7L »

ejflick wrote: post #88
21asdffdsa12 wrote: post #73

Earlier quoted context omitted.

You are so ready : https://fsharpforfunandprofit.com/rop/ The separation of functions and records..

I've read his book "Domain Modeling Made Functional" without much prior knowledge of F#. He provides some compelling examples and some of it ended up inspiring how I write OO code. F# seems cool but it felt like it was close to being extinct.

Honestly one of the best books I've read about programming. It's inspired me to try the language out just for fun things, think I'm going to use it for Advent of Code this year. I think it does benefit from being interoperable with C# so you can use it where it makes sense and still have C# to fall back on. Kind of like Scala/Kotlin with Java.

Re: Fifty Shades of OOP

#96

Post by vips7L »

elric wrote: post #40
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.

Why did you create an anemic domain model? Java has had "data carriers" in the form of records for a while now. Immutable(ish), low boilerblate, convenient. record User(String name){} Records are great when doing more "data oriented programming".

I don't think anyone sets out to make an anemic domain model, it just happens. Lots of developers start with POJO's for JPA models and then never advance them into being full fledged objects when the requirements develop.

Re: Fifty Shades of OOP

#97

Post by bccdee »

lukan wrote: post #63
ffsm8 wrote: post #59

Earlier quoted context omitted.

> I don't see how it could be expressed in a different way without loosing that clarity. What value does the inheritance provide here? Can't you just use a flat interface per usecase without inheritance and it will work simpler with less mental overhead keeping the hierarchy in mind? Explicitly your graphic library sounds should be fine to have the interface DisplayObject which you can then add default implementation…

That would be way, way more verbose for everything. Every display object has a x y width and height for example. And there is basic validating for every object. Now a validate method can be conposited. But variables? Also the validating, there is some base validating every object share (called wih super) and the specific validating (or rendering) is done down in the subclasses. And even for simple things, you can com…

> Every display object has a x y width and height for example.

Intuitively¹, I feel like this is something that should be separated out into a BoundingBox object. Every component that needs a bounding box satisfies a small `HasBoundingBox { getBoundingBox(self) -> BoundingBox }` interface. Maybe there's a larger `Resizeable` interface which (given a type that satisfies `HasBoundingBox`) specifies an additional `setBoundingBox(self, bb)` method.

You don't end up with a tidy hierarchy this way, but I'm not sure you'd end up with a tidy hierarchy using inheritance, either. I feel like this sort of UI work leads toward diamond inheritance, mixins, or decorators, all of which complicate inheritance hierarchy. Flat, compositional design pushes you toward smaller interfaces and more explicit implementations, and I like that. The verbosity can be kept in check with good design, and with bad design, the failure mode leans towards more verbosity instead of more complexity.

For more complicated features, composition & interfaces can make things more verbose, but honestly I like that. Inheritance's most powerful feature is open recursion (defined in the linked article), and I find open recursion to be implicit and thorny. If you need that level of power, I'd rather the corresponding structure be explicit, with builders and closures and such.

[1]: Not saying this is correct, but as someone who prefers composition to inheritance, this is what feels natural to me.

Re: Fifty Shades of OOP

#98

Post by bccdee »

pjc50 wrote: post #48
LukeShu wrote: post #17

Earlier quoted context omitted.

Inheritance is just the unnecessary coupling of composition and polymorphism.

Delegation is a very useful part of composition. Almost all OOP languages have two techniques to delegate some methods to another object: - manually write a bunch of forwarding methods and remember to keep them updated, or - inheritance.

To be fair, the compiler generally forces you to keep the forwarding methods updated. It can be irritating, but there's little risk of forgetting in a statically-typed language.

Manual forwarding also operates as a forcing function to write small interfaces and to keep different pieces of logic separated in different layers, both of which feel like good design to me. (Though I'm not saying I'd turn my nose up at a terser notation for method forwarding, haha.)

Re: Fifty Shades of OOP

#99

Post by bccdee »

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.

Languages like Go and Rust have module-scoped visibility, though. This is definitely encapsulation, but I wouldn't call it inherently OO.

Re: Fifty Shades of OOP

#100

Post by bccdee »

vips7L wrote: post #94
taberiand wrote: post #72

Earlier quoted context omitted.

I would say specifically encapsulation of mutable data

Lots of modern OO uses immutable data.

A lot of the underlying intuition behind OOP is expressed as "cells exchanging messages like an organism" and such, and I think that implies the distribution of state among a variety of small, special-purpose state-managers. More functional variants of OOP where state is managed centrally are a meaningful shift away from traditional ideas of OOP, and I think calling them both equally OO glosses over that shift a little.
Post reply on HN