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

How else would you write software with modular and re-usable components?

^ 64 words.

edit: I assumed that the vast majority of languages typically used in web development incorporated some OO features. I'm interested in what is familiar to you; perhaps that will help people describe something that means something to you.

Your question is sort of odd.

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 :-(

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".

Bonus analogy:

The web itself is object-oriented. You ask a server to return a resource for a given URL; what server it is (Apache; IIS) and how the content is generated (static page; CGI; PHP) is unnecessary for the conversation.

State and behaviour are deeply intertwingled, and object orientation seeks to make programming easier by acknowledging that fact.

Put simply: an object is something with state and behaviour, and an object-oriented programming system is one that makes working with objects easy.

Two ways they do this are information hiding (so you can consider an object a black box and not care about its inner workings) and inheritance (when two objects are similar, you only need to specify the differences between them).

If there isn't an inherent ownership and hierarchy of data and data properties, OO isn't at all necessary. When the structure is well-defined though, which is in many cases, it is the most intuitive abstraction.

Each object wraps up a program. The program's global variables become variables of the object. The program's functions become functions of the object. The public functions are the interface of the object (an interface is the part of a module that interacts with other modules, like the surface of an object). So basically, you have the inside of the object, and the outside (surface).

Think of it as support for the modules that you already wanted, that seem to be naturally present in the problem, or in how you naturally want to divide it up and think about it. That is, use OO to support your conception, instead of a priestly template to mold yourself into. Tools are good slaves, poor masters. If you follow your conception, you will make mistakes - but those mistakes will belong to you, and so you will learn from them.

Using objects for modularity does not work well for every case (e.g. I think parsing works better in the old-fashioned style).

OO is nothing special. There's no wonderful mysterious secret. It doesn't even have a precise definition that everyone agrees on. It's just a tool. Inheritance and polymorphism are grossly overrated, but presented as a quasi-religious AI solution-to-everything - but are useful in some cases (e.g. great for windows/GUIs). There's also a danger of having overly theoretical modules - the "spaces" you mention. Be problem-driven. What does the problem need?

I wrestled with this one in school for a while, because the name is so screwy. What is an object? It's a blob of code. It's a walled off place in your computer's RAM that has variables and functions. It's just a bit of reusable code.

Why is that special? If you've spent your programming life copying and pasting code in a text editor, it's probably not going to be readily apparent. It's pretty easy to reuse code without having to jump through OOP hoops.

In OOP, those reusable bits of code aren't copied and pasted, in the text editor, however. They're reused automatically in memory. When programming in an OOP style, you create one blob of code (an object), and then without touching the original, you can use the object and use it's methods and variables.

You can modify or extend the object, and you're never changing the original object.

For instance, in Ruby. Everything is an object. Even integers are objects and strings are objects. That is, every time I use the integer "5" in my code, I have all the methods from the Integer class available at my finger tips.

So, I can do something like this:

   5.next  #this returns 6
   5.next.next # this returns 7

   5.times do |i|
      print i, " "
   end
      #produces
   0 1 2 3 4

The same goes for strings. In Ruby, every string is automatically given all the methods from Ruby's String class for free. So, you can do stuff like this:

   "hello".capitalize  #this returns "Hello"
   "HELLO".capitalize  #this returns "Hello" as well

   "hello".empty?  #returns false
   "".empty? #returns true
   "hello".length #returns the length of the string
   "hello".reverse   # returns "olleh"

There are lots of other things that you can do with OOP, this is just a taste of what Ruby does. I think the key to learning OOP is to learn it in a language that uses it very elegantly like Ruby, or even Python. If you're trying to learn OOP in PHP or Perl or Java, you're in for a rather difficult time, because there's so much other stuff that gets in your way.

But, if you learn OOP in a langauge that uses is really well, you can isolate some of the OOP concepts, and you can go back and use them in your language of choice if and when you need to.

OOP certainly isn't the be all end all of programming paradigms, but it's well worth your while to learn if you're going to be writing code for a living. It's one way to reuse code. It's certainly not the only way.

Going much deeper gets controversial; there are many, many elaborations on that theme, each of which you can find a language that implements it and a language community that considers it anathema.

Not all objects are alike. Smalltalk is "pure"; Python and Ruby mostly "just work"; C++ is very complicated.

No programming paradigm can save you from under-specification. You need a very good description of your desired behavior before you start coding.

Smalltalk is a great start. If you want to read more, this poorly named book is by far the best I've read on the topic: http://www.amazon.com/Software-Development-Principles-Patter...

[1] http://en.wikipedia.org/wiki/Programming_in_the_large

abstraction, hierarchy, modularity, encapsulation

manage complexity reduces resistance to change over time

design patterns give best practice advise