Fundamentos del Desarrollo Orientado a Objetos: Clases y Objetos ☁️

Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .

El enlace a la publicación original, lo encontrarás al final de este artículo.

…

Como entrenadora de RAD Women , a menudo me hacen preguntas relacionadas con la intersección de clases y objetos. Estas preguntas merecen una respuesta sólida y concreta que dure mucho tiempo. Pero primero: la filosofía.

En el famoso cuadro de René Magritte titulado “La traición de las imágenes”, debajo de la imagen de una pipa de tabaco aparecen las siguientes palabras: “Ceci n'est pas une pipe”. En inglés, esto se traduce como: "Esto no es una pipa". Los círculos de filosofía aman esta imagen. Como implica el título, señala las formas en que las herramientas que usamos para comunicarnos pueden complicarse. Por un lado, esta imagen es definitivamente una pipa. Está justo ahí, todos podemos verlo. Al mismo tiempo, esto no es una pipa, sino una imagen de una pipa, una representación de la idea de una pipa .

Las clases y los objetos tienen esa misma dualidad confusa. En esta publicación, exploraremos qué es una clase y en qué se diferencia de un objeto. Espero que se vaya con una sólida comprensión de cómo estos dos conceptos se relacionan entre sí.

Entra en la taza de café

Decir que amo mi café es quedarse corto. Si yo fuera un oso cariñoso, el símbolo en mi barriga sería una taza de café. Entonces, cuando busqué una metáfora para ilustrar clases y objetos, surgió el café. Las clases y los objetos son abstracciones , y parte de lo que hace que sea difícil hablar de las abstracciones es su naturaleza genérica. Entonces, hablemos de una taza de café. Usaremos nuestra humilde copa como metáfora, permitiéndonos explorar la dualidad de clases y objetos.

Es muy probable que todos podamos imaginarnos una taza de café en la cabeza. Podemos enumerar sus propiedades: altura, ancho, diámetro, color, volumen, etc. Pero al enumerar estas propiedades, estamos hablando de la idea de una taza de café , no de una taza de café física real. Críticamente, mientras discutimos la idea de una taza de café, no podemos llenarla con café y traer alegría a nuestra vida.

Para disfrutar de verdad, necesitamos progresar desde la idea de una cosa, a una cosa física real. ¿Recuerdas la pintura? Necesitamos pasar de la imagen de una tubería a una tubería real . Esta progresión es muy importante. Sabemos que la idea de una taza de café tiene propiedades como alto y ancho. Dicho esto, no podemos conocer los valores de esas propiedades sin una instancia real de nuestra taza de café. La diferencia entre una idea y la manifestación física de esa idea refleja la diferencia entre una clase y un objeto. También coincide muy bien con la diferencia ilustrada por la pintura de Magritte.

¡Clases para la victoria!

Una clase representa la idea de una cosa. Esta es una de esas oraciones engañosamente simples; pasa por alto una tonelada de matices e ignora la dificultad de discutir abstracciones (como "cosa"). Por eso traje una “cosa” específica: la taza de café. En esta publicación, discutiremos la Coffee Cup , sin embargo, es importante entender que usamos clases para modelar o representar cualquier idea que tengamos. Entonces, con esa advertencia en su lugar, hablemos de la idea de la humilde taza de café.

En el ámbito de las ideas, podemos identificar propiedades comunes, pero no valores concretos . Entonces, es totalmente justo decir que la idea de una taza de café tiene una altura y un radio. Después de todo, una taza de café es tridimensional (una versión en 2D sería una imagen de una taza de café, ¿ves lo que hice allí?). Además, la idea de una taza de café tiene un color, pero también puede tener un logotipo. Nos referimos a esto como las propiedades de una clase.

Nota: es bastante fácil crear una lista mucho más larga de propiedades para la idea de una taza de café, pero por razones de simplicidad, nos quedaremos con estas.

