Of course, my Socialist-Totaltarian regime has a multi-pronged approach to addressing this:
1. All children will be confiscated from their parents and birth and raised in sanitary state-run facilities. Processes will be put in place to insure that no violent or sexual abuse of the children will be possible.
2. All children will be reversibly sterilized at puberty. Anyone wishing to breed will be required to pass a parental competency test.
3. For anyone unable to pass a parental competency test, the state will choose a partner based on specially-designed algorithms designed to insure the happiness of the couple.
4. All religion will be illegal except for the state-run one, which will involve Smurfs. Non-Smurfy behavior will be dealt with harshly.
I predict that my society would reach the "Utopia" stage within three generations.
The deeper I get into OO, the more I start to understand that getters and setters are just as bad as exposing members of your object to the public. If you have to expose the working data of your objects that regularly, you're not working at the correct level of abstraction. A lot of the coding style I see in java is geared toward "I'll need this in the future" or "I have no idea what I'm going to need in the future, so I'll make this bit so generic that it can do anything." Both of these habits are incredibly bad practices that have been superseded by refactoring. A lot of inexperienced programmers think that once they've designed and coded some shit, it's carved in stone forever after that. I've seen countless cases of companies wringing their hands and working around problems in code that can be fixed with trivial changes to program design and adjustments to half a dozen or so objects.
I have much the same problem with introspection as I do with getters and setters. People say "Oh we have to use introspection because someone might want to write something new and drop it in there and we don't know how it'll behave!" Again, that's limiting your current design because you don't know what will happen in the future. Design a solid and maintainable interface NOW and if you need to change it in the future, change it in the future. Don't build some twisty maze of introspection that delegates any real work 10 objects away from the functions that initiate it just because someone in the future might want to write something else! And quite frankly, no one EVER WILL, because that would require knowing implementation-level details of the ball of shit you rolled up to support that.
All that went away when I switched to Longmont's municipal service. System wakes up, internet's instantly accessible.
I tried CentryLink's 1MB DSL prior to Comcast but the latency was always shit with it. If my room mate was doing anything, I could see ping times in the 1 second range.