Can Python do Factory Method design pattern?

207 Views Asked by At

I did it in C using an array of function pointers. The pointers are randomly accessed and used to call their pointed-to function, which runs a unique animated light pattern in a WS2812B LED strip [using the ADAFruit NeoPixel library]. But, I want to OOP it up [for 1, 'cuz OOP makes it easier to design new animations]!

I tried in C++, but it's been a few decades, so I'm rusty. Which places me at a nexus - do I re-bone up on C++, or use this as incentive to finally learn Python?

That's the why. Here's the what:

Since this runs in a memory meager MCU environment, I want the animation routines to only take as much memory as they need, and then when done, release that memory. So, I want to avoid something like: Instantiating a bunch of animation objects, and loading those into an array, to be indexed at random. That would cram Heap/Stack with the sum of memory needed by ALL the animation objects at once -- which would put a greater constraint on the number of animations that could exist in the MCU [especially since RAM is usually in shorter supply than ROM/PROM].

No, I want to fill that array with something more like pointers to "instantiation" functions, that, when called, instantiate the ONE, selected animation object. And, then, when that animation is finished, does a "delete"/stimulates destructors/etc. so memory is exactly cleared [i.e. no memory leaks].

My C++ implementation is riddled with memory leaks [no memory management in C++] -- though, far less than when I started, so I'm getting better [a little Monty nod, there].

So... do I continue my pursuit of the restoration of my C++ magnificence [I was once a "go-to expert"], or do I dump C++ and take up Python? The only tipping point is: CAN PYTHON DO THE JOB?

OK, another tipping point might be my fondness for Operator Overloading ;)

BTW: The MCU I'm currently using is the SeeedStudio XIAO, which is a fast and ferrous little bugger, so, even if Python is a bit more dilatory than C++ [because of the extra overhead], no worries [much?].

0

There are 0 best solutions below