> The issue is whether the interfacing technique adds in non-essential coupling. A technique that has at least the constraints of another technique will also have trivially have at least the non-essential coupling of the other technique.
I'm not sure exactly what you mean. Could you elaborate please?
I'll clarify my view with an analogous example: you can think of a
database as having a set of types - its schema. Think of each of the
applications that use that database as also having its own set of
types - its classes or data structures in general. Now, an example of
the "mechanism" I mean is that SQL provides a way for each app to
translate data in the database's schema into its own data structures.
If its data structures change, the SQL can change to adapt to that;
similarly, if the DB's schema changes, it can also adapt by changing
SQL (or even creating a virtual schema with another layer of SQL - a
view). Of course, this only works if these are only changes of the
representation of the information, and the information content itself
is the same. If the information changes, in a way that the DB or an
app depends on, then there's no avoiding that dependency.
A similar example are JSON/XML API's, where the JSON/XML is like the
DB, and the data binding code is like SQL. The "type" of XML is often
explicitly defined with an "XML Schema" document; JSON doesn't usually
have that, but it is of an implicit expected form - which is still a
type, just informally defined. There are also tools for converting
between XML types - XSLT, and may GUI "XML mappers" that display two
xml schema and let you draw lines between them.
tl;dr These enable "modules" with different types to interoperate
without dependency. Each defines its own types at its own boundary,
and so can be compiled independently. The middleware glue
(SQL/databinder/XSLT/datamapper) facilitates interoperation by
converting between types at the respective boundaries of two modules -
provided those types are equivalent, i.e. contain the same
information, just in a different schema/type.
Does your concept of "non-essential coupling" include the requirement
of precisely identical types at the boundary? If so, by loosening that
to only require the same information, this mechanism avoids that particular kind
of non-essential coupling.