Implementation Independence Limits

I believe that the concept of simple implementation independence is myth. It tends only to work in things like simple device drivers because a device must handle all or most of a given interface in order to be labeled "compatible". In other words, it can work if the builders of an implementation purposely set out to satisfy a given set requirements. Often that luxury is not available. We have to fit somebody else's world instead of the other way around.

The set of features that A implements may not be the same as B's implementations. If our generic interface expects feature X, but B does not implement feature X, then we have a complex conundrum.

For a simple example, lets say our interface assumes a color printer. However, what if printer B does not implement color. It might try bold or different shades of gray as an approximation, but that may not be appropriate for all situations. If you have a document that says, "See the red lines in the diagram", the reader will be confused.

A workaround might be to display a pop-up box that says, "Sorry, color is not implemented. Do you want a gray-scale approximation? (Yes) (No - quit print job)". For simple situations this may be appropriate, but what about something like an SQL database server? It could give the user a message like, "Sorry, SELECT statements can only be nested up to 3 levels on this server. Do you want to ignore levels past 3, or quit the operation?" We cannot expect the end user to know if a truncated SQL statement will give them a usable result. Nor may they know what exactly is being "quit" if they opt out. Further, what if this is a batch job with no human operator present?

Perhaps our ApplicationProgrammingInterface could emulate features not supported by specific implementations? However, if we are going to implement so much stuff, we perhaps might as well implement our own database server from scratch so that we don't have to deal with all those different vendors and variations to begin with. (Or perhaps require usage of an open-source database system.)

OperatingSystems, database systems, and UserInterfaces tend to be complex and different enough that similar such issues will raise their ugly head all the time. One-size-fits-all substitutions are generally not sufficient. A usable substitution or approximation for one situation may be a disaster in another.

See SeparateInterfacesFromImplementation.