Buzzword Buster — Dependency Inversion Principle

Def­i­n­i­tion:

Depen­dency Inver­sion Prin­ci­ple refers to a spe­cific form of decou­pling aimed at rend­ing high-level mod­ules inde­pen­dent of the low-level mod­ules’ imple­men­ta­tion details. Its prin­ci­ple states:

  • High-level mod­ules should not depend on low-level mod­ules, both should depend on abstractions.
  • Abstrac­tions should not depend upon details. Details should depend upon abstractions.

Depen­dency Inver­sion Prin­ci­ple is often talked about in con­nec­tion with Inver­sion of Con­trol or Depen­dency Injection.

Pur­pose:

Even in N-tiered appli­ca­tions you can often find tight cou­pling between the dif­fer­ent lay­ers, usu­ally from upper to lower lay­ers but not vice versa. For exam­ple, whilst your busi­ness layer might be inti­mately famil­iar with and depen­dent on your data access layer, the reverse is not true. This how­ever, still rep­re­sents a cou­pling prob­lem and it:

  • makes changes to the data access layer more dif­fi­cult as it might require changes to the busi­ness layer (rip­ple effect)
  • makes it hard to unit test the dif­fer­ent lay­ers in isolation

Depen­dency inver­sion (and decou­pling in gen­eral) allows soft­ware archi­tects to design their sys­tems with greater flex­i­bil­ity by loos­en­ing up the depen­den­cies between the dif­fer­ent lay­ers of their system.

Part­ing thoughts…

  • Cou­pling is like radi­a­tion, there are harm­less back­ground cou­pling every­where (say, the core .Net libraries!), but expo­sure to tight cou­pling across the ser­vice boundaries/between inter­con­nected mod­ules in your appli­ca­tion can be haz­ardous! With that said, with­out any cou­pling your sys­tem is as good as useless.
  • Tight cou­pling restricts a system’s abil­ity to change in an indus­try where the only con­stant is change!

Fur­ther reading:

Loosen Up – Tame Your Soft­ware Depen­den­cies For More Flex­i­ble Apps (MSDN arti­cle by James Kovac)

Robert C. Martin’s arti­cle on Depen­dency Inver­sion Principle

Design Pat­tern – Inver­sion of Con­trol and Depen­dency Injec­tion (by Shiv­prasad Koirala)

Share
January 4, 2010 | | Tags: , , , | 1 Comment »

Buzzword Buster — IoC

Def­i­n­i­tion:

Inver­sion of Control (IoC) refers to the inver­sion of the flow of con­trol (the order in which indi­vid­ual state­ments, func­tion calls, etc. are exe­cuted) in a soft­ware. You’ll often hear the term Hol­ly­wood prin­ci­ple being men­tioned in the same breath as IoC, it sim­ply states “Don’t call us, we’ll call you” which more or less sums up the prin­ci­ples of IoC.

Pur­pose:

In tra­di­tional soft­ware design, the flow of con­trol is gov­erned by a cen­tral piece of code which often have to address mul­ti­ple con­cerns (log­ging, val­i­da­tion, etc.) and need to be aware of the imple­men­ta­tion details of its depen­den­cies. This cre­ates a very tightly cou­pled appli­ca­tion where changes in one com­po­nent have a rip­ple effect through­out the rest of the application.

Fol­low­ing the prin­ci­ples of IoC can help you achieve:

  • decou­pling of exe­cu­tion of a task from imple­men­ta­tion (through the use of interfaces)
  • greater sep­a­ra­tion of con­cerns (each com­po­nent only focuses on what it’s designed to do)
  • more flex­i­bil­ity (imple­men­ta­tion can be eas­ily changed with­out any side effects on other components)
  • more testable code (enables the use of stubs/mocks in place of con­crete classes intended for production)

Advan­tages:

  • Sim­pli­fies the build­ing of spe­cific tasks.

Dis­ad­van­tages:

  • Has the poten­tial to make the flow of con­trol in an appli­ca­tion more com­plex, and there­fore mak­ing it harder to follow.

Part­ing thoughts..

  • Mis­us­ing or abus­ing IoC can result in Mac­a­roni code.
  • IoC is not a sil­ver bul­let for all your sys­tem engi­neer­ing prob­lems, and remem­ber, “Don’t fix what’s not broken”
  • When adopt­ing IoC, there is addi­tional train­ing needs for new join­ers to the team.
  • Design sys­tems for flex­i­bil­ity, which allows quick adap­ta­tion to chang­ing environment/requirementsimage
  • Avoid com­pli­cat­ing sys­tem design by try­ing to be future-proof upfront, you can’t pre­dict the future! image

Fur­ther readings:

.NetRocks show 362 — James Kovac Inverts our Control!

Loosen Up — Tame Your Soft­ware Depen­den­cies For More Flex­i­ble Apps (MSDN arti­cle by James Kovac)

Design Pat­tern — Inver­sion of Con­trol and Depen­dency Injec­tion (by Shiv­prasad Koirala)

Share
| | Tags: , , , , | No Comments »