Using IoC as a pure design pattern?
Ke Jin
Let me have this followup separately.
Ke
On Mar 22, 3:34 pm, seas seas <seasm...@gmail.com> wrote:
>
> From my point of view, IoC is an excellent pattern. It decouples logic
> inside application from each other. This opens the way to extensive
> unit-testing. And this means, IoC can be used as a pure design pattern
> without dynamic configuration feature. And that is highly desired.
>
>
Most people took the same vision as in your word above for grenteed.
Unforturnately, in my opinin, this mainstream description is
fundamentally WRONG:
Firstly, IoC is not to decouple cohesive objects but to decouple these
objects from the container (and vice versa). Loose coupling between
cohesived objects has long been supported by OO languages through
abstract classes or interface inheritance. Such loose coupling is
orthogonal to IoC. It is obviously wrong to believe that it was IoC or
DI design pattern enabled such loose coupling (or decoupling).
Secondly, IoC is also orthogonal to the ability of unit-testing.
Namely, it neither increases nor descreases the unit-testability. I
see no reason that one can only use mock service in IoC/DI design. In
fact, as service lookup has lower lifecycle coupling between cohesive
beans, it is more ideal for applying mock services for unit-tests.
Thirdly, IoC containers are not to facilitate the IoC design pattern
(i.e to help programmers writing code in this design pattern).
Instead, it is IoC design helps these containers to decouple
themselves from their beans and vice versa. Therefore, it does not
make sense to have an IoC design without IoC container. This is just
like it is four-wheel-driver helps the car, instead of car for four-
wheel-driver. It would make no sense to have a four-wheel-driver
design without a car.
Finally, there is no such thing as "IoC design pattern" or "DI design
pattern". The name of "design pattern" here is the biggest misleading
hype. Passing object references as method/function parameters is a
basic feature of OO languages. How could it become a design pattern in
using these language? Should interface inheritance, polymophic,
dynamic binding, etc. also be referred to as design patterns when one
using Java or C++?
With above list of "NO NO NO", one may ask what IoC containers are
"YES" (i.e what they are actually for?). In a short answer (and quick
summary), IoC containers is to:
1. have all plumbing logic of cohesive objects orthogonal and agnostic
to the implementation of these objects.
2. be able to perform such plumbing declaratively from a central
point.
3. enable a data integration approach for external applications to
generating and manipulating these plumbing logic.
Regards,
Ke
>
> > Best regards,
> > Ke
>
> Regards,
> Andrey