Todos los lenguajes de programación proporcionan abstracciones. Se puede afirmar que la complejidad de los problemas que se pueden resolver está directamente relacionada con el tipo y calidad de la abstracción. Por «tipo» me refiero a «¿Qué es lo que está abstrayendo?». El lenguaje ensamblador es una pequeña abstracción de la máquina subyacente. Muchos lenguajes llamados «imperativos» que siguieron (como Fortran, BASIC y C) eran abstracciones del lenguaje ensamblador. Estos lenguajes suponen grandes mejoras con respecto al lenguaje ensamblador, pero su abstracción primaria todavía requiere pensar en términos de la estructura del ordenador, en lugar de la estructura del problema que intenta resolver. El programador debe establecer la asociación entre el modelo de la máquina (en el «espacio de soluciones», que es el lugar donde está modelando ese problema, como un ordenador) y el modelo del problema que se está resolviendo (en el «espacio de problemas», que es el lugar donde existe el problema). El esfuerzo requerido para realizar esta correspondencia, y el hecho de que sea extrínseco al lenguaje de programación, produce programas difíciles de escribir y caros de mantener y, como efecto secundario, creó toda la industria de «métodos de programación».

La alternativa a modelar la máquina es modelar el problema que está intentando resolver. Los primeros lenguajes como LISP y APL eligieron concepciones del mundo particulares («Todos los problemas son listas en última instancia», o «Todos los problemas son algorítmicos»). PROLOG reduce todos los problemas a cadenas de decisiones. Se han creado lenguajes para programación basados en restricciones y para programar manipulando exclusivamente símbolos gráficos (lo último demostró ser demasiado restrictivo). Cada uno de estos métodos es una buena solución para el tipo particular de problema para el que fueron diseñados, pero cuando uno sale de ese dominio se hacen difíciles de usar.

El método orientado a objetos va un paso más allá, proporcionando herramientas para que el programador represente los elementos en el espacio del problema. Esta representación es lo suficientemente general como para que el programador no esté limitado a un tipo particular de problema. Nos referimos a los elementos en el espacio del problema, y a sus representaciones en el espacio de la solución, como «objetos» (por supuesto, necesitará otros objetos que no tengan analogías en el espacio del problema). La idea es que permita al programa adaptarse al lenguaje del problema añadiendo nuevos tipos de objetos de modo que cuando lea el código que describe la solución, esté leyendo palabras que además expresan el problema. Es un lenguaje de abstracción más flexible y potente que los que haya usado antes. De esta manera, la POO permite describir el problema en términos del problema, en lugar de usar términos de la computadora en la que se ejecutará la solución. Sin embargo, todavía existe una conexión con la computadora. Cada objeto se parece un poco a una pequeña computadora; tiene un estado y operaciones que se le puede pedir que haga. Sin embargo, no parece una mala analogía a los objetos en el mundo real; todos ellos tienen características y comportamientos.

Algunos diseñadores de lenguajes han decidido que la programación orientada a objetos en sí misma no es adecuada para resolver fácilmente todos los problemas de programación, y abogan por una combinación de varias aproximaciones en lenguajes de programación multiparadigma. ^[11]

Alan Kay resumió las cinco características básicas de Smalltalk, el primer lenguaje orientado a objetos con éxito y uno de los lenguajes en los que está basado C++. Esas características representan una aproximación a la programación orientada a objetos: