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.

    A Smalltalk object can do exactly three things:
    Hold state (references to other objects).
    Receive a message from itself or another object.
    In the course of processing a message, send messages to itself or another object.

O.O is useful to you because it makes it easier to understand your code, especially if your code base becomes very large. You can look at your code object by object rather than line by line.

O.O is useful for group projects because each member can code an object and the algorithms behind its methods individually. It also makes it easier to swap different functionality in and out.

Finally, O.O also promotes good coding practices, like reusing existing code and writing documentation. It also makes you think about your code's structure, which is crucial to keeping your code maintainable, upgradeable, readable, and reusable.

For me, writing good O.O code is a something that I learned after writing a lot of bad O.O code. So there's no reason to delay - write it and you'll see.

"Programming by making things that can be interacted with in different ways"

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.

A lot of objects have no real-world equivalent (they are not "objective", I kill myself), but that doesn't make them useless.

Objects are an odd mash of concepts: inheritance, interfaces, global data with limited access, encapsulation, memory management. The object model will differ from language to language, and your objects will look different depending on what features you use.

You can program in a pretty object-oriented way in straight C. Some languages bend more easily to these ideas than others.

http://www.planetpdf.com/codecuts/pdfs/ooc.pdf [pdf]

I have sometimes thought the same thing. There are ample explanations of the use of OOP put in terms of stuff like, poodle inherits from dog, which inherits from mammal etc. or a car could be represented as a series of objects interacting with each other, the engine, gear box etc. This is all perfectly fine and super easy to visualise. But the stumbling block for me is sometimes when I try to turn these ideas to something that's actually useful. Abstact concepts that indeed do not always have a neat corelation in the real world.

If anyone has some tips on how one can begin to develop a clearer method for modeling more abstract concepts in OO, I'd love to hear them.

"All of these objects do very similar things. I don't want to have to write these functions over an over again if they're so similar..." and inheritance was born.

Most OO concepts are about writing and seeing less code. I think the best way to grasp OO is to ban ctrl+c for anything longer than 2 lines. It really forces you to think about structure and code reusability, which is what OO is all about.

Most articles carry some example to go with the concept being explained.

Regarding inheritance, I once had a conversation with a "application architect" who advised staying away from inheritance until you fully grok it, because it's easy to paint yourself into a corner with it (he then disappeared before I could question him further). The only issues I could think of at the time was stuff like say you have a bird class which contains a "fly" method, with duck and emu child classes (now I'm using the dodgy animal examples :P), the duck and most other birds should be able to fly, but the emu and some others should not. What is the better practice way of dealing with this issue? And what other adverse issues can arise when using inheritance?

It has been recommended to me in the past that when it comes to systems that require more abstract objects, this is where researching design patterns would assist. However, pretty much all the design pattern literature I can find is not directly related to my current language of choice, Ruby. I can find lots of stuff talking about design patterns in Java and whatever else, which still provides some utility, but is there any books/articles that anyone can recommend on design patterns etc. using Ruby?

  large automaton
  complexity is too high
  for my meager brain

  small automatons
  your prison cells will prevent
  intertwingling

  you aren't alone
  use the pneumatic tubes for
  sending messages

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.

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.

    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"

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

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

People with advanced OO skills use clever techniques to write interesting programs. For example, sometimes we want to give a class (technically, "an object of the class") to other programmers without letting them know which class we gave them. To achieve this goal, we give them another class with a function to generate objects of the first class without telling them which one. If you have trouble following, don't miss the helpful diagram: http://en.wikipedia.org/wiki/Image:Abstract_Factory_in_LePUS... An award-winning book of twenty-three such techniques is required reading for good OO programmers.

So your gut feeling is right.

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?

What can you do with a string? Set it, save it, match it. What properties does it have? Length, value, encoding, language, etc.

Object Oriented software is built with methods and properties.

(Do I get extra credit for using 64 words exactly?)

Earlier this was a garbled mess, full of functions like custID = addCustomer(form_info) updateAddress(custID, "Billing", some_args) and so on ...

On the flip side, OOP is trickier (b/c of encapsulation) to debug esp when object model gets complicated. In terms of programming the only way to do it better (and this is frankly v debatable, esp when you consider management of DB connections and API administration etc) is "LISP style", where you effectively concoct a DSL for your specific app.

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.

Are you sure you're doing it right? Maybe your design is too abstract. Beginners to OO often overdo generality and they especially overdo inheritance. If your only goal is to handle a few operations with one particular filesystem, there is no shame in writing well-commented procedural code.

OO is not in itself a way of solving problems. It's supposed to model your problem so you can change different parts independently. So, for instance, in code modelling a filesystem, you can have code that performs a 'read()' and gets data but doesn't have to know where the blocks are or if it's talking to a pipe or an inode.

I struggled with understanding OO for a long time too. In retrospect, one of my biggest problems was that I simply hadn't worked on systems that were large enough. I could fit all my programs in my head. When you can't fit the whole program in your head, you need strategies for knowing (not just guessing) exactly how many things your code will affect. So the idea of an object as a sort of contract emerges. You want a read() of 12 bytes from an inode to work just the same as a read() from a pipe. So you devise a sort of 'contract' that the general class of "FilePointer" has to adhere to, and then you try to fulfill that in InodeFilePointer and PipeFilePointer. Make sense?

