So jumping back to OO design principles, how do you define "one" thing?
For instance, if I'm attempting to use a database via JDBC (because this was before I learned of ORM), does one thing mean an object that performs CRUD on the database (it only handles queries against that one database, basically), or does one thing mean a separate object for Creation, Read, Update, and Deletion? Or some other combination?
The way I traditionally did it was create an interface for Database connections that defined the CRUD methods (create(Object newObj), get(Object toGet), etc), and then have a separate implementation for each database (if, for instance, I wanted a stub database or a connection pool over direct connection, Oracle vs Postgres vs MySQL, etc). So if I am accessing three databases, I have three objects. And if I accessed them concurrently (e.g. I needed the data to be cloned across all of them), I might have a Database Manager object that contains those three db objects and sorts out the logic appropriately.
For web services, I would do something similar. We had a REST API that used JSON or XML, so I created a separate class for each request object (Like user, some data point, a collection containing references to both, etc), and implemented a method for each REST function (The HTTP commands GET, PUT, UPDATE, DELETE). Then when we manipulated data, we went to a manager object who held all of the service request objects.
In case you didn't gather from objects within objects, I was always taught "Make main as simple as possible, and encapsulate objects as much as possible. Ideally, main should use as few objects as necessary, within reason."
I think that's better than God objects, but not sure if that fits your definition. How do you view it?