En código Apex, nuestra clase de taza de café podría verse así:

 público con compartir clase CoffeeCup { // propiedades efectivamente requeridas con valores predeterminados pública Doble altura = 0.0; radio doble público = 0.0; public String color = 'Blanco'; public Boolean hasHandle = verdadero; // propiedad opcional sin valor predeterminado hasLogo booleano público; }

Cuando se trata de la idea de una taza de café , es lógico notar que tiene una propiedad de radio . Pero debido a que solo estamos tratando con la idea , no sabemos cuál podría ser el valor de esa propiedad de radio. Es posible, y útil, dar valores predeterminados a las propiedades de clase. Pero los valores predeterminados son solo eso: valores predeterminados. La idea de una taza de café puede tener un radio predeterminado de 1,5 pulgadas; sin embargo, sin una taza de café real, no sabemos si ese valor predeterminado es válido, ni si podríamos cambiar el valor.

Las clases también contienen m étodos – bits de re-aprovechables de la lógica que manipulan el objeto. Por ejemplo, con nuestra taza de café, podríamos tener un método empty() Los métodos agregan una capa adicional de complejidad, por lo que para esta publicación los ignoraremos. Busque una publicación de seguimiento sobre métodos en las próximas semanas.

Las clases son útiles para modelar cosas del mundo real como una taza de café. Pero hasta que creemos una instancia de la clase, llamada objeto, todo es conceptual y de solo lectura.

Los objetos son reales

Si una clase representa la DEA i de una cosa, un objeto es un hormigón, en la vida real, instancia de esa clase. Podemos manipular y cambiar objetos; por ejemplo, en lugar de la idea de una taza de café, tenemos mi taza de café (hay muchas como esta, pero esta es la mía). Debido a que hemos cambiado de la idea a una taza de café específica , ahora podemos usar la taza de café.

Diferentes lenguajes de programación usan variaciones en la terminología de clase/objeto, tanto que los desarrolladores tienden a usarlos indistintamente. Esto puede ser confuso para los desarrolladores que están aprendiendo programación orientada a objetos (OOP), así que intentemos resolver esto usando terminología concreta para desarrolladores de Apex.

Todos los objetos son una instancia de alguna clase.

Un objeto debe, por definición, ser una instancia específica de una clase. Esta es una regla dura y rápida, y un concepto básico en la programación orientada a objetos: unos objetos ll son una instancia de alguna clase. Las clases definen incluso objetos "primitivos" como (la cadena) "Hola, mundo". Si bien es posible que un desarrollador de Apex no vea el código fuente de la clase de cadena, allí se rigen todas las cadenas.

A veces, los desarrolladores también se refieren al tipo de objeto, que es una forma diferente de especificar la clase que respalda un objeto. Si tomamos my C offeeCup , podemos decir que es una instancia de CoffeeCup . También es correcto decir que el tipo de myCoffeeCup CoffeeCup . Cuando los desarrolladores hacen preguntas como "¿Qué tipo de objeto es ese?", utilizan "tipo" como sinónimo de "clase".

Una cosa más: hacer instancias de clases.

En el arte de la programación, modelamos nuestras clases en objetos de la vida real, creando la idea de una cosa como una taza de café. Sin embargo, las ideas son difíciles de manipular y utilizar. La idea de una taza de café no me saca de la cama por la mañana. Una instancia de una taza de café, llena de café, es una historia diferente. Entonces, ¿cómo pasamos de la idea de una cosa a una instancia de una cosa mientras codificamos? Usamos la new y un tipo especial de método llamado constructor .

Todos conocemos la sintaxis para crear una nueva variable en Apex; siempre se ve así: Type variableName = new Type() . Recuerda, tipo es sinónimo de clase. Por lo tanto, también podemos escribirlo de esta manera: ClassName variableName = new ClassName() . Tenga en cuenta que esto también demuestra que todas las variables en Apex son, de hecho, ¡objetos!

Dado que todas las variables de Apex deben tener un tipo, todas las variables de Apex son objetos.

Al observar el código, vemos que el código que sigue a la new palabra clave parece una llamada a un método. Porque es. Esto puede ser confuso porque no siempre hay un método llamado className() en nuestro código. Por ejemplo, si miramos hacia atrás a nuestro código de clase anterior, no hay métodos definidos en esa clase en absoluto. A pesar de la falta de un constructor definido, esto funciona bien. De hecho, CoffeeCup myCoffeeCupHasAName = new CoffeeCup(); compila y funciona bien.

Esto funciona porque cada clase tiene al menos un constructor implícito. Incluso si no lo codifica, aún puede llamar a new ClassName() . Cuando llamamos a new CoffeeCup() , el compilador nos da una instancia (objeto) de esa clase. Este objeto estará en blanco: sus propiedades serán null o se establecerán en los valores predeterminados que codificó. Es importante tener en cuenta que puede crear constructores personalizados, como uno que requiera un parámetro de número entero para la amountOfCoffee de café en la taza. Pero ese es un post para otro día.

Una vez que tenemos un objeto, también conocido como una instancia de una clase, podemos comenzar a manipularlo. Podemos establecer y leer sus propiedades, y podemos llamar a sus métodos.

Conclusión

Ok, aquí está el flaco: las clases son ideas y los objetos son instancias específicas de una clase. Usamos la new con un constructor para crear nuevos objetos y usamos objetos para almacenar propiedades y ejecutar lógica. ¿Qué significa eso para nuestra clase específica de CoffeeCup y la instancia de myCoffeeCup ? Bueno, significa que podemos definir una propiedad sobre la idea , o clase, de CoffeeCup . También significa que no podemos modificarlo hasta que hayamos creado una instancia de esa clase. No podemos llenar o vaciar la idea de una taza de café: esas acciones necesitan una instancia.

Las clases y los objetos pueden parecer similares, pero esperamos que el ejemplo de la taza de café ayude a aclarar sus diferencias. En publicaciones futuras, discutiremos métodos, constructores, interfaces y herencia.

Sobre el Autor

public with sharing KevinPoorman {
public static String pronouns = 'he/him';
public static Double startedWithSalesforceAtApiLevel = 11.0;
public static String[] interests = ['Apex', 'Testing', 'iOS SDK', 'Generics', 'Metaprogramming'];
public static String funFact = 'Has two daughters he's training to take over the world.';
public static String twitterHandle = '@Codefriar';
}