[allendoerfer]

As soon as you know a little bit, I would start as soon as possible to learn by copying existing code. Learn by using different frameworks, which show you how to do things.

The classic OOP examples ("This class is a car, this Mercedes class inherits from the car class, it also has a method to move, and this Mercedes object is an instance of a Mercedes") are pretty easy to grasp for a person of normal intelligence. The frustration is to then apply this when you are stuck thinking in a procedural or functional model. However once you have learned for example how to handle a database connection, you start to apply that on your own and when a similar problem comes along, you start to notice patterns: "This is really similar to the db object, I know I did right, because I just copied the concept, so I will do this in a similar way." After that learning the design patterns is quite easy, too. But at first knowing what - in this example a - singleton is does not get you anywhere, because generally you do not know how to start.

[llamaz]

If you think inheritance is central to OOP, then you are mistaken. The most important aspect of OOP is dynamic dispatch (e.g. objects accessed through Java interfaces), and that's closely related to the idea of messaging. Have a read of what other people are writing here.

[kazinator]

A language without classes that feature inheritance (at least single) can be used for OOP, but cannot be said to have support for it. It may not be central, but it is important.

Java Interfaces are in fact an example of inheritance. Moreover, they are an example of "non OOP inheritance": it's an inheritance of type checking that actually doesn't bring any attributes to an object. It exists in support of compiler diagnostics and compile-time optimization of dispatch.

In some languages (even ones that do support inheritance very well) objects of different types can be substitutable over a common set of functions without any explicit inheritance of interfaces or anything.

We can make a Dog and Cat class in complete isolation from each other, with no common dependency, and give them a speak() method. Then pass an instance of either class to some function which just calls arg.speak(). This produces "bark!" if arg is a Dog, or "meow!" if it is a Cat.

A Java-style interface just makes this dispatch easier to optimize via a static type system, and to implement checks. The function cannot call arg.speak() unless arg is a reference to an ICanSpeak type. That is assured externally because code which passes anything else to that function will not compile. Thus Dog and Cat must inherit this ICanSpeak, which causes their instances to be eligible as arguments to that function. When they implement speak(), their implementation is type-checked against ICanSpeak's speak(): to have the right number of properly typed arguments.