Where OO really takes off is in collaborating with other programmers.

Some languages are so in love with OO, they decree that everything is an object. This can be annoying, but it's also helpful in the long run. If you're strict about it, it's impossible to write code with weird side effects or that relies on mysterious globals to communicate information. Because all state changes are captured in the object, and the object also carries around a notion of how to modify itself, you can write a new kind of object and be very sure it will Just Work.

Once we have divided responsibilities this way it becomes possible to change our models in one part of the code without changing them in other parts. (In procedural code we might have to change the function signatures of just about every procedure in the codebase.) It's even possible to add in 'Mock' objects that just test the behaviour of other objects.

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

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

Object-orientation is fundamentally just a way of organising programs.

In most non-OO programming, you've got a bunch of data, and a bunch of procedures that can operate on the data. The two are defined and considered somewhat separately, though they must fit together.

In OOP, a kind of datum and the operations on it are instead designed, defined and used together, as essentially linked.

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

Procedural programming is like a recipe- you program a sequence of instructions and while there can be if/then, loop and other logic constructs, it still runs like a "choose your own adventure" book. Since you have an imperfect view of the world and how requirements will evolve and you're providing what are essentially sequential instructions, it's brittle and unforgiving to unanticipated requirements.

OO is less about writing instructions and more about creating a representation of the world (or at least the aspects you care about) as objects and having them interact with each other to achieve things. Because you're modeling the entities involved and having them interact rather than imposing a prescriptive set of instructions from above, it's cleaner and more resilient to unanticipated requirements.

Granted it's overkill to use OO for simple tasks when a script will suffice. But if you're building a system that involves interaction of different entities and will need to be adapted & maintained it will almost certainly be more productive to use an OO approach. Btw, I found this book provides the most concise and useful primer on OO I've seen: http://www.amazon.com/Object-Technology-Managers-David-Taylo...

sean

There is only a small step from writing stuff like this :

FILE* ofile = fopen("test.txt","w"); fprintf(ofile,"%s %s %s",1,2,3); fclose(ofile)

to writing code like this :

FILE ofile("test.txt","w"); ofile.printf("%s %s %s",1,2,3); ofile.close();

So. you've grouped some data and some code together so it's easier to work with it. This is just the first step though, but the small objects you make will be very useful. You can make a small library of useful objects that way : file, string, date, time, point, rectangle, socket, regexp etc.

Also, you don't have to make the whole program OO. You can keep it procedural (and for most scripts that's the case), but you can use the above objects just like you'd use their procedural counterparts before. Slowly, and with experience both with OOP and larger programs, you'll see other parts of your work that would make sense as an object. On the other hand, some of them won't. And it's perfectly ok - not all problems can be naturally modeled as a system of objects.

Start reading this and keep going until the end. In two hours or less, you will understand object-oriented programming. This is very well written and explains many differences between functional languages and object oriented languages.

http://developer.apple.com/documentation/Cocoa/Conceptual/OO...

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.

^ 64 words.

abstraction, hierarchy, modularity, encapsulation

manage complexity reduces resistance to change over time

design patterns give best practice advise

'OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.'

He might know....

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.

This is more cohesive than parallel hierarchies of data structures and code that must be kept in sync.

(63 words)

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.

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

The answer to your question hinges mainly on how you define components. In the Erlang language for example: It is completely functional but threads actually become somewhat stateful and ultimately end up recreating some similar scenarios for OOP programmers. On top of that, functions themselves showcase an even higher amount of reusability at times especially in functional languages because of the prevalence of lists of things and tuples. This prevents an over abundance of duplicate implementations of the same thing that, even though their signatures are identical (or nearly so) can't interoperate because they haven't been specified as exactly the same. So language wide consistency is a big plus for some functional languages.

Having said that no one tool is a golden hammer. OOP and Functional programming are just tools and there are others out there. Some not even based on Von Neumann architectures that are even more flexible than the ones we, Von Neumann proggies, are (think data flow architectures for example).

Clearly you're inexperienced with golden hammer methodology, which provides both a mightier paradigm and a pleasantly horned helmet.

Erlang is a well thought out compromise between tying your hands by restricting side effects (the monad approach) and allowing a wide audience of people to be quickly productive.

[1]: Changing the temperature of the environment can be considered a side effect thereby rendering the 100% functional language 99.999% functional.

Hah! However you want!

The first few chapters of Paul Graham's `On Lisp' does a great job covering closures, which can provide elegant encapsulation. But even in Java or C++, objects aren't the only modular or reusable components - consider packages or name spaces, for example. Data types such as streams, arrays, and trees don't have to be classes, either - take a look at Haskell's data types.

But seriously, if you had to write software that abstracts complexity (good), has modular components (good) and let's you attack specific problems one at a time, how would you do it? If you don't think these are worthwhile tenets of software engineering, what are, in your opinion?

If you are curious, look at abstract data types and polymorphism in SML/OCaml and Haskell. Also, look at Haskell's type classes, and look at SML/OCaml's module system.

Here's a paper you can read: http://www.cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT...

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.