Interface Classes in arduino

I want to develop a library which will have extendable methods but standard format. That can be done using an interface class. For example I have a communication interface which can send and receive data. I'll be using the same class to communicate over UART and SPI (with their own defined methods). If someone wants to define a method for one wire, he'll be able to define his own method in standard communication class. Similarly if i have a class for storage which can load and store data, i might have a pre-defined method of handling on chip memory but if a developer wants to extend it for an SD card, he should be able to define his own method.

Now the question is, that is it a good practice to use interface classes in small embedded systems with prog memory of 1 MB or lesser?

Are there any examples of platforms where this has been done and shows the standard ways?

Does arduino IDE itself uses any such approach?

Are you sure that this "interface" is part of standard C++?
A bit of googling make it look like a Microsoft extension...

A bit more googling, and it looks like an "interface class" is more of a principle than a keyword (although microsoft has apparently added a keyword as well.) A C++ "Interface class", also known as an "abstract base class", is a class that defines virtual methods with no base class implementation ("pure virtual method")

Virtual methods are somewhat frowned upon on very small microcontroller because they consume RAM for the function pointers, and it is relatively intensive to do the indirect function call (uses a specific highly in-demand register, requires several instructions to assemble the (at least) 16bit pointer from 8bit memory, etc. (although perhaps compiler optimization comes into play.)
On an ARM like Zero or Due, I don't think I'd worry about it very much. Within reason.

The Arduino core has several classes with some pure virtual methods (Stream and HardwareSerial, for instance.) I don't know if they're specifically implemented as "interface" classes (I'm not sure I could tell!) I've had reason to doubt that they're designed as well as the could be (But I'm not sure I'm understanding how things should be...)

Your particular effort may run into a realization that a UART and SPI are not as similar as you thought...

westfw:
Your particular effort may run into a realization that a UART and SPI are not as similar as you thought...

I had the thought one day, why can't SPI inherit from Stream like Serial and Wire do? I spent a few minutes getting started on it before I realized pretty quick why it just can't.

(In particular, SPI is master-driven - the only way you can receive data from the SPI "slave" is to send data simultaneously.)