Ask HN: can you summarize OO for me in 64 words or less?

I've only been writing code for so long, while I grew up designing web-sites, it really doesn't count; so, as of now, I've been invested in programming for more than four years but have never had the courage or foresight to write something in OO. However, for the past couple weeks I've been pouring myself into the OO textbooks, yet I still don't feel reassured in it's value. So, as of today I can speak OO, since I know all the jargon, but I still can't muster up the courage to write an application that seems practical to me, which is where my problem lies. I'm also no software-engineer, but I've come to face the facts that my vision of building tools/programs/output is flat; so please, inspire me with your wisdom from 30,000 feet above, metaphors, philosophy, and expression by comparison is welcome.

EDIT: I guess the origin of my writers block in doing something in OO is that I don't really feel like I'm handling real data. I feel like I'm defining and declaring spaces as I see fit, thus leading me down the path of this pseudo/pretend file-system while ignoring the platform I'm really working on. Please prove me wrong.

modular and re-usable components is not really OO specific tho.

It's amazing that you've been able to spend four years coding without having to work on code that used object orientation. If you collaborate with others, you'll learn many useful as well as useless coding techniques and will be come a much better programmer yourself. So pick apart a few of your favorite open source projects; I'll bet you find plenty of practical object-oriented programming.

^ 64 words.

OO property 1: You're in a house. An appliance is a physical object that does something. A fridge is an appliance that keeps things cold, a toaster is an appliance that makes things warm, a blender is an appliance that blends things. If you change the definition of an appliance to be "a thing in a kitchen that does stuff," all of the other things that I've used "appliance" to define will still continue to be what they are, but their "scope" will be different.

OO property 2: You've got a cookie cutter and dough. The Cookie Cutter is the constructor, it makes a object the shape of the cookie cutter insides. It looks like the shape of the cookie cutter, it smells like that shape, it _is_ that shape; but it's only really a copy of that. Which is why people have issues with "equals." Equals can refer either to having the same value, or actually being the same object.

There are other really nice analogies (is-a vs has-a and children vs people), but I hope that my analogies make sense to y'all!

EDIT: the above is 181 words, sorry :-(

OO programming is great fun!

Take a real world model and simulate it with some OO code in your favorite language.

For instance, model an elevator system in a large apartment complex. Model the buttons, the elevators, the call buttons, the system the decides what elevator goes to which floor, etc. Those are all objects interacting with each other in some form.

You can't hardly screw up. Mastering OO takes many years, so just get out there and starting hacking around.

BTW, you can read all you want about driving a car, but until you sit down in the driver's seat, it isn't going to "click".