Lo he visto una y otra vez. Un programador de computadoras proclama con orgullo: “Sí, mi código está orientado a objetos. ¿Ves? Todos mis miembros de datos son privados y solo se puede acceder a ellos a través de funciones de miembros públicos. De eso se trata estar orientado a objetos”. Incluso he escuchado este tipo de tonterías de boca de graduados en Ciencias de la Computación, personas que presumiblemente han estudiado orientación a objetos en el aula, o que habrían tenido una amplia oportunidad de educarse.

Los eruditos pueden objetar los detalles de la orientación a objetos; sin embargo, una cosa es cierta: el mero hecho de tener datos privados y funciones públicas no constituye un diseño orientado a objetos adecuado. Más bien, la orientación adecuada a los objetos implica mucho más.

Uno de los elementos más básicos es la ocultación de información. Esto significa que los objetos solo deben presentar la información que necesita verse; es decir, debe presentar una interfaz de funciones coherente y bien seleccionada, una que no traicione el contenido de los datos y el funcionamiento interno de la clase. En otras palabras, la forma en que se implementan las funciones permanece oculta al usuario, lo que permite al desarrollador alterar la implementación según sea necesario. (Algunos también se refieren a esto como “encapsulación”, mientras que otros afirman que la encapsulación es simplemente un medio para ocultar información. Yo me inclino por el último punto de vista; sin embargo, para los propósitos de este artículo, esta distinción no es importante. Basta decir que la información ocultar es un elemento clave del diseño orientado a objetos).

Cuando un programador declara que su código está orientado a objetos en virtud de tener datos privados y funciones públicas, está colocando el carro delante del proverbial caballo. El uso de datos privados y funciones públicas es simplemente un medio para lograr el ocultamiento de información; no es un objetivo en sí mismo. Por ejemplo, considere un diseño en el que cada miembro de datos tiene los accesos “get” y “set” correspondientes (por ejemplo, un miembro de datos “x” tendría funciones “getx ()” y “setx ()” coincidentes). En este ejemplo, la información está mal oculta, ya que la elección de funciones (¡de hecho, sus propios nombres!) Delata la forma en que se han implementado los datos.

La herencia es otro elemento clave; es decir, las clases específicas deben derivarse de otras más generales. La herencia es un medio de implementar la abstracción; es decir, permite al usuario identificar objetos con características comunes y que, por tanto, deben utilizar código común (o al menos, interfaces comunes). Esto es parte integral del pensamiento en términos de objetos, en contraposición a pensar principalmente en términos de funciones y procedimientos.

Otra característica clave es el polimorfismo, que permite que un objeto descendiente anule las funciones miembro de su padre. Con el polimorfismo, un objeto descendiente no tiene que responder a un mensaje exactamente como lo hace su antepasado; más bien, puede tener su propia implementación. Tenga en cuenta que los objetos descendientes no tienen que anular estas funciones; más bien, simplemente se les debería permitir hacerlo, según sea necesario. Hay mucho más que se puede decir sobre la naturaleza de la orientación a objetos; de hecho, los estudiosos a menudo discuten sobre su definición precisa y sus ideas principales. Cualquiera que sea el caso, sin embargo, el punto sigue siendo: el simple hecho de mantener datos privados y un conjunto de funciones públicas no constituye un diseño orientado a objetos, no en ningún sentido significativo del término.