OO programming is a bit like people in an organization.
Let's say you're going to hire 10 people. You can give them each a job to do, and things will go smoothly. You can manage each person well, as long as things stay small and you can manage it individually.
But, if you try to hire 1000 people, and do the same thing, it's a nightmare. You need some way of dealing with it. You system won't scale. Every time somebody leaves on vacation or quits, you'll be left with a broken system that needs patching. Nightmare!
But let's say you create departments in your organization. Each department is made up of 5 people. Each person know what their job is, and they talk within their group, and everybody knows how to do the group's job relatively well. Not everybody in the organization knows what everybody else's group does to get things done, but they know what each group can accomplish. You don't have to manage individuals, only tell them what other groups can do, and how to get things done. If somebody quits or
gets fired... the group still functions... you don't have a crisis where everything breaks down.
This would be an "object".
Using objects that have "methods" and "properties" makes it possible to change objects entire internal workings without changing the way other parts of your code access them. It's more work to set up (generally), but if you plan on having a large system, this kind of programming is really powerful, so long as it's consistenly enforced (languages like Java make is impossible to not write OO code, though you can still screw it up if you write Java like a proceedural langue like lots of older programmers do when they switch from C++ or whatever).
Hope that helps.
If you want to learn more, read the intro to the java tutorial:
http://java.sun.com/docs/books/tutorial/