Mostrando entradas con la etiqueta Android. Mostrar todas las entradas
Mostrando entradas con la etiqueta Android. Mostrar todas las entradas

miércoles, 14 de noviembre de 2018

Programación Orientada a Objetos (POO) desde un Enfoque Simple

Este paradigma es descubierto en el año 1966, por Ole Johan Dahl y Kristen Nygaard, dos años antes que la programación estructurada, pero es adoptado después de esta.

Dentro de la POO existen dos conceptos claves.
  • Clase: Modelo o plantilla a partir del cual podemos crear los objetos.
  • Objeto: Un objeto es una unidad de software de estado y comportamiento relacionados, también puede describirse como la instancia de una clase.
Profundicemos un poco en los objetos, estos a menudo se utilizan para modelar los objetos del mundo real, esto incluye conceptos, cosas tangibles e intangibles que se encuentran en la vida cotidiana. Los objetos del mundo real comparten dos características: 
  • Estado 
  • Comportamiento
Por ejemplo, los perros tienen estado (nombre, color, raza, hambre) y comportamiento (ladrar, buscar, menear la cola). Un objeto almacena su estado en campos, atributos o variables  y expone su comportamiento a través de métodos o funciones, los métodos operan el estado interno de un objeto, pero para que dicho objeto o una clase realice alguna acción se debe enviar un mensaje, pero no basta con esto, ya que, para que el objeto o la clase procese el mensaje que recibe, debe poseer un método de coincidencia. Ilustremos lo anterior con un ejemplo escrito en Java.

Automovil auto = new Automovil();
auto.encender();

Como podemos ver, creamos a partir de la clase Automovil un objeto llamado auto al cual le enviamos el mensaje auto.encender() ya que queremos que encienda, pero para que esto se de la clase Automovil debe tener un método que coincida con encender()

Teniendo claro y comprendiendo los conceptos de Clase y Objeto, podemos hablar del Diseño Orientado a Objetos (DOO), que como menciona Rober C Martin en su libro Arquitectura limpia, "podemos utilizar  tres palabras mágicas para explicar la naturaleza del DOO: encapsulación, herencia y polimorfismo. La implicación es que el DOO es la combinación adecuada de estas tres cosas"

Encapsulación: Describe la capacidad de un objeto para ocultar sus datos y métodos del resto del mundo. Ocultar el estado interno y exigir que toda la interacción se realice a través de los métodos de un objeto se conoce como encapsulación de datos. Vemos la encapsulación con las variables privadas y métodos publicos de una clase.

Herencia: Diferentes tipos de objetos a menudo tienen una cierta cantidad de características en común entre sí, sin embargo, cada uno también define características adicionales que los hacen diferentes. La programación orientada a objetos permite que las clases hereden el estado y el comportamiento de uso común de otras clases. De aquí que Rober C Martin en su libro Arquitectura limpia la defina como "La redeclaración de un grupo de variables y funciones dentro de un ámbito de inclusión".

Polimorfismo: Es la capacidad de diferentes objetos para responder de manera diferente al mismo mensaje. Ejemplo: Tenemos dos clase EstudiantePregrado y EstudiantePosgrado que Heredan de la clase Estudiante, el polimorfismo nos permitiría que una variable de tipo Estudiante no se limite a referirse a un objeto de la clase EstudiantePregrado, ya que, puede hacer referencia a cualquier objeto de las clases descendientes de Estudiante.

Para finalizar hablemos de la Abstracción una palabra muy utilizada cuando hablamos de POO pero que es?, bueno se podría decir que la abstracción consiste en captar las características esenciales de un objeto, así como su comportamiento.

En mi repositorio de GitHub https://github.com/cedaniel200/Programacion-Orientada-a-Objetos encontraras algunos talleres donde puedes practicar los temas vistos y más, en caso de no poder solucionarlos, no te preocupes cada taller tiene una posible solución.

lunes, 28 de noviembre de 2016

Clean Code Capítulo 2 Nombres con Sentido (2/2)



Continuando con la segunda parte del capítulo 2, vamos a seguir viendo aquellas reglas para crear nombres correctos. Si aún no has visto la primera parte te invito para que la veas.

Nombres de clases: Los nombre de clases no deben ser verbos. Los nombres deben proporcionar de manera clara el propósito de la clase, por lo general debe ser un sustantivo, evitando nombres genéricos. Algunos ejemplos de nombres correctos serían: Persona, Direccion, Cliente. Algunos nombres incorrectos de clases podrían ser: Info, Procesador, CalcularNomina.

