Past, Present and Future (yeha right!) as I know it (which is not much)
Do I see eyes rolling on the mention of the word history? Well Ill make it short!
One of the goals of software programming has always been to take a problem and write a program what solves it. As the problems started getting complex, so did their solutions (programs written to solve them) also started getting complex.
Languages like C are procedural languages, they break down a problem into multiple functions which try to solve one part of the problem each. A C program contains a set of functions which ideally represent one part of the problem each to solve the complete problem.
It was realized that although this method worked (and still works) it really becomes very complex to understand and manage large C programs with functions as the unit of break down.

In order to solve this problem, one of the popular new ways of thinking that arose was Object Oriented Programming. One of the basic premises of this paradigm is that it modeled based on the real world, so it lets us break the problems down just as we observe in the real world. The idea behind using Object Oriented Programming is that that it helps break down the problem into simpler units that can be easily understood, maintained and reused; The keywords which every CTO looks to derive out of his solutions. An example could be suppose we want to describe the bicycle in an object oriented way. So we could say Bicycle is an object that is built of small objects like bicycle frame, handle, breaks, seat and tyres.

Although object oriented programming has been around for a long time its hardly used correctly, hence the benefits promised by the paradigm rarely derived. One of the reasons I see is that Object Oriented Programming is sensitive to context, the way the objects are designed really depends the context in which they get designed. This hampers the ability to reuse the same objects in a different context. Taking the same bicycle example someone else might think of a different context and try to describe the bicycle into the following objects: Transport Vehicle, Manual, Two Wheeler, Bicycle, bicycle frame, handle, breaks, seat, gears and tyres. This kind of classification as well as the one given above are two possible ways out of the many other ones that are possible. So the best way is to think the context of your program and design your objects based on that. With the understanding that if your objects need to participate in another context in future you will have to undertake some kind of refactoring.

As new problem solving techniques emerge object oriented programming is considered to be the base for a lot of these new techniques that are built to overcome the problems faced by programmers today.
I believe that object oriented thinking definitely helps the developer think clearer and design his solution better. And its essential for one to make the effort to learn this skill before getting into writing production code.

What is Object?
An object is a core packaging unit of state and behavior in object oriented programming, modeled after real world objects. The idea is to visualize the problem you are trying to solve in real world terms and trying to identity various real world objects and its components that would be required to define the solution set for the problem. For example if we were to create a software program to replicate the function of an electrical switch. We would identify a switch object with the mutually exclusive state of On or Off as well as a behavior to Turn On and Turn Off the switch.
As I mentioned above its very important to keep the context in mind while defining the objects. While trying to define solutions for complex problems more complex objects would need to be defined as well as sometimes you might need to define relationships between the objects.

What is a Class?
A Class is the software blueprint of an object containing the state as well as behavior of the object. Hence a Switch class would define a variable for the On/Off state as well as methods TurnOn and TurnOff to define the behavior of the object switch.

There is really a fine line to understand the difference between an object and a class. One way to understand is that a class is the software definition of an object. So when you instantiate a class, we say that you create an object. So, the Switch class defines the blueprint of a switch. But there could be many switch instances that you create from the Switch class, all of them have similar state and behavior but are independent. Each one of them could be called as objects of the switch class.

What is State?
Every object demonstrates some state/property for example a switch can have On/Off state, but there could be more states of the switch like its color, style, manufacturer etc. In real world all objects demonstrate some state, like cars can be of certain kind, color, model etc. All these define the state of the object. In software terms, State of the object is represented by variables (fields) and properties. It is important to note that not all state is visible from outside the object.
For example, from outside you might be able to know the speed of a car by looking at its speed property, but you might not be able to determine the position of the piston of the engine. But, the engine would defiantly be tracking the position of the piston but it does not choose to expose that state to the outside world. Similarly in software an object can have both public and private state and its the object creators decision to only expose some of the states of the object to the outside world while hide some other state which is internal to it. This is achieved using access modifiers on variables and properties. The ability to hide some internal state of the object is also referred as Data Hiding.

What is behavior?
Just as every object has a state it also exposes some behaviors. Like a car can be accelerated, a switch can be turned on/off all these are behaviors of the respective objects. In software terms behaviors are represented by methods of a class. Similar to state, even behavior can be internal to the object or external. Its the object creators responsibility to define which behaviors he wants to expose to the outside world and which behaviors he wants to keep internal to the object. Just like in case of state, there are access modifiers on methods that help to define the access to the methods.

What is Encapsulation?
The packaging of state and behavior within a class is called encapsulation. The reason it is important is that now its the class that explicitly defines the state and behavior it want to expose to the outside world at the same time protecting access to its internal state and behavior. Hence the class really becomes a container that is in charge of all the state and behavior of an object and makes sure that its always in consistent state and behavior.

What is Inheritance
When we look at relationships amongst objects in real world we can often clearly see a commonality amongst objects of a particular type. Most of the times these common features are due to an explicit parent-child kind of relationship amongst objects. For example all trees even though they are different have a common features of having leaves, trunk and roots. So we could say that a particular banyan tree by virtue of being a tree inherits the properties of having leaves, trunk and roots. Although, at the same time the size, texture, color would differ from other trees. Hence while each tree has its own identity, by virtue of it being a child of Tree it has some basic common properties.
The same concept gets applied in software, where we try to identify the common state and behaviors demonstrated by various objects and then create a class that acts as the base (parent) class of the objects. So in a banking system the Accounts class would be the parent class of the various other types of account classes like Savings Account, Current Account etc.

Conclusion
In this article I have briefly brushed some of the core Object Oriented Programming concepts. I would definitely recommend that refer to a good book if you have no idea of Object Oriented Concepts.