Programacion orientada a objetos arduino

Programacion orientada a objetos arduino

Programacion orientada a objetos arduino

clase de arduino

El objetivo del tutorial será encender el LED 1 y 3, y apagar el LED 2 y 4 cuando se pulse el botón. Cuando el botón no esté presionado haremos lo contrario: apagar el LED 1 y 3, y encender el LED 2 y 4.
Con la clase Led podemos ocultar todas las cosas de Arduino sobre los pines digitales. Ten en cuenta que el objeto debe ser creado en el ámbito global si quieres ser capaz de utilizarlo en las funciones setup() y loop().
La POO es genial para la reutilización. ¿Recuerdas que añadimos 4 LEDs al principio del tutorial? Bueno, ahora que tenemos una clase para un LED, sólo tenemos que crear objetos adicionales, toda la implementación ya está hecha.
El código anterior funciona bien, pero todo está en el mismo archivo. Queremos utilizar la POO para la reutilización, modularidad, legibilidad, etc, pero es imposible si escribimos todo el código en un solo archivo. A medida que tu programa crece en complejidad, también lo hace la longitud de tu código, hasta que llegas a un punto en el que el código es tan largo que pasas más tiempo encontrando cosas y arreglando errores en lugar de añadir nuevas funcionalidades.

polimorfismo en arduino

La plataforma Arduino funciona con C++ y con ello vienen todos los pros (y contras) del lenguaje. Uno de esos pros es el uso de clases y, en general, la codificación orientada a objetos. Este artículo pretende guiarte en la creación de tus propias clases de Arduino que pueden hacer tus bocetos más eficientes.
Aquí class es una palabra clave y <nombre de la clase> es el nombre que asignas a tu clase. El <modificador de acceso> define los miembros y es privado, público y protegido. Estos modificadores de acceso se definen como:
Por último, los miembros son variables o funciones. Si no están definidos, los miembros reciben un modificador de acceso privado. Esta es la principal diferencia entre los structs y las clases porque en los structs (estrictamente en C++), los miembros son públicos por defecto.
En la versión anterior de nuestra clase, esta variable se utilizaba para definir dónde se conecta el LED. Pero como ese número de pin es ahora parte del constructor, sólo los miembros de la clase utilizan la variable pin. Por lo tanto, ahora es un miembro privado.

objeto de la clase arduino

hay menos bolas en el aire mientras codificas. Una vez que escribes una función y la haces bien, ya no tienes que pensar en lo que hay en esa función: sólo la usas para lo que hace. Otra característica muy importante es que este aislamiento de trozos de código hace que sea mucho más fácil para los equipos de programadores construir algo.
Releyendo esto después de no haberlo visitado durante unos meses, hay algo que merece la pena destacar en esta sección. El comentario «ahora que tenemos una cosa que puede hacer clic en la cosa clicky». No digo «tengo una función» para hacerlo o «venga código» para hacerlo. Tengo una cosa para hacerlo.
Cuando codificas a la manera OO, una vez que has construido un objeto procedes a pensar en él como una caja negra. Es como conectar un circuito integrado a un circuito. Fíjate en que ningún código del faro se ocupa del pin en absoluto: el faro ni siquiera guarda el valor de brightnessOutAttach. Depende por completo de brightnessClicker para tratar con él.
Headlamp no «piensa» en brightnessClicker en términos de pines, tiempos, estado interno. Todo lo que sabe es que brightnessClicker es una ClickQueue, lo que significa que puedes añadirle tantos clics como quieras y que puedes cancelar todos los clics en cualquier momento. Eso es todo. Lo cual es bueno. El objetivo de encapsular el código y el estado en una clase es que una vez que hayas escrito (¡y probado!) ClickQueue puedas descargar de tu tren de pensamiento actual todo el diseño que hiciste sobre su funcionamiento. Lo único que te tiene que importar a partir de ahora es lo que hace.

variable del objeto arduino

hay menos bolas en el aire mientras codificas. Una vez que escribes una función y la haces bien, ya no tienes que pensar en lo que hay en esa función: sólo la usas para lo que hace. Otra característica muy importante es que este aislamiento de trozos de código hace que sea mucho más fácil para los equipos de programadores construir algo.
Releyendo esto después de no haberlo visitado durante unos meses, hay algo que merece la pena destacar en esta sección. El comentario «ahora que tenemos una cosa que puede hacer clic en la cosa clicky». No digo «tengo una función» para hacerlo o «venga código» para hacerlo. Tengo una cosa para hacerlo.
Cuando codificas a la manera OO, una vez que has construido un objeto procedes a pensar en él como una caja negra. Es como conectar un circuito integrado a un circuito. Fíjate en que ningún código del faro se ocupa del pin en absoluto: el faro ni siquiera guarda el valor de brightnessOutAttach. Depende por completo de brightnessClicker para tratar con él.
Headlamp no «piensa» en brightnessClicker en términos de pines, tiempos, estado interno. Todo lo que sabe es que brightnessClicker es una ClickQueue, lo que significa que puedes añadirle tantos clics como quieras y que puedes cancelar todos los clics en cualquier momento. Eso es todo. Lo cual es bueno. El objetivo de encapsular el código y el estado en una clase es que una vez que hayas escrito (¡y probado!) ClickQueue puedas descargar de tu tren de pensamiento actual todo el diseño que hiciste sobre su funcionamiento. Lo único que te tiene que importar a partir de ahora es lo que hace.

Acerca del autor

admin

Ver todos los artículos