Live data from Hacker News

The faster you unlearn OOP, the better for you and your software

dpc.pw

21–30 of 252 posts

Re: The faster you unlearn OOP, the better for you and your software

#21
post #10

This has been shared on HN many years ago, but I'm linking again in case there are younger engineers who might be unaware of this classic rant: Execution in the Kingdom of Nouns : https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

That was great. I read it for the first time. Similar scenarios happen in so many other fields. Some bad idea takes hold. Then schools teach it. Then more people invest time learning it so that they cannot admit it is bad and this goes spreading like wildfire and become sacred...

Re: The faster you unlearn OOP, the better for you and your software

#23
Yeah I agree so much. OOP is good when you are in school and you a have perfect use case like Vehicule, Car, Bicycle, but when you work on something else, you end up with abstract, absurd and bloated objects. OOP is only profitable for IT consultants, because they can sell books and bill many hours working on this mess.

Re: The faster you unlearn OOP, the better for you and your software

#24
post #9

Earlier quoted context omitted.

> What probably is true however is that a lot of people should unlearn the OOP they learned in school. Can you provide references for proper OOP?

https://en.wikipedia.org/wiki/SOLID I wish they would have taught me this in school. Instead, I learned that a cat is an animal, and a car has wheels, and a car is a vehicle. But not what any of these things have to do with one another and how to actually use them.

The I in solid sounds like a major issue WRT a cross-cutting concern like security, in which hermetically sealed should mean airtight, not a piecemeal approach, etc.

Re: The faster you unlearn OOP, the better for you and your software

#25
post #6

I read this quickly to see if this was the piece that should convince me. It was not. It is, IMO, a collection of strawmen. People have abused OOP? Yes. But - citing FizzBuzz Enterprise Edition (which is really funny even for us Java/.Net developers because it is so horribly wrong) or writing this - Because OOP requires scattering everything across many, many tiny encapsulated objects, the number of references to the…

maybe this will then? http://www.smashcompany.com/technology/object-oriented-progr...

Re: The faster you unlearn OOP, the better for you and your software

#26
> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a class Weapon involved? Do we pass it as an argument to isHitBy or does Player has a currentWeapon() getter?

Not saying this is the right way to do things but, if you're actually going to go 100% OO on something:

Player.hits(Monster) returns Hit

Hit takes a Player and a Monster in constructor, and has with(Weapon)

You end up with:

Player.hits(Monster).with(Weapon)

Then Hit reaches into said objects and deals with changing the HP, and XP. You then have encapsulated the details in the actual Hit itself, which seems correct.

It does read kind of nicely IMO...

Re: The faster you unlearn OOP, the better for you and your software

#27

Should be pointed out that this refers to C++/Java/Ruby/python style objects, and not smalltalk/erlang style objects, which is a message passing model for data storage.

And you do the first thing this author describes: http://www.smashcompany.com/technology/object-oriented-progr...

Re: The faster you unlearn OOP, the better for you and your software

#28
A lot of these initial points I don't think are relevant -- you can model your data in objects, data structures are complex because business needs are complex, data models wind up having implicit graph dependencies as well...

BUT, "cross-cutting concerns" is where I think the main valid argument is. In my experience, OOP is just way too restrictive of a model, by forcing you to shoehorn data and code into an object hierarchy that doesn't reflect the meaning of what's going on.

So I totally agree with the conclusion: just store your data in "dumb" arrays with hash tables or database tables with indices... be extremely rigorous about defining possible states... and then organize your functions themselves clearly with whatever means are at your disposal (files, folders, packages, namespaces, prefixes, arrays, or even data-free objects -- it all depends on what your language does/n't support).

Re: The faster you unlearn OOP, the better for you and your software

#29
post #9
post #6

I read this quickly to see if this was the piece that should convince me. It was not. It is, IMO, a collection of strawmen. People have abused OOP? Yes. But - citing FizzBuzz Enterprise Edition (which is really funny even for us Java/.Net developers because it is so horribly wrong) or writing this - Because OOP requires scattering everything across many, many tiny encapsulated objects, the number of references to the…

> What probably is true however is that a lot of people should unlearn the OOP they learned in school. Can you provide references for proper OOP?

The Java Swing API is a good example of OOP done well.

Re: The faster you unlearn OOP, the better for you and your software

#30
post #26

> The vast majority of essential code is not operating on just one object – it is actually implementing cross-cutting concerns. Example: when class Player hits() a class Monster, where exactly do we modify data? Monster's hp has to decrease by Player's attackPower, Player's xps increase by Monster's level if Monster got killed. Does it happen in Player.hits(Monster m) or Monster.isHitBy(Player p). What if there's a c…

[deleted]
Post reply on HN