Aprende Unity [1]

Hola bienvenido al comienzo de esta hermosa capacitación que le voy a brindar de manera gratuita. Si aún no sabe como es la forma de esta capacitación, le invito a leer el post anterior AQUÍ. Bien, pasaremos a ver el temario de lo que veremos en el día de hoy.

Temario

Propiedades

Las propiedades son muy útiles para mantener el principio de encapsulamiento que rige en la programación orientada a objetos(POO).

Operador Ternario

Sirve mucho para reducir líneas de código, es un condicional simple en una sola línea de código.

Estáticos

Variables y métodos estáticos, son valores o acciones accesibles desde cualquier sitio.

Sin aún no ha visto el video de práctica, aquí se lo dejaré. Si ya ha visto el video simplemente lo puede saltear o verlo nuevamente si lo desea.

Ahora daremos comienzo a la teoría. ¿Esta preparado? Espero que si. Acomódese bien y comenzamos.

TEORÍA

PROPIEDADES

Bueno antes de comenzar vamos a repasar el resumen que he dejado más arriba. 
«Las propiedades son muy útiles para mantener el principio de encapsulamiento que rige en la programación orientada a objetos(POO).»

Para comenzar debemos conocer algunos de los principios del paradigma orientado a objetos, el cual es utilizado por Unity. Puntualmente debemos saber que nos dice el principio de encapsulamiento. Antes de eso veremos que nos dice wikipedia al respecto de la POO.

programación orientada a objetos

Los objetos son entidades que tienen un determinado «estado», «comportamiento (método)» e «identidad»:

  • La identidad es una propiedad de un objeto que lo diferencia del resto; dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).

Un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos, que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.

Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una «programación estructurada camuflada» en un lenguaje de POO.

La programación orientada a objetos difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada solo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

Fuente :»es.wikipedia.org»

Principio de encapsulamiento

Significa reunir todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión (diseño estructurado) de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.

Fuente :»es.wikipedia.org»

explicación

Bueno ahora que ya sabemos a grandes rasgos de qué trata la programación orientada a objetos y el principio o característica de encapsulamento de dicho paradigma, es hora de darle nuestra explicación.
Pasaremos a explicar el cómo y porqué utilizar este principio y cómo las propiedades son una parte fundamental para respetarlo.

Imaginemos que cada clase es un objeto independientemente que esto no es real, ya que un objeto es una instancia (creación) de una clase, pero para simplificar el ejemplo vamos a suponer que así es. 
Si cada objeto tiene todas sus partes abiertas (métodos y variables) cualquiera puede entrar y alterarlo causando daños en su funcionamiento. Entonces lo que debemos hacer es controlar ese acceso, no darle libertad a cualquier para acceder sino sólo compartir la información que necesita el otro objeto de mi.

Vamos a poner un ejemplo, si tenemos sin protección al personaje, es posible que por un fallo de la interfaz de usuario o de un enemigo haga que el personaje se comporte de manera errónea. Al intentar solucionar ese comportamiento indebido, lo primero que iremos a ver es si el personaje posee algún error, incluso es posible que hagamos cambios en su código incluso cuando ahí no radica nuestro error.
Ahora viene el gran problema, puede pasar que rompas el código del personaje intentado solucionar ese problema, o en el mejor caso solo desperdicie valioso tiempo intentando llegar al error. Usted dirá que es fácil encontrar el error, simplemente se ven las referencias y se detectará que el enemigo provoca el error. A simple vista esto parece estar en lo correcto pero a medida que el proyecto crece y las referencias aumentan, esto se vuelve cada vez más insostenible, solucionar un bug le lleva cada vez más tiempo. 

Tal vez usted me dirá que lo realiza rápido para probarlo, que luego lo va arreglar cuando el proyecto comience a crecer. Lamento informarle que esta manera de pensar es un error, ya que te tomará más tiempo reestructurar su código cuando el proyecto ya haya crecido , en vez de hacerlo desde un principio.
Como ya podrá ver nuestra forma de pensar, le aconsejamos que se plantee el encapsulamiento de métodos y variables desde el inicio del proyecto.

