The Human Class

If a garbage truck picked up your garbage, delivered your mail, and sold you ice cream, it would be extremely inefficient at doing all 3. But by focusing on just one thing, it is able to do its job well. This is the same with code: if an object or class knows too much, and is too tightly coupled with other classes, it becomes confused, difficult to change, and in most cases ineffective. This is also true in economics: if a country is efficient at producing a certain export and inefficient at producing another, it would be in its best interest to trade with another country that is more equipped to produce that other product. Let us not be fooled to think that humans are some special exception to this rule. We are all classes; objects in a program, and all of us are subclasses of the Human class. We have certain methods, certain properties, and know how to interact with other Human objects, but know very little on how to interact with other classes.

Software design patterns are no coincidence; are not some random discoveries of the best arrangement and structure of code. Nay, they are, inadvertently (as with everything), modeled after nature. Everything we create will always somehow behave according to some universal laws, as everything that exists or we create inherits from the base class PhysicalObject. This world follows excellent design patterns, namely that for the efficient execution of a program, each object should only know what it needs to know and nothing more. Looks like the Human class was just endowed with deep and wonderful introspection abilities. So don’t be disheartened that we are stranded on a lonely planet with vague and iridescent traces of our origin,— the less you know, the more effective you are, and the better you serve the overall program.