I actually knew a guy that argued that one method per class is ideal. He never quite got that at that point you're really just writing a function with a manual closure (the constructor).
Was it tiny objects or tiny messages, or both? And I wonder how much of the Smalltalk system was made that way. I think at some point your class needs to handle some complexity that isn't easily broken into smaller classes.
But that’s just OOP in general. You can choose a language that defaults to not using OOP-style abstractions, but then people will question why you choose python/node/ruby over a proper language like Go (or whatever else)
The OOP paradigm itself requires rather heavy use of abstraction. You can deviate from those patterns to an extent, you can add more polymorphism if you want to, you can be selective in using some design patterns like DTOs. But most of the complaints I hear about Java would apply equally to most of the C# projects I’ve worked on, because those are just the annoying bits of OOP. I’d agree the Java is a bit more inflexible, but it’s not like the other OOP languages aren’t also full of boilerplate and layer upon layer of abstractions.
- paid per class
- sought to reduce the number of executable lines per class to 1.