Bueno ahora pasaremos a explicar el porqué las propiedades son un punto fundamental para aplicar este principio. Nosotros debemos tener todas nuestras variables en privadas(private) o en caso de herencia en protegidas (protected). Se preguntará y ¿cómo hago para compartir la información con los otros objetos? Para eso es qué existen las propiedades, lo que hace es definir si la propiedad es sólo de lectura o sólo de escritura o ambas. Luego se define que hacer cuando lees la propiedad, puede ser que le des el valor de una variable privada o un cálculo que realices con una variable privada,etc. eso lo debe decidir usted, lo mismo sucede cuando se escribe una propiedad , puede asignarla directamente a una variable privada o llamar a un método privado, hacer un cálculo matemático, entre otras cosas que puede llegar a utilizar.

¿Cómo utilizar las propiedades?

Le daré un par de ejemplos para que vea cómo Unity utiliza las propiedades.

public class Personaje : MonoBehaviour
{
    int experiencia;
    public int Experiencia
    {
        get { return experiencia; }
        set { experiencia = value; }
    }
    public int Nivel
    {
        get { return experiencia / 1000; }
        set { experiencia = value * 1000; }
    }
    public int Vida { get; set; }
}

Como podemos ver la variable experiencia no está declarada como pública, por lo tanto no puede ser accedida por un objeto externo. Sin embargo, la experiencia es una variable que se necesita tanto para ser obtenida como modificada por varios objetos externos, como por ejemplo los enemigos o la interfaz de usuario.
Entonces para esto creamos una propiedad pública (es muy importante que la propiedad sea pública) la cual devuelve en valor entero pero puede devolver cualquier tipo permitido por Unity, ya que como mencionamos anteriormente no es está necesariamente ligada a una variable. 

Ahora una vez creada la propiedad debemos decir si es posible la lectura o la escritura. Puede ser una u otra o ambas. Con el get (lectura) y el set (escritura). En cuanto a la práctica debes manejar desde los objetos externos como si una propiedad fuera una variable pública (en caso de que esté acostumbrado a la practica de colocar variables públicas). 
No acostumbres a colocar la escritura dentro de las propiedades sólo utilizarla en caso de que sea necesario actualizar los datos de la propiedad desde un objeto externo, siempre que pueda evitarlo, hágalo. Trate de manejar el flujo de información dentro del mismo objeto, y en caso de ser necesario utilizar las propiedades para la comunicación con objetos externos.

En el caso de la propiedad Nivel es un ejemplo claro de la utilización de un cálculo dentro de una propiedad. Esta toma el valor de la variable privada experiencia y calcula el Nivel en base a la cantidad de experiencia que tiene el jugador. Este es uno de muchos ejemplos en donde se puede utilizar las propiedades de esta manera. Muchos ya estarán aplicando esto mediante métodos; no digo que esté mal utilizar métodos en algunos casos, pero va a depender estrictamente de la situación, no siempre se puede utilizar las propiedades para cálculos o métodos para los cálculos. Más adelante cuando tratemos temas de buenas práctica en el desarrollo explicaremos más en profundidad esto que acabo de mencionar.

Perfecto, todo esto que me esta enseñando es genial, pero en muchas ocasiones necesito editar una variable desde el inspector y si es privada no puedo acceder a ella, y si es pública no tiene sentido utilizar propiedades. Para eso se debe colocar un modificador llamado [SerializeField], esto permite que una variable privada sea mostrada y modificada desde el inspector de Unity. Más adelante explicaré más a fondo el tema de la serialización de campos, por ahora sólo le dejaré un ejemplo para que lo vaya implementando de a poco.

public class Personaje : MonoBehaviour
{
    [SerializeField] int experiencia;
}

Por último en el ejemplo de la propiedad Vida, tenemos una declaración vacía de la propiedad lo que significa que se maneja igual que una variable pública, aún no le encuentro mucha utilidad, sobretodo en que casos utilizar esta forma de propiedad, pero si está permitido debe tener un porqué. En lo personal si colocamos la propiedad de esta manera tenemos el mismo nivel de control que una variable pública ya que no existe un filtro entre los datos internos y cómo los datos internos deben comportarse ante los datos externos.

Nuestros servicios

¿Necesita que desarrollemos su proyecto?


Desarrollo

¿Necesita aprender cómo desarrollar su proyecto?


Tutoría

TEORÍA

OPERADOR TERNARIO

Bien ahora comenzamos con el operador ternario, como es de costumbre analizaremos el resumen dejado más arriba.
«Sirve mucho para reducir líneas de código, es un condicional simple en una sola línea de código.» No hay demasiado que explicar en este caso, es un muy buena práctica para la optimización de lineas de código, además tendrás un código mucho más limpio y fácil de mantener. Lógicamente es igual que un if de única línea, la ventaja está a la hora de mantener el código limpio, legible y reducido. 
Bueno sin más vamos a ver el ejemplo.

