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...
The faster you unlearn OOP, the better for you and your software
21–30 of 252 posts
Re: The faster you unlearn OOP, the better for you and your software
#22Re: The faster you unlearn OOP, the better for you and your software
#23Re: The faster you unlearn OOP, the better for you and your software
#24Earlier 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.
Re: The faster you unlearn OOP, the better for you and your software
#25I 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…
Re: The faster you unlearn OOP, the better for you and your software
#26Not 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
#27Should 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.
Re: The faster you unlearn OOP, the better for you and your software
#28BUT, "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
#29I 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?
Re: The faster you unlearn OOP, the better for you and your software
#30> 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…