Explanation
Scenario 1
You work in an organization where you and your colleagues tend to travel
a lot. Generally you travel by air and every time you need to catch a
flight, you arrange for a pickup by a cab. You are aware of the airline
agency who does the flight bookings, and the cab agency which arranges
for the cab to drop you off at the airport. You know the phone numbers
of the agencies, you are aware of the typical conversational activities
to conduct the necessary bookings.
Thus your typical travel planning routine might look like the following :
Decide the destination, and desired arrival date and time
Call up the airline agency and convey the necessary information to obtain a flight booking.
Call up the cab agency, request for a cab to be able to catch a
particular flight from say your residence (the cab agency in turn might
need to communicate with the airline agency to obtain the flight
departure schedule, the airport, compute the distance between your
residence and the airport and compute the appropriate time at which to
have the cab reach your residence)
Pickup the tickets, catch the cab and be on your way
Now if your company suddenly changed the preferred agencies and their
contact mechanisms, you would be subject to the following relearning
scenarios
The new agencies, and their new contact mechanisms (say the new agencies
offer internet based services and the way to do the bookings is over
the internet instead of over the phone)
The typical conversational sequence through which the necessary bookings get done (Data instead of voice).
Its not just you, but probably many of your colleagues would need to
adjust themselves to the new scenario. This could lead to a substantial
amount of time getting spent in the readjustment process.
Scenario 2
Now lets say the protocol is a little bit different. You have an
administration department. Whenever you needed to travel an
administration department interactive telephony system simply calls you
up (which in turn is hooked up to the agencies). Over the phone you
simply state the destination, desired arrival date and time by
responding to a programmed set of questions. The flight reservations are
made for you, the cab gets scheduled for the appropriate time, and the
tickets get delivered to you.
Now if the preferred agencies were changed, the administration
department would become aware of a change, would perhaps readjust its
workflow to be able to communicate with the agencies. The interactive
telephony system could be reprogrammed to communicate with the agencies
over the internet. However you and your colleagues would have no
relearning required. You still continue to follow exactly the same
protocol as earlier (since the administration department did all the
necessary adaptation in a manner that you do not need to do anything
differently).
Dependency Injection ?
In both the scenarios, you are the client and you are dependent upon the
services provided by the agencies. However Scenario 2 has a few
differences.
You don't need to know the contact numbers / contact points of the
agencies – the administration department calls you when necessary.
You don't need to know the exact conversational sequence by which they
conduct their activities (Voice / Data etc.) (though you are aware of a
particular standardized conversational sequence with the administration
department)
The services you are dependent upon are provided to you in a manner that
you do not need to readjust should the service providers change.
Thats dependency injection in “real life”. This may not seem like a lot
since you imagine a cost to yourself as a single person – but if you
imagine a large organization the savings are likely to be substantial.
Dependency Injection in a Software Context
Software components (Clients), are often a part of a set of
collaborating components which depend upon other components (Services)
to successfully complete their intended purpose. In many scenarios, they
need to know “which” components to communicate with, “where” to locate
them, and “how” to communicate with them. When the way such services can
be accessed is changed, such changes can potentially require the source
of lot of clients to be changed.
One way of structuring the code is to let the clients embed the logic of
locating and/or instantiating the services as a part of their usual
logic. Another way to structure the code is to have the clients declare
their dependency on services, and have some "external" piece of code
assume the responsibility of locating and/or instantiating the services
and simply supplying the relevant service references to the clients when
needed. In the latter method, client code typically is not required to
be changed when the way to locate an external dependency changes. This
type of implementation is considered to be an implementation of
Dependency Injection and the "external" piece of code referred to
earlier is likely to be either hand coded or implemented using one of a
variety of DI frameworks.
Benefits
- Dependency Injection enables user to write loosely coupled code
- Dependent object give up control of managing their dependencies and instead let a Composition Root inject the dependencies into them.
- DI + Repository + Programming against Interfaces overall help in separation of concerns and greatly improves the overall application maintainability.
- No Framework is required to do the changes.
Practical Examples:
MEF, Rhino, Spring etc.
Conclusion:
Use the principle intelligently.
No comments :
Post a Comment