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

    class Animal
      def initialize(options = {})
        @type = options[:type]
        @name = options[:name]
        @legs = options[:legs]
        @noise = options[:noise]
      end
  
      def type?
        return @type
      end
  
      def name?
        return @name
      end
  
      def noise?
        return @noise
      end
  
      def legs?
        return @legs
      end
    end

    dog = Animal.new(:type => "Dog", :name => "Pipin", :legs => 4, :noise => "Woof")
    puts "#{dog.name?} the #{dog.type?} has #{dog.legs?} legs and goes \"#{dog.noise?}!\"\n"

    cow = Animal.new(:type => "Cow", :name => "Kevin", :legs => 4, :noise => "Moo")
    puts "#{cow.name?} the #{cow.type?} has #{cow.legs?} legs and goes \"#{cow.noise?}!\"\n"

Output:

    Pipin the Dog has 4 legs and goes "Woof!"
    Kevin the Cow has 4 legs and goes "Moo!"

…a simple class which turns the dog and cow variables into objects, like small boxes with information referring to that animal. By the way — I hope code isn't classed as words, else I've failed to describe it in under 64! :P

You do object oriented analysis of your problem domain. This results in a set of objects. Then you design a class hierarchy for your objects (base, child etc). Trick is to realize objects themselves do not accomplish project purpose, they just have behaviors. How you play these behaviors decides what the application finally does.

I am surprised to see no one has mentioned the analysis part. To identify and abstract (like pulling oil well from well) "classes" of objects in your problem domain is the core proponent of OO programming. This is the basis for all data hiding and reuse.

The OO design principles (not design patterns) tell you how to go about your class design.Check this link: http://www.objectmentor.com/resources/publishedArticles.html

Once you have completed all your classes, you will realize how easy (and natural) it is to script the actual business logic of your application - more or less like a movie: while all the actors have their identities, the "script" tells how they interact and decides the movie experience.

Object oriented programming is definitely the way to go. OOP came about as a series of incremental improvements made to procedural programming.

First came the idea of segmenting functionality into more manageable 'building blocks' called modules that worked together to provide the functionality of the entire system.

Next came abstract data types which incorporated the idea of treating a set of data and the logical operations on that data as a single unit. Different ADTs were naturally stored in separate program modules.

Next came the idea of information hiding, or separating out a module's interface from its internal structure. Information hiding serves two major purposes: a) allowing a module implementer greater freedom in changing how a module works without distrubing clients of the module and b) making it so a user does not have to understand everything about a module in order to use any part of the module.

Having figured out modularity, abstract data types, and information hiding, programmers then turned to the task of how to better reuse code. Structured programming reduced the amount of duplicate code in a system, but still had quite a bit of code with only slight differences. Inheritance was developed as a mechanism to deal with this problem. Basically ADTs, now called classes, were arranged in a tree structure with the most general classes at the top and the most specific classes at the bottom. Several additional mechanisms were added to the system that allow child classes to have access to their parent class definitions and for runtime polymorphism.

More than 64 words, I know. However, because seeing how OOP evolved out of the solutions to procedural programming problems helped me to understand it and see its value, it seemed like it may help you as well.

Thanks for the book link!

Others have done well here, but I'll give it a go too, in procedural terms.

Objects are just a style of programming. As our program begins to process different types of data, we begin to see that some data always goes together and tends to hit certain branches of code together. This is because the code and the data together form an implicit model of how a particular kind of data should be handled.

Object orientation makes this explicit. We can store a little namespace of data in an object, and also give it a way to find the right code to run when it receives a 'message'. Then we can start to think of our program as a cascade of 'messages' between objects.