Re: Disadvantages of Dependency Inversion?

On Jun 14, 5:49 am, Mark Nicholls <Nicholls.M...@xxxxxxxxx> wrote:
On 14 Jun, 13:42, nas <nas...@xxxxxxxxx> wrote:

On Jun 13, 6:17 am, c...@xxxxxxxxx (Christian Brunschen) wrote:

In article <1181362203.286759.92...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,

topmind <topm...@xxxxxxxxxxxxxxxx> wrote:
On Jun 8, 11:57 am, sweetchuc...@xxxxxxxxx wrote:
Nowadays, DI (DependencyInversion) is one of the widely used design
pattern.
It provides several benefits, such as (1) loose coupling between
component (2) effective and easy testing (component testing or unit
testing)

What are the drawbacks or disadvantages of using DI?

Thank you very much for your answer in advance.

I have not seen a good example of it improving software maintenance
outside of device-driver-like applications. Thus, it may only be
useful in narrow or limited domains or contexts.

Actually, I believe you probably have, even though you may not have
recognised it as such, becauseDependencyInversionis used almost
everywhere, though not necessarily in an OO context, and not necessarily
explicitly under the 'DependencyIinversion' name - but usually with
excellent effects.

[ Disclaimer: All of this post, above and below this disclaimer, is to the
best of my understanding, and may contain errors and/or inaccuracies,
all of which are entirely unintentional and all of which I am happy to
be corrected on. ]

Fundamentally,DependencyInversionis very simple, and has
absolutely nothing to do with object orientation:

Consider a situation where one subsystem A uses some functionality offered
by subsystem B, and specifically, directly invokes (and thus depends on)
the implementations in subsystem B of that functionality:

A --- depends on the implementation of ---> B

'DependencyInversion' is the process of extracting from B an interface to
the functionality that it offers, but which is agnostic to the
implementation of that functionality in B. Call this interface 'I'. In the
process, we alter A to depend on I rather than on B; we also make B
implement I. So we end up with a situation where A no longer depends on
B, but instead on the interface I; and we have introduced a newdependency
from B onto I, as B now implements I:

A -- depends on some implementation of --> I <-- implements -- B

It is thisdependencyfrom B to I, which goes in the _inverse_ direction
from the original A->Bdependency, that is the source of the 'inversion'
part of the term 'DependencyInversion'. Ultimately, we have broken adependencyfrom A onto B, and replaced it with two dependencies, from both
A and B onto I. Hopefully, 'I' will be much smaller and less frequently
changing, which will mean that the dependencies A->I and B->I are also
easy to maintain. The interface itself serves as the rendezvous point
between different subsystems, which now no longer have to depend on each
other, but instead can have just thedependencyon the shared
interface(s).

We don't need to look around very far to see examples of this.

1) POSIX, for instance, is an interface; Unix applications (subsystem A)
are written to and depend on the POSIX interface (interface I), and
likewise Unix-like operating systems (subsystem B) are written to
implement the POSIX interface. Thus, Unix applications are prevented from
having to depend on the particular Unix-like system they are being written
on, and instead can run on any Unix-like OS that implements the POSIX
interface; this means that applications become easier to maintain, and in
fact can remain unchanged in the face of changes to their underlying OS,
or even replacement of the OS (as long as the new one also implements the
POSIX interface). And from the point of view of the OS, any OS that
implements the POSIX interface immediately gains the capability of running
all the Unix software that has been written to the interface; further,
even if the applications change, the OS doesn't need to; and similarly, as
long as the OS keeps implementing the POSIX interface, it can be changed
without having to check whether any applications break.
This example of course also applies to the Win32 APIs (implemented on
various different versions of Windows, decoupling Applications from the
OS), Apple's Carbon and Cocoa interfaces (again, decoupling applications
from the underlying OS implementation), etc. Both subsystems (A and B)
have become easier to maintain, because they have been decoupled from one
another by the introduction of an interface I between them that they both
depend on.

2) SQL is another excellent and widely spread example. Without a
well-defined interface, any programs (subsystem A) using a relational
database management system (subsystem B) would have to be written to call
the precise functions in the RDBMS that implement the necessary
functionality (selection, projection, etc). Introducing SQL (interface I
in the form of a query language, and a standardised one at that) decouples
programs from the implementation of the RDBMS, allowing portability of
programs between different RDBMS:es, changes to the implementations of a
given RDBMS without disturbing any programs that use it, etc. Again, both
subsystems A and B have become easier to maintain by the introduction of
an interface I between then that they both depend on.

3) Even a high-level programming language could be considered an example
ofDependencyInversionat work. After all, you're introducing an
interface (the programming language) between application programs in
general (subsystem A) and the computer hardware (subsystem B), in such a
way that the programs no longer have to depend on the precise
implementation of the hardware, and the hardware (with the help of a
compiler) can be modified as well (as long as the hardware+compiler
combination still accurately implements the interface, i.e., the
programming language).

