After years of developing applications using data structures and the divide and conquer technique, a new thought-pattern emerged that modeled computer programs after real-world objects. The thought is that you do not think of a car as a set of attributes, and then define methods to manipulate those attributes. You instead think of a car in terms of both attributes and behavior: a car has an engine, four wheels, and two doors and you can turn it on, accelerate it, put it in reverse, and turn it off. Because real-world objects do not decouple the interaction between attributes and actions (behavior), why should computer programs?
When you accelerate a car you don't need to think about a fuel tank firing gas into a combustion chamber, which generates heat and eventually turns the wheels; you just press the gas pedal and the car goes the things happening internally do not concern you!
A class represents an object in Java. Thus, when analyzing your problem and designing your classes you can start thinking in terms of objects that can be used to solve your problem. And, if you do a good enough job, you can define an object that you can reuse later in a different application.
When properly designed, Java objects can act as black boxes. Which means you know the information that you pass to the object, and you know the expected result from invoking methods, but you do not know anything about the internal implementation of those methods. This is a powerful programming paradigm because it enables you, as the object developer, to change the underlying implementation without affecting the applications that are using your objects. This object-oriented principal is referred to as encapsulation. Your Java classes are encapsulating data and attributes in such a way that they provide a programmatic interface that enables you to use the object without knowing the underlying implementation.
A very similar object-oriented concept to encapsulation is information hiding. When building your objects you choose the information that you want to publish to consumers of your objects, and the information that you want to keep private to your implementation. In the car example you might want to expose the method accelerate, but hide the speedUp method. It is an internal method that accelerate needs, but it should never be accessed by applications using the Car class.