That can be OO. I think in general object inheritance is pretty unfashionable, and while it occasionally does solve problems, it's rarely the first thing to rea

That can be OO. I think in general object inheritance is pretty unfashionable, and while it occasionally does solve problems, it's rarely the first thing to reach for. It can be useful in library code though, were you might otherwise end up with significant code duplication. Overall the move is toward having data classes (basically records) that are light on logic, as well as logic classes that are light on data. I don't think pure functions are necessary or in many cases even desirable in Java, as it largely lacks the tools required for this not to be crippling; although I will concede that any state changes typically ought to remain local. Factories can be pretty good for separation of concerns, although in many cases it's been superseded by dependency injection frameworks in modern java. I still reach for it every one in a while though. Also fwiw, game development is a bit of a weird case. It usually reaches for design patterns like ECS. This is in part a data locality optimization, since you can just iterate through all components in a "straight line", but mostly it's for the sake of malloc, which generally doesn't deal well with billions of objects being allocated and deallocated over and over randomly with growing fragmentation as a result. There are many types of programs this or other game dev patterns aren't suitable for.