As an exercise, I tried to rewrite the multiple-fade code in OO style. Probably wastes some ram bytes and some cpu cycles, but the main sketch looks indeed more elegant, or at least more concise
This is the sketch:
#define ARY_LEN(a) (sizeof(a)/sizeof(a[0]))
#include <LiquidCrystal.h>
#include "Fade.h"
#include "LcdFade.h"
#include "PwmFade.h"
LiquidCrystal lcd(8, 9, 4, 5, 6, 7);Â Â // nuelectronics lcd-shield v1.1
int numCols = 16;
int numRows = 2;
Fade* faders[] = {
  new LcdFade( 0, 255, 4, 250, true, lcd, 0, 0),
  new LcdFade(100, 200, 10, 300, true, lcd, 0, 4),
  new LcdFade(175, 255, 1, 500, true, lcd, 0, 8),
  new PwmFade(175, 255, 5, 50, true, 3)
};
void setup() {
  lcd.begin(numCols, numRows);
  lcd.clear();
}
void loop() {
  for (unsigned int i = 0; i < ARY_LEN(faders); i++) {
    faders[i]->run();
  }
}
To avoid creating a two-pages long post I've attached the other files.
The main point was encapsulating the fading algorithm in a general Fade class, and leaving the definition of what to do with the fading value to the derived classes. Therefore the Fade class has a pure virtual outFunc(), which makes it an abstract class.
In my previous example I had two "actuation" functions, one that actually drove a pwm pin, and another that printed the value on an lcd. Thus I created two child classes, one for each of those output functions.
Each child class has some additional data members required for the specific "action" it has to perform with the value.
The array of "faders" is an array of pointers to the base class, so inside loop() I can just call "run()" and let the polymorphism figure out which actual function to call.
This code looses the ability to perform two actions with the same fading value. This can be easily changed in different ways. For example the two child classes could be merged into one.
LcdFade.h (600 Bytes)
PwmFade.h (401 Bytes)
Fade.h (529 Bytes)
Fade.cpp (1001 Bytes)