Quote:
Originally Posted by
Firefly7475 
If you gave me code with multiple switch statements 100 cases long that needed to be updated whenever a new hardware/software combo was released I'd either cry or slap you up side the head. Probably both
Every problem has a solution... and the strategy pattern is strong in this one my child.
Just because there is at least one difference between a pair to switch between doesn't mean there are 100 differences in every place. Your example is theoretically the worst case, but so unlikely as to be laughable. Worthless to use except as a poor means of trying to make the problem appear smaller than it is.
That's hardly the kind of mistake I would expect an "elder" to make if they actually stopped long enough to think it through or had any actual experience dealing with the messiness of real variable hardware. Kinda glad an "elder" like you isn't working for a "child" like me, because it's a sad thing when the "elder" shows the "child" disdain for solving the problem by trying to be trite and overbearing. Shall we dispense with the poorly executed place-putting, screw our heads back into place and actually examine the problem rather than try to be cutesy?
The real problem is you have small differences all over the place. And those differences will often have cross dependencies. Maybe you can cover many of them via the strategy pattern, but those cross dependencies will make it difficult to get the rest cleanly; now you are back to adding conditionals or switch statements anyway. It's a mess. And now project how many combinatoric combinations of strategy based classes and methods you might need. Gee that might even entail a ton of duplicated code if we are't careful -- man, now we have to encapsulate more code out of the strategy satisfying duplicates into another set of classes. It does not take long for a blind application of patterns to generate an architectural nightmare where you can't keep track of what's doing what. When you have LOTS of special cases to handle it's never as simple as the solution you propose reads. You tradeoff pure OO-design which may be generating architectural messiness against the smaller and less invasive special casing.
Assess which makes the most sense where and then implement (usually both flavors) in a mess like this. There isn't an architecture or pattern book anywhere on Earth that will tell you otherwise -- they all tell you that you have to use you head, not always blindly follow a textbook pattern where it doesn't fit well.
And just the fact you have to whip out the strategy pattern (or any other pattern) not to support your core functionality (where it would make sense) but to handle low level deficiencies in the hardware abstraction layer, to do so in multiple places and
-- to support a generic app written against one operating system -- says you have a fragmentation issue going on.
Desktop game developers complain about this at times with the various GPUs they need to support. But at least they are already dealing with a voluntary and easily changeable piece of hardware so the fragmentation is acknowledged and embraced by them before they even start. CUDA and OpenCL are growing together and starting to look a lot like an "uber" OpenGL, all to reduce that hardware fragmentation exposed at the application level. Even then the games devs only deal with maybe a dozen well publicized feature lists and the dev is the one that gets to choose which profiles they want to support. In the Android phone biz, you are stuck with all 100+ of them or you get a black eye fast.