Nombre de métodos: Debe ser un verbo como por ejemplo, eliminar, agregar, guardar. Los métodos de acceso, modificación deben tener como nombre su valor y usar como prefijo get, set e is. Como recomendación el autor dice, que “Al sobrecargar constructores use métodos de factoría estáticos con nombres que describan los argumentos

No se exceda con el atractivo: Esta regla hace referencia a no utilizar nombres provenientes de formas coloquiales de decir las cosas o de jergas, dejando a un lado la claridad, ya que, si llega un nuevo programador que no conozca estas formas de decir las cosas, se llenará de desinformación. 

Un nombre por concepto: Es simple, cuando nos decidimos por una palabra para representar un concepto, esta debe ser constante por todo el código y no utilizarse en unos lados y en otros no. Por ejemplo, no es conveniente utilizar en algunos nombres de métodos la palabra get y en otros retrieve. 

No haga juego de palabras: Se refiere a no utilizar una palabra con dos fines distintos, por ejemplo, digamos que en nuestro código hemos venido utilizando la palabra remove para nombrar métodos que inactivan, y en algún momento somos tentados a utilizar remove para hacer referencia a un método que elimina, en este caso sería mejor utilizar el nombre delete para el método en cuestión.

Usar nombres de dominio de soluciones: No es necesario que todos los nombres utilizados sean extraídos del dominio del problema, ya que, los lectores del código son programadores y ellos conocen o están familiarizados con términos informáticos, de patrones, y demás. Por ejemplo para un programador va a tener mucho sentido si una clase tiene el nombre de ListAdapter.

Usar nombre de dominios de problema: Cuando no se pueda cumplir la regla anterior porque no existe un término en el ámbito de programación, se debe recurrir a un nombre del dominio del problema. El autor nos dice “Separar los conceptos de dominio de soluciones y de problemas es parte del trabajo de un buen programador y diseñador”.

Añadir contexto con sentido: Cuando los nombres no tiene sentido por sí mismo, es necesario crearle un contexto que enriquezca dicho nombre, esto puede hacerse convirtiendo variables en parte de un concepto mayor, es decir, extraer una clase de la cual hagan parte o en una función o método que aporte un contexto. Como última instancia usar prefijos.

No añadir contextos innecesarios: Se refiere a no agregar en los nombres más información de la necesaria. Imagine una clase llamada DireccionResidencia y otra DireccionTrabajo, estos nombres no son realmente adecuados para una clase, lo mejor sería una clase Direccion y estos nombres serían ideales para nombre de instancias. Otro caso es agregar prefijo al nombre de las clases.


Como hemos visto en estos dos post acerca de nombres con sentido, el elegir un nombre adecuado para cada parte del código es fundamental, tanto para la legibilidad como para entender qué se hizo o qué se va a hacer. Para dar un nombre adecuado es necesario emplear habilidad descriptiva, gran vocabulario, conocimiento técnico y dejar los miedos, es momento de empezar a buscar mejores nombres, agregar o quitar el exceso de contexto, refactorizar el código, cambiando los nombres que no sean adecuados en el código existente.

Nota: Para más artículos relacionados ver Clean Code

domingo, 4 de mayo de 2014

Android Soporte para Múltiples Pantallas 2/2

Nota: Si aun no has leído la primera parte da clic aquí.
Todas las imágenes son tomadas del IDE Eclipse.

Tamaño de la pantalla: A partir de Android 3.2 se introduce un nuevo enfoque para el tamaño de las pantallas, incorporando nuevos selectores numéricos con respecto a lo que se venía trabajando. descritos por tres números (selectores numéricos) representados de la siguiente manera:

 Width dp: Anchura de la pantalla del dispositivo, el ancho cambia cuando la orientación de la pantalla es cambiada.

Height dp: Altura de la pantalla del dispositivo, esta altura cambia cuando la orientación de la pantalla es cambiada.

Smallest Width dp: El ancho más pequeño del dispositivo, para el diseño de la app este es la menor anchura que se puede encontrar en cualquier rotación de la pantalla siendo este el más importante de los tres números que describen el tamaño de la pantalla.

Los números típicos para el ancho dp en pantallas son:

320: Una pantalla de teléfono
480: Una tablet Tweener
600: Una tablet de 7”
720: Una tablet de 10”

Estos nuevos selectores numéricos pueden seleccionar los recursos de diseño utilizando el Smallest Width dp (sw), Width dp, Height dp o combinaciones entre ellos.

Para ilustrar mejor lo anterior, pongamos un ejemplo; queremos implementar una interfaz para tablet, recordemos que su ancho mínimo es de 600dp, entonces tendríamos lo siguiente:

