[cmiller1]

It's also a cherry picked example, networking code, of a problem that can be expressed equally as nicely with OO or functions. Now refactor a gui or a game without OO and you'll find the OO version easier to understand or cleaner.

[jlokier]

Fwiw, many games uses a different representation of state and behaviour than standard OO, called entity-component-system (ECS): https://en.wikipedia.org/wiki/Entity_component_system

ECS doesn't represent game objects with standard OO such as classes in C++/Java/C#. You can argue about whether it's still OO in principle, but it's not the kind of OO an enterprise developer would recognise.

[henry_bone]

Is this true for games? I read an article[1] some years ago that pointed out the OO design (with C++ in this case) was bad for performance due to the data not being arranged in a particularly cache-friendly way.

[1] http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal...

[thangalin]

Depends on the problem domain. See the posts on Wizards and warriors:

https://ericlippert.com/2015/04/27/wizards-and-warriors-part...

For card games, OOP is very well-suited (so to speak).

[regularfry]

"Easier to understand" and "performant" are different axes.

[nightski]

There is a fantastic GDC video about Blizzard's use of ECS in Overwatch and how it made it far easier to understand the system due to all of the interacting subsystems.

https://www.youtube.com/watch?v=W3aieHjyNvw

[bitwize]

It's funny because a few years ago I read about how the developers of a game from the same studio -- specifically StarCraft -- ran into the exact same problems I did when trying to write a game in the then-common "bag of subclassed game objects framework" in the 90s. To this day I thank the gods that I chose ECS for my latest game because it has made changes, bugfixes, and extensions of functionality so much easier. To say nothing of more data-driven.

[agumonkey]

Some day I believe that when you think for performance your brain gets things faster because it's not potential benefits or stylistic argument. It's raw perf and everybody seeks that (not at the expense of tech debt ofc.)

[lostcolony]

Well, yes. When in a domain that is heavily noun driven it makes sense to reach for OO. It's just that most domains aren't (hence Yegge's famous article re: nouns and verbs).

[fifilura]

Isn't the point here whether nouns should be able to perform verbs or not?

In a "noun driven domain" you can still disallow the noun to perform the verb.

[lostcolony]

More do verbs -have- to be bundled with nouns (or live second class citizen lives), as that's more what OO requires. Even in functional languages, you -can- have verbs living with nouns (your struct can have a field that is of function type); it just isn't required (or recommended for most use cases).

It's not a question of can they, or should we prevent them, it's 'should it be required?'

It may make sense to require all verbs to be coupled to a noun when your problem domain is mostly modeling nouns, and verbs only describe how those models change and interact with each other. But when the problem domain is mostly process, with nouns being ancillary, it is unwieldy to talk that way. It's why you have so many "ThingDoer" and "Utils" and the like in most OO codebases.

[cmiller1]

Exactly, my take is "use the right tool for the right job"

[Rumudiez]

> Now refactor a gui ... without OO

made me chuckle — that’s my day job! Check out RamdaJS btw