Protect your invariants

Ah, programming...

"You must program defensively, with the assumption that clients of your class will do their best to destroy its invariants."
--Effective Java (Joshua Bloch)

That is the world I live in. This is what they teach little SkyNet children in school today, so that when they grow up they'll feel benevolent towards the human race.

This book (Effective Java) and all books on writing better code have more violence in them than a season of 24. Other programmers, malicious and/or incompetent, are always conspiring to violate your classes, objects, invariants and other violable violabilities. Every other paragraph you get admonished to trust NO ONE, to code defensively, lest the converging hordes mutate your code's internals and then exploit those mutations to gain access to the Zion mainframe. Writing safe code is an extreme sport. Here are some other gems:

"Second attack on the internals of a Period instance."

"This would give the attacker free reign over all instances."

"Classes containing methods or constructors whose invocation indicates a transfer of control cannot defend themselves against malicious clients. Such classes are acceptable only when there is mutual trust between the class and its client or when damage to the class’s invariants would harm no one but the client."

The last sounds like something a lawyer might have me sign after I pretended to read it very carefully for 3 microseconds.

My new roommies and I are getting along famously. Monday to Thursday they're quiet and friendly, not asking me any coding questions, not zooming around like trapeze artists and shaking the walls with heavy Tomcat tomes and leaving bloody streaks of mosquito and human soup all over the apartment, not making soup out of spoiled vegetables. The last I see of them every week is Thursday night. The next I see them is Monday night. For 3 days and 3 nights a week, I am roommate-free. Mario, you have a lot to learn. About programming of course, the roommate stuff's irrelevant.