I like small objects. An object with one public method and a couple of fields is perfectly fine. You can name it precisely, test it in isolation, and understand it without loading half the system into your head.

The trade-off is real: small objects reduce local complexity at the cost of global complexity. More files, more connections, more things to navigate. Large objects do the opposite. One file, everything in one place, but you need to hold all of it in your head to change any of it.

Here's why I pick small objects anyway: context falters over time. You understand UserService today because you wrote it last week. In six months you won't. The key to sustainable development is being able to recoup context quickly, and that's easier when the problem is broken into pieces that match the domain. RegistrationHandler. EmailVerifier. WelcomeNotification. Each one tells you what it is. That's not just a code pattern, it's part of a larger approach: split the problem down, compose solutions up.