Primero debemos crear un nuevo archivo XML, para esto nos ubicamos en nuestro proyecto, entramos a File > New (Alt + Shift + N) > Other … (Ctrl + N) > Android; de las opciones desplegadas seleccionamos Android XML Layout File, clic en Next. Nos aparece la siguiente ventana, ingresamos el nombre del archivo, debe ser en minúscula y podemos seleccionar el tipo de elemento, en este caso solo agregaremos el nombre y dejaremos el resto por defecto.
Esta resaltado un Warning generado porque ya existe un archivo con el nombre de activity_main.xml, lo pasaremos por alto. click en Next. Nos aparece la siguiente ventana donde aparecen los calificadores disponibles. 

Seleccionamos el calificador Smallest Screen Width (Resaltado) y clic en el botón de selección (Resaltado). Aparece la siguiente ventana.


Primero debemos agregar el valor para Smallest Screen Width recordemos que queremos dar soporte a una tablet de 7” para ello ponemos el valor de 600 que nos cambia el nombre del calificador escogido a sw600dp y por último no indica el Folder en el cual se va a guardar. Clic en Finish. Al terminar si la carpeta donde va a guardarse no existe la crea y tenemos lo siguiente en la estructura de nuestro proyecto.


Si queremos hacer lo mismo pero para tablet de 10” debes repetir todos los pasos anteriores reemplazando el Smallest Screen Width de 600 por 720 y con esto se adiciona un nuevo recurso:

Para tener en cuenta, Android utilizara el recurso que esté más cerca al ancho más pequeño, del dispositivo sin que el recurso sea más grande.

Para hacer un diseño que nos dé soporte al cambiar de orientación utilizaremos el selector de Ancho (Screen Width) siguiendo los mismo pasos anteriores.

martes, 29 de abril de 2014

Android Soporte para Múltiples Pantallas 1/2

Primero debes tener claro algunos conceptos.

Densidad de Pantalla: Cantidad de pixels en un área física de la pantalla.

Orientación de la Pantalla: posición con respecto al usuario, Vertical u Horizontal


Pixel independiente de la Densidad (dp): Es una unidad virtual utilizada para definir el diseño de la interfaz. un dp es equivalente a un pixel físico en una pantalla de 160dpi. la conversión de DP a pixel es la siguiente: px = dp * (dpi / 160).

teniendo estos conceptos hay dos puntos en cuanto a las pantallas de los dispositivos que debes tener en cuenta al momento de hacer tus diseños.


La densidad: El primer punto es la densidad que afecta principalmente tus imágenes. Android escala tus recursos drawables en caso de ser necesario, por eso es una buena practica que proporciones los recursos para cada grupo de densidad con el fin de evitar que tus imágenes se vean borrosas, despixeladas o que simplemente no se vean como tu lo esperabas. Android divide los grupo de densidad en 4 principalmente; ldpi, mdpi (Linea Base), hdpi, xhdpi y ahora como están tan populares los dispositivos móviles con altas densidades entonces también es conveniente el xxhdpi; este ultimo es indispensable para tu icono lanzador en tablet con alta densidad. Para conocer que tamaños deben tener tus imágenes para cada grupo ten en cuenta cada factor de grupo.

ldpi(120dpi): tiene un factor de 0.75x, es decir, que 1dp equivale a 0.75 pixel.
mdpi(160dpi): linea base factor de 1x, es decir, que 1dp equivale a un pixel.
hdpi(240dpi): factor de 1.5x, es decir, que 1dp equivale a 1.5 pixel.
xhdpi(320dpi): factor de 2x, es decir, que 1dp equivale a 2 pixel.
xxhdpi(480dpi): factor de 3, es decir, que 1dp equivale a 3 pixel.

¿como obtenemos este factor?
Sencillo utiliza la formula de conversión px = dp * (dpi / 160), tenemos que la linea base que es mdpi tiene 160dpi.

px = 1 * (160/160)
px = 1 * (1)
px = 1


Miremos un ejemplo con el icono lanzador que tiene un tamaño de 48 x 48 pixels en mdpi como hacemos para conocer de que tamaño necesitamos la imagen para las demás densidades; solo debes multiplicar el tamaño por el factor.


ldpi: imagen de 36 X 36 no es necesario proporcionar esta imagen ya que Android escalara hacia abajo las imágenes que hayas proporcionado para un grupo de mayor densidad.

mdpi: imagen de 48 x 48
hdpi: imagen de 72 X 72
xhdpi: imagen de 96 X 96
xxhdpi: imagen de 144 X 144




Tamaño de la pantalla: Este es el segundo punto, que veremos en la segunda parte de este post.

Instalación NodeJS

Ingresamos a la página oficial de NodeJS donde lo descargaremos  https://nodejs.org/en/download/ Escogemos el instalador que se ajuste a ...