Quick search:

What is object orientation

a way of programming where what the program does results from a dynamic network of interacting objects
Object orientation (OO) was originally invented for programming simulations. The first full grown OO programming (OOP) language was Smalltalk, which was developed together with the GUI at Xerox Labs. Together with the popularity of GUI's the popularity of OOP grew. Its flexibility and support for abstraction makes it a good tool for software reuse.

If you are used to procedural programming OOP can be hard to grasp in the beginning. The problem is that you see your computer as a single entity with a single processor and memory space. A procedural program is essentially a list of instructions for this processor, referring to variables in this memory. You need to let go of that idea. Objects are more like the those beasts/puppets that run across your screen in a computer game like boulderdash: a whole bunch of entities that seem to live inside your computer, each doing its own things, remembering for itself what happend and what it is doing in its own private memory space, and interacting with one another.

With OOP, objects are things in memory you can call methods on. If you call a method on an object, the object may do somthing. It is like a little home computer: you can type a command, it will print a reaction (or trigger an error if it does not know the command). It may also remember somthing. What is does may depend partially on the things it has previously remembered. You don't need to know how it works internally. You just need to know what will happen for each command.

But there's more. Objects are networked. They can store references to other object in their own private memory (member variables). When you call a method on one object, it may ask other objects to do things by calling more methods on them (delegation). If you call a function in procedural programming, you know what code will be executed. If you call a method on an object, you don't, unless you know what object you are calling the method.

Most method calls are made using a variable with a reference to an object. So if at some point some code puts a different object in that variable, all method calls on that object may end up executing different code (polymorphism). In this sense object references are much like function pointers. Those objects can hold other objects in their member variables and make more method calls on those objects, and so on. This easily leads to a magnitude of spaghetty you can not even dream of with procedural code, even if you are using GOTO's in the large! This spaghetty even changes dynamicly as the program changes the contents of variables! New objects may be created. References to objects may be returned and stored . AARCH!

This is what classes are made for: To create some structure in the object spaghetty. First we classify all objects. Then we only define methods in the classes. So if you have a variable referencing an object, and you know the class of the object in advance, then you know what code will be executed if you call a method on that object. Becuase most programmers somehow tend to know the type (class with subclasses) of what is in each variable, they can find their way in the spaghetty.

Object orientation works best if you make small methods with descriptive names. If several methods are needed by several classes, you either make a superclass and put the common methods there, or delegate to another object that is kind of a specialist for the given tasks. For non arbitrary programming tasks, even experienced programmers can not know in advance what methods will be needed and where these methods can be put so that there is little duplication. So be prepared to change the design of your program during development, and keep doing so even after the program is finished. For further reading see extreme programming.

Even with classes OOP is formally still very messy. C++ made it formally more straightforward by using strong typing: let the compiler enforce the type of objects that can be referred by a variable. Later this was included in Java too. Nowadays it is recognized that for most applications strong typing makes life harder for programmers, because of the overhead and inflexibility it introduces. I guess php chose weak typing (only typing classifying the objects, not the variables) because simplicity is generally preferred over formal correctness. Formally this may be messy, but who cares, programming is a matter of psychology after all ;-)