All of the aboth examples show theprincipleat work. Neither of those
examples employ OO terminology (or need to be developed in an
object-oriented manner). In all cases, the term 'DependencyInversion'
probably hadn't even been invented. But that doesn't negate the fact that
this is theprinciplebeing used, to excellent effect, in those cases.

And in all of the above examples, there really _is_dependencyinversion
at play. In all cases, Subsystem A is the 'client' of the functionality in
Subsystem B, perhaps initially even the only client, and even the reason
for the creation of subsystem B in the first place (running programs is
the reason for computer hardware to exist; the ability to manage data for
use in applications is the reason for RDBMS:es; the ability to manage
resources for application programs is the reason why OS:es exist); and in
each case, once subsystems A and B existed, with the deendency from A->B,
the interface I was created and inserted between A and B (higher-level
languages were invented to make it easier to program and to not have to
deal with the precise hardware; SQL was introduced to allow applications a
standardized interface to different RDBMS:es; POSIX was introduced to
unify different 'dialects' of Unix and allow software to be portable
between them). And in each case, the positive effects are fairly obvious
and rather difficult to dispute (higher-level language programs are easier
to write than assembly-language ones, among other things specifically
because we don't need to know about the precise processor architecture,
its instruction set, and so on, and if the underlying CPU changes, we
don't need t change the program; we dont need to know how and where
tables and columns are stored in an RDBMS when we use SQL to access it,
and in particular if those details cahnge, we don't care or even need to
know, thus allowing on-disk, in-memory, and other sorts of RDBMS:es to be
used and intermingled freely; Unix programs no longer have to be written
to slightly different variants of sstem calls, but can instead use the
POSIX-defined ones and be much easier to maintain, even across different
Unixen and different versions of them).

As to the use of DI in OO: When subsystems become smaller (such as can be
the case when writing classes in an OO language), and especially if you
are writing code in an incremental sort of manner (such as advocated by
agile development methodologies), it becomes easy to create multiple
subsystems that depend on one another. When programmers find themselves in
such a situation, it is nice to be able to have a succinct phrase that
describes a (possible) solution, rather than having to describe the
details every time (and perhaps getting them wrong). Thus, identifying theprinciple, and giving it the label 'DependencyInversion', means that it
can now be easily referenced and reused, and also helps to increase the
efficiency of any discussion where every participant is conversant with
the term (as any jargon does). But again, this is only codifying an
existing good practice and giving it a snappy name. And it also doesn't in
an way limit the usefulness or applicability of theprincipleonly to a
specific domain (such as OO), as can be seen from the widely-different
examples described above.

So, basically,DependencyInversionis a widely-used pervasive practice,
with many examples of uses with excellent results in a wide variety of
areas.

Best wishes,

-T-

// Christian Brunschen

I agree..every thing you mentioned here. It speaks about the benefit
of "Programming to interface"..my problem is I cant differenciate the
terms "Program to interface" and "DIP".

For the problems like this.. "A --- depends on the implementation of
---> B" we already know the solution "Bring the interface" that is
what "Program to interface" says

Now I want to know what was the necessity of bringing one more term
DIP- Hide quoted text -

none.

- Show quoted text -

none??
[i apoligize if it posted multiple times]

.

Relevant Pages

  • Re: Disadvantages of Dependency Inversion?
    ... Consider a situation where one subsystem A uses some functionality offered ... 'DependencyInversion' is the process of extracting from B an interface to ... POSIX, for instance, is an interface; Unix applications ... implement the POSIX interface. ...
    (comp.object)
  • Re: Disadvantages of Dependency Inversion?
    ... outside of device-driver-like applications. ... by subsystem B, and specifically, directly invokes ... but instead on the interface I; and we have introduced a newdependency ... implement the POSIX interface. ...
    (comp.object)
  • Re: Disadvantages of Dependency Inversion?
    ... outside of device-driver-like applications. ... by subsystem B, and specifically, directly invokes ... but instead on the interface I; and we have introduced a newdependency ... implement the POSIX interface. ...
    (comp.object)
  • Re: Disadvantages of Dependency Inversion?
    ... outside of device-driver-like applications. ... by subsystem B, and specifically, directly invokes ... but instead on the interface I; and we have introduced a newdependency ... implement the POSIX interface. ...
    (comp.object)
  • Re: Disadvantages of Dependency Inversion?
    ... outside of device-driver-like applications. ... by subsystem B, and specifically, directly invokes ... but instead on the interface I; and we have introduced a newdependency ... implement the POSIX interface. ...
    (comp.object)