* Doing this will make it easier to shuffle the logic in WatchyRTC to
these other subclasses of AbstractRTC
* I think we may even want to collapse WatchyRTC completely into
AbstractRTC, as the two resemble each other pretty close. We will
see what sort of design we end up with in the meantime
* We are now going to make _rtc a pointer, and use that
process of polymorphism as part of the refactors. Again,
I worry about memory management, but there does not seem
to be a very clear way around this
* I worry about the simple constructors here though. I believe that
causes things to be instantiated on the stack which is then blown
away. That would mean that I would need to rely on the heap with
the new keyword, but if I do that I will need to deallocate later.
* Digging into DS3232RTC, it looks like it has no deallocator, and I
kind of suspect the same for Rtc_Pcf8563. Either way, we will want
to ensure that we can delete those classes where we need to. I
would hate to introduce a memory leak somewhere on something so
small
* My current understanding of the WatchyRTC class is that it came about
due to the need to ship Watchys with new RTC chips. The class here is
designed to accomodate both chips
* This class is a good way of doing just that--a single spot that
hides the implementation details of both chips. The downside to this
approach in the moment is that we have a bunch of conditionals that
check if we have this or that chip, and if we ever need to support
yet another chip, we will have an even more complex WatchyRTC class
* I am going to refactor this to simplify it so that way we will not
have to worry about modifying this much if we need to support a new
chip, or if someone else wants to support a new chip
Andre LaFleur
sqfmi