public class OperadorTernario : MonoBehaviour
{
    void Start()
    {
        int vida = 10;
        string mensaje;
        mensaje = vida > 0 ? "Estoy vivo" : "He muerto";
    }
}

Analicemos un poco de que trata esta simplificación. 
Tenemos 2 variables, una de tipo entero y otra de tipo cadena de texto. Cuando la vida (entero) es mayor a cero, la variable mensaje (cadena de texto) va a valer «Estoy vivo» en caso contrario valdrá «He muerto». El ejemplo es muy sencillo. Es lo mismo que el siguiente ejemplo.

public class OperadorTernario : MonoBehaviour
{
    void Start()
    {
        int vida = 10;
        string mensaje;
        if(vida>0)
            mensaje="Estoy vivo";
        else
            mensaje= "He muerto";
    }
}

Como puede llegar a notarlo es mucho más limpio, fácil de entender y reduce líneas de código, es por lo cual recomiendo utilizarlo siempre que tenga la oportunidad. Recuerde que funciona para una sola línea, no serviría si dentro del if necesita tener más de una línea de código.

TEORÍA

ESTÁTICOS

Bueno ahora comenzaremos con los estáticos, es un modificador que permite acceder los datos que hay en ella desde cualquier punto. Este modificador se puede usar para clases, métodos y variables. Para las clases, esto permite poder llamar a una clase sin la necesidad de crear una instancia de ella, si bien llamar a una clase en sí no tiene sentido alguno; pero si deseas acceder a una variable o método que también necesitan ser estáticos si es de mucha utilidad. 

Veamos algunos ejemplos para aclarar el cómo se usa.

public class Enemigo : MonoBehaviour
{
    public static int enemigoCantidad = 0;
    private void Start()
    {
    }
    public Enemigo()
    {
        enemigoCantidad++;
    }
}

Como podemos ver en este ejemplo, sólo la variable enemigoCantidad es estática, la clase y los métodos en ella no lo son. 

public class Juego2 : MonoBehaviour
{
    private void Start()
    {
        Enemigo enemigo1 = new Enemigo();
        Enemigo enemigo2 = new Enemigo();
        Enemigo enemigo3 = new Enemigo();
        Debug.Log(Enemigo.enemigoCantidad);
    }
}

Tenemos que tener en cuenta si la clase no es estática, aún así podemos acceder a la variable estática y no requiere que haya una instancia de esa clase en el escenario. Tal como se hace en el Debug.Log, en esa sentencia no se llama a una instancia de la clase, no se llama ni a enemigo1, ni 2, ni el 3; llamamos directamente a la clase y accedemos a su variable.
En este ejemplo creamos 3 instancias de la clase Enemigo, con el propósito de aumentar el valor de enemigoCantidad, ya que en el constructor de la clase Enemigo se suma 1 al valor existente de enemigoCantidad. Si no sabe lo que es un constructor de una clase, es un método definido por el lenguaje que es llamado cuando se crea una instancia de la clase, este método puede o no ser utilizado. 
Bueno ahora veremos un ejemplo de método estático.

public static class Utilidades 
{
    public static int Agregar(int valor1, int valor2)
    {
        return valor1 + valor2;
    }
}
public class UtilidadesEjemplo : MonoBehaviour
{
    private void Start()
    {
        int valor = Utilidades.Agregar(5, 6);
        Debug.Log(valor);
    }
}

Como podrá observar tenemos en el primer código una clase llamada Utilidades, la cual tiene un método estático Agregar. Este método puede ser llamado desde cualquier lado, este tipo de métodos son muy útiles a la hora de hacer cálculos que se van a necesitar varias veces en su programa. Si bien en el ejemplo la clase es estática pero no es necesario que lo sea para poder acceder al método estático. Vuelvo a repetir que es una buena práctica la utilización de métodos estáticos para la reutilización de código, aunque en lo personal no uso variables estáticas ya que se mantienen en memoria todo el tiempo, lo cual puede afectar al rendimiento de su programa.

DESPEDIDA

Si ha llegado hasta aquí quiero felicitarlo por su esfuerzo y dedicación con el aprendizaje de su carrera profesional. Espero que le haya sido de utilidad, que le haya gustado. Déjanos su comentario que le ha parecido nuestro primer post de la saga Aprendiendo sobre Unity. Nos vemos en el próximo post.

“Esfuércese, capacítese y haga la diferencia”