Hardware abstraction should be by composition rather than inheritance

[jamesmyatt]

Especially since there is a Button class now, the hardware abstraction should be done by composition rather than inheritance. For example, it's not possible to define a Button instance that uses something other than digitalRead to read the state. What do you think?

https://en.wikipedia.org/wiki/Composition_over_inheritance

[thomasfredericks]

Hum, interesting. But how would this be implemented?

[KenwoodFox]

I also want to find a way to do this, id like to be able to define a button instance with an input that is not digitalRead, maybe add in an override?

[thomasfredericks]

@KenwoodFox this can already be implemented. See the source for class Bounce in Bounce2.h.

You can set your custom override for digitalRead : virtual bool readCurrentState() { return digitalRead(pin); }

[KenwoodFox]

@KenwoodFox this can already be implemented. See the source for class Bounce in Bounce2.h.

You can set your custom override for digitalRead : virtual bool readCurrentState() { return digitalRead(pin); }

This is pretty awesome! thanks so much.

[KenwoodFox]

@KenwoodFox this can already be implemented. See the source for class Bounce in Bounce2.h.

You can set your custom override for digitalRead : virtual bool readCurrentState() { return digitalRead(pin); }

Sorry to ask, but where would you implement this? Should this be done for every button instance you create or do i need to make my own button class using inheriting from bounce?

[Thynix]

It isn't a complete replacement because it doesn't have complex debouncing techniques, but the Debouncer library allows passing